Fanatics deliberately abandon objective judgement.
Many of the quotes makes me question the authors experience. Everything is relative. Compared to Fortran, Lisp is all that and more. Compared to modern languages (say, Haskell), not so much.
Many of the quotes makes me question the authors experience. Everything is relative. Compared to Fortran, Lisp is all that and more. Compared to modern languages (say, Haskell), not so much.
Around 1987 I was as a student sitting in front of a real Lisp Machine, a Symbolics 3600, running in an AI research lab for natural language interaction. The machine with a stack-based CPU ran an object-oriented operating system written in a million lines of Lisp, with full source code and runtime changes.
There is nothing which will blow your mind like that.
McClim is not a business case. It is just a project to revive the most sophisticated GUI for Lisp. The graphical shell [1] for instance which already works gives a remarkable impression.
[1] https://common-lisp.net/project/mcclim/static/media/screensh...
Do you have enough experience that you dare to judge him?
> Compared to modern languages (say, Haskell), not so much.
I disagree. I was in a lot of languages, in all different programming styles. Lisp still is the language with a maximum of freedom of programming, probably also regarding productivity. Only Nim comes close.
Haskell may look elegant at the surface, regarding productivity however I don't recommend it except for DSL and compiler construction. If you are not a world class expert in Haskell then in most cases Haskell takes a lot more time for development than other languages (say Lisp, Python, C++, even Rust).
- and takes negligible maintenance/refactoring time compared to Lisp/Python/C++. Maintenance timesink might easily outweigh the gain in development time.
That's the promise of strong type systems: preventing bugs from happening before you have to debug them in production and it does not come absolutely free.
I actually had heard something similar about how JPL used Lisp and they could just debug the satellite remotely from the earth.
In something like Common Lisp you can do changes to the object-system at runtime, both to the program and the programming language. For example you can load a patch, which changes the class hierarchy, adds slots, ... Also existing objects can be changed - they can change their class or the list of slots, etc.
That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code.
If maintenance is the main issue I would choose Ada than Haskell. I have no problem to understand my own Ada code written 10 years ago, even without documentation. In Haskell however I had problems to understand my own code which was just some weeks old :-)
Have you worked with Haskell professionally? Your observations do not match my experience of approx. 3 years of professional Haskell development across 3 different companies. Guiding the growth of Haskell codebases is trivial compared to Python, which is the other language I have professional experience of.
Not yet. I was seriously interested in Haskell. The cabal hell however put me back. Stack is interesting but installation from source is still troublesome.
I always want to be able to install my developer tools from scratch (by source only) since I want to make sure that I can port my software to new systems. Haskell's and Rust's way of installation (curl | sh) is convenient but inacceptable for porting. Nim's bootstrap from source (no dependencies except a C compiler) is the right way how it should be.