Why Racket? Why Lisp?

http://practicaltypography.com/why-racket-why-lisp.html

by Tomte • 12 years ago

418 278 12 years ago

From what I've seen out of the Clojure community over the past few years, it seems like they're far more likely (and able) to offer up concrete examples of how Clojure makes their businesses and products successful in a way that an imperative language could not. So, yay Clojure community, and boo on hand-wavy Lisp people.

e.g.:

http://www.kreuzwerker.de/en/blog/posts/why-clojure-rocks-2/

https://news.ycombinator.com/item?id=5113060

pjmlp8• 12 years ago

That is also a sore point from the Lisp community in regard to Clojure.

Clojure devs are willing to compromise a bit to allow a good integration within the JVM and other implementations, thus allowing some shops to buy into Clojure.

Whereas many in the Common Lisp community will not, no matter what.

mark_l_watson• 12 years ago

A long time ago, the inventor of the Clojure language Rich Hickey wrote a Java bridge for one Common Lisp implementation that was very good - I used it a lot for a while.

So, Rich has been thinking of the practicalities of Java interop for a long time.

_delirium2• 12 years ago

I don't see CLers as having a problem with JVM interop per se. ABCL is often recommended as a perfectly respectable implementation for people who need Lisp on the JVM. But it's true that Clojure and ABCL take different approaches to it.

eudox4• 12 years ago

Whereas many in the Common Lisp community will not, no matter what.

Common Lisp on the JVM: http://abcl.org/

Common Lisp/Java bridge: http://foil.sourceforge.net/

pron• 12 years ago

... in a way that an imperative language could not

Perhaps a nitpick, but sometimes nomenclature is important. Clojure (like all Lisps) is an imperative programming language. "Imperative" languages are contrasted with "declarative" languages[1]. Where does functional fit in and what is the name for "non-functional"? Well, that's not clear, as "functional" (in the PL sense) doesn't even have an agreed upon definition. Is Clojure "functional", then? Well, it's certainly not pure like Haskell is (and it has explicit loops etc.), but it does encourage more uses of function composition than, say, Java, it's more declarative, and it also isn't object-oriented, but that doesn't make it not imperative. Actually, I think even Haskell still qualifies as imperative.

But Clojure can certainly be contrasted with OO and procedural languages (even though at least one of its core abstractions -- protocols -- is borrowed from OO).

[1] http://en.wikipedia.org/wiki/Imperative_programming

andreasvc6• 12 years ago

I think declarative should be contrasted with procedural, not imperative. Also, your reference/footnote [1] is missing.

wtetzner4• 12 years ago

Actually, I would say that protocols are more influenced by Haskell type classes than OO interfaces.

eru• 12 years ago

Actually, I think even Haskell still qualifies as imperative.

How so?

LesZedCB2• 12 years ago

Clojure (like all Lisps) is an imperative programming language. "Imperative" languages are contrasted with "declarative" languages.

Wikipedia, and probably everybody, defines truly functional programming languages (which includes Clojure and the other Lisps) to be declarative, not imperative. [1]

[1] http://en.wikipedia.org/wiki/Declarative_programming

bjourne• 12 years ago

Taken to the extreme like you are doing, no language could ever be considered "functional" because in the end, they all need to perform io and ordered execution to be of any use. Instead, the commonly understood meaning of the word "functional" is that the language's design emphasizes and encourages use of immutable data and Clojure fits that meaning.

s-phi-nl• 12 years ago

It is meaningless to nitpick about whether a language is declarative or not since the term "declarative" lacks a good definition. Robert Harper, a programming languages researcher, lists 6 separate definitions and concludes, "It seems to me that none of them have a clear meaning or distinguish a well-defined class of languages. " [1]

[1] http://existentialtype.wordpress.com/2013/07/18/what-if-anyt...

fnbr• 12 years ago

I tried Clojure, and I quite like it as a language (especially the thread-first & thread-last macros [1, 2]).

I don't, however, like the ecosystem surrounding it. I find Leiningen (while an excellent tool) far too heavy for the majority of my purposes. I much prefer other functional languages (e.g. OCaml, Haskell) that don't need such an intricate project structure.

With OCaml & Haskell, I can start with one source file in one directory and gradually build up to a more sophisticated layout as needed, rather than have a complicated layout imposed upon me by the project.

[1] http://clojuredocs.org/clojure_core/clojure.core/-%3E [2] http://clojuredocs.org/clojure_core/clojure.core/-%3E%3E

bad_user7• 12 years ago

You can get started with Clojure without Leiningen. You can get started with Scala without SBT. These are build tools for serious projects, with lots of options and lots of things they do for you. Some people recommend them to beginners and while that's not necessarily wise, it goes to show that they are mature and OK enough that some beginners cope with it.

Yes, you can get started easily with Haskell - but then Cabal is such a complete piece of shit that people felt the need for a Haskell distribution with batteries included. And it is my feeling that you're mixing the cause and the effect here.

leishulang2• 12 years ago

Leiningen prevents clojure from having the dependency hell problem from the beginning, which haskell was prone to but eventually fixed by sandboxing. Then would you say sandboxing is too heavy for haskell?

Now if by heavy, you mean the folders structure lein generates, then I disagree. Those folders actually keep the task of understanding any lein project easy.

If by heavy, you mean the JVM: You can compile the thing into a jar that runs on any jvm, or a js file using clojurescript. JVM, web browsers and Node.JS are very likable cross-platform layers, and I don't see why binary executable that are OS dependent compares.

cturner5• 12 years ago

The top reason here could been written - lisp is more expressive. You can find ways to express an idea that make sense now, and which are readable. Macros is a different part of the same idea.

Maybe I'm doing it wrong, but a problem I've had with racket is as you begin to build larger projects, when something breaks it can be quite difficult to find out exactly where the break happened. When you compile Java or run Python, it's almost always immediately obvious what broke.

The way I got around this was to use a methodical TDD approach. Would be a shame if that turns out to be as good as it gets for lisp.

Something I haven't done yet but am interested to get to is attaching a repl console to a running process.

calibraxis• 12 years ago

Yes, that is very important. When I watch experienced programmers learn Lisp, they write a couple functions, then go through the pain of debugging that.

They should unlearn that. And put tiny fragments in the REPL. (Or whatever interactive tool you have.) Playing with it.

cturner5• 12 years ago

Since lisp is homoiconic (refreshed on this, see downvotes below) it would be nice if you could type things into a repl and then run a function like this: (persist function-i-just-wrote). And then it would save to a text file. Then you wouldn't need to stuff around with the mouse copying from one buffer to another and the like.

(I expect something similar is possible in emacs, but emacs is not my thing.)

Hmm. I suppose I could just write the persist function myself. Watch this space.

qewrffewqwfqew• 12 years ago

That's some pretty ugly text for a site called 'practical typography'.

arm• 12 years ago

Oh? What makes you say that? On my OS X computer at least, it honestly looks gorgeous:

http://f.cl.ly/items/3o2r3E2T2y3v3M3T291i/Screen%20Shot%2020...

fake-name• 12 years ago

Yeah, except the obnoxious diamond symbols used to denote each link, rather then underlining them, like has been standard for 20 years now.

_delirium2• 12 years ago

The manual to this publishing system, discussing how its markup/programming language is implemented as a custom Racket language, is pretty interesting: http://mbutterick.github.io/pollen/doc/

_ofdw• 12 years ago

I sure hope the giant, hideous, obtrusive diamonds inserted into the text to denote a hyperlink doesn't catch on as a trend. It's a great way to break the flow of the text and irritate your readers.

As for the idea of Lisps, well, it sure seems neat. But I've literally never run across a situation where I needed my code to edit itself. I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do.

So I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time.

cespare• 12 years ago

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue.

In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it.

Then again, I just noticed that I type ( and ) with my third and fourth fingers, so maybe it would be worse if I typed properly :)

jsmeaton3• 12 years ago

I would assume it'd be the same as people complaining about significant whitespace in python. No one who actually programs in python complains about the whitespace.

aerique• 12 years ago

If you write Lisp every day why not remap the ( and ) to a non-shifted position? I use the [ and ] keys but I use Common Lisp, not Clojure.

