Ask HN: Lispers: Which dialect of Lisp do you use and why?
Scheme. The whole "build a language from a small set of well-chosen primitives" really resonated with me.
I tried a bunch of other lisps but disliked them for various reasons. Clojure is nice because of the tooling, but I disliked being tied to the JVM and all what that means.
CL has some very nice implementations (Allegro CL has a limited free version that has forever changed how I think a programming environment should be).
In the end I found guile scheme which is great. The threading situation is good and getting better, the language has all the comfortable srfi's that implementations like chez lack, and it has nice community.
The reason I chose guile over chicken was the r6rs compatibility, which made supporting both chez and guile rather easy. Other than that, I'd say that the chicken community is probably the nicest one online. Chicken is really a fine scheme as well.
I am not a programmer though, and what I want is for programming to be just fun. Not enterprise ready, not web6.0-cool. just fun.
Shameless self-plug: I just finished my racket-like for l-loops for guile: https://bitbucket.org/bjoli/guile-for-loops
Common Lisp, for it's maturity, stability(decades old code still runs on modern implementation) and remarkably good design considering it's a language designed by a committee. Almost all of it's problems or dusty corners that show their age can be worked around by libraries. Not to mention the quality of the spec is great. I really miss the attention to detail the common lisp hyperspec has when I have to read about some obscure corner of python for example.
I also spend some time with clojure around the time of v1.0-1.2 and quite liked it, but it's maturity level and the JVM made it less attractive in the long run.
I like scheme as well, but because of the spartan(to use a nice word) spec, If I actually want to get stuff done I'd have to chose just one implementation and it's associated libraries, rather than rely on portable code.
Scheme.
Simple, strongly typed, and really really easy to write and read.
On top of that, its fairly easy to compile as well, which gets rid of a bunch of distribution problems that come with other Lisps.
My first in-production experience was converting a monolithic Python web app to Scheme.
We wrote a library that brought a lot of Python conventions over to make things easier. Like an import macro that automatically namespaces things. (And we copied Clojure's "->)" macro for closing all open parentheses).
Total conversion for ~18,000 LOC Python to ~7,000 LOC Scheme took about nine weeks. The speed-up was about 2.5x.
And despite the much smaller codebase for Scheme - we actually added a whole heap of features, whilst matching all old features. (A bug or two as well, but that's to be expected).
Scheme is just really well suited to parsing, and rewriting itself as necessary.
So far as I'm aware, that stack is still running three years later, so Scheme wasn't just a fad for the team (who picked it up in about a week or so).
> Total conversion for ~18,000 LOC Python to ~7,000 LOC Scheme took about nine weeks. The speed-up was about 2.5x.
You should really do a blog post on this and submit it to HN! So people could appreciate the real-world benefits of using a Lisp.
What is is about scheme that allows the 18k LOC to be condensed to 7k LOC? I assume there was some culling of excess code, but that's a dramatic improvement.
The biggest improvement was at the parsing/eval side of things.
Because Scheme has something utterly amazing, that I've seen in very few modern languages.
A safe eval function.
Only what you bind to the environment exists, and in the case of null-environment, that's all that gets bound. (There are other environments you can use, or you can prebuild your own easily).(let foo foo (eval '(foo arg) (null-environment)))Scheme also provides string->symbol and symbol->string type conversions, which allow you to do things that are normally next to impossible, though mainly only useful in macros.
That can let you generate let-bindings on the fly, which if you contain them with a safe eval, gives you some really amazing possibilities.
Like parsing and binding URL queries.
Interesting. Which version of Scheme did you use for this? I really mean the "make", like Chez Scheme or some other, not the version number.
Gambit-C. [0]
Development is slower than most, because it's mostly a one-man operation, but it's fast, can statically compile, can make tiny binaries and is mostly compliant, and the dev fixes compliance/bugs fairly quickly.
Docs can be lacking at times, but the code is fairly clear.
Thanks for the info. Cool that one person has done most of it.
Also, it was interesting to see that large-scale real-world software has been developed using it.
http://gambitscheme.org/wiki/index.php/Real-world_software_a...
LFE (Lisp Flavoured Erlang). It's the ideal tool for exploring AI.
Handbook of Neuroevolution Through Erlang by Gene Sher makes a compelling argument (with detailed, varied examples) that Erlang is the perfect language with which to implement neural nets.
Lisp has always been associated with AI, of course. Nowadays it's all Python, Java and R for machine learning, but Lisp can do just as well, plus more: Lisp has an affinity for recursion, and its homoiconicity will - I suspect - prove fundamental for true AI. One can't just 'strap on' its features to those other languages (including Elixir: https://news.ycombinator.com/item?id=7623991).
So, obviously the right tool for the job is LFE!
Common lisp via SBCL. I tried Practical Common Lisp for the hell of it one day, and fell in love with the syntax and macro system once I got the hang of it. I've been using it with Clack to make web applications which is pretty fun.
I use Emacs Lisp for Emacs and Guile Scheme for everything else. I prefer Scheme over Common Lisp and Emacs Lisp, because it is more stream-lined, simpler, and elegant.
I'm very happy with Guile and its performance has greatly been improved with version 2.2 (not that performance was a problem before); one thing I miss in Guile is the picture language that Racket comes with.
I use Common Lisp and TXR Lisp, which is my own dialect. (http://nongnu.org/txr)
Common Lisp is well-optimized for application programming. It has excellent compilers, and good debugging support.
TXR Lisp is geared toward scripting; it is a very agile, ergonomic Lisp dialect. It has minimal dependencies and builds as a single executable with some satellite library files in your /usr/share tree, yet is loaded with features.
TXR Lisp is a Lisp-2, but thanks to a square bracket notation, the coder can seamlessly shift into Lisp-1 style programming with higher order functions. Though it has the equivalent of CL's funcall function and function operator, they are almost never used, and there is no #' (hash quote) notation at all.
I am currently working on the aarch64 (64 bit ARM) port of TXR which I hope to be able to include in version 184.
I started the TXR project around this time of year in 2009, which makes it 8 years old now.
Clojure, with heaps of Clojurescript to manage the Javascript ecosystem.
For over a decade I wrote mainly in C++ doing a lot of Windows programming, usually games or simulations. Mix in some VB and C# when I didn't want to battle the Win32 API. I was used to seeing codebases with 100k+ loc and hundreds of megabytes of code files. xkcd COMPILING is real!
While working at BitTorrent in 2013, a coworker back introduced me to his little server that distributes uTorrent executable to everybody. It was an implementation of this[1] paper for a general purpose rules-based engine with a snappy (Clojurescript?) front-end. The whole thing was ~5k loc, and ran on surprisingly small hardware compared to it's traffic.
From there I was hooked. My project sizes are radically smaller, it's LISP, and I can go wherever Java goes. I wrote about my experiences with AWS Lambdas last year [2], for example. The community itself is outstanding. They are some of the nicest people you will ever meet. Because the community focuses on small libraries that are composable, those libraries become remarkably stable. Several heavily used libraries haven't had commits in months or years.
[1]: http://moscova.inria.fr/~maranget/papers/ml05e-maranget.pdf
This is a really interesting perspective. Do you have any advice for someone looking to get into LISP? Ways to learn, how to learn, etc?
If you're interested in Clojure, I _highly_ recommend /r/Clojure on Reddit. It's very active; several library devs, book authors, and core maintainers frequently post and comment. There's a weekly thread dedicated to new Clojure users ([Latest thread here][1]). The Clojure Slack[6] is even more active if you have a burning question.
If you would like to dip your toes in the water, 4Clojure[2] is an online interactive Clojure Kata. There's also a (nearly) full REPL environment at Try Clojure[3] or repl.it[4]. The Clojure Cheatsheet[5] makes it easy to browse and discover the Clojure standard library, and IMHO is _so_ well organized!
But the biggest part of Lisp is the interactive development. You really have to see it, and I love showing the [Bruce's Figwheel project presentation][7] because it's a very visual demonstration of what hot-reloading code and interactive development can bring. It also helps that he's doing Clojurescript in a live browser for web development.
[1]: https://www.reddit.com/r/Clojure/comments/6tq8f5/new_clojuri...
[4]: https://repl.it/languages/clojure
"Practical Common Lisp", available online. Great book.
Also if you want to have nice silly fun, take a look at "Land of Lisp" which IMHO is destined to become a classic.
racket.
The ecosystem is great. I wouldn't use it for anything big on prod though, but it's easy to experiment with and is fun.
SCAM, because it's mine.
Common Lisp.
It has standarized, well-documented, proven-for-decades way of doing necessary, common day to day stuff like conditions and restarts (aka "exception handling"), package system, or object-oriented-programming. Consider, for example, that Scheme has no standard way of organizing your code into packages and namespaces. Nor standard exception handling system; you are expected to use a lib, use what the particular Scheme implementation you are using offers or roll your own using the (extremely powerful) continuations feature. Scheme also doesn't have a standard OOP system like CLOS. You can implement all of this in Scheme, but Common Lisp has this standarized, proven, well-documented way for all of that. This makes reading others' people code easily, because common stuff is going to be done in a standard way that you already know.
It is a Lisp-2 which, for me, makes programming comfortable. People always talk about how macros in Common Lisp are "unhygienic" by default, but it is trivially easy to write a hygienic macro on Common Lisp.
It is an ANSI standard and the Common Lisp implementations largely comply with the standard, which means that I can take my code and run it with no changes (or very slight changes) on awesome Lisp implementations like LispWorks, SBCL, CLISP and many others.
There is a big amount of documentation available and in the last 10 years the amount of libraries, books and tooling has increased to make CL programming nicer than ever.
The implementations can be really high performance. SBCL can be had for free and it's performance is awesome. It is amazing that a dynamic programming language could be that fast. Also the implementations are mostly very nice to the programmer.
Common Lisp also allows to do low-level stuff if you like, for example it has full support for bitwise binary manipulation. Numeric support is magnificent and standarized: All CL implementations support real, fractional, complex, int, arbitrary precision numbers, and work with them really quickly.
Clojure seems more limited compared to Scheme or Common Lisp, being tailored for doing everything the functional way; while both CL and Scheme allow you to be 'eclectic' and use whatever programming paradigm the situation calls for.
I'm using Chez Scheme for a side project. It supports R6RS.
And should power Racket soon!
Clojure. It works very well, I prefer the lisp-1 nature of it to something like Common Lisp, and I really appreciate being able to call out to the JVM (or Javascript, but I don't use ClojureScript at all) for whatever I please.
It has Pulsar, which is miles ahead of any other lisp's threading abilities.
I wish it had a more mature static typing story, but I guess you can't have everything.
> It has Pulsar, which is miles ahead of any other lisp's threading abilities.
What about Lisp Flavored Erlang (LFE)? It was designed for concurrency.
Yes, I suppose LFE has a pretty good concurrency story too!
I like NewLisp just for syntax (http://www.newlisp.org/) also OwlLisp (https://github.com/aoh/owl-lisp).
Clojure is, I think, still my most go-to Lisp.
You can argue Clisp is easier to get a quick project going with, but short of that rather old project nothing with a setup any less capable than "lein new" is going to compare for dashing something out real quick.
Clojurescript. Because it works. Because it's not frustrating.
clisp mostly. Easier to use than sbcl, which mostly fails to install.
That's interesting, because I've never had sbcl fail to install from a package manager on linux, BSD, or Mac.
sbcl fails to install? what?
Since decades on windows with foreign locales. The installer just breaks, and self-building fails also.
With rpm or apt it works of course, but doesn't feed my interest. clisp also fails on many systems (e.g. libsigsegv on win64), but there I can at least hack it away.
> Since decades on windows with foreign locales. The installer just breaks, and self-building fails also.
Are you sure? I use SBCL with Windows with no problem. My machine is localized for spanish language. Also CLISP works just fine.
Elisp, because it's the practical way to do "real work" in Lisp under the radar ;-)
Javascript.
Cheating because it's not a lisp. But it was created by a schemer who originally put scheme in the browser (before he created javascript). Not what I prefer, but it's the most lisp-like language I actually use in real projects. The support for closures, lisp-1 invoking functions from variables, and dynamic typing feel very scheme-like.
No, it's not even sort of a Lisp. JavaScript is not secretly a Lisp. JavaScript is no more a Lisp than Python, Ruby, or Lua. Crockford is right that JavaScript is closer to Lisp than C, but so is Awk.
http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...
I know there is no formal definition, but without homoiconicity provided by s-exps, it is hard to call it a lisp. Of course, it sounds like you're well aware of this. Do you use a lisp for hobby projects.
There are a bunch of Lisp dialects without s-expression syntax.
McCarthy's first Lisp programs were written in MLISP notation.
My bad...s-exprs OR m-exprs I guess? I'll yield to the r/lisp mod's opinion of course :)
M-expr syntax wasn't homoiconic.
Soooo...less awesome?
JavaScript is not a lisp.