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