dmpk2k• 12 years ago

In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses.

Whelp, now you have. Hi! :)

Although I sometimes miss the goodies homoiconicity brings, I much prefer the increased syntactic structure of other languages.

jahnu5• 12 years ago

It's a zombie complaint.

I feel it's actually easier with parenthesis because with always well formed lisp you get the benefit of incredible tools like paredit-mode which make it easier to type than in other languages and I say this as someone who does full time c++ with a fair bit of python, javascript and html and I only do lisp stuff as a hobby.

agumonkey2• 12 years ago

I was looking for a way to summarize lisp syntax benefits. Most BNF-heavy languages are statically appealing. They have layout and differentiators that makes it nice to look at.

Lisp is a building material, the expressions are objects, the syntax is object. You don't want to look at it, you want to model with it, live. And with the "metacircular" (sorry for the sophisticated looking lingo) mindset, you can program how you interact with it (protorefactoring ala paredit/redshank etc).

Most people can't judge s-exp properly because they're not playing with it only looking at dead printouts; and the few who does are using a textbuffer[1], avoiding one important programming rule : automate everything. Lisp syntax has a simple and potent programmable API giving you a lot of power for free.

[1] I even watched a lisper using emacs without paredit at a meetup and it was painful.

therockhead• 12 years ago

For me it is the prefix notation and still find nested expressions difficult to read.

derengel• 12 years ago

Why don't you enjoy it?

cturner5• 12 years ago

Yeah, middle clicking on the page to start a scroll got weird as well.

In defense of why-homoiconicity-is-cool: it's useful to build pipelines of things in code.

Imagine if you had a series of functions that manipulate an audio signal. You could create a pipeline of these on the fly just by putting the functions in a list, and then reflecting the data against it.

You can imagine exposing this to a user - they check some boxes saying what features they want, and then the pipeline gets assembled for them.

This would be do-able but laborious in Java.

Javascript and iolanguage are homoiconoic language without the parens emphasis.

SamReidHughes• 12 years ago

Imagine if you had a series of functions that manipulate an audio signal. You could create a pipeline of these on the fly just by putting the functions in a list, and then reflecting the data against it.

That's not an example of homoiconicity.

grayclhn• 12 years ago

For a book typsetting program that's trying to produce html without a lot of writing overhead, some of those features are pretty great. Steve Yegge has a related blog post (the context is emacs): https://sites.google.com/site/steveyegge2/the-emacs-problem

simias• 12 years ago

If you've never had the possibility to do so before it's not surprising that you never felt the need to do it. Languages affect your way of thinking and implementing algorithms.

On the other hand, once you've tried the sweet honey of lisp macros, going back to C macros makes you sad. There's not a week that goes by without me being frustrated at the rudeness of C macros. Not to mention languages that don't offer a macrosystem at all. And the parens thing is a tired meme.

I agree with you for the diamonds though, very distracting.

Havvy• 12 years ago

The first macro system I learned was Clojure's. Only once have I used a C style macro, and that was in my assembly class.

I noticed the article mentions that some don't like calling syntax extensions macros because of the comparison to Common Lisp macros. To that, I say that's a crazy way of thinking. Macros are necessarily dependent upon the semantics of the language they are for, so anybody who thinks that all macro systems are identical are the people who probably wouldn't go out of their way to learn a language with a non-textual substitution macro system, so changing the name for that purpose seems foolish. On the other hand, syntax-extension or syntax-transformations are a more descriptive term on their own merits.

And yeah, the diamonds are silly. Better to just color the word.

kitsune_• 12 years ago

I mainly develop software in C# and Python at work, and I sure do miss some of the convenience that lisp-inspired languages offer. I'm responsible for the overall architecture of quite some large-ish enterprise apps. There's a reason why many Java and C# business applications have tons of MySuperAbstractFactoryProvider classes and use reflection-based look-up of metadata attributes obsessively. There's just no other way to provide a flexible framework that meets the changing and often arcane demands of our customers.

About macros, in the case of C#, what, if not a kind of macro, is the 'using' statement that works with IDisposables? If it's useful here, why not in other places?

dkersten• 12 years ago

giant, hideous, obtrusive diamonds inserted into the text to denote a hyperlink

I hadn't even noticed that they're hyperlinks, I thought something had went wrong with the text formatting or character set!

I've literally never run across a situation where I needed my code to edit itself.

Needed to is too strong a statement. I've never needed to write a macro (and in Clojure, its somewhat frowned upon to write macros when normal functions will do), but sometimes it saves you from a lot of working around limitations (and every language has limitations). It also allows things to be added to the language as libraries that otherwise would have to be built in - the majority of programmers won't need to do this, but if you do, its awesome knowing that its possible. Clojure's core.async is an excellent example (Go-style goroutine's, as a library).

I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do.

Of course not, but you can also do everything you want in assembly. What everything-is-an-expression-is-a-list gives you is 1) uniformity - everything works the same way, so it lowers the cognitive load; 2) simpler code - if you need a statement in an expression, you can do so, and other languages don't prevent you from getting the same result - they just take more code, or the code is more complex, or you use less-than-ideal constructs, or...

So you never need these things, but they make life more pleasant to have them.

I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time.

I program in Clojure fulltime and I don't find that it has any more parentheses than a language like C++ or Java does. On top of that, anyone who programs in a Lisp for a while will use some form of paredit, which makes working with parentheses a breeze to the point where I find I type less than I do in other languages because jumping between parentheses, splicing parentheses-enclosed lists, wrapping things in parentheses and such tasks are a single keypress that just isn't possible in other less-parentheses-focused languages.

In short, just like significant whitespace in Python, parentheses are a non-issue in practice (after a short adjustment period).

But at the end of the day, to each his own. If Lisp doesn't do it for you, then that's fair enough - you don't have to use it :-)

pjmlp8• 12 years ago

I program in Clojure fulltime and I don't find that it has any more parentheses than a language like C++ or Java does.

People see the parentheses and go crazy, but in fact it is just a matter of moving the opening parentheses.

I now use this approach when explaining Lispy languages to others.

swah3• 12 years ago

I didn't mind but note that he wrote http://practicaltypography.com.

As for not missing stuff from Lisps, I think opportunities start appearing once you start using it more. But I agree, it doesn't prevent you from getting things done.. I don't see any Lisp in the Go space (native compilation, great networking features), so I find Go more pragmatic at this time.

aaron-lebo• 12 years ago

I think Gambit Scheme has both of those features. Granted, it doesn't have the community or momentum of Go, but it exists.

pjmlp8• 12 years ago

I don't see any Lisp in the Go space (native compilation, great networking features)

What?!?

Proper Lisps compile to native code, both JIT and AOT.

Plus there are quite a few code commercial compilers with networking libraries.

http://franz.com/products/allegrocl/

Don't judge Lisps by the open source alternatives.

TeMPOraL• 12 years ago

As for the idea of Lisps, well, it sure seems neat. But I've literally never run across a situation where I needed my code to edit itself. I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do.

This is classic Blub paradox. You don't feel like you need a feature until you start using it, at which point you start wondering how anyone can live without it. Tools you have available limit the thoughts you can have. That's why it's always good to look for better and more powerful tools :).

AnimalMuppet3• 12 years ago

OK, but I've been aware of Lisp macros for a while, and still never seen a situation where I needed them.

A couple weeks ago, though, I found myself in a situation where the user needed to be able to specify a filter, and the filter was going to be a tree of expressions, and the program had to take what the user specified and turn it into something the program could execute... and the filter tree looks a lot like an S-expression... hmm...

