92 entries in 0.094s
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: he (and just a few more bounty people) are slowly making it through mcclim bugs, while at the same time introducing questionable things. here's a random example that came up while i was googling his name, https://common-lisp.net/project/mcclim/posts/Progress-report-8.html
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: like https://common-lisp.net/project/climacs/images/screenshots/old/swine-ss.png
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: in related http://www.method-combination.net/blog/archives/2017/03/07/nibbles-and-ironclad-releases.html " I will no longer be maintaining nibbles, ironclad, nor any of my other Common Lisp packages"
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: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html this is the canonical document on error handling in common lisp. it's long and dense, because powerful machinery
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: but so that it's not just noise, here's one thing that i used as a jumping point, http://foldr.org/~michaelw/log/programming/lisp/diff-sexp there's also a cmu archive of differs, including a working common lisp diff implementation (with a different output though) http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/tools/src_cmp/0.html
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: gabriel_laddel: https://common-lisp.net/project/closure/
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: (an example is https://gitlab.common-lisp.net/cmucl/cmucl/blob/master/src/compiler/x86/float-sse2.lisp#L1426 x87-set-floating-point-modes prelude with keywords says some handy things about what's being emitted to put it in context, but then (:generator 6 ...) is your regular asm, mov xor ...)
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: the linux approach actually's been done twice, i.e. write something shitty, but it boots and then improve it until it's somewhat ok. there's https://common-lisp.net/project/movitz/ and https://github.com/froggey/Mezzano
phf: i probably wrote most code for tbr/shiva, and it was an exercise in rewriting common lisp from scratch
phf: trinque: you're on a book cover blurb ;) https://common-lisp.net/project/mcclim/excite.html
phf: gabriel_laddel wrote a mcclim tutorial https://common-lisp.net/project/mcclim/posts/CLIM-the-galaxys-most-advanced-graphics-toolkit.html
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-07#1477855 << actually research done by ECL people claims that mocl is derivative of this project http://www.informatik.uni-kiel.de/~wg/clicc.html (via https://common-lisp.net/project/ecl/static/quarterly/img/vol4/all-hierarchy.png)☝︎
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: jurov: i've not seen where asdf is deprecated, you looking at this guy https://common-lisp.net/project/asdf/?
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: gabriel_laddel: anything that https://common-lisp.net/project/cmucl/doc/clx/ doesn't answer?
phf: oh, man, another fukamachi project (re quickutil). guy works for a tokyo ad startup, generates massive amounts of web dev style common lisp code. he's behind http://log.bitcoin-assets.com/?date=19-11-2015#1327538 ☝︎
phf: sucks that he ended up writing book on sgml, but not on common lisp
phf: asciilifeform, ben_vulpes, adlai: edi weitz (cl-ppcre, hunchentoot, flexi-streams rest of ediware) published a book of common lisp recipes http://www.amazon.com/o/asin/1484211774
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: punkman: mcclim itself has a handful of examples, but https://common-lisp.net/project/climacs/ and https://common-lisp.net/project/gsharp/
phf: can use http://shinmera.github.io/qtools/ for Qt work from common lisp. adds a thin protective layer
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
phf: https://common-lisp.net/project/closure/ for the curious
phf: BingoBoingo: i use that ibook for mac os 9 now, with kaleidoscope, hypercard, mcl (macintosh common lisp). i boot it up from time to time and it feels like the cyberpunk future that never was
phf: a good common lisp book to have in addition to keene's clos book is AMOP http://www.amazon.com/The-Metaobject-Protocol-Gregor-Kiczales/dp/0262610744
phf: in practical terms, common lisp quirks are direct result of underlying machine level architecture
phf: i think "minimal set of common lisp primitives" is a common theme on #lisp, not surprisingly with different answers every time
phf: i'm not one of those people you're arguing against, i like cl standard just fine. i did paid common lisp consulting on and off for the past 10 years.