Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
The term "Lisp" (or "Lisp-like") is an umbrella for lots of different languages, such as Common Lisp, Scheme, and Arc. There is similar fragmentation in other language communities, like in ML.
However, Ruby and Python have both managed to avoid this fate, where innovation occurred more on the implementation (like PyPy or YARV) instead of making changes to the language itself.
Did the Ruby and Python communities do something special to prevent language fragmentation?
Ruby and Python both have benevolent dictators at their helm. They are languages deeply rooted in pragmatic concerns. Those are probably the most significant factors inhibiting fragmentation. Lisp and ML, on the other hand, are more like "design by committee" languages, conceived in academia, for theoretical purposes.
Lisp was originally designed by John McCarthy as a practical mathematical notation for computer programs. He never implemented it as an actual programming language; the first implementation was developed by Steve Russell, but he was not a benevolent dictator. Over time, many different implementations of Lisp appeared; Common Lisp was an attempt to standardize them.
Lisp is more of a "family" of languages. So is ML, which followed a similar evolutionary path to Lisp.
One likely factor is simply age. Lisp and ML are a lot older than Python and Ruby:
Lisp: 1958
ML: 1973
Python: 1991
Ruby: 1995
Lisp and ML have obviously seen much greater change in hardware capabilities, more trends in computer science, and a great many more Ph.D students looking for something to work on.
They're essentially all implementation defined languages
When it is easy to create a new implementation of a language that is largely compatible with existing code, then hackers being hackers, they go ahead and do it. Everyone writes a Lisp implementation at some point. ML compilers are almost mandatory for grad students in language design -- the language is after all famously well documented.
On the other hand we have the ad hoc and implementation-defined languages. Or languages that are just so complex that it is a signficant barrier to ever producing a viable alternative implementation:
This seeming downside -- languages that are too hard to produce viable alternatives to, have the massive upside: scarce developer resources are concentrated on the one true implementation.
As a historical note, several in the Haskell community actively pursued mergers and concentration of dev effort, recognizing that any splintering of the dev community would mean we'd not succeed. GHC was chosen and championed.
cabal is not a fun tool to use and rather easy to break:. Even Yesod acknowledges it: yesodweb.com/blog/2012/04/cabal-meta Python and Ruby are a lot better in regards to package management.
Oct 31, 2012 at 20:19
I would say one factor is a defining platform. For Haskell the platform is the Haskell standard and the GHC (I would imagine). For Ruby it was Ruby on Rails that "defined" the Ruby development platform. For C it was Unix.
Compare that to Lisp, where there was no original kick-ass platform that defined what the language was like. If I recall correctly each Lisp machine had slight differences depending on model and manufacturer. Common Lisp was for some reason not defining. Possibly because of too much competition and reluctance to move to another platform.
This is, of course, entirely speculation from my side. The thought came from the comment replies on Harvey's answer. However, it seems that the defining platform comes in many shapes, but the common property seems to be that it is what gains popularity from.
Don't forget to weigh the culture driving a language's development
I would also weight the fact that development on python/php is actively done in public. You have one group of individuals nailing down a standard specification that is freely available to anybody/everybody.
Much like the W3C does with the HTML/CSS standard. You have a small group of motivated individuals who control the finer details of what the language is designed to accomplish. Everything goes into a clearly defined specification before it's released to the public.
OTOH, languages like LISP are forked behind closed doors by professors or other individuals that genuinely believe that their perspective on the 'best use' of the language is right. They may be simultaneously right and wrong at the same time because some implementations are great at certain things; while none are the best at everything.
That's not necessarily a bad thing because diversity breeds innovation. Languages like LISP are, and will remain great languages for learning and research because they push the boundaries of understanding.
But the qualities that make an environment good for innovation aren't necessarily beneficial for stability; conversely, the qualities that make an environment good for stability aren't necessarily good for creativity.
When development is based on active collaboration, sometimes individuals are forced to concede for the benefit of the greater whole. Bad for research/good for consistency.
The fact is, we're still living in the wild-west of programming language development. The problem of designing the 'ideal language' is so great that, despite monumental efforts, nobody has come close to solving it.
In the research/academia sector, there's still a lot of room for improvement and innovation. In the commercial sector, where there is an exponential growth of software being use in practical applications and the driving force is simplicity and consistency.
Some languages specialize in the former, some specialize in the latter. Those that try to specialize in both usually don't do either very well and die off.
By both, I'm referring to monolithic languages like VB/C#/Java. It's too early to say but I'd like to see what C# and Python look like in 10 years. At the current pace C# is growing functionality and inconsistency at a rate that makes it look pretty grim. Even with great documentation, it's just too much of a pain to remember all the subtle details and quirks included in the language. It's great for a single developer but as soon as you throw in more developers with unique styles, inconsistency in the codebase grows, quality suffers, and nobody wins. I think there's a lot to be learned from the difficulties Perl presents in a production environment.
I don't think it's correct to say that languages like Python and Ruby aren't fragmented. Already we're starting to see some fragmentation effects. For instance, Python 3 isn't entirely backwards-compatible with Python 2, so both versions need to be maintained and lots of existing code works only with Python 2. There are some Python spinoffs, too, including PyPy.
Another factor is the age of the languages. The ones most subjected to fragmentation are the older languages and are thus subject to pressures of evolution and revision. Lisp was invented several decades ago, so there has been ample time to take some of its ideas and incorporate them into new languages. C is another example of a fragmented language. While C had only one really major revision to the language itself (K&R to ANSI), there have been numerous spinoffs including C++, Not Quite C, and all the others that share a C-like syntax.
Ruby itself is a "fragmentation" (if you will) of previous languages. Since it incorporates ideas from C, Smalltalk, and Perl (among others), it's currently the language doing the fragmenting. I don't see why we might not see further convolution of Ruby with other languages in the future.
Lisp is fragmented because it is such a powerful model, the most amazing language ever conceived. Most languages today borrow things that were first implemented in Lisp, so in a way you can say that every language is part of this particular fragmentation. Smalltalk was for instance heavily inspired by Lisp, and Ruby is heavily inspired by Smalltalk. JavaScript is Lisp in a Java-disguise, and so on.. It's all connected, and every language inventor selects his favorite pieces from other languages.
Another factor is that Lisp is probably the easiest programming concept to implement - which is why it's done again and again and again.
Lisp-like languages are too basic and theoretical to be changed dramatically. Grammatical changes (I do not mean to just change the names of commands) would just not fit the functional-programming theory behind them.
But the fact that there are languages like lisp shows that "changes" were already made to lisp anyway. In other words, there are languages made by people who were inspired by lisp or it's theory behind it and made a in-a-way similar new language.
There are also a lot of languages inspired by Python. E.g. Julia, CoffeeScript, etc. which would form their own family of whitespace-sensitive object-oriented languages.
I think, fundamental basics of a language like Python will never really change. Python is object-oriented and therefore has similarities to C++ and Java but it's dynamic and therefore also similar to a lot of script languages.
Well who actually cares about languages? What counts is the purpose: French is similar to Latin but girls who understand French are way hotter ;)
