106 entries in 0.242s
phf: i was very much insulated from open sores
lisp with acl, just sort of assumed that they were all basically the same. turns out that
common lisp world is a cargo cult. for when spec was never supposed to be and all be all: it was a _thin_
common ground of a variety of rich
lisp ecosystem. writing _just_ to spec is an exercise in frustration..
phf: it's a compatability layer between
lisp machines, and as such provides a minimum of coverage of
common functionality.
phf: well, after reading the CADR documentation, source code and generally spending more time on a
lisp machine, i realized that modern
common lisp is a cargo cult. i'm not sure how naggum didn't see it, but possibly because his
lisp was emacs/cmucl/franz
phf: (in slime C-c C-d h on a standard
common lisp symbol will open relevant hyperspec page for you)
phf: lobbes: hyperspec is first and last documentation you'll need for
common lisp. it's generally a good idea to get a feel of what's where in it. it's the only authority on the expected behavior of your code.
phf: !Qlater tell lobbes not sure that you really need to introduce emacs into the mix, if it's not your first language. an exception in a thread ought to log itself, but you can explicitly hook into debugger machinery and capture it manually:
common lisp has *DEBUGGER-HOOK*, which is documented in hyperspec. sbcl further adds sb-ext:*invoke-debugger-hook*. you should also check that those values are nil after you load your
☟︎ phf: you should know that
common lisp standard is not the whole, but rather the top, i.e. the commonality of features between multiple
lisp machines. there are parts that explicitly under specified to allow for a variety of behaviors
phf: are you talking in the context of tmsr, or your commercial work? i had both of them bought at some point, back in my
common lisp consulting days it was a no brainer, the cost was always a small fraction of the contract, but the technical advantage immense. but then i don't have the source code for many things that i make my food with
☟︎ phf: btcbase (being a sprawling
common lisp beast) has one of the possible solutions actually implemented and working. i'm wrestling the essence of it out, enough to add some kind of graph sorter to vtools
phf: correct approach is of course
common lisp's readtable, but i don't think
LiSP covers that
phf: from that perspective climacs is a better approach:
common lisp as a vm, mcclim as an application authoring framework, climacs as an editor widget
phf: asciilifeform: back then i had slightly different concerns, nor did i build anything that wasn't already built. the whole thing compiles with djgpp, clisp is also available. bulk of the code i wrote was either
common lisp by way of clisp or allegro "games" and visual hacks and such
phf: there's also portable hemlock in
common lisp and edwin in scheme
phf: well in my case btcbase is written in
common lisp, so slime, unless i also rewrite btcbase in elisp
phf: trinque: have you seen
https://masteringpostgresql.com? it's by dimitri fontaine, who's a major postgresql contrib, but he also wrote pgloader, a proggy for etl into postgresql, which he wrote in
common lisp; you get mentions of clos and naggum and such in his book.
phf:
common lisp sidestepped that issue by not standardizing the ffi at all, and there are still hairy parts in all the implementations. there's fundamentally folly in talking to C word, which you have to do on C's terms
phf: right, platonic unicode, i think it was more aligned even with
common lisp's notion of character object or somesuch, than what the spec actually become. i think he might've ranted somewhere about ms fucking it up and such
phf: asciilifeform; first class characters like in
common lisp for one, proper defstruct implementation, also they clarified significantly the buffer structure
phf: asciilifeform: i'm not sure you can even scheme without a bunch of srfi's, the first dozen establish a subset of
common lisp standard
phf: but then i can also understand the whole "back in my day" sentiment.
common lisp certainly lets you write ~very sloppy~ code and get away with it :>
☟︎ phf: please do, it would be useful as a reference, but also for me specifically: btcbase.org/patch is written in
common lisp, but it can only eat vpatches, not spit them out, so a mcilroy would be a solid addition
phf: knuth managed to do a lot to keep tex what it is, given that he's essentially a pacifist academic. there aren't many other examples (
common lisp, ada) where preservation has been taken to this extreme.
phf: source reading can be a preprocessor stage (which is a lot saner to do in
common lisp than elsewhere), this is also how traditional tex handles orclangs, before xetex and luatex and such. special ascii sequences to represent local lang glyphs and if you don't want to write those by hand, you use (or write) a tool that takes a local encoded document and translates it into ascii
phf: none of these are properties of sbcl past certain vintage though though, sbcl is already a modernization of
common lisp phf: note that the redirect says "~most~ of the
common lisp stuff is now on shithub"
phf: "shinmera" is part of the new school of
common lispers who put out reams of code that's basically ffi to c world. nothing wrong with it per se, but from traditional
lisp perspective they are prime wreckers
phf: fwiw all our production
lisp runs on sbcl, including btcbase. as much as i'm pimping cmucl, it's not "modern" enough to host a website on unix. i still think it's a better target for a hypothetical on the iron
common lisp phf: spyked: keep in mind that all the lispers here are
common lisp programmers, so a ~practical~ scripting
lisp would be
LISP-family themed, rather than an explicit scheme. that's my personal experience with trying to get useful things out of shiva: having to write a bunch of "missing" hyperspec functions. asciilifeform said something similar in the past
phf:
common lisp specification defines a memory safe language, yes, but in the crevices of "undefined behavior" you can have memory related exceptions. for example you can define a function with (safety 0) optimization declaration, which will neglect to check the type of a passed argument, which might (and often will) result in a memory exception.
phf: but ffa also doesn't have that many moving parts. it's a single stack mathematical code that mostly operates on same, uniform memory regions. so my original issue was that there's no enough quality code, certainly plenty of shit code, which is not quite the case in
common lisp world
☟︎ phf: well, problem is that there doesn't seem to be much in terms of tasteful ada code available to public. with
common lisp you can go to mid-90s and before and you start getting some very reasonable works, worthy imitation.
phf: for the longest time i thought that
common lisp spec is a magic paper against modernization. not so, and you can see it with the recent evolution of sbcl. for example they made it an error to locally shadow cl package symbols, e.g. (flet ((first (...))) ...) will fail, breaking a lot of reasonable old code. many historic idioms likewise produce compilation warnings, etc.
☟︎ phf: like i said elsewhere, sexp is not a data exchange format, it's a way of writing
common lisp code. various extensions are there to facilitate the process of programming. it's a folly to look at sexp and go "oh, so simple! lets just store our data in it! lets rpc with it too!" because that's not really what it's designed for
phf: so if you want to use
common lisp's readtable/printer for data interchange, you'd better ~specify~ what your sexp actually is
phf: there's ISLISP standard, which was supposed to create a subset of multiple different lisps (like
common lisp and scheme, but also eulisp, since designed by europeans). i don't think anyone (particularly sexp library authors for other languages) ever tried to conform to it. typical solution is to have a JSON-like subset of sexps, so that you can express (FOO "abc" 2), i.e. symbol, string, number and list and nothing else
phf: (
common lisp sexps are backed by a full blown reader, with multiple non-trivial dispatch macros, so for example '(1 #.(+ 1 1) 3) is a valid sexps that's read as '(1 2 3), i.e. (+ 1 1) is evaluated at read time. there's a dispatch for structs, like #S(FOO :A 1 :B 2) results in a structure foo with two slots a and b set to 1 and 2 respectively, but there's no corresponding constructor for classes. there's a reader for arrays, but that one doesn't let you
phf: note that
common lisp's sexps are not an ideal data exchange format
☟︎ phf: i wrote a hilariously bad
common lisp version of fhf
phf: i kind of want to take a stab at doing a
common lisp text only client, but i think i lost my password again, and i'm too embarrassed to ask for another recovery........
phf: asciilifeform: clim fwiw predates micro exodus. was, like
common lisp, an attempt by the three vendors to make a unified gui foundation. you can still see scarring in genera where they started transitioning to clim apps from their flavors
phf: (speaking of
common lisp. asdf the system dependency tool turned from 30k in version 1 into a asdf/uiop 900k monster in version 2. in a systemd move took over most of the compatability packages and is now present ~in every single
lisp distribution~. with the did accomplished, Fare posts the following
http://fare.livejournal.com/188429.html )
phf: fwiw ada is a harsh mistress is an illusion. if it were to become fashionable to write ada among the hacker news crowd, there will be rapid attempts at modernization.
common lisp went through that process
phf: huh, you're right, 2009-12 is 3 clojure to 4
common lisp phf: "lispjobs" that's traditionally a place, where one posts rare and meaty
common lisp and sometimes scheme jobs is now full of clojure work. last one is "clojure and clojurescript web developer"
phf: these days when you say "
lisp" you usually either mean an equivalent of "algol" or "
common lisp" specifically
phf: there's a lineage of
lisp, which is significantly mutually compatible.
LISP, maclisp, interlisp, zetalisp.
common lisp is a standardization attempt on top of those. for example if you take eliza code (written for
LISP 1.5) you can make it run on
common lisp without any transformations (need to provide some missing forms though)
phf: there's was a wip fork of making linux-unix.
lisp talk directly using syscalls without libc. that's probably lowest
common denominator
phf: it opens with enough of
common lisp to be useful, and then goes into actual programming problems. i think it's one of the best programming books in general.
phf: i'm not here to ~defend~
common lisp, i made an analogy that didn't stick
phf: another take on this might be
common lisp vs scheme. cl was standardized after the fact, existed and evolved on
lisp machines. i'm looking at mit's cadr at the moment, and at a certain point you have maclisp, interlisp, zetalisp and "
common lisp" all coexisting on the same machine, 10 years before the standard was written. scheme on the other hand was esparantoed for a purpose. the result is that as you move closer to speaking
common phf:
http://btcbase.org/log/2016-12-07#1578953 << just fyi, while you can diff an intermediate ~state~ of an image as a sexp,
common lisp's input is a ~character stream~. builtin dispatch ~mostly~ operates on forms (like #p #. (concatenate 'string "foo" "bar")), but not always, like #\; comment reads till end of line.
☝︎☟︎ phf: ben_vulpes: if you were to use bind everywhere you can use it (e.g. as a replacement for let, destructuring-bind) your code is going to look sufficiently different that it's not clear if you're even programming in
common lisp at that point. makes the result less readable for other cl programmers, and code becomes harder to future proof. the tradeoff is generally seen as not worth it (too intrusive for little payoff)
phf: trinque: that's a nifty wot explorer. are you spitting html from
common lisp or some other tech?
phf: presumably he doesn't have a key, because there's no openpgp implementation in
common lisp...
phf: it's like halfway between
common lisp and elisp
phf: well, then you have a hitler diddled copy, ironclad's tagline always has been "entirely in
common lisp"
phf:
http://paste.lisp.org/display/327488 lamport parachute PoC in
common lisp (it has soft dependency on ironclad for sha256, but otherwise follows the design in that own function can be substituted)
phf: movitz and mezzano are
common lisp compilers, they are just shitty ones. they are good enough to boot an os on x86, but they are missing bits (large chunks of standard) because nobody's written those
phf: i probably wrote most code for tbr/shiva, and it was an exercise in rewriting
common lisp from scratch
phf: or
common lisp music which is a subset of
common lisp to describe a wavelength generation/transformation/composition (i'm pretty sure it was used to do first computer FM synthesis)
☟︎ phf: they had a bunch of appel books there, mead's introduction to vlsi, a bunch of old
common lisp books, 80s expert system books, etc.
phf: Framedragger: despite the rhetoric people here are extremely pragmatic. but when you think about these things there's no reason to allow sloppy thinking. the question is "how much of a dick up your ass is too much dick", and the healthy answer is "none at all". llvm is good technology (it gives you same kind of layering that a decent
common lisp compiler does, but for languages that are not used to that kind of richness, so everyone's excited abou
☟︎☟︎ phf:
http://btcbase.org/log/2016-06-03#1475432 << i've used it, and the wukix people are responsive to feature requests. i think the source is a fork of one of kyoto
common lisp derivatives, probably akcl. fwiw it's the same lineage as gcl and ecl, so ascii's "why not compile ecl" is entirely reasonable
☝︎☟︎ phf: ben_vulpes: to be fair
common lisp tumor is mainly perceptible only to a special kind of basket cases. it is still one of the healthier ecosystems.
phf: fwiw my first exposure to clojure was a clojure job in finance industry, i did a couple of talks on
common lisp within airshot of the hiring person from the team, that was way before 1.0, and we must've been one of the first corporations to use clojure, because hicky made a point of coming to a local tech conference and speaking, i've had beer with him a few times
phf: well, i think anything short of
common lisp is not really a
lisp :P (i.e. reader macros, restarts, pervasive defvar/defparameter clarity, well thought out function library, and such)
phf: from the world of
lisp rot, asdf, the `make' of
common lisp, has been gaining features for a while now to the point that it contains all kinds of crazy shit, like a fullblown cross-
lisp compatibility layer for various file operations, etc. so i pulled version 1.369, last one before faré took over the operations, it is 75kb vs current 560k (which is itself packed from a large repo). not surprisingly it works, but when it doesn't it exposes cockroa
phf: 12 step bot, you could buy PAIP and learn to write one yourself, a cleaned up eliza version for
common lisp is somewhere there in the later chapters
phf:
common lisp doesn't let you redefine +, it does have somewhat sane numeric tower
phf: trinque: yes! that would be handy. i just audited that postgresql
common lisp driver (not the popular one, but the pure network pg one)
phf: re standartization, issue i'm personally running into is that we can drag tinyscheme in the direction of
common lisp or stick to scheme conventions. both have downsides
phf: a curio for the
lisp aficionados
http://mumble.net/~jar/pseudoscheme/ an implementation of scheme in
common lisp forward ported from
lisp machines. a precursor to scheme48, so gets a lot of things right
phf: sucks that he ended up writing book on sgml, but not on
common lisp phf: asciilifeform: you were right re gossip prototype in
common lisp. it was a needless distraction, i spent a long time getting
lisp gpgme bindings working, and the end result was still pos. i'll just send the patches to gnupg ml, and maybe they'll update upstream, but that's not gotten me anywhere closer. i learned that cffi is mostly a mess. (someone worked some improvements on cffi recently, which resulted in cffi documentation being
phf: it's just impressions. i've been looking at a lot of high traction
common lisp code (top quicklisp packages) and there's a lot of senseless turd polishing in the past few years. broken interfaces for the sake of "cleanliness", half baked code, needless macros, dependency hell etc. and then you look at the code and it's the same set of aggressive, google employed queergenders.
☟︎ phf: named loops in
common lisp? i don't actually know the feature
phf: i have some code for gossipd, i'm going to by the spec that's published on trilema, rather then follow up conversation about udp and first packet validation. i wrote enough in c to be able to prime gpg machinery and send packets over the wire (which basically coveres things that i wasn't sure how to do before i started), then i switched to
common lisp to get a prototype up. what came out of that so far is updated bindings for
lisp phf: ben_vulpes: libgpg-error, and share/
common-
lisp is installed with brew version, but
phf: huh, libgpg-error and gpgme come with
common lisp bindings (and only cl) in the standard distribution..
phf: i did technical review for it, which was pretty stressful. barsky is a poliglot and writes with a lot of grahamisms, so i rewrote a lot of bits to make them more "
common lisp", though i don't think i fully reached that goal
phf: trinque: re
lisp rps, you might want to look at cmucl's WIRE and REMOTE packages,
https://common-lisp.net/project/cmucl/doc/cmu-user/ipc.html. while you can send sexps over the wire and slime/swank do it by sending readable forms in netstring format, you start running into issues when you need to ipc opaque blobs, like lambdas, hashtables or clos instances. cmucl's ipc solves all those issues, unfortunately married to cmucl. i think it woul
phf: you could target picolisp from sbcl, same way as you're right now targeting the unix to
common lisp machine abstraction layer, that's written in c
phf:
common lisp specification is written in a such a way that you don't need to know anything about the outside world to fully replicate a ~useful~ computation