So I'm seeing something that could be done much easier in Lisp. It's still not a need for a macro, though (unless you're going to suggest that I use a macro to turn some user-writeable DSL into Lisp, and sure, it could be done that way.)

jimbokun2• 12 years ago

"But I've literally never run across a situation where I needed my code to edit itself."

Well, "need" is a strong word. I mean, you could probably argue, in a philosophical sense, you never needed to write any computer programs in the first place (plenty of people go through life without doing so).

However, it is very likely there were times in your life where having your code edit itself would have led to getting a program working in less time, with fewer bugs, or better performance. Which of these benefits apply, of course, depend on the problem you were trying to solve.

"So I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time."

Um, no. Rich Hickey has pointed out idiomatic Clojure requires fewer parens than the equivalent Java.

lostcolony• 12 years ago

Good call on the diamonds.

Echoing everyone else, basically, your other points are a bit shortsighted.

You never need code that edits itself - completely true. Completely missing the point. Most programming features fall into this category; you don't -need- them, you could always use assembly instead. The point is that once you get them into your brain as an option, problems that might otherwise be tricky or time consuming become much easier.

To that end, everything is an expression is a list...yeah, you don't need it either. But, assuming the above (that code that can edit itself turns out useful sometimes), imagine how easy it is to metaprogram when all your executable code is just a list, and you already know how to modify lists.

In either case, you don't -need- the feature, sure, but a moment's reflection might open up the possibility that once you fully grok the ramifications, and have it amongst your other programming tools, you'll find a good use for it.

As to too many parentheses, as someone else mentioned,

  foo(a, b, c)

simply becomes

  (foo a b c)

Not really any more of them.

GregBuchholz2• 12 years ago

hmm...

    c = sqrt(a*a + b*b)

    (setf c (sqrt (+ (* a a) (* b b))))

RHSeeger• 12 years ago

Being able to write new control structures can come in very handle. Imagine if your language of choice had exceptions/errors, but didn't have try/catch/finally. Now imagine you could just implement that structure as a command/macro. That's a rather extreme example, but it does highlight the power available.

jstoja2• 12 years ago

Please.... text-align: justify; ...

Tomte• 12 years ago

Please... see http://practicaltypography.com/justified-text.html for the author's opinion.

Personally I believe that Matthew is wrong there. There's no justification for justification. :-)

jstoja2• 12 years ago

Thank you :)

swah3• 12 years ago

Also on that page: "Justification is a matter of personal preference. It is not a signifier of professional typography. "

pera• 12 years ago

Justification is terrible for people with dyslexia.

happywolf2• 12 years ago

Agree with some of the earlier comments: the diamond-shaped thingies inserted are really a nuisance and breaks the reading flow.

jey• 12 years ago

Maybe only because it's unfamiliar. After all, other punctuation doesn't break your flow. And trying to figure out whether something is a link or not also breaks flow.

happywolf2• 12 years ago

The real question is why someone would change something most people already getting used to. I don't see any compelling reason to change the link in this way, do you?

Illotus• 12 years ago

Indeed. Whenever you break convention like underlined and colored text for links you in general need to have a good reason.

mapcar• 12 years ago

If Lisp languages are so great, then it should be possible to summarize their benefits in concise, practical terms.

His list is concise but man did he take a while to get to it!

Seriously though. The introduction was super relevant as I have wondered the exact same question about Lisp myself. What features make it so praise-worthy? Maybe X-expressions isn't a core feature for everyone to appreciate, but the fact that everything is an S-expression is an understated value. People complain about its syntax, but alternate versions (so many reincarnations of parentheses-less Lisps) have never caught on.

The thing is, Lisp is no longer unique in its feature set, and languages with more standard forms of syntax have incorporated some of its features. But it is uncommon to find all of these listed features in one language. In the domain of data analysis where I do most of my work, it still makes me sad that XLISP-STAT has been supplanted by other languages which leave the user wanting.

agumonkey2• 12 years ago

By feature set you mean sequences, map/filter/reduce and such ?

I felt there was more to Lisp than that. It was the root of the ML/function-based family, which deepened the recursive typed logic McCarthy talked about in his early papers.

The first-class function and functions as modeling unit, giving composability, and domain embedding as first class.

guilloche• 12 years ago

When visited with w3m I got spaces breaking words frequently. Is there any justification to use complex html to control intra-word spacing for a web page?

sjy• 12 years ago

