On Wed, Dec 9, 2020 at 7:13 AM Hans Hübner <hans.hueb...@gmail.com> wrote:
> Am Mi., 9. Dez. 2020 um 11:03 Uhr schrieb Jean-Claude Beaudoin < > jean.claude.beaud...@gmail.com>: > >> On Wed, Dec 9, 2020 at 4:36 AM Hans Hübner <hans.hueb...@gmail.com> >> wrote: >> >>> I like using CL when I know that I don't need scalability and when I >>> know that I'll be the only developer of the program that I'm writing. >>> Under these circumstances, I enjoy it very much because it caters for this >>> setting. >>> >> And I'd like it with scalability too, how about that? The "only >> developer" part I simply do not get. What is the deal with the solitary >> state here? >> > > My personal conclusion, having used Lisp for many years, is that it caters > very well for the individual. After all, REPL based, exploratory > programming is all about the interaction of an individual with the > machine. This nature of Lisp goes far, and then Lisp itself wants to be > explored. As an individual programmer, Lisp provides me not only with a > set of tooling that I know how to use, it also provides me with its own > exploratory space: There is this set of Lisp features that I have not > found a good use in the past, but that I would like to try out in the > future. Now, this might not be that far from other large languages, yet > due to the fact that Lisp carries a lot of baggage from older Lisp > dialects, a lot of these seldom-used features would not have made it into a > new language, had it not been to appease different parts of the language > committee who had their own baggage to carry over into the new, unified > Common Lisp dialect. > > As an example, I would like to point at symbol plists, which were integral > to earlier LISPs lacking better, dictionary-like data structures. They > sleep dormant in the spec, but rest assured: If Common Lisp is your > community, you will eventually run into someone who insists that symbol > plists are great and uses them all over. Looking at you, Ken. > > Now, this is all good and fine for the solitary experience of having a > tool that you can both use to create solutions and that is in itself > something that you can endlessly explore. It is less useful in the world > of industrial software development, where maintainability of systems > written by other people is one of the key properties that should be > supported by the implementation language. While this usually makes > languages boring and often causes features that "one" would "like" to > to have be missing, it also is a property that makes one language > successful and the other language less so. > > This is also where scalability comes into play, and that word certainly > needs to be qualified before it can be discussed. If scalability simply > describes the raw size of the problem that can be addressed with a tool, > then there are limits to what a given language can do based on its inherent > support for threads that execute in parallel. Parallelism is something > that requires proper abstractions. Some say that these can be just on the > library level, but my experience tells me a different story. I find it > difficult to create robust parallel solutions in languages like Lisp, as > the language itself assumes a single thread of control in how it makes > variable bindings accessible and how information is passed between > invocations of functions by reference. > > If scalability is about the number of people that one can bring into a > team that develops a single system, Common Lisp is not a particular nice > environment either. Due to its size, age and heritage, every program that > is written in it basically subsets the language and, worse, often also > extends it because the subset was found to be insufficient and extending > the language is easy. The result is that unless a new person has already > mastered a lot of Common Lisp, they will usually have a hard time finding > their way around in a new system. > > This is not to say that the Common Lisp is the only language with that > problem - It is a property of many old languages. I would still argue that > CL is particularly affected because it was an amalgam of several languages > to begin with, because it had very strict performance goals in the > beginning and because the model of development that it always catered for > is not that of a team, but that of a person interacting with a long-running > program. > > -Hans > Much to think about, thank you Hans
