The Lisp Curse (2011)
winestockwebdesign.com
winestockwebdesign.com
These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for.
For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.
It is not for embedded systems, not for Android (last I checked, it was very slow), and not for browsers. I believe that ClojureScript is probably what's going to take the crown, eventually.
Still, Clojure or ClojureScript missing a lot of things from Lisp. Restarts, for instance.
For example, if it wasn't for the existing JVM ecosystem of tools and libraries, I would probably end up creating my own undocumented, unportable, bug-ridden implementation of 80% of Netty. Instead, I just use https://github.com/ztellman/aleph
I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: https://www.youtube.com/watch?v=8X69_42Mj-g and https://www.youtube.com/watch?v=0rSMt1pAlbE
You've instantly inspired me to change career paths. This weekend I'm going to set up a home chemistry lab so that I may one day contribute to the amazing body of work you've started.
Does anybody on HN have some recommendations for learning intermediate chemistry? or setting up home labs? Just for context, I have math/CS degrees and have already taken introduction courses to physics, chemistry, and biology.
If you're interested in theory, then it's a whole other thing.
(I'm a chemist.)
But UCLA is right down the street; I'll see what they have to offer.
Thanks for the tip!
Every couple of years I spend a couple of months with Lisp and then decide that I actually want to use Lisp to generate code in other languages. Recently I've been on a modern C++ kick, and have been really amazed at how Clang and LLVM are being used to do code indexing.
So, C++ + CL + LLVM + scientific computing ... wow!
"C++ templates are to common lisp macros as IRS tax forms are to poetry" so true.
Having spent time at the MIT AI Lab and having co-founded a company whose principal product was a Lisp/C hybrid, I think the challenge with mainstream adoption of both Lisp-like and functional languages is the syntax. There's an element of "don't use a programming language that's hard to hire for" but I think that's secondary as it never bothered us or posed a real problem.
Naughty Dog's Crash Bandicoot games (which I also worked on) used Lisp for all the character control logic.
They switched to C++ because it was too hard to find good lisp devs.
Dan Leibgold gave a talk about their system at RacketCon a few years ago: https://www.youtube.com/watch?v=oSmqbnhHp1c
Ironic(?) considering there is almost no syntax to Lisp.
Using Racket:
(if bool then else) instead of (if bool then) or (if (bool then) (bool else))
(if (> x y)
(x)
(y)) ;fails for numbers because (x) is considered a function call (even though 3 is an invalid identifier and thus can be assumed to be always be a number).
(define (fun x y) (...)) instead of (define fun (x y) (...)) or (define ((fun (x y)) (...)))
Just because I'm not using {}'s here and infix there doesn't make it any less syntax. That's just the two most basic forms too; bring in loop? forget about it. This also ignores things like '(@,) or (x . y) but I'm not a lisper so I don't know how often that actually comes up
https://common-lisp.net/project/iterate/
Even the ITA/Google style guide says to avoid loop if possible:
Almost every macro in Lisp provides syntax.
It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.
(func arg1 arg2 (func arg3))
But Lisp has a few special forms and zillions of macros. Most of them are syntax.
Lisp has IF. What is the syntax of IF?
IF form then-form else-form+
cond {clause}*
clause::= (test-form form*)
defun function-name lambda-list [[declaration* | documentation]] form*
lambda-list::= (var*
[&optional {var | (var [init-form [supplied-p-parameter]])}*]
[&rest var]
[&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]]
[&aux {var | (var [init-form])}*])
> It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.
What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.
Exactly. The data syntax if what most people worry about. The names of the verbs (funcs/methods/etc.) may change from language to language, but the data syntax is what trips people up. I think Lisp has one of the simplest and clearest. There are very few cases of "oh you can't write that there, only nouns are allowed in that position".
I agree with your point, but I think we're arguing slightly different points here ;)
(lambda x (+ x x))
(cond (> x 2) (+ x x))
(if (> x 2)
(do-this when-true)
(also-do-this when-true))
That is to say, a problem with s-expressions is that they are so regular that everything looks the same, and when everything looks the same, it can become an obstacle to learning. Mainstream languages are not very regular, but they are more mnemonic. I think Lisp works best for a very particular kind of mind, but that for most programmers its strengths are basically weaknesses.
(if (> x 2)
(do-this when-true)
(also-do-this when-true))
x > 2 ? doThis(whenTrue) : alsoDoThisWhenTrue();
x > 2 ? doThis(whenTrue) ; alsoDoThisWhenTrue();
If not, how is the macro different other than implicitly changing the evaluation?
for a more simple example, why is the idiom CALL-WITH-FOO (implemented as a function) not syntax while WITH-FOO (implemented as a macro) is? What precisely is syntax is somewhat nebulous (if I use a regex library in C, have I added syntax to the language? Regexes certainly are syntax, despite being wrapped in a C string).
(def (fun x y) (...)) is syntactically different than (def fun (x y) (...)) even if they are semantically equivalent.
syntactical ( ) isn't actually a procedure call we can see this in (define (id x y) (..)) or (let ((x 3)) ...) in the theoretically pure Lisp semantically it's just a leaf in the tree but as part of an if-block in a real language it gets treated as procedure call even if it makes no sense.
The Lisp syntax is defined on top of s-expressions.
For example Common Lisp has a CASE operator. That's the EBNF syntax:
case keyform {normal-clause}* [otherwise-clause] => result*
normal-clause::= (keys form*)
otherwise-clause::= ({otherwise | t} form*)
(case id
(10 (foo))
(20 (foo) (bar))
(otherwise (baz)))
Every special operator and every macro provides syntax. Since users can write macros themselves, everybody can extend the syntax. On top of s-expressions.
list -> ({symbol | number | string | list}*)
* using SBCL: (defun foo (x y) (...)) instead of Racket (define (foo x y) (...)) is again an example of syntax.
(f x)
f(x)
(* (+ a b) (+ c d))
(a + b) * (c + d)
Math papers usually use neither the first nor the second.
they use:
(a + b)(c + d)
(+ (* a b) (* b c))
(a * b) + (c * d)
ab + cd
Of course, since in lisp + and * are variadic rather than binary operators, they are a lot more like the pi and sigma operators applied to sets in mathematics than binary operators. Which are prefix, not infix. So, there's that.
(* (+ a b)
(+ c d))
Also, * and + in the former, aren't strictly the same as in the latter. * and + take an arbitrary number of parameters in CL. From [0], `(* )` => `1`. I can't test, but I believe `(* 2)` => `2` (the spec doesn't describe the case of a single parameter, unless I'm missing it). `+` is the same, but `(+)` => `0` instead, it's identity value.
Order of operations is made more explicit, and, I've found, it's more useful to think of `+` and `*` as `sum` and `product` rather than `plus` and `times`.
[0] http://www.lispworks.com/documentation/HyperSpec/Body/f_st.h...
[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.h...
I would venture to say that the reason infix notation is naturally preferred is related to our psychology, the same way most human languages are SVO (Subject Verb Object) or SOV. VSO languages (Lisp like) are less prevalent.
In general my opinion is that when a majority vastly prefers one alternative, there is usually a strong reason for it (even if it may be irrational) and it's foolish to go against the grain.
Java is SVO.
C is VOO too.
$ sbcl
This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
> (ql:quickload 'infix)
; Loading package
(INFIX)
> #i(1 + 1) ; addition
2
> #i(2^^128) ; exponentiation
340282366920938463463374607431768211456
> (defun factorial (x)
#i(if x == 0 then
1
else
x * factorial(x-1))) ; infix function call
FACTORIAL
> (factorial 5)
120
> #i(factorial(5) / factorial(6))
1/6
> '#i((a + b) * (c + d)) ; Put a ' before the #i() to see what code is generated
(* (+ A B)
(+ C D))
[1] - https://www.quicklisp.org/beta/ [2] - Don't know if there is a similar package for Scheme.
I have to agree with others in the thread that infix in Lisp/Scheme is not the convention, and IMO an awkward fit. Don't recall encountering infix in any published/shared code I've seen, it may exist, but to learn Scheme becoming comfortable with s-expr notation is definitely necessary.
However, there is SRFI 105[0] which describes "curly infix expressions". It's implemented in Guile 2.x, possibly available in a few others but evidently not had a lot of uptake among Schemes.
[0] http://srfi.schemers.org/srfi-105/srfi-105.html
Edit: added URL
Pretty much the whole language is based on Polish notation. The sooner you realise that + - * / are just function names like any other, the better you'll do.
For example:
(+ 1 2 3)
in plain symbols is just:
(function parameter parameter parameter)
But if I were to write my own addition function:
(addition 1 2 3)
it would also be:
(function parameter parameter parameter)
and so is:
(http-request "http://www.google.com")
(function parameter)
The Lisp syntax is so incredibly controversial, and that fact itself is incredibly strange to me. I see it as a pragmatic engineering decision: let's represent source code as syntax trees, and then sophisticated editing modes become straightforward, macros become straightforward, and the syntax becomes very uniform.
This big thread indicates another reason Lisp isn't popular: because people keep arguing back and forth about the textual syntax, rather than discussing actual experiences with using it.
Symbols and lists behave differently depending on the context:
Examples for Lisp snippets:
(foo bar baz) ; it could be a macro, function or special operator form
(quote (foo bar baz)) ; here it is data
(defun do-something (foo bar baz) (a b c)) ; here it is an arglist
(defun do-something (a b c) (foo bar baz)) ; one element later it is a form
This is puzzling for a lot of people. A few never really take that hurdle.
(+ x y z a) instead of (x + y + z + a)
Therefore I would say the answer is simply familiarity and concern for the audience.
(+) 4 2
vs.
(+) <$> Just 4 <*> Just 2
liftA2 (+) (Just 4) (Just 2)
Indeed, most math syntax (in my experience) has a very explicit reason why it's used: historical circumstance, convention and common tradition.
As a mathematician I'd love to use it in my papers, but no reviewer would accept such a paper.
But I'd like to point out that in your second example the parentheses are needed because infix notation is inherently more complicated.
In the first example however, the notation is far simpler: a simple list of function plus zero or more arguments.
c = sqrt(a*a + b*b)
(set! c (sqrt (+ (* a a) (* b b))))In this example, the advantage is on the C side, because pretty much everybody who knows any math knows that multiplication has precedence, and they can just read that syntax. If you have to go look at the precedence chart in K&R or Stroustrup before you know how to parse the expression correctly, well, then the Lisp approach is probably more efficient...
(define c
(sqrt
(sum (sqr a)
(sqr b))))
Easy to read as you see and easy to understand. This:
c = sqrt(a*a+b*b)
Infix notation works better when it is applicable. Limiting the number of parentheses is also best when possible.
You can add parentheses and make it less compact if you want. You could theoretically write c=sqrt(axa+bxb) as:
c =
sqrt(
((a *
a) +
(b *
b)))
You are now arguing against parens. You can have mostly prefix syntax without parens, with blocks delimited with indentation only. Scheme's sweet-expressions[1] are one such example. Anyway, please take my example, remove the parens and check if your argument still applies.
If it does, then it's down to the function names and your (common) misconception that "+" or "^" is somehow more readable, easier to understand or something than "sum" or "sqr". Where I simply disagree. BTW: why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?
> Limiting the number of parentheses is also best when possible.
No. It's only best if it aids readability. This is something that Lisp does rather well actually - there are many examples of equivalent Java and Clojure expressions where Clojure version has half as many parens. Getting rid of parens for the sake of getting rid of parens is counterproductive.
And yes you can remove the parentheses, but not only does no one do that, it still takes up 6 lines. And then you have significant whitespace too.
>why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?
Because that's universal and standard for math notation. But also sqrt only takes one argument. If it took two arguments, then it would be perfectly reasonable to add an infix operator for it too. Many languages do add infix operators for everything from combining strings to ANDing booleans, etc, because they are so much more readable.
c = sqrt(a^2+b^2)
vs.
define(c, sqrt(sum(sqr(a),sqr(b))))
def getMaxValue(numbers):
answer = numbers.first()
for (i in xrange(numbers.length)):
if (numbers[i] > answer):
answer = numbers[i]
return answer
vs.
(defun get-max-value (list)
(let ((answer (first list)))
(do ((i 1 (1+ i)))
((>= i (length list)) answer)
(when (> (nth i list) answer)
(setf answer (nth i list))))))
if you could only use python functions:
defun(get-max-value, [list],
let(answer,first(list)),
do( (i,1,(1+ i)),
(>=(i, length(list)), ans),
when( >(nth(i,list),answer),
setf(answer,nth(i,list)))))
defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list))))) (defun get-max-value (list)
(reduce #'max list))
(defun get-max-value (list)
(loop for element in list maximize element))Any language where you write an entire function as a huge one liner expression with functionality in nested function calls is hard to read. It's the behavior, not the syntax per say.
What the actual behavior is doesn't matter as much, even if you can reduce both of them to one liners in many languages.
ex:
def get-max-value(list)
reduce(:max, list)
endIn actual Lisp practice, one uses macros, special forms and function calls.
You seem to have failed to understand the difference.
There are two REAL reasons why Lisp is harder to read than some other languages:
* the syntax looks and works slightly different and most programmers have been trained to other programmning language syntax. With training, this is less a problem.
* Lisp uses a data syntax as the base layer of the programming languages and encodes programs as data. So the syntax of Lisp comes on top of s-expressions. Very few other programming languages are doing that and as a consequence it complicates a few things. The user of Lisp has to understand the effects of code as data. This is something you don't have to understand in Java or Python. It can be learned, but it has to be learned.
At the same time, this code as data principle of Lisp gives a lot of power, flexibility and new capabilities. It makes Lisp different and in some way more powerful than Java or Python. The added power comes from easy syntactic meta programming in Lisp, which neither Java nor Python provide. This has also consequences for interactive programming, since programs can be written and manipulated by programs under user control.
This does change the situation somewhat.
I'm not sure if this is what you're talking about but there actually is a Lisp where you can call Python functions. It's called Hy[1] and I encourage you to take a look, it borrows some good solutions from Clojure, but generally is quite an acceptable Lisp :)
Why do mathematicians not use s-exps but syntax that is much more similar to C? Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.
Please tell me why should I care. No, really - I'm a programmer, not a mathematician.
> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +.
Citation for this?
IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.
> And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.
Ok, so 2 ("sum" vs. "+", 3 vs. 1 char) additional characters are bad, because they take longer to read, but for example 3 additional characters here:
(+ a b c d)
vs.
a + b + c + d
> Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.
I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning.
For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).
There's another guy who explained this at length
http://c2.com/cgi/wiki?LispLacksVisualCues
Search for "top" throughout the page.
> (+ a b c d) vs. a + b + c + d
Yes. But as explained in my other comment, that's not optimizing for the common case.
I don't think there is a difference in speed between reading "sum" and "+". You don't read the word "sum" letter by letter: you see it as a whole token and your brain recognizes it instantly.
> For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).
You're talking GUI, which is different than writing and reading code. There are, for instance, much less GUI elements visible on the screen than there are identifiers even in a short snippet of code and there is much more context available for deduction in the code than in the GUI. I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.
And you don't think (sum (mul a (minus b c)) d), or (+ (* a (- b c)) d) for that matter, is more readable than a * (b-c) + d, do you?
> There are in fact, a lot of uses of sums and products, so after a while, they are pretty naturally.
I think you are talking about summing up a collection (like, an array, a matrix, etc.) as opposed to building an expression tree. Of course, sum(myIntList) is just fine. That's a whole different story.
There are also the rare cases where you have to sum, like 6 integers. (sum a b c d e f) might not be worse than a + b + c + d + e + f. But that's by far not the common case in most problem domains. The common case is like a*(b-c) + d.
What? You were serious? Um, no. Just no. Your way is not easier to read - at least, not for (I would guess) 95% of programmers, and 99% of humans.
Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what
c = sqrt(a*a + b*b)
Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Or is it just easier to read for you?
We're either talking about objective readability or personal familiarity. What you say is that, after extensive training for many years, it is easier for people to read notation they were trained to read. This is both true and utterly uninteresting.
What is interesting, though, is how much training you need to read prefix and how much training you need to read infix. It's obvious that infix takes more time to learn: operator precedence and things like using "-" in both infix and prefix forms make it objectively more complex than prefix notation. You just forgot how much time you spent learning it.
> Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math?
Again, this is not interesting at all. You're talking familiarity, not readability. Of course, it's easier to read something you've been taught to read. To make this more objective, take an elementary school kid - who wasn't exposed to years long infix propaganda - and check both notations' readability with them.
Personally, I learned to read just about any kind of notation used in programming. From my observations, there are only minor differences between the speed of comprehension when using different notations - once you've trained enough. The difference is how much training you need. I can tell you that reading J - an infix language, it's an APL descendant - took me much, much longer to master than reading Lisp.
Maybe the ordering of something is being forced. Maybe something else is going on, but whatever it is requires more thought than things that are parentheses free.
So you look at Lisp and your brain locks up the brakes, with "WTF is going on here??? I'm out".
It's like going from Arabic numerals to counting by groups of five; initially, it feels like you're losing expressive power. And, of course, at a glance, you can't read "|||||||||||||||||||||||||||||" as quickly as you can "28".
http://c2.com/cgi/wiki?LispLacksVisualCues
After a brief period of usage 'the parens disappear' and you just read the code by indentation.
I was dumping ASTs as part of a little language project recently and my first impulse was to render them as S-expressions. Alas, it just wasn't readable; I couldn't make any sense of it. Indented YAML style lists, though? The structure pops right out and the information I wanted was immediately obvious. There were no constraints here, I was free to render text in any way that suited me; the Lisp style syntax just wasn't helpful.
(I think they are replaced in modern versions but my point still stands as I remember the old ones, not the new)
I don't think there's an equivalent to cddadr for example, but at that level of deconstruction you're better off abstracting the data structure (maybe a struct [2]) or using some other mechanism like match [3]
[1] http://docs.racket-lang.org/reference/pairs.html?q=second#%2...
[2] http://docs.racket-lang.org/reference/define-struct.html?q=s...
[3] http://docs.racket-lang.org/reference/match.html?q=match#%28...
In 5 characters with cadar you can express walking along a tree structure to get exactly the node you want.
However, Lisp as in Common Lisp most certainly has a good amount of syntax. And let's not forget macros which amount to user defined syntactic extensions.
Here are some examples of syntax built into the standard:
Lambda lists have varying syntax depending on context. http://www.lispworks.com/documentation/lw70/CLHS/Body/03_d.h...
Declarations have both standardized and implementation defined syntax for introducing information into the compile-time environment: http://www.lispworks.com/documentation/lw70/CLHS/Body/03_c.h...
Type specifiers introduce new syntax for both standardized and user-defined types: http://www.lispworks.com/documentation/lw70/CLHS/Body/04_bc....
Logical pathnames: http://www.lispworks.com/documentation/lw70/CLHS/Body/19_ca....
Feature expressions: http://www.lispworks.com/documentation/lw70/CLHS/Body/24_aba...
And of course, programmable reader macros which is how syntax for every single language primitive in the language is introduced: http://www.lispworks.com/documentation/lw70/CLHS/Body/02_d.h...
Here's an example of a complex standardized macro with its own domain specific syntax (loop): http://www.lispworks.com/documentation/lw70/CLHS/Body/06_a.h...
Let's not forget that most of what one might think of as built-in features in Common Lisp are actually standardized extensions to the language built with macros.
All of the power, expressivity, and extensibility of Common Lisp is what makes it my favorite programming language. It's what makes everything like above possible and gives power back to the user. But ignoring the syntactic complexity will not win us any followers!
TLDR: Common Lisp isn't simple, but it exposes one of the most powerful and empowering programming environments we have.
That's what I was talking about. The language, being programmable, especially with read macros, can be used to create a very syntactically full language, but at it's basic core level, there is really just '(', ')', '.' and symbols.
But I generate and validate that Ruby code with Common Lisp -- in other words, I write Lisp that writes correct, idiomatic Ruby.
I would be very surprised if I were the only person doing this.
Lisp is more like research language than implementation language for bean counting apps. Better question is what bleeding edge things have originated, are being done or have been done in Lisp.
John Carmak is doing VR research with Racket.
Christian Schafmeister doing molecular metaprogramming.
Raytheon implemented a signal processing analysis pipeline for missile defense in Lisp
Commercial Lisp vendors keep lists of some of their customers. Specialized Cad programs like Bentley PlantWise are not popular but they are very complex.
There's also cl-abnf from the same author and project which is another great example of the expressive power of common lisp.
Also, everything Fernando Boretti does is awesome ;)
https://github.com/eudoxia0 http://eudoxia.me/article/common-lisp-sotu-2015/ https://github.com/dimitri/cl-abnf
- https://github.com/asciinema/asciinema-player
- https://precursorapp.com/ (not open-source)
aka. Clojure (...) compiled to JavaScript
You stopped reading a few words too soon :)
The GP says "ClojureScript, a.k.a. Clojure ... compiled to Javascript, which (I believe) is accurate.
Edit: Urbit has a Lisp (http://urbit.org/)
The music on your home page reminds me a bit Utopia soundtrack (like the sound of the frog).
http://kruhft.bandcamp.com/album/listenerBrendan Eich is a bit too.
I'd only call this anecdote, but one or more benchmarks assert that cl-ppcre, common lisp's perl-compatible regex implementation, is faster than any other, include perl's.
The larger question I'm intuiting from your post, "Why doesn't language power make a difference in practice?" I don't have an answer to.
Depends on your definition of "make a difference in practice". If you mean "make the language become one of the dominant ones", yeah, that doesn't seem to have happened. Either Lisp is less effective in the large than one would expect from its power, or it's less powerful in practice than people think, or power has almost no relation to language dominance.
But if you mean "make a difference to the user", well, it lets the user more easily write the program that the user wants to write. In practice, that makes a difference - to that user.
That question would be: what programs are written in <LANGUAGE> that couldn't benefit from being rewritten in another language?
And most often, the answer to that question is none.
Because languages matter a lot less than language fanatics want you to think.
As for Lisp, I used to be a total fan until I realize the importance of a sound static type system, and now I will never go back. Lisp will never go anywhere because this is the 21st century and we know now that static type systems are an absolute requirement for modern programming.
I am not saying that you are wrong in liking static typing, but arguing that dynamically typed languages are non-starters in this decade is a statement that is easily disproven by the existence of Javascript.
What remains is that the Lisp design contains numerous elements which are great ideas, which, if they are nicely implemented in their proper form, give you a great programming language.
That doesn't translate to being able to return to the time when you're showered with institutional money to just go wild hacking on whatever you like.
Some of the most popular languages today, from a web development perspective at least, are JavaScript, Ruby, and Clojure.
One of them is an actual Lisp with full-blown macros and a lot of Emacs users.
The others are also extremely expressive, dynamic, and amenable to metaprogramming.
I don't think there's a single, simple, beautiful explanation for why Common Lisp isn't more widely used. Mostly it just has an undeserved bad reputation... partly because articles like this show up all the time, reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or whatever.
- Clojure user :)
1. Ruby + Clojurescript have prominent, opinionated community leaders who spend an immense amount of resources on proselytizing and preaching agreed-upon best practices (hell, 90% of Ruby development is done within a framework that all but forces you to write code in a particular, proven way).
2. As for JS: web developers are all forced to use it, which naturally leads to less fragmentation (if Chicken Scheme was the only scripting language available on a UNIX OS, by necessity some libraries would become dominant). Even then, most large enough JS codebases are ghastly.
---
Contrast that with Lisp/Scheme. I am now learning scheme, and love the language to point that it's depressing not to get to work in it on a daily basis. That said, the most impenetrable aspect of scheme/lisp is not the language, it's the community:
I don't think I'm exaggerating if I say that the entirety of the scheme community (with the exception of racket) is scattered into completely fragmented groups of under 20 individuals, all of whose landing pages look like they were designed in 1993, filled with broken and outdated links; libraries are maintained and abandoned willie-nillie, communication happens mostly in the form of mailing lists... where do I go to watch a talk? where do I read about latest libraries and projects? what are some of the agreed upon best practices?
"Read the SRFI" is not documentation (if you can figure out the relevant SRFI in the first place).
Example 1: this is the package manager Gambit Scheme recommends http://snow.iro.umontreal.ca/ -- a noble attempt at unifying scheme packaging across implementations. DEAD (as far as I can tell). And why? Because each scheme implements its own unique module system, implements its own unique subset of RnRS.
Example 2: need an LMDB library? Well, the chicken scheme version is a port of a version that exists only within the LambdaNative framework (which is implemented in a different scheme). Why does it have to be ported? because the two schemes have an incompatible way of handling c-bindings. So one can't just write a library that's R5RS compliant and assume it works across implementations. So we end up with two developers maintaining two versions of the same library, instead of both focusing on the same one. And when one of them decides to start using leveldb on his projects instead? The project is DEAD.
(I'm not arguing for a singular implementation of scheme. Part of the beauty of the ecosystem is the variety in implementations suited for different purposes. But so many of the incompatibilities are trivial, and are a community problem, not a technical one. If everyone agreed to implement, say, R7RS-small and better efforts were made to standardise the trivial, like how modules are defined, or how c bindings are to be declared, we could have a central repository of cross-compatible packages.)
The problem isn't the language or its power, it's a lack of community building efforts, which makes it extremely frustrating for a newcomer, even one who is absolutely enchanted by the language; and downright prohibitive for a company to bet on scheme.
Imagine you are a project manager, would you gamble the success of your company on a language whose libraries, as far as I can tell, almost ALL have a bus factor of 1?
tl:dr scheme needs a modern, newcomer-friendly, robust community portal. When there is one link I can give to people where they can find: practical tutorials, lectures, a quick overview of the ecosystem, portable libraries, books and articles full of tips and best practices, charismatic community leaders (who explain things in simple terms that don't scare off the uninitiated, as opposed to trying to convince you how much smarter Lisp programmers are)... then there will be no reason for the language not to be widely used.
The book The Scheme Programming Language http://amzn.com/026251298X is a good overview of the main libraries and language features, and has lots of examples.
Other than that, I've been learning mostly through google and trial and error.
You can find solutions to the first 7 chapters here: http://playpen.sixbit.org/studies/aop/
At the end of a day working on the Lisp portion, which assembled sketched lines into a CAD model I went home happy and relaxed with a feeling of accomplishment. At the end of the C days I felt tense and slightly worried, thinking about ways of more cleverly detecting what the user was trying to sketch on the tablet.
In my 20+ years of programming I never returned to Lisp and I don't quite know why I don't miss it. I have a vague nostalgia for Lisp but I think modern programming languages give us enough tools to get our job done without feeling too much shame about abandoning the purity of Lisp.
Also, the proselytizing has not helped. I think the "Blub paradox" article embodies the mindset that was ultimately the nail in Lisp's coffin.
I have a lot of warm fuzzy feelings about Lisp as well, but a lot of Lisp advocacy has been of the "One True Language" variety as opposed to "right tools for the right job, and here's why Lisp might be the right tool for you". It doesn't affect my perception of Lisp, but it doesn't help market it either.
The author makes an example of the many Object Oriented (OO) systems, but he performs some bait-and-switch there. Those many OO systems were for _Scheme_, not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time, Scheme was focused on being the smallest possible Lisp. Common Lisp on the other hand, while it briefly went through an OO experimentation period, really only has one OO system: CLOS.
Also, the whole Emacs line is off target too. What has that to do with the expressive power of the language? And why ignore the two extremely powerful commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't successful because there isn't a better free IDE?
And the "lone wolf/80%" isn't doing it for me either. The Common Lisp specification was the work of many bright minds and is brilliant. And it stands in complete opposition to the situation the author attempts to describe.
I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has been successful, or that Common Lisp in particular has been. If the standard is mindshare and acceptance they have not been successful. There are histories and causes aplenty, but being too powerful is not one of them.
I wrote it during a period when I was especially fascinated with Lisp and got caught up in the theorizing to which the Lisp community can be prone. Nowadays, I freelance in front-end web development and doing Lisp hacking is something that I put on the back-burner.
I stumbled on LISP and Scheme around the time I graduated from high school in 1991. I became interested in LISP from learning about classic AI research. I found a professor my first year in college who mentored me in an independent study of LISP. I then learned scheme doing a self-study with SICP.
Despite all of this, I've never done any paid work in LISP, and I've spent the majority of my career writing C. I can't write a LISP program from scratch from memory any more.
However, I've found that the ideas of functional programming and the concept of the read-eval-print loop have colored my understanding of software design in a really positive way. I remember when I learned TCL in the mid 90s it was immediately obvious that TCL is just LISP on strings (read-substitute-print). Lua is also very LISP-like, with tables instead of lists.
There was, around 1990, a fad for "extensible languages".[1] It died, because the resulting code was so hard to read, with program-specific syntax for each program. Don't go back there.
> resulting code was so hard to read,
DSL code is the easiest to read and maintain. No "general purpose" language would ever match this.
> with program-specific syntax for each program.
As if it's something bad.
> Don't go back there.
You failed to understand the entire concept.
I don't think so. As the article states, this is a social/community issue, if every application has it's own language and syntax that is a huge barrier for others coming to work on it. You might not care about that but most large pieces of software are not written by one person. Beyond that you come to issues of code and skill reuse. A lot of people dislike the expressibility of Go, but it's hard to write code that someone else can't easily come and read and understand.
The article is plain wrong.
> if every application has it's own language and syntax that is a huge barrier for others coming to work on it
And this is quite obviously not true. A well designed (note the emphasis!) DSL makes any app/problem domain/library/whatever much more accessible than any kind of a "general purpose" language can. Simply because DSL does not obscure the essence of the problem.
> Beyond that you come to issues of code
Code reuse with DSLs is way beyond anything the inferior languages can achieve. I witnessed cases where 30+ years old DSLs got revived by reimplementing them from scratch, immediately making an entire (huge) code base available on a new platform, with new tools and bells and whistles.
> and skill reuse.
One should never care about those pitiful "language" skills. They're worthless.
I think empirical evidence is that DSLs are easy to make not readable, especially as they evolve. Then again, that's true of almost everything, including assembly language programming, structured programming, object oriented programming, and functional programming (did I miss anything?).
Every application already has its own vocabulary, which is a huge barrier for others coming to work on it (seriously: try to check out the Linux kernel, or Firefox, or the Python interpreter, and try to start hacking on them).
Macros and custom syntax can help make that vocabulary more understandable, in the same way that functions can help make control flow more understandable.
Turing's original Universal Machine (you know, the moving read/write head over an indefinitely long tape of symbols) is not expressive at all; a simple task like adding two integers on that machine requires a completely arcane, verbose piece of gobbledygook to be prepared on the tape, where you cannot tell at a glance which part of it is the program, and which is the integers to be added. It is less expressive than 4 + 4 in a calculator language that doesn't have loops.
Expressive power is, in its barest essence, the freedom to assign an arbitrary meaning, from some domain, to a new combination of symbols, such that every symbol in that combination refers to some entity in that domain only.
It behooves us to have a general-purpose language with as much expressive power as we can get our hands on.
It is not hard at all to add restrictions in domain languages created inside an expressive language. For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc.
I've written one such assembler in Common Lisp. It was rather straight-forward and generated nice code. Debugger came practically free.
Lisp is a language for symbolic computing. Values are not so valuable as computations and trees. If the level you're working at is too restrictive you're free to invent a new algebra for symbols at a higher level in terms of the lower-level primitive symbols. It's the same power one gets from manually calculating sums to inventing a language for expressing all sums. How you choose to represent things has great power in your ability to reason about them.
Check out Henry Baker's Comfy 65 Compiler[1] to see how far a little lisp changes an assembler language.
[1]: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pd...
But it won't enforce those things at compilation time in the type system, because it doesn't have one. You might have a macro that checks them, but it would be ad-hoc.
But [Lisp] won't enforce those things at compilation time
in the type system, because it doesn't have one.
You can very easily write an assembler in Haskell that doesn't verify any of that stuff statically. Learning to do advanced kinds of static verification with Haskell's type system is actually rather difficult, and usually requires language extensions.
Using a macro that checks those things seems like it could be a very pragmatic way to provide safety. It might also let you verify properties that would be hard to figure out how to verify using only Haskell-style type checking.
Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification of type class laws, for example, since they can't be proven in the type system.
Perhaps. But it benefits greatly from being a consistent way of doing things: everyone does their static verification the same way, because the language supports exactly one way of doing it.
> and usually requires language extensions.
Sometimes. But again at least those extensions are relatively standardized, rather than completely ad-hoc as a macro can be.
> Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification of type class laws, for example, since they can't be proven in the type system.
Yeah, that's one of the reasons I'm excited about Idris. But even in your example, QuickCheck is again a standardized way of doing this.
In Haskell land, you can do wonderful things like Servant, the statically verified API server—but that kind of code is very advanced, and written by a shadowy cabal of type level wizards. I think there is less of a standardized way of doing this stuff than one might expect.
I'm not really sure what you mean by "standardized." Common Lisp is an actual ANSI standard... But you seem to be referring to the existence of common practices.
I'm not convinced that the problem you describe is actually a problem, and I'm not convinced that Haskell or Idris will end up being more successful in the mainstream than Lisp.
(I'm a huge fan of Haskell, Agda, and static/dependent typing, for the record.)
Sure, but the conditions that lead you to do that can be arbitrary Turing-complete code. IIRC in unextended Haskell what you can do at type-level is more restricted; certainly you're guided towards a particular way of structuring your constraints. That in turn makes it more practical for other tools to support your constrained sublanguage.
I think the future of programming lies in constrained (BWIM non-Turing-complete) languages and provably correct code. I guess we'll find out.
It's optional for an implementation to provide static checks and optimizations based on type, which is different. "Static type" and "type" are not synonyms.
Common Lisp code is safe by default; you can't use an object of type X as if it were one of type Y.
(That isn't to say that that kind of runtime behaviour isn't valuable or doesn't provide (some of) the same functionality as a type system. But it's not what the word "type" means).
This is true, within a particular paradigm, which isn't the be-all and end-all of what "type" means in computer science.
All kinds of things are type. For instance, "JPEG file" or "alphanumeric character" are both type terms.
You don't get to dictate to everyone one narrow definition of a term that has an obviously broad applicability in numerous contexts.
If we are discussing Common Lisp, and you want to get properly pedantic about what "type" means, the way you can do that is to look up its definition in the ANSI CL glossary, which says:
"type n. 1. a set of objects, usually with common structure, behavior, or purpose."
Or you can use it in a broader way which is compatible with this concept.
If you insist that it means something else which is not compatible with the glossary definition, and you still want to talk about Lisp, then I'm afraid it's not productive; you are more interested in engaging in a conflict about word semantics: which "camp" gets to "own" the ideologically precious word, such as "type".
Usually how we can resolve that conflict is to split our vocabulary into different words. You can have "type", I don't need it; I will call it this other thing that the CL glossary refers to "genus". Now type can be the property of a syntactic term in a program, and genus refers to sets of objects which have something in common.
I'm mostly interested in genus systems, and type systems in their context (agreement between the type of a program term, and the genus of the run-time thing it operates on).
But in any case, any genus-but-not-type system is irrelevant to my original point: that when writing an x86-64 assembler in lisp (as an embedded DSL), any enforcement of restrictions at compile time would have to be expressed as ad-hoc macros, because there is no (language-standard) type system in which to declare them.
$ clisp -q
[1]> (typep nil '(and symbol list))
T
[2]> (typep :foo '(and symbol list))
NIL
[3]> (typep '(1 2) '(and symbol list))
NIL
[4]> (typep '(1 2) '(or symbol list))
T
[5]> (typep 3 '(or symbol list)
What you write in a language has its own de facto language, whether you capture its conventions in a notation or not.
Simply knowing the elements of the language in which that work is done isn't enough. Otherwise you could just memorize a language reference manual and call yourself a software engineer.
Or could just argue that since the program in any modern language is written in UTF-8, and the users know that already, they have nothing to learn.
Which is rather the problem. Types, in particular, are only useful if everyone has them - optional add-on typing has been tried for many languages, but I've never known it be successful.
Typed Racket code often gains a speedup over untyped Racket, since sound typing allows the elision of contracts and other runtime overheads for safety. There is no penalty at all for invoking Typed Racket code from untyped code, either in terms of performance or in terms of what the untyped-language programmer needs to know.
The truth is that Lisp is not the right language for any particular
problem. Rather, Lisp encourages one to attack a new problem by
implementing new languages tailored to that problem. Such a language
might embody an alternative computational paradigm […] A linguistic
approach to design is an essential aspect not only of programming but
of engineering design in general. Perhaps that is why Lisp […] still
seems new and adaptable, and continues to accommodate current ideas
about programming methodology.
The thousand functions in a big C program are just as much a language, as some Lisp macros.
The functions all do something. That something isn't "transform the code", but that doesn't matter; if you're looking at the function call and don't know what it does, you're just as lost.
Basically, if you're reading Lisp, you go from "outside in" and just assume that everything you see whose definition you are not familiar with is a macro.
Well-behaved code follows certain unwritten conventions. For instance, it avoids creating confusion by exhibiting multiple completely independent uses of the same symbols in the same scope. So for instance if we have (frobozz a b) wrapped in a lexical scope where we have (let (a b) ...) in effect, this well-behavedness principle tells us that the a and b symbols in (frobozz a b) refer to these variables. So, we can probably lay aside our suspicion that, for instance, frobozz is redefining some unrelated a in terms of some unrelated b. However, frobozz might be a macro; so we can't cast aside our suspicion that either a or b has its value clobbered. (Same in Pascal or C++, with ordinary functions: frobozz(a, b) could take VAR parameters or references, respectively).
Which is not bad at all. You still have to do it with the programs written in the same language built with different libraries and targeting the different problem domains. In the latter case the language is obscuring the essence of the code.
And if you're using a well designed DSL, and you're familiar with the problem domain, it will be readable naturally, just like a pseudocode.
(and cond1
cond2
cond3)
We already do something similar with our algol-like languages:
if((cond1 || cond2) && (cond3 || cond4)
&& (cond5 || cond6)
&& (cond7 || cond8))
(if (and (or cond1 cond2)
(or cond3 cond4)
(or cond5 cond6)
(or cond7 cond8))There are ways to provide infix independently. That is to say, one person can develop this domain specific syntax, and another can develop or customize an infix engine for it.
In Common Lisp, there is a well known "infix.cl" module that provides mappings like a[b,c] -> (aref a b c), f(x, y) -> (f x y), a + b -> (+ a b) and so on.
This isn't understood as creating a new language as such; it's just a sugar. I think it allows new operators to be added with custom precedence and associativity. Or you can hack it however you want.
I've never seen it used in any production code.
The main purpose it serves is to satisfy people who want to know that it can be done; after that it turns out that they don't actually want it done. They just don't want to work with a language that can't do it.
The only program I'm aware of which actually supports writing mathematics that looks like the mathematics mathematicians write (the actual 2D notation) is Tilton's Algebra: written in Common Lisp.
The various mathematics languages out there fail.
Oh, and not to mention that mathematicians have been trained to work with this:
$\sin{(\frac{\pi}{2}-\theta)} = \cos{\theta}$
n P k = n! / (n - k)!
SML allows you to have an infix function named "P", and Haskell allows something similar, although you have to quote it with backticks and can't use a capital letter to start a function name...
https://en.wikibooks.org/wiki/Standard_ML_Programming/Expres...
https://wiki.haskell.org/Infix_operator#Using_prefix_functio...
(FWIW Scala allows postfix operators, though you'd have to put the n! in brackets)
See Wolfram Mathematica for example.
Also, one of my usual DSL tricks is to allow arbitrary TeX in identifiers, which, combined with the literate programming tricks, allows to write very idiomatic mathematical expressions as a code.
Mathematics isn't written with infix operators alone. Mathematics is written in a fancy 2d notation with all kinds of operator types: infix, prefix, postfix, around-fix, sub-fix, super-fix.
If you look at actual software for maths - several famous ones were written in Lisp like Macsyma, Reduce and Axiom - they provide more than infix.
And DSLs done the right way, via macros, are much better in integrating with tools than any ad hoc interpreted DSLs would ever be able to. You can easily have syntax and semantic highlighting infered, with auto indentation, intellisense and all the bells and whistles. For no extra cost.
No you can't. If the macro is arbitrary code then no tool can offer those things - there's no way to offer intellisense if you don't know what strings are meaningful in the language, and an unconstrained macro could use anything to mean anything.
It doesn't take much imagination.
You know how GNU Bash is customizeable with custom completion for any command, so that when you're, say, in the middle of a git command, it will complete on a branch name or whatever?
Similarly, we can teach a syntax highlighter, completer or whatever in some IDE how to work with our custom macro.
I expect that not that many C++ tools that do not use libclang will remain.
A good example of such a thing would be something like https://github.com/kframework/c-semantics
It's trivial. Any PEG parser I add on top automatically communicates all the highlighting, indentation data and all that to the tools (and it's inferred from the declarative spec, no additional user input is required). Underlying typing engines do the same, for the nice tooltips and code completion. The very compiler core doest the same with all the symbol definitions, dependencies, etc. Easy.
I've got some code published, but not that much in writing, planning to fix it some time later. See the stuff at my github account (username: combinatorylogic). Relevant things there are Packrat implementation, literate programming tools and an Emacs mode frontend.
The way you express DSLs is something that needs to be understood by language tooling, so it belongs in the language spec.
So, in your rot13 example compiler would rat all the new identifiers with their origins to the tools.
How can the compiler know which identifier connects to which origin, unless because the macro complied with some standard/restriction/protocol? From a certain perspective all I'm suggesting is making these protocols part of the language standard - that is, define the DSL that's used to define DSLs, rather than allowing macros to consist of arbitrary code.
Well, by that definition you get exactly the same if the host language of your DSL is statically typed and doesn't use macros. Custom syntax is custom syntax and whether tools/IDEs understand it has nothing to do with the host language.
Of course macro+syntax extension got absolutely nothing to do with what you can achieve in a language without macros.
And, no, you did not understand. Any custom syntax you're adding (if the right tools are used, like mine, for example) would automatically become available for your IDE and all the other tools, because they're reusing the same compiler front-end.
Just being able to execute the macro isn't enough for the IDE though. E.g. if a macro is "rot13 all identifiers in this block" then sure the IDE can run it, but it can't offer sensible autocompletion inside the block without understanding more about the structure of the macro.
EDIT: Which is obviously impossible if you assume a Turing Complete macro expansion language.
While you're technically correct, as a practical matter you won't implement a type system/type checker for all the DSLs you create. (Nor do I believe you'll even do it for anything approaching a majority.). Obviously, I'm using the impersonal "you" here.
Implementing real type systems is hard and mostly rather tedious work.
syntax-parse only gets you so far[1].
Maybe even have a series of examples that illustrate solutions you keep mentioning so others can learn and apply them. Just a thought. :)
If so, then I suppose I misunderstood you original claim, but I won't apologize because your claim was very opaque to anyone who doesn't know you.
[1] An example of what I mean would be xtext.
If you don't have a ready to use language construction framework targeting your meta-language, just build one. Easy.
As for typing specifically, the approach is rather fun and simple. Firstly, you'd need something like Prolog. It's really not that much, you can quickly build a passable implementation in just a couple of dozens of lines of code in pretty much any language. See miniKanren [2] for example. Then, any kind of typing is done easily: write a simple pass over your AST (may require some preparation passes, like resolving the lexical scope - but this is useful for all other things too), that will spit out Prolog equations for each expression node that needs typing. Then execute your Prolog code and get your types back. An implementation won't look any more complicated than a formal specification of a type system in a paper, using the type equations (as in [3]).
[1] https://github.com/combinatorylogic/mbase
[3] http://stackoverflow.com/questions/12532552/what-part-of-mil...
And then you'll get the most powerful programming environment possible - building arbitrarily complex hierarchies of languages, with a cost of adding a new language being close to zero, and with a free support from all your tools, for no extra cost.
Actually, while building such a hierarchy I naturally came to a number of "restrictions", although they're not enforced. I prefer to build compilers using chains of very trivial transforms, each implemented with at most a total language (or a simple term rewriting for most of the cases). It also helps to maintain a nice interaction with the tools.
That can only be true if your supposed "tree" actually contains loops. What language do you know of that generates cyclical parse structures?
https://www.livecoding.tv/burtonsamograd/videos/
See the 'building a language' parts for actual lisp programming, the rest is JS webdev.
Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond, null, atom, lambda and a few others) and macros. The project is an experiment in building a lisp from the axioms and seeing how far one can go without having to add to the underlying lisp implementation (which is in javascript).
That said, even if it were true that the power of lisp turned out to be it's curse, one should be careful to generalize this way about lisp hackers, 80% projects and lack of documentation. The language might tempt you to become the hacker portrayed in this article, but it certainly doesn't fight you should you want to follow best practices.
Members of the Lisp family seem to be judged by a different standard. I don't know why that is.
My perspective: the implementations attest to good documentation and collaboration. SBCL by itself is an admirable artifact with extensive documentation that's been maintaned since 1999 (when it forked from CMUCL).
So what gives?
"...The moral of this story is that secondary and tertiary effects matter....Employers much prefer that workers be fungible, rather than maximally productive...[in regards to creating a larger framework] The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other..."
So here's what I see. I see a lot of frameworks and libraries composed by folks using other languages. Many of these, yes, are much more complete than one, totally-custom-made solution by some Lisp hacker. And yes, large numbers of people participate in creating and maintaining these larger frameworks and systems.
I also see large corporations bleeding cash because they wanted silo'ed, fungible programmers. Got seven architectural tiers, each with its own framework? Hell, you're going to need seven extremely specialized programmers, kid. Time to get on the phone with the recruiter.
So they purchase these specialists. All the buzzwords match. The specialists sit down at the magic frameworks, the ones all the cool kids over the last two years have decided to support. Life is good. For about ten minutes. Then something is required that's not in the frameworks. Or the framework is broken under this one particular edge case.
Suddenly we need somebody who's general purpose again. Except -- and this is especially nice -- that's not the guy we hired. So seven layers of experts sit struggling with seven oddball issues. Googling Stack Overflow. Hacking the crap out of things. Making a total mess.
And at the end of the day, if we're lucky, something ships. Something with little problems here and there that requires seven different areas of expertise to figure out. Plan on maintenance being fun.
The next day version 2.0 of the framework on layer 5 ships. Now if you want maintenance programmers, for layer 5 they have to know both version 1.0 and 2.0
More complexity continues. It's fun for everybody.
Compare this to the guy who uses a standard language, decades-old libraries, hacks out a partial solution (but good enough to ship) in a few days and then moves on to something else. Now tell me that the framework guys have a better technology development model. I ain't believing it.
I'm not saying become a lone wolf and never work with folks. I'm saying that "working with folks" can completely kill any kind of value you're trying to create. Do it wisely.
If Lisp flourishes, more people would get to use it at work.
Lisp not flourishing means less fun.
Also, when I've worked in Lisp it just seemed like the right way to do things. Everyone likes to do the right thing, so anguish results when you seem denied the opportunity to follow the path you feel is right.
That said, I think the author was right and the community issues and ease of building your own solutions will limit Lisp as a language family.
Because it's fun.
Is it possible to do the same in another language? Sure, Slack is proof that it's possible. But would I have persisted in actually doing it without any hope of profit? No, because programming in other languages is a chore, and the only light at the end of that tunnel is the finished product.
With Lisp, the journey is a reward of its own.
Yes, I know the same thing has been said by Haskellers and others, but I doubt it was ever said by a C++ programmer.
APL is less extensible in this regard (to my understanding, someone might prove me wrong). Smalltalk is probably on par, if you can model it with objects and methods/messages cleanly.
But in the end, for me, it's the idea of programming the AST directly and being (mostly) freed from arbitrary syntactical constructs.
To me, this hits the nail on the head, for all the wrong reasons. Syntax isn't the problem, implementing the feature is!
If I'm writing Lisp code, why do I want it to look like Erlang? What's wrong with it looking like Lisp? ("Erlang style concurrency and message passing" is two things, syntax and functionality. Do you want the functionality? Fine. You want the syntax too? Why?)
In fact, this is kind of what the article is about. People want the syntax "their way"; it makes it hard for others to work with their code.
The only time you should invent new syntax is when it is impossible (or very hard) to say something in the syntax you've got. "I don't like it" isn't good enough. "It will save me a few keystrokes" isn't good enough.
- The core library is has enough built in that many questions are answered using built in solutions (e.g. what is done with objects elsewhere is very frequently done with maps and functions that operate on maps) - The language designer (Rich Hickey) is very opinionated, and the language tends to attract people who agree.
There still are multiple choices when it comes to solving some problems (Om vs Reagent vs Rum vs etc.), but is that really that much different than other languages? Javascript has a million choices for the same domain.
The rest of us just shut up and hack some Lisp.
Assuming you have a good toolbox of operators, working with that kind of AST is not much harder than working with s expressions. Maybe it is easier if you can build a general notation that can be generalized for multiple languages and also represent more ordinary data such as json formatted, relational, rdf, etc.
The proof that it is so much harder is that no one ever does it. Yet people do this all the time in Lisps. If its "not much harder" I'd expect to see more of it, but I don't, because it is just so much work.
Aside from parsing, what about templating. Yes, you can manipulate the AST once you have it, but what would templating AST look like? Would it look just like the Java code? With the syntax quote in clojure it looks very much like the output. How would you even begin to template syntax in your hypothetical Java implementation?
http://www.eclipse.org/articles/Article-JavaCodeManipulation...
as for SPARQL derived rule format see
although we've done a bit to humanize the syntax and try to add back some of the features that were common in production rules engines back to the 1970s.
Teams of people were required to write Haskell and Dr Whatshisname tossed off Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then it's not a problem for Qi to be 90% done. And that's a lot easier to accomplish by oneself.
Oh is it time already for another "C is for idiots" thread from Lisp supremacists again? If Lisp fanboiz were slightly less busy ridiculing the rest of the world over how stupid everyone else is, they might even have had some time to pay attention to silly things like performance and tooling. That might help the adoption a bit more than the supercilious rock throwing that is almost exclusively the tone of every single article/post from Lisp lovers.
Clojure is more than fast enough for serious server side programming, often coming close to Java in performance with minimum amount of tuning needed in the average case. When you add multithreading into the mix, it's not even a contest; the amount of time you'll have to spend to make an idiomatic Java or C++ run both correctly and fast is gargantuan compared to a language where concurrency was built-in from the start.