From the article: "My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized."
It's a laudable aim, and I wish you all the best with it. A new language with it's own 'zen', similar to the 'zen of python' but with a functional flavour, is something I'd love to see, and I think it'd do well.
Is there something I can read that's a little more specific about the "different tradeoffs" you have in mind?
I really appreciate the design principles behind Cuis. Great to see it mentioned here.
I'm sure there must be plenty of people (like me) who have heard good things about Smalltalk over the years but haven't had much chance to explore it. If you want to dip your toes in the water, and if you agree with the following quote from Cuis's lead developer (Juan Vuletich), Cuis is definitely worth a look.
"Unbound complexity growth, together with development strategies focused only in the short term, are the worst long term enemies of all software systems. As systems grow older, they usually become more complex. New features are added as layers on top of whatever is below, sometimes without really understanding it, and almost always without modifying it. Complexity and size grow without control. Evolution slows down. Understanding the system becomes harder every day. Bugs are harder to fix. Codebases become huge for no clear reason. At some point, the system can’t evolve anymore and becomes “legacy code”.
Complexity puts a limit to the level of understanding of the system a person might reach, and therefore limits the things that can be done with it. Dan Ingalls says all this in “Design Principles Behind Smalltalk”. Even if you have already done so, please go and read it again!" [0]
After much searching for the perfect languages and perfect tools (while using emacs as a simple text editor), it finally dawned on me that Emacs itself is as close as I'd get to a lisp machine right here in my own back yard. A lisp machine that sits quite nicely on top of linux/unix and plays very nicely with it.
There's much that I love about the lisp world, and the author does a great job of articulating the reasons why. There's also much that I love about the unix philosophy. Emacs is a bridge between these two worlds that I love, and I'm old enough now not to give a shit (or need to give a shit) what the rest of the world is doing. This is home.
Reading Peter Norvig's PAIP (https://github.com/norvig/paip-lisp) in 1998 totally blew my mind. It completely changed how I think about programming in every other language I use(d). I love it still, and always will. And yes, my experience is the same as yours: learning lisp made me a better programmer in every other language I use (especially -- but not only -- Python).
The simplicity and symmetry of the syntax is a big part of that love for me. Being able to manipulate lisp code as lisp data, using the full power of the language to do so, is just brilliant.
It's a laudable aim, and I wish you all the best with it. A new language with it's own 'zen', similar to the 'zen of python' but with a functional flavour, is something I'd love to see, and I think it'd do well.
Is there something I can read that's a little more specific about the "different tradeoffs" you have in mind?