Those are soft hyphens, which supplement the crappy hyphenation support built in to most browsers. w3m should probably just ignore them, but it looks like your version is broken[1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441934

TheMagicHorsey• 12 years ago

Why does Racket perform so slowly on benchmarks compared to Clojure and SBCL?

LeonidasXIV• 12 years ago

Why does Racket perform so slowly on benchmarks compared to Clojure and SBCL?

Clojure benefits from the optimization of the JVM and SBCL has a couple of pretty bad-ass hackers working on the compiler. Racket on the other hand uses a pretty of the shelf JIT compiler which might not be as specialized as the other two.

Language-wise, there is hardly anything that would make Racket inherently slower than Clojure. Maybe continuations.

alvatar• 12 years ago

Many of the last items in the list should be in the category "Scheme". Racket is a dialect from Scheme, but it still is a Scheme. The syntax-case macro transformations are available in most Scheme systems.

dragonwriter14• 12 years ago

Many of the last items in the list should be in the category "Scheme". Racket is a dialect from Scheme, but it still is a Scheme.

The name was changed to Racket from a name with "Scheme" in it because its not a Scheme in the strict sense; Racket does not conform to any of the Scheme reports (though its bundled with language definitions that do, as well as lots of others, but the Racket language, while near Scheme, is not.)

pflanze• 12 years ago

because its not a Scheme in the strict sense; Racket does not conform to any of the Scheme reports

The same could be said for many, if not most "Scheme" implementations.

Scheme didn't standardize stronger language abstraction features, otherwise what Racket offers aside its core implementation (unless they would deviate just for the purpose of lock-in) would just be Scheme libraries, and it would be fair to call it "the Racket implementation of the Scheme language, which comes bundled with more involved language libraries than most".

From a marketing standpoint, their move is good for them and bad for the Scheme community because they imply that "Scheme" as a brand or community isn't able to support the languages that they are implementing. They may have the finances and manpower to make it work for them, but it leaves out the community from which they have grown. I'm not deep enough inside the community to know all the factors that lead to this but as a fringe participant it seems (more than?) somewhat untruthful and disappointing.

georgegeorges• 12 years ago

but the Racket language, while near Scheme, is not.

You've described 99% of Scheme systems. The only exception I know of is Scheme48, which is pretty much the Third Reich of Scheme systems.

Portability between Scheme systems is tedious and, in some cases, close to impossible. Even moreso when you start using some combination of SRFIs.

PuercoPop3• 12 years ago

mutable cons cell by default is a very big departure from the Scheme Standard AFAIU (not that I think it is a bad idea, just not Scheme).

DCKing2• 12 years ago

Why Lisp? That is understood.

Why Racket? From an ignorant outsider's perspective, all Lisps seem to be more or less interchangeable when it comes to the language. They only differ in the details, and each seems to be about as difficult to learn as the other. Although this article does make somewhat of a case for specifically Racket, it seems to be a rather weak one - tools are nice and some language details are nice. But the same general arguments can be made for other Lisps, most notably Clojure. It seems to me that Clojure is a lot more practical: it has many good libraries in both Clojure and Java, it has some great tools, there's a lot of momentum, and it can be deployed everywhere (including the browser).

So, being an ignorant outsider, is there any reason the Lisp I should learn isn't Clojure?

pervycreeper• 12 years ago

SICP

klibertp5• 12 years ago

Structure and Interpretation of Computer Programs by Abelson and Sussman, for the uninitiated.

It's one of the best introductions to basic and advanced (and then even more advanced) programming there is. This book, along with a series of "The Little Schemer", "The Seasoned Schemer" and "How to design programs" use Scheme as a language, and Racket makes it particularly easy to follow them by providing special environments (#langs) crafted for them.

densh• 12 years ago

Racket has probably the best macro system out of all existing lisps available to date. Plus it has concept of extensible languages via #lang. If you care about lisp-style macros and meta-programming that's probably the main reason why I would recommend Racket.

Clojure macros in comparison are very ascetic. You can get stuff done in them but it's not a strong feature of the language in my opinion.

cturner5• 12 years ago

Racket has strong multi-platform support of its own. I actually chose racket over options like clojure for building a game, because I wanted to be able to be able to easily and quickly package one codebase for deployment on windows (running in a window), OSX (running in a window) and linux (running in a terminal). From the standard install, you can quickly package code to a stand-alone binary. With Clojure, some users would need to install a JVM. Clojure's great though.

klibertp5• 12 years ago

all Lisps seem to be more or less interchangeable when it comes to the language

Definitely not true.

It may be true to an extent for implementations of one particular lisp, like Common Lisp or Scheme, but even then there are very real, and significant differences. Simple and regular syntax makes it actually much easier to build many different semantics, and that's what lisps are about.

Racket has less libraries than Clojure and no access to JVM ecosystem. On the other hand it's FFI capabilities to C are very nice and easy to use. Racket macro system - syntax-parse (with syntax-rules and syntax-case and... defmacro for simpler cases) - is the most powerful there is right now. Combined with access to the reader and ability to make reader macros this makes Racket much easier to extend and transform than Clojure (by design). Which takes us to the biggest advantage of Racket, which is it's actually a family of languages, both s-exp based and with traditional syntax, built for specific purposes, which you can mix and match easily. Typed Racket and lazy variant, and FrTime, and Datalog - and more - are examples of this. Then you have module system which is a game changer for unit-testing, object system which is more powerful than most (besides CLOS, but there's always Swindle), the most advanced contracts system among all PLs, and of course quite fast JIT compiler and many more.

Clojure is simpler than Racket, but provides a set of highly opinionated defaults which people are comfortable with. I think Clojure and Racket are like Sublime Text and Emacs - Emacs is strictly more powerful, but it requires much more work to use this power well, while Sublime works well from the get go. But in the end both are infinitely better than Notepad and sooner or later you will come to know both, which is what I suggest you should do.

DCKing2• 12 years ago

Thanks for the clarification. Is it worth considering others besides Racket and Clojure as a first Lisp? Are there Lisp equivalents of Vim and Atom as well?

crististm2• 12 years ago

Racket vs Scheme vs Common Lisp is like C# vs Java vs C++ vs ...

sanatgersappa• 12 years ago

My personal experience with Clojure has been that it 'bends' the brain - in a good way, and it forever changes the way you program. It is extremely difficult to go back to the style of coding I did before my exposure to Clojure. I guess other Lisps would provide a similar experience.

theRhino• 12 years ago

Not sure how closely you have read Siebel - your 1st few points are covered pretty comprehensively at the start of his book

jimbokun2• 12 years ago

If you took a Common Lisp programmer from the early to mid 90s in a time machine to today, very little about current programming languages would seem novel or an advance over what he or she was using then.

I think this is a reason for much of the smugness of Lisp programmers. Whatever features you think are new or cool or advanced about your programming language, Lisp probably got there first.

lmm4• 12 years ago

Nonsense. We've figured out how to do type systems. We can even fully infer types if you're willing to accept some quite reasonable restrictions on how polymorphic your code is. We have a bunch of reasonable approaches to effect tracking, which Lisp folk used to have to do by hand (that story about the T garbage collector sounds like the most unmaintainable piece of code I've ever heard of). We know how to solve the expression problem.

Modern "pragmatic"-oriented languages have little that wasn't in Lisp - or in Algol. Which is fine! The innovation is about the wider ecosystem (a lisp programmer from the '90s would be amazed by CPAN, never mind maven), or about making common tasks easy (a lisp programmer might eventually put together a collection of idiosyncratic macros with much of the functionality of Rails, but that wouldn't be a project you could hire someone else to maintain). OTOH modern "researchey" languages, like Coq or even Haskell, are far far ahead of Lisp.

eudox4• 12 years ago

a lisp programmer might eventually put together a collection of idiosyncratic macros with much of the functionality of Rails, but that wouldn't be a project you could hire someone else to maintain

There is, in fact, such a thing as Common Lisp libraries. See https://github.com/quicklisp/quicklisp-projects

1034 projects with ~48 waiting to be added.

tel• 12 years ago

To be clear, they were far ahead of lisp in the 90s too.

The major innovation is probably more societal in these languages. We discovered that they really are much better for writing reusable abstractions on the level of the whole community. We also ran into some issues with scaling those abstractions at the level of 10s of thousands of packages and are slowly coming to solve them.

progman3• 12 years ago

OTOH modern "researchey" languages, like Coq or even Haskell, are far far ahead of Lisp.

I know Common Lisp well, and I honestly tried to learn and to use Haskell. I realized that Haskell has the advantage of a strong type system but it seems only to be useful for language research (compiler writing) and mathematical applications. Haskell is (in my case) almost useless for every day real world applications. It is a very good choice if I know the algorithm and data structures exactly in advance. But real world applications often require changes which are not predictable. It is a pain to align a whole Haskell project according to new requirements to make the whole system work again. It takes far too much time, and I wonder where the benefits are if other weaker typed languages can do the same job as well, or even better.

In the Lisp world I can develop prototypes very quickly. And if I need a strong type system as in Haskell then I can use Shen (shenlanguage.org) which has a strong rule based type system on top of Lisp. That means that I can use both worlds -- the default dynamic system of Lisp, and the strong type system of Shen.

Lisp is still very powerful and yet small in comparison to the huge LLVM system of Haskell. It can be used on embedded systems (ECL for instance) which Haskell is not able to do (AFAIK).

I don't know what you exactly mean with "tracking". If that means tracing then Lisp even offers backtracking (debugging back in time), and I think almost every Lisp programmer knows Slime.

So the claim that Haskell is "far far ahead" of Lisp is not true at all. The only real weak point of Lisp is a good GUI library. I wish there were strong support of Qt and HTML5.

Another favorite language of me is Nimrod because it joins the best of several languages (Python, Perl, Lisp and C) together.

kd0amg• 12 years ago

We can even fully infer types if you're willing to accept some quite reasonable restrictions on how polymorphic your code is.

Personally, I don't consider "don't pass a polymorphic function to another polymorphic function" and "don't demand a polymorphic function as an argument" to be all that reasonable.

wes-exp8• 12 years ago

Type systems are the one exception, but it still remains broadly true that Lisp was way ahead of everybody. There are many things we could talk about besides type systems:

Lambda expressions - just now reaching Java and C++, been in Lisp forever

Garbage collection – (obviously)

Turing-complete (edit: fully evaluating) macro systems – I've heard C++ is moving in this direction (not sure to be honest) but Lisp is still ahead on this

Gradual/optional typing – Others have been moving towards this, CL has had it forever

Interactivity/REPL – e.g. Swift may finally give a REPL to systems programmers, Lisp has had it forever

Dynamism/late-binding – Lisp is still way ahead on this, goes hand-in-hand with interactivity

Everything serializable – Lisp is still ahead

Structured code editing (paredit) – Lisp is still ahead, not sure anyone else even knows what this is

Multiple inheritance – I think this is coming to Java finally

Image systems (hibernating a running process) – Still ahead

Condition system / advanced exception handling – Still ahead

Functional programming techniques (map, reduce, etc.) – Still ahead

Keyword arguments – Recently added to Ruby, Lisp has had them forever

masklinn• 12 years ago

Nonsense. We've figured out how to do type systems. We can even fully infer types if you're willing to accept some quite reasonable restrictions on how polymorphic your code is.

That dates back to the 70s: http://en.wikipedia.org/wiki/ML_(programming_language)

kazinator7• 12 years ago

But you only have to infer types because you insisted on removing them from the run-time information.

Sure, you're clearing the road of fallen logs, but they fell there by your own axe.

Having the type there at run time is smarter than working up a lather prior to run time to avoid having it there.

Also, real systems don't have a well-defined "compile" and "run time": the two are intertwined. Compile time is just the compiler's run time, and we need access to the language at that time, and has to be type-safe also, and we would like that comile-time code to itself be compiled (and to have access to the language during that code's compilation ...).

sedachv• 12 years ago

We've figured out how to do type systems

This is probably the only valid point you have.

a lisp programmer from the '90s would be amazed by CPAN, never mind maven

CPAN was started in 1997. A lot of Lisp programmers back then were also doing Perl, and a few people who were doing Perl then are doing Lisp now.

Whoever is "amazed" by Maven should go jump off a bridge.

We have a bunch of reasonable approaches to effect tracking, which Lisp folk used to have to do by hand

I'm assuming you're talking about generalized arrows or something and not monads. Generalized arrows partly came out of work on linear types and parallelism done by Lisp people in the 80s and early 90s.

We know how to solve the expression problem.

Thanks mostly to PLT/Racket people: http://en.wikipedia.org/wiki/Expression_problem

blah blah blah Rails functionality

Rails doesn't have functionality, Rails has a bunch of shitty complicated ways of doing web programming, with a bunch of shitty poorly maintained Ruby libraries (most of the good ones are just FFI into C libraries).

If you're going to talk about modern "practical" languages, you could do better. Go is pretty great except it doesn't have exceptions. JavaScript solved code distribution and program-level virtualization. Those are much better comparisons.

Stubb• 12 years ago

Yeah, I think that most programming language developments since the '70s have involved putting some ideas from C and Lisp in a blender for a few minutes.

The main advances IMO have come in the areas of IDEs, build systems, and language ecosystems.

I'm a mediocre programmer at best who's done a bunch of Lisp in the past. I loved using it, but these days I rely on Ruby for getting things done because it gives me what I need from Lisp backed up with a package system that just works. I'd rather work in Lisp, but I can make more progress in Ruby.

ianstallings• 12 years ago

And smalltalk in that mix too.

pjmlp8• 12 years ago

From the 70's I would rather wish that the mix would be Lisp, Smalltalk, Cedar and CLU. No need for C.

Avshalom• 12 years ago

Sure but that can be said of half a dozen languages in the 70s. Unix taking over the world ended up convincing two generations that C was state of the art.

pjmlp8• 12 years ago

Sometimes I feel like a Roman after the Empire downfall.

So many choices for systems programming gone thanks to UNIX, and now kids think C is the only way.

colig• 12 years ago

Does anyone else find it difficult to highlight things on this page? Specifically, 'kvetchery' which is found in the third paragraph.

I believe the author is the one responsible for the facelift of Racket's documentation. He may belittle his own lack of formal programming education but I am thankful for his design chops.

amirouche2• 12 years ago

I tried somewhat Pollen and it's kind of fantastic, the only thing is getting to work with a new project in a language that I don't know very well is difficult for me. That's why I started a similar project in Python, watch https://warehouse.python.org/project if you interested /azoufzouf/

amirouche2• 12 years ago

I just pushed the code. You can have a look at it @ http://amirouche.github.io/azoufzouf/ there is all you need to know and ⵣcode{pip install azoufzouf}.

With that markup, it's easy to plug any function you want. That's right. It's not nested and is inspired from unix philosophy, I dare to say. I tried several time Sphinx, docutils alone and other markups they don't deliver as much as this one (sofar).

CMCDragonkai• 12 years ago

Many of the reasons you wrote are the same that got me attracted to Elixir. That and of course erlang interop and OTP.

mrottenkolber4• 12 years ago

Can not resist...

This article is fairly misguided. I find it painful that everybody who writes about a Lisp offshoot (Scheme, Clojure, ...) ends up misrepresenting Common Lisp.

To sum up "Why Lisp?" from a CL perspective: CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. It's just a poweruser language. Its not just macros, sexps and lambdas. Its also number types, arrays, OOP, symbols, strings, structs, dynamic/lexical variables, lambda lists, multiple return values, on-line disassemble, exceptions, restarts, MOP, metacircular definition, great implementations, great libraries...... the list goes on and on... I surely forgot a ton of great stuff. TL;DR: CL got everything. And this "everything" is designed so well that its extensible and no CL programmer ever needs to doubt that any new feature can be implemented easily in CL.

To correct a few of the wrong statements of OP:

“Wait—I love state and data mutation. Why would you take them away?” Because they’re false friends.

CL is NOT particularily functional. Just because we know how to write good side-effect free code, doesn't mean its a functional language. (We jave SETF after all, failed to mention that aove).

a syntax transformation in Racket can be far more sophisticated than the usual Common Lisp macro.

Outright wrong. The only reason Scheme has weird macro systems is because its a Lisp 1. CL is designed well (thus being a Lisp 2), and thats why its simple but ultimately more powerful macro system can work.

A macro in Common Lisp is a function that runs at compile-time, accepting symbols as input and injecting them into a template to produce new code.

This is so wrong I had to write this comment. A macro in Common Lisp is a COMPILER, it accepts arguments and returns an SEXP. It is infinitely powerful, it can do EVERYTHING.

hvs• 12 years ago

I would take issue with the OOP in CL being better implemented than other languages. Don't get me wrong, the Metaobject Protocol is a feat of modern engineering, but the actual result is an OOP that feels tacked on after the fact. CLOS is very powerful, but when it comes to OOP, other languages are syntactically cleaner in their implementations.

Also, it's a bigger debate, but the lack of hygenic macros in CL is often seen as a negative. Again, this is a larger debate, but certainly a case can be made that CL doesn't have everything designed so well.

I love CL, but it's helpful to remember its limitations.

mrottenkolber4• 12 years ago

syntactically cleaner in their implementations.

Listen to yourself please.

lack of hygenic macros in CL

Which lack? CL macros are usually very hygienic, being a Lisp-2 and all, having GENSYM.

I love CL, but it's helpful to remember its limitations.

What limitations? Not having syntactical things you seem to like and supporting non-hygienic macros are not limitations. Quite on the opposite, I believe these are features.

wtetzner4• 12 years ago

CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful.

The thing is, sometimes what makes a language powerful is the restrictions it imposes. For example, if you know a function is referentially transparent, then you know that calling it multiple times won't cause side effects to happen multiple times.

Having restrictions means that you can rely on those restrictions applying to other code, which might allow you to do things that would otherwise be unsafe.

samth5• 12 years ago

The number of bindings you can add to a symbol in CL is irrelevant to the macro system. In CL, you run into somewhat fewer instances of specific kinds of bugs that Racket's macro system prevents entirely.

The Racket macro system is more powerful, having more information and more control over the system, than the CL system. This additional expressiveness is what enables systems as sophisticated as the Racket contract, class, unit, and type systems to be built entirely with macros.

pmelendez• 12 years ago

> “Wait—I love state and data mutation. Why would you take >them away?” Because they’re false friends. CL is NOT particularily functional. Just because we know how >to write good side-effect free code, doesn't mean its a >functional language.

He didn't claim that CL or even Lips were pure functional though:

"Yes, I know that other languages offer functional-programming features, and that Lisps aren’t considered pure functional languages."

dschiptsov• 12 years ago

"Clarity is an evidence" as the saying goes. This post only proves its correctness.)

The distinct feature of Lisps and good lispers is clarity of thought and conscience of writing.

ColinDabritz2• 12 years ago

A good list of some interesting 'day to day' benefits of Lisp. Maybe that is something that would appeal to beginners especially.

From my perspective Lisp is a powerful language because of its genesis in research. The question wasn't "How do we make a tool to make this hardware do what want?" but rather for a research goal.

If you want to read the actual original Lisp paper look up: Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I John McCarthy April 1960

Paul Graham covers it nicely in this essay, especially the "What made Lisp different" list about 1/3 in http://www.paulgraham.com/icad.html

Lisp has had expressiveness we're only recently seeing in popular mainstream languages now. It has to do with the design, the simplicity, and how Lisp expresses problems. I've often heard it described as "the language gets out of your way." That's why Lisp.

smeyer• 12 years ago

Thanks for the link (it's one of PG's I hadn't read yet.) That being said, I really didn't like the part where he implied that if 1 line of Lisp can replace 20 lines of C that it also means that a feature can be developed 20 times faster in Lisp than C. Are you a Lisp programmer? I've only used it a bit, but I didn't get the impression things would scale that way for feature development.

BugBrother2• 12 years ago

If you check the research on the subject of development speed, it suggests a given programmer generates around a certain number of pages of code in any language he/she is proficient in. And if the programmer learns another language, they will write about the same number of pages when they get proficient. (Apply NaCl. I assume the real statement is that a given programmer generates a given amount of complexity in a work day.) [This paragraph of background was not needed, you seem aware of this point.]

You can, simplified, see Lisp as the grandfathers of the scripting languages. (But with parse trees as syntax, efficient compiler decades ago and so on.)

The point with the scripting languages is that development speed is so much quicker than e.g. C, for many cases. Lots of less code is needed. Personally, I went to scripting languages from C originally because of that the sheer productivity is so fun. I would have gone Lisp if there were jobs.

ColinDabritz2• 12 years ago

Interesting point. Particularly I believe that the 'coding' part isn't the real job, I'm not just an overpaid typist. So why is concise expression good?

For the record, I am NOT a day-to-day Lisp programmer, but I've played with it a little and read about it some.

I think it's because its about expressing your problem clearly. It's not "20 times less lines" so much as it is "20 times clearer expression". Not that it's exactly 20x, but it seems better. When you express things more clearly, and structure your code more like your problem, and less like your programming language, you shed a lot of accidental complexity ( See Out of the Tarpit - http://shaffner.us/cs/papers/tarpit.pdf ), so managing the complexity of your project is easier, which means fixing bugs and adding new features is also easier. I think this is the route being implied when they say you can develop features faster. I'm not so certain you'd see the benefit in a particular feature, but over time.

Note that a lot of the modern languages are picking up many of these expressive features, closing the gap there as well, which is wonderful.

wes-exp8• 12 years ago

Author is wrong about hygienic macros – they are not more powerful. They are less powerful, and more complicated, in order to enforce safety. Whether this is preferable or not is a matter of debate.

samth5• 12 years ago

No, the article is correct. Hygienic macros give you strictly more information to work with, enabling them to be more expressive. It's possible to implement unhygienic macros, either at an individual macro level or a whole new macro syso, using Racket's macro system.

wes-exp8• 12 years ago

I'm thinking you're right in the theoretical sense, but I'm right in the practical sense. Every time I've looked at hygienic macro systems, it just seems like now I'm jumping through extra hoops to overcome a more restrictive way of doing things. Is that extra information you cite typically useful for anything besides safety? Can you give an example?

agentultra• 12 years ago

Some practical features I enjoy in CL:

1. Conditions and restarts: As far as error handling in programs go this is the most rock-solid system I've encountered. You can tell the system which bits of code, called restarts, are able to handle a given error condition in your code. The nice thing about that is you can choose the appropriate restart based on what you know at a higher-level in the program and continue that computation without losing state and restarting from the beginning. This plays well with well structured programs because the rest of your system can continue running. Watching for conditions and signalling errors to invoke restarts... it's really much better than just returning an integer.

As a CL programmer using SLIME or any suitable IDE, this error system can throw up a list of appropriate restarts to handle an error it encounters. I can just choose one... or I can zoom through the backtrace, inspect objects, change values in instance slots, recompile code to fix the bug, and choose the "continue" restart... voila the computation continues, my system never stopped doing all of the other tasks it was in the middle of doing, and my original error was fixed and I didn't lose anything. That is really one of my favorite features.

2. CLOS -- it's CL's OO system. Completely optional. But it's very, very powerful. The notion of "class" is very different than the C++ sense of struct-with-vtable-to-function-pointers-with-implicit-reference-to-this. Specifically I enjoy parametric dispatch to generic functions. C++ has this but only to the implicit first argument, this. Whereas CLOS allows me to dispatch based on the types of all of the arguments. As a benign example:

    (defclass animal () ())
    (defclass dog (animal) ())

    (defgeneric make-sound (animal))
    (defmethod make-sound ((animal animal))
      (format t "..."))
    (defmethod make-sound ((dog dog))
      (format t "Bark!"))

    (make-sound (make-instance 'animal))
    (make-sound (make-instance 'dog))

Will print "..." and "Bark!" But the trivial example doesn't show that I can dispatch based on all of the arguments to a method:

    (defclass entity () ()) ;; some high-level data about entities in a video game
    (defclass ship (entity) ()) ;; some ship-specific stuff... you get the idea.
    (defclass bullet (entity) ())

    ;; ... more code

    (defmethod collide ((player ship) (bullet bullet))) ;; some collision-handling code for those types of entities...
    (defmethod collide ((player ship) (enemy ship))) ;;; and so on...

Conversely...

    Ship::collide(const Bullet& bullet) {}
    Ship::collide(const Ship& ship) {}

Where collide is a virtual function of the Entity class requiring all sub-classes to implement it. In the CLOS system a method is free from the association to a class and is only implemented for anyone who cares about colliding with other things.

The super-powerful thing about this though is that... I can redefine the class while the program is running. I can compile a new definition and all of the live instances in my running program will be updated. I don't have to stop my game. If I encounter an error in my collision code I can inspect the objects in the stack trace, recompile the new method, and continue without stopping.

3. Macros are awesome. They're like little mini-compilers and their usefulness is difficult to appreciate but beautiful to behold. For a good example look at [0] where baggers has implemented a Lisp-like language that actually compiles to an OpenGL shader program. Or read Let Over Lambda.

One of the most common complaint I hear about macros (and programmable programming languages in general) is that it opens the gate for every developer to build their own personal fiefdom and isolate themselves from other developers: ie -- create their own language that nobody else understands.

Examples like baggers' shader language demonstrate that it's not about creating a cambrian explosion of incompatible DSLs... it's about taming complexity; taking complex ideas and turning them into smaller, embedded programs. A CL programmer isn't satisfied writing their game in one language and then writing their shaders in another language. And then having to learn a third language for hooking them all up and running them. They embody those things using CL itself and leverage the powerful compiler under the floorboards that's right at their finger tips.

Need to read an alternate syntax from a language that died out decades ago but left no open source compilers about? Write a reader-macro that transforms it into lisp. Write a runtime in lisp to execute it. I've done it for little toy assemblers. It's lots of fun.

... this has turned into a long post. Sorry. I just miss some of the awesome features CL has when I work in other languages which is most of the time.

[0] https://www.youtube.com/watch?v=2Z4GfOUWEuA&list=PL2VAYZE_4w...

dllthomas9• 12 years ago

"CLOS allows me to dispatch based on the types of all of the arguments."

But can it dispatch based on the return value?

taeric4• 12 years ago

That sounds like a feature that would both be awesome, and annoy the crap out of me.

Are there examples where this actually leads to clearer code in the wild?

juliangamble• 12 years ago

This is an example of dispatching on return type in Clojure - which is similar to Common Lisp.

http://stackoverflow.com/questions/22740178/clojure-dispatch...

(The Haskell purists point out that the dispatch isn't determined at compile time - form your own opinion about whether they have a point).

arethuza• 12 years ago

Given that you can define your own custom method dispatch mechanisms in CLOS I'm pretty sure you could do something like this - you'd have to define the return type of each method somehow (can you use ftype with CLOS methods?) and have a way of specifying the return type you want back - but none of that sounds hugely difficult.

Mind you - its 20 years since I was paid to write Lisp/CLOS so take this with a grain of salt :-)

kazinator7• 12 years ago

Dispatch what where based on the return value of what?

Can you explain this with an example of what the syntax would look like, along with a description of the fantasy semantics?

Of course if a specializable argument to a CLOS generic function call is itself a function call expression, then it is evaluated to its return value, and the type of that value is dispatched on.

The return value of the generic function itself doesn't dispatch anywhere; return "dispatches" to the caller.

We can think about dispatching a different method based on some type which the caller expects. A way to do it in CLOS is to add an extra parameter, perhaps a class symbol. CLOS can dispatch on symbols via the (eql ...) specialization, so we can do something like (foo 'integer arg) to call that specialization of foo which returns integers. This won't be deduced from context; evaluation of a form is context free in ordinary Lisp. Doing that sort of thing requires a code walker to transform the program.

PuercoPop3• 12 years ago

Great concrete examples, a couple of things to add about them:

Handler, conditions and restarts are much more expressive than in other languages, you can signal a condition (the analogue of throw) with restarts attached to it which only if you desire to handle it in another part of the program where(/if) you decide to handle the conditions(the analogue to try). It is analogue to throwing an error with catch statements attached and when you write the try statemet the catch statements attach to the throw statement are made available to said catch. Kent Pitman explains it much more eloquently than me[1].

Also to add how well thought out CLOS dynamic redifining of classes is, when one redifines the change is garaunteed to happen between redefinition and the next time you access said class, as to give leeway to the implementation to decide the best strategy to do so (for example if redifining a class with 10K+ instances if you do it all at once the system may become unresponsive). Also if the redefinition isn't just adding or removing slots you can provide a function to handle the updating of slots for the redefinition.[2]

[1] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...

[2] http://www.lispworks.com/documentation/HyperSpec/Body/f_upda...

hyp02• 12 years ago

Re 1. everything is an expression benefit, condition example:

C-like languages often have the ternary operator, cond?exp1:exp2, that is exactly this. I feel clever using it, but I consider it a hack, because it's (usually) less clear. A microcosm of lisp, clever but unclear.

wtetzner4• 12 years ago

I think it mostly seems unclear in C because of the syntax.

If you could write this in C, would it still seem unclear?

    int x = if (y == 0) then 7 else 10;

As opposed to one of these:

    int x;
    if (y == 0)
      x = 7;
    else
      x = 10;

    int x = 10;
    if (y == 0) x = 7;

It makes everything local, and in my opinion reduces cognitive load.

hyp02• 12 years ago

(speaking for myself only): I find the ?: syntax clearer... probably because I've known it for so many years. It's the doing several things at once that, for me, makes it unclear.

Of your examples, I find the very last one the clearest. Arguably, it's a hack, because it assigns values twice to x - but it feels like the syntax embodies the semantic truth of y==0 being an exception. A pattern matching solution (with a specific and then a general rule) would also embody this, but to me, having the general rule first, with a following exception, seems more intuitive.

Disclaimer: "intuitive" is all very subjective, and it's certainly possible that with experience, my intuition could change. But for better or worse, the above is my opinion today!

PS: I do think your first example is cool, neat and clever. I understand and feel that aspect of the appeal.

reikonomusha2• 12 years ago

I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp.

""" That’s asking too much. If Lisp languages are so great, then it should be possible to summarize their benefits in concise, practical terms. If Lisp advocates refuse to do this, then we shouldn’t be surprised when these languages remain stuck near the bottom of the charts. """

What?? Why? The problem is not and has never been communication of Lisp features. No one made a concise list of why C and Java are so great that people rushed to use them. Instead, they were pervasively used and taught in universities, and they are pervasively used in the development of most applications for e.g. Windows and Linux, and they are relatively simple languages (in theory) whose semantics most people "get". No wacko high order crap, no weight curried things, no arrows or morphisms or monads or macros.

Programmers of such languages don't owe the rest of the world anything. Everyone has a choice about what to use, and it's each individual programmer's responsibility to choose them wisely. There is plenty of material about Lisp and Scheme out there. Unfortunately, we are in this TL;DR culture where no one has the time to spend a few hours every week to learn something new, since somehow that's too big a risk on their precious time.

Now, for some comments:

1. Everything is an expression.

He says this is a boon, but it's also confusing for "expressions" which are side effectful. Too bad he did not talk about that, nor did he talk about how the expression-oriented way of thinking is really best for purely functional languages that allow for substitution semantics.

2. Every expression is either a single value or a list.

This is wrong, unless we devolve "single value" into the 1950's idea of an "atom". What about vectors or other literal composite representations of things? What about read-time things that aren't really lists or values?

3. Functional programming.

Functional programming is indeed great, but why don't we talk about how in Lisps, we don't get efficient functional programming? Lisp has tended to prefer non-functional ways of doing things because Lisp will allocate so much memory during functional programming tasks that for many objectives, FP is far to inefficient. Haskell solves this to some extent with things like efficient persistent structures and compilation algorithms such as loop fusion. Lisp doesn't really have any of this, and the data structures that do exist, many people don't know about or use.

4 and 5 don't really have to do with Lisp but particular implementations. That's fine I guess.

6. X-pressions.

What the hell is an X-pression?

7. Racket documentation tools.

Okay.

8. Syntax transformations.

He made the same mistake as he so baroquely outlined at the start. What in the world are these "macros" and "syntax transformations" good for? You're just telling me they're more powerful C preprocessor macros that can call arbitrary functions. But I was taught that fancy CPP code is a Bad Idea, so boosting them is a Worse Idea.

9. New languages.

Same problem as 8. You say it's useful but you don't say why. Just that it's "easier".

10. Opportunities to participate.

Nothing to do with Lisp again.

* * *

Instead of all this glorifying of Lisp and etc, why don't we spend time increasing that library count from 2727 to 2728? Or do we need to go through an entire exercise about whether that time spent is worth it or not?

""" Rather, you are—because a Lisp language offers you the chance to discover your potential as a programmer and a thinker, and thereby raise your expectations for what you can accomplish. """

You're repeating everyone else. Notice how difficult it is to convey such things without being hugely abstract and unhelpful? Why don't other programmers see this huge productivity benefit from these Lisp wizards in their day-to-day life? Where are the huge, useful applications? They all seem to be written in C or C++.

""" It’s mind-bendingly great, and accessible to anyone with a mild curiosity about software. """

It is accessible to those who are intently curious about theoretical aspects of software development, especially abstraction, and who can take exercises which require mathematical reasoning. A "mild curiosity" in my experience with others will not suffice.

* * *

This post may sound somewhat cynical and negative, but Lisp enlightenment articles are almost as bad as Haskell monad tutorials. They're everywhere and by the end, still no one gets it. And I don't like the attitude that because a group G doesn't understand it, and group H does, that H owes it to G to spoonfeed the information. That's not the case.

yayitswei• 12 years ago

It benefits both groups to to enlighten G. Since G is so much larger, that's how we would increase the library count from 2727 to 27280.

reikonomusha2• 12 years ago

The best way to demonstrate it is to write interesting software, not to flounder on some abstract explanation about the greatness of G's favorite language.

ScottBurson3• 12 years ago

Lisp doesn't really have [efficient persistent data structures]

It does now: http://www.ergy.com/FSet.html

einhverfr2• 12 years ago

On the syntax transformation side....

I have started to get really into what you can do with closures and coderefs in Perl. It isn't a macro in the lisp sense but it really works well and you can do some incredible things with it, and with closures and lexically scoped variables....

I suppose I should probably at some point blog about it.

I think a big part of the problem is that these are not tools you had to a beginner. They are things which take a lot of time to really master.

innguest6• 12 years ago

Great post.

It is accessible to those who are intently curious about theoretical aspects of software development, especially abstraction

Agreed. That's why I think it's disingenuous when people complain that Haskell folks are in an "ivory tower" or they think they're the elite. I just think they're more curious and that's why they learned it.

And I don't like the attitude that because a group G doesn't understand it, and group H does, that H owes it to G to spoonfeed the information. That's not the case.

Exactly. I always think 'I should write this and that tutorial and then people will finally see why FP is so much easier and then perhaps...' but then immediately I think 'but I learned fine with the existing tutorials, why can't others?'.

The answer is, because most people don't care or aren't curious enough. The moment I learned of Lisp and Haskell and people gushing about it I knew I had to learn them just to see what the fuss is all about, and whether people are right in their praise. And they are right in their praise.

It takes time to learn but so does everything (for me, at least), but in the end you invariably get there, and it's more than worth it.

mschaef2• 12 years ago

A couple comments:

I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp.

There are a couple reasons why I think this happens. The first is that people who use Lisp (or any other technology) will rightfully get excited about using it. Sometimes this translates into trying to evangelize it to other people, which is not a bad thing.

The second reason is that Lisp has a long history of 1) incubating major contributions to the field and 2) being continually marginalized by commercial practice. In many cases, this marginalization is warranted... there have been many good reasons not to use the language. In that kind of environment, it's easy to see enthusiastic users of Lisp getting a little defensive and writing apologetics about their tooling.

What the hell is an X-pression?

He describes it, in some detail, directly in his post.

Opportunities to participate. ... Nothing to do with Lisp again.

I do think this is an area where Lisp has unique advantages. Good Lisp systems tend to have good online documentation, good access to the underlying source code, and good interactive facilities for modifying a system.

Just as an illustration, I tend to think that Emacs couldn't really work as a closed source software package, and I don't think it would be nearly as powerful as it is with a different language than Emacs Lisp. (Eclipse is also open source, written in a very different language, and not nearly as easy to extend as Emacs.)

michaelsbradley• 12 years ago

RacketCon is being held in Saint Louis, Missouri, USA the day following the Strange Loop 2014 conference (also in Saint Louis):

http://con.racket-lang.org/

I hope to see some of you there!

bad_login3• 12 years ago

It seems most people here have never used (and not tried) racket.

I decided to use racket for my little sides projects, as replacement for scala and clojure.

I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write what i want to express. In facts i rarely write macro because writing a good macro demand you take care of errors syntax, i am lazy in the bad meaning of the term.

I choose it because it's dynamic typed and i get more convinced that type go on your way most of the time (expect complex algorithms)(i write little projects, so refactoring argument is out). It enable me to write code and eval it on the fly with geiser (using enter! on the back), after eval the new function i test it in the repl, hack until the function meet the requirement copy paste from repl and boom i get a unit test. Because it as eval and it will become handy one time in your programmer life for sure.

I choose it because of it's sexpr syntax, as a heavy user of emacs i know that other syntax is a pity.

Also because it has (and i use):

1. llar parser (implemented through a macro).

2. A pattern matching nothing to envy scala or clojure deconstructs.

3. An optional type system.

4. A contract system.

What i find hard as a new comer (to racket, not as a programmer already now scala, clojure, half of c++ :), php) is

1. The broadness of the features the language offer, which feature to use e.g.: class or generics.

2. The documentation is rich but lack of examples for the common cases, so you need to read the doc of the function (sometime it's huge).

3. Understanding how racket module works is quite hard and you have the documentation, if you don't plan to play with the macro expander (the stuff that run your macro) and some dynamic features you don't really need to.

4. You need to 'register' the errortrace library if you want a stacktrace, quite a surprising behaviours for me.

My opinionated conclusion:

Racket is the best language design i ever see, it's hard to learn but make you feel learning an other language will just become to learn a new sub-optimal syntax. Sadly the ecosystem is lacking libraries and peoples and i am not helping in this way.

samth5• 12 years ago

I'm glad you like Racket, and you're right about some of the weaknesses, especially in providing guidance and examples for how to do things.

I have questions about points 3 and 4. For 3, do you mean it's hard to figure out how the implementation of something works, especially when that something is a complex macro? If so, I can't disagree.

For 4, if you just run Racket programs at the command line, you should get stack traces (although less nice than the ones errortrace provides). Do you not get those?

bad_login3• 12 years ago

For 4 if i run from the command line (racket 5.93) i just get the contract violation message, which don't provide positional informations, it's not usefull when you have a list contract error with dozen of uses in a file.

For 3 i mean the words like 'visiting', 'instantiated', the phases, the syntax transformer there are many things to grasp. For instance i used to believe that phase 1 bindings where the functions executed by the expander instead of the one defined by define-syntax.

For complex macro i just expand it that's fine.

Other point the continuation is hard to grasp, i really understand when i see http://www.infoq.com/presentations/continuations-web-os, the key point that help me is the fact he mentions continuation capture also the exit.

Another flaws i didn't mention is messages of typed/racket could be hard to understand especially one involving parametric function, this problem occur time to time in the mailing list. I know you take this kind of problems seriously.

A point why i like racket is because it's lexical scoped but also let me precise the portion i want more dynamism in with parameters or with eval + namespace.

Racket also miss some tooling the one come in mind is coding standard checker and formater, it could be done with free-identifier=? and have some rules. New macro could write their associated rule as metadata in a submodule. Is it doable, i mean technically not the fact to expect macro writer will write such rules?

MrBuddyCasino2• 12 years ago

Ah, someone with Clojure experience. I wanted Clojure to be my next language to learn, so now I'm curious why you ditched it in favor of Racket?

Especially:

- Whats the concurrency story for Racket?

- If I wanted to code my REST endpoints in Racket, are there competitive libraries available?

logicchains• 12 years ago

Regarding the Racket concurrency story, it has places; http://docs.racket-lang.org/reference/places.html.

"A place is a parallel task that is effectively a separate instance of the Racket virtual machine. Places communicate through place channels, which are endpoints for a two-way buffered communication."

So places are somewhat like Erlang processes.

Distributed Places are also interesting: http://docs.racket-lang.org/distributed-places/index.html

bad_login3• 12 years ago

I ditch clojure because i wanted something with a more meta-language capabilities (syntax object + racket macro), it also as a llar parser and a lexer lib which i needed when i made the choice.

For the libraries you can checked out yourself at http://pkgs.racket-lang.org, for what i do i don't need one of the library.

For concurrency keep in mind that racket use green thread where clojure use jvm thread so OS thread in openjdk.

I don't what you want to do with clojure, but i think it is a best choice than racket. Clojure as a very opiniated way of how you should write a program and this view reflects in propably every clojure library. The documentation in clojure is lacking but it provide the implementation (on the web page) so the learning is imho faster especialy if you are new commer to functional programming. The other advantage is the leverage it get from the jvm in term of performance use of the java lib.

kazinator7• 12 years ago

Check it out. For five years I have been developing a tool called TXR. It's a "Unixy" data munging language that is ideally suited for programmers who know something about Lisp and would like to move away from reaching for the traditional stand-bys like awk, sed, perl, ...

You do not have to know any Lisp to do basic things in TXR, like extracting data (in fairly complicated ways) and reformatting it, but the power is there to tap into.

In TXR's embedded Lisp dialect, ("TXR Lisp"), you can express yourself in ways that can resemble Common Lisp, Racket or Clojure.

You can see a glimpse of this in this Rosetta Code task, which is solved in three ways that are almost expression-for-expression translations of the CL, Racket and Clojure solutions:

http://rosettacode.org/wiki/Self-referential_sequence#TXR

Or here, with syntax coloring:

http://www.nongnu.org/txr/rosetta-solutions-main.html#Self-r...

If you closely compare the original solutions, you will see that certain things are done more glibly in TXR Lisp.

picardo• 12 years ago

Is it just me or is this page entirely blank? I poked through the source for quite a long time, but couldn't undo it. The text is there. There is something in the CSS that obscures it in Chrome. So annoying.

einhverfr2• 12 years ago

I am learning Perl's FP features and really liking it, and teaching myself common lisp. I enjoyed the article quite a lot actually.

I find it is very hard to define functional programming for many people but this is what I have come to explain to people:

Functional programming means thinking in terms of mathematical functions in the f(x) sense. Once you get that basic promise, that for any given input you have a single correct output, then it transforms the whole way you think about and designing your software.

The better I get with lisp, the more everything else changes. I may have to try Racket.

innguest6• 12 years ago

I think your explanation is excellent for getting the point across. All other nice things that we get in FP derive from the "mathematical functions" fact you stated. It's also good in the sense someone can then ask you "how is it that using mathematical functions transform the way you think" and now you have their attention and interest. :)

raiph• 12 years ago

What about spending a few minutes exploring P6 and providing feedback about it to Larry Wall et al on #perl6?

One easy way follows (for you or anyone else reading this who is curious about P6). Preferably between about noon and midnight GMT (so you're more likely to catch Larry Wall, nick TimToady) visit the freenode IRC channel #perl6 (eg go to https://kiwiirc.com/client/irc.freenode.net/perl6 and enter a nick) and enter 'hi'. There are on channel evalbots and folk who will be happy to show you a well designed and continuously improving Perly blend of FP, OO, etc.

Yesterday's log is at http://irclog.perlgeek.de/perl6/yesterday. Hope to see you in the log. :)

rodrigosetti• 12 years ago

Nice write-up. I really like Racket, but never had a chance to use it in a professional project so far.

By the way, Scribble (item 7) is an implementation of Literate Programming - a feature is some other languages too. In Haskell, for example, you can write programs in Latex with embedded code.

59nadir• 12 years ago

I think it's kind of sad that most of the comments in this thread are about other languages than Racket and only barely touch on the articles points (mostly the stuff you don't need to actually try the language (or any lisp) to comment on). I think it says a lot about what the crowd on HN is really all about.

GFK_of_xmaspast• 12 years ago

It's kind of interesting that the author's examples of 'woah! look at all these cool packages' include plotting, unit testing, and a gui. Those standards feel a little low to me.

Why Racket? Why Lisp?

Related Stories