5 ms·
Back in 2012 when I was sure I wanted to master some dialect of Lisp but wasn't sure which one yet, I read about 80% of Practical Common Lisp before I noped the
by sdegutis 11y ago
Back in 2012 when I was sure I wanted to master some dialect of Lisp but wasn't sure which one yet, I read about 80% of Practical Common Lisp before I noped the heck out of there. The whole reason I was drawn to Lisp was for its semantic and syntactic purity, simplicity, and consistency, and out of the three popular Lisps at the time, CL felt like it had these the least. Ultimately I ended up going with Clojure after a year of flirting with various Schemes.
- mbrock 11y agoI don't think purity and simplicity are virtues of Common Lisp. It's more of a pragmatic, industrial, old language, meant to unify the competing dialects back in the 1980s.
- hga 11y agoOld as in so old, its goes directly back to the first LISP, which was implemented as FORTRAN subroutines which ran on a vacuum tube computer, the IBM 704, which was, at least, advanced enough to use magnetic core memory. Scheme rethought a number of things with the experience of a couple of decades in developing languages, and Common Lisp included one of its breaking changes, lexical scope (I think Gnu Emacs Lisp and AutoCad's AutoLISP are the only widely used dialects with dynamic scope, and they're obviously not primarily language implementations).
- duncanawoods 11y agoI have tried lisps looking for the famed syntactic purity but I didn't really find it. For example, following the little schemer books, they don't print scheme as the actual ascii you need to type, instead they use typography like bold, italic and greek symbols that you have to replace with the uglier reality to distinguish between things like s-expr from lists. It feels like they are embarrassed by the cludgy real syntax, so they hide it and push the difficulty on to the reader. To give clojure a whirl, I was prepared for lispy paren extravagance but when translating a small program to my best guess at idiomatic clojure (I'm sure I failed) there were so many non-s-expr syntactic special cases for things like list comprehensions and common macros that the result felt like it was jealous of non-s-expr languages and didn't actually want to be a lisp. In truth, I believe a strong contrast between different syntactic elements helps readability, so I don't think the s-expr regularity I expected is something I actually want.
- undershirt 11y ago> ... they use typography like bold, italic and greek symbols that you have to replace with the uglier reality to distinguish between things like s-expr from lists. My main complaint with Scheme is that it's hard to distinguish a "call" from a plain list. For example, in `(let ((foo 1) (bar 2)))`, `let` is a call, but `foo` and `bar` are just being assigned, not called. Clojure uses `(let [foo 1 bar 2])`, so you can tell that `let` is a call, but `foo` and `bar` are now unwrapped and placed inside square brackets to signify plain data, not a call. > To give clojure a whirl, ... there were so many non-s-expr syntactic special cases for things like list comprehensions and common macros Everything is still an s-expr. The square and curly braces still follow the same rules, but they just mean they are not "calls" like parens would normally signify. For a list comprehension example: `(for [m messages] (str m))`, `for` and `str` are calls and `[m messages]` is just data. It could be unwrapped like `(for m messages (str m))`, but it's wrapped in square brackets as a visual indicator for what's important. But if it was wrapped in parens like in Scheme, it could be confused as a "call". Clojure is very well-designed to solve visual problems of Scheme and other Lisps. I recommend looking at it again :D
- jwdunne 11y agoFrom what I can tell, Scheme (or it may be a Racket thing) allows the use of square brackets - this aids in readability greatly. There is no type difference as there is in Clojure.
- goldfeld 11y agoWith the downside being inconsistent style across the community, making for more overhead when reading code (see also macro abuse). Scheme has bigger fragmentation problems anyhow.
- dwc 11y agoI sympathize. Different concerns pull lisp in different directions. CL is, and always has been, about getting stuff done and isn't above having some warts, especially historical warts. Scheme was more academic and elegant, but not great for real world use until some implementations "fixed" that. Racket, for instance, isn't quite a proper Scheme any longer, but is definitely practical. Clojure looks interesting, but I have absolutely no need or desire to use a JVM-based language.
- KingMob 11y agoMaybe give it another look sometime? You rarely have to interact with the Java ecosystem if you're not using Java libs, and the JVM != Java. There's also ClojureScript, which is the same, but runs in browsers, Node, etc.
- eudox 11y ago>semantic and syntactic purity, simplicity, and consistency Who wants simplicity? People learning the language, so they have less to learn and a lower cognitive overhead when starting out. People teaching the language, so they have less work. Language implementors, so they have a much shorter period of time between prototype and release of a language implementation. Who doesn't want simplicity? People who've already learnt the language and are proficient with it and use it regularly, having grown accustomed to the features it provides that can't be properly added afterwards as macros or libraries.
- wtbob 11y agoThe Common Lisp standard is definitely neither pure, nor simple, nor consistent, but it is pragmatic, practical and powerful. Scheme is a fun learning toy, but I wouldn't use it for a production system. As for Clojure? I'd like to get around to taking a serious look at it someday, but I do somewhat emotionally & irrationally blame it for stealing the momentum of the Lisp resurgence of the late 2000s. It probably has some good ideas, but it's also pretty radically different from Lisp, which is (under the parentheses) a fairly traditional language.
- scrupulusalbion 11y agoFWIW, PicoLisp[0] is one of those lisp dialects that went way out of its way to be syntactically simple/pure/consistent. Whether this is a good idea, I don't know, but it is nevertheless an interesting example of a modern-made lisp that actually considers less data types (i.e. numbers, symbols and lists) to be a virtue. [0] = https://en.wikipedia.org/wiki/PicoLisp https://en.wikipedia.org/wiki/PicoLisp
- darkseas 11y agoI have been interested in taking PicoLisp for a spin, but I've found the friction of installing on OSX a bit much. Do you know of an easier way to use PicoLisp, without re-hacking gcc back into the system?
- scrupulusalbion 11y agoI have no experience compiling anything on OSX, so I am not sure if I will be very helpful. Looking at the download page, it looks like the OSX version is 32-bit only: "It should compile and run on 32-bit GNU/Linux, FreeBSD, Mac OS X (Darwin) and Cygwin/Win32 distributions, and on 64-bit GNU/Linux systems." Reading through the INSTALL file seems to confirm this. [0] A while ago (2013), some one seems to have gotten a 64-bit version up and running on OSX through make emu (don't know what the emulation option exactly is, so I can't say if it is relevant). [1] [0] = https://github.com/evanrmurphy/PicoLisp/blob/master/INSTALL https://github.com/evanrmurphy/PicoLisp/blob/master/INSTALL [1] = http://picolisp.software-lab.narkive.com/oCd1TRXz/pre-compiled-picolisp-for-centos-cygwin-osx http://picolisp.software-lab.narkive.com/oCd1TRXz/pre-compil...