I did early Lisp development on Symbolics Lisp Machines back in the day. Wrote 3D graphics on them. I didn't realize how special the development environment was until I got my first job, writing 3D graphics in Fortran on VAX/VMS. Spent the rest of my career (Fortran, C, C++, IRIX, Linux) bemoaning all the stuff I missed from my Lisp days.
I did venture back into Common Lisp development (MCL/CCL on MacOS) for my personal projects. Even did my masters thesis in CL by writing a socket connection to Maya and using it as a graphics engine from CCL.
It took me a long time (decades) to get over the "everyone should be using CL" mentality.
Thinking back on things, I have come to realize that Lisp is not a magic bullet: it won't necessarily make you a better programmer, and it won't necessarily make your project more successful.
What Lisp will do is give your developers more power at their fingertips. For better or worse.
The philosophy behind Lisp (and Smalltalk) back in the 70's and 80's was that programmers should be given as much expressive power as possible so they can develop better, faster, etc. The reason why CL allows you to define macros, redefine classes and methods on the fly, use generic functions and multiple inheritance, and recover from errors, is simply that the language designers considered these import enough to do the hard work to make them happen.
I feel that philosophy, backed by the economics of software development, fell out of favor over time. Performance, safety (preventing developers from shooting themselves in the foot), code maintenance by large teams, cost, etc became more important.
Today, the main factors in language choice are (1) the availability of developers, and (2) the availability of libraries/tooling. Going against these currents requires awareness and a strong commitment. To paraphrase an old computer industry saying: no one got fired for choosing Java.
On a personal note, I continue to use CL for my own projects, where the pleasure of development is more important to me than commercial considerations. I have done so for kons-9, my 3D graphics system, and am happy that I did so. I simply would not have been interested in doing the project in C++. I find that CL is a language which supports me in my development, rather than fighting back.
As an added bonus, the features of CL have encouraged me to think differently about the architecture and design of the system. A system built in C++ would simply have converged towards being another Maya/Houdini/Blender (at best, after many years of development). This way, I have a chance to do something different, which is a big part of the fun.
>"I did early Lisp development on Symbolics Lisp Machines back in the day. Wrote 3D graphics on them."
Interesting. Symbolics Lisp Machines seem almost mythical to me. Are there things about 3D graphics development that lent themselves particularly well to that hardware and Lisp in general? Did Symbolics Lisp Machines target certain types of development or industries?
You can find videos of the machines in use online.
This was in 1985. The Symbolics machines did not have any special 3D hardware. The SGI boxes were the first to do so.
The Symbolics did have a "high resolution" (around 1K pixels across) b&w bit mapped monitor with a windowing system and reasonably fast bitblt (copying of pixel areas) which made it possible to do simple wireframe animations.
In addition my machine had a second color frame buffer with 24-bit color, a rarity at the time which allowed me to develop my first 3D renderer.
Lisp machines were marketed as productivity enhancers with an emphasis on (old fashioned) AI. Expert systems and such. They were more complex pieces of hardware design than the emerging Sun workstations which ran Unix, and consequently more expensive.
A while after I graduated, Symbolics released their own suite of 3D applications (S-Geometry & co) which for a while were the best commercial packages out there, probably until around 1988 when Softimage was released on SGI machines (I developed their animation code).
I wrote about some of this in a series of blog postings:
Rule based systems, natural language parsing, planners, expert systems, symbolic math, theorem provers, and the like. Basically not the current ML/NN systems.
Recently, I've seen the acronym GOFAI used for "good old-fashioned AI".
I did early Lisp development on Symbolics Lisp Machines back in the day. Wrote 3D graphics on them. I didn't realize how special the development environment was until I got my first job, writing 3D graphics in Fortran on VAX/VMS. Spent the rest of my career (Fortran, C, C++, IRIX, Linux) bemoaning all the stuff I missed from my Lisp days.
I did venture back into Common Lisp development (MCL/CCL on MacOS) for my personal projects. Even did my masters thesis in CL by writing a socket connection to Maya and using it as a graphics engine from CCL.
It took me a long time (decades) to get over the "everyone should be using CL" mentality.
Thinking back on things, I have come to realize that Lisp is not a magic bullet: it won't necessarily make you a better programmer, and it won't necessarily make your project more successful.
What Lisp will do is give your developers more power at their fingertips. For better or worse.
The philosophy behind Lisp (and Smalltalk) back in the 70's and 80's was that programmers should be given as much expressive power as possible so they can develop better, faster, etc. The reason why CL allows you to define macros, redefine classes and methods on the fly, use generic functions and multiple inheritance, and recover from errors, is simply that the language designers considered these import enough to do the hard work to make them happen.
I feel that philosophy, backed by the economics of software development, fell out of favor over time. Performance, safety (preventing developers from shooting themselves in the foot), code maintenance by large teams, cost, etc became more important.
Today, the main factors in language choice are (1) the availability of developers, and (2) the availability of libraries/tooling. Going against these currents requires awareness and a strong commitment. To paraphrase an old computer industry saying: no one got fired for choosing Java.
On a personal note, I continue to use CL for my own projects, where the pleasure of development is more important to me than commercial considerations. I have done so for kons-9, my 3D graphics system, and am happy that I did so. I simply would not have been interested in doing the project in C++. I find that CL is a language which supports me in my development, rather than fighting back.
As an added bonus, the features of CL have encouraged me to think differently about the architecture and design of the system. A system built in C++ would simply have converged towards being another Maya/Houdini/Blender (at best, after many years of development). This way, I have a chance to do something different, which is a big part of the fun.