This is a very good read and it’s interesting to see his arguments and where they lead:
Lisp is too powerful for most programmers, the “Curse of Lisp”.
Because of its power it is the “wrong” type of programmers who use it.
A personal observation is that Lisp has almost for its whole life had a very negative image by, dare I say it, those who haven’t understood its beauty and power.
Most of the open source stuff developed is pretty standard fair, by pretty standard groups of programmers. Unfortunately it is this type of programmer/group which would be a great boon for developing things for Lisp. But they don’t which leads to a negative spiral.
The reason why it is still with us in spite of its problems is because of its super powers.
All I can say is once you’re hooked there is no going back.
I don’t think this will impact Elixir’s future as Elixir is quite far from Lisp. Yes, it definitely has some very nice features but is not in the same league. I an say this being a lisper and one of the developers of Erlang on which Elixir is based.
I don’t think this is what the author identifies as the main cause of the curse. I think the problem (as the author identifies it!) is that it is too powerful a tool to weils responsibly. Most programmers will be happy and productive using lisp. But they will also use its power to isolate themselves from others because the language allows it.
Exactly, this complements the above. Power corrupts and absolute power corrupts absolutely.
My problem is that I’m hooked to mutually disjoint things:
Lisp syntax and how easy it is to manipulate
Phoenix channels, which require the BEAM and Plug (and a a result, elixir). Also iolists and their amazing performance characteritics (and to be fair this doesn’t require Elixir)
Static typesystems like those of Haskell and ML (I’d scrap the IO monad and lazy evaluation from Haskell, though)
These 3 are not very compatible… I can combine 1 with 2 (it’s quite easy to write a lisp compiler that compiles to Elixir AST with trivial interop and better code generation)
Combining 2 with 3 is probably not very hard. Just ignore he typing of receive (accept you’ll have to check at runtime) and adapt this work from @OverminDL1 to lift the restrictions of the Elixir syntax. Then, write an FFI to phoenix and plug and you’re part of the way there. I’m simplifying and I don’t know how I’d deal with macros, butthat’s the idea.
My main problem is combining 1 and 3. AFAIK, no one has been able to graft a HM typesystem into a Lisp, because you can’t have heterogenneous lists in a HM typesystem… You fake it with tagged unions, but then you langstops being homiconic.
WARNING: what follows is based on a paper from 2017 which I’m totally underqualified to read but did it anyway…
There are ways around the above with union and intersection typing (using untagged unions), but although typechecking is decidable withing this framework, it’s complex and probably slow (I couldn’t find a real implementation in code of the relevant algorithms). This typesystem seems to be a conservative extention of HM, so whatever you can do in HM you can do here, but now youcan have lispy lists and some delicious “dynamically typed” AST fragments for your macros to eat.
But the pain point here is that you lose the simplicity of the HM typesystem.
Someone could /should implement Shen (http://www.shenlanguage.org/learn-shen/index.html) on the BEAM. But the type system is not HM and the macros aren’t actually just normal macros. There is a source level prolog in it that you can use for much more.
Having done some digging into ReasonML and PureScript I would love to have their type capabilities on top of BEAM. (PureScript and Elm seem to have more in common with elixir’s way of allowing one to write code than ReasonML does. PureScript’s libraries also seemed to be clearer and cleaner than ReasonML’s so I ended up switching. The biggest selling point of elixir to me are its top-notch libraries built on top-notch Erlang libraries.)
I personally have been extremely productive in elixir but many of my co-workers complain about the lack of typing which makes it harder to comprehend code you haven’t written yourself. While my elixir code (and the naming) tends to be crafted to convey its intention most of all, many people find it easier to reason about strongly typed code.
(And regarding the side discussion above: I just love Lisp. I guess I should check out lfe again. It looked pretty good last time I checked. )
Just a playground to see how much I can twist Elixir’s AST. ^.^
No time lately (busy busy at work) for much development though, but as it was never intended for a useable ‘language’ that’s fine. There are a few things I’d do different if it were to be an ‘enhanced’ elixir on elixir.
+1 !
Oh it’s awesome, if it had read-macro’s then it would be essentially ‘complete’! *Hint*hint*@rvirding*hint* ^.^
(PureScript and Elm seem to have more in common with elixir’s way of allowing one to write code than ReasonML does. PureScript’s libraries also seemed to be clearer and cleaner than ReasonML’s so I ended up switching. The biggest selling point of elixir to me are its top-notch libraries built on top-notch Erlang libraries.)
)
