Live data from Hacker News

Ask HN: Lispers: Which dialect of Lisp do you use and why?

news.ycombinator.com

21–30 of 46 posts

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#23

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...

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#24
post #18
post #5

clisp mostly. Easier to use than sbcl, which mostly fails to install.

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.

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#25

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…

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?

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#26
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).

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#27
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.

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#28
post #26

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…

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.

Re: Ask HN: Lispers: Which dialect of Lisp do you use and why?

#30
post #26

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…

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.

    (let foo foo
    (eval '(foo arg) (null-environment)))
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).

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.

Post reply on HN