Programming languages can be divided into three groups based on their implementation strategies:
A) Multiple competing implementations, relatively small standard libraries, many third-party libraries available. C, C++, Cobol, Fortran, JavaScript use strategy A.
B) A single dominant implementation which comes with a fairly large library which everybody uses; typically there is no formal standardization. Substantial third-party libraries may or may not be available. Second-source implementations are continually playing catch-up with the dominant version. Ada, Java, Perl, Python, Ruby use strategy B. So do most DSLs, research languages, and personal toys. Haskell used to be strategy C but is now B due to the increasing dominance of GHC.
C) Multiple implementations, relatively small standard libraries, each implementation comes with lots of libraries. Substantial third-party librarys may or may not be available. The Lisp languages use strategy C; so do Forth, ML, and the Posix shell.
Common Lisp and the shell have fairly large standard libraries (for the shell, it's the Posix utilities that constitute the library); R5RS Scheme and even R6RS Scheme have fairly small ones. When the R7RS Scheme process is complete, the relative sizes in the Lisp world will be R5RS < R7RS-small < R6RS < Common Lisp < R7RS-large, but the standard libraries of R7RS-large will be optional for conformance rather than mandatory, so Common Lisp may still be larger in practice.
In a strategy C language, an implementation is more than just an implementation; it's a community, or even a movement. Strategy A languages don't draw this sort of loyalty for the most part; decisions between implementations are based only on cost, or else technical criteria such as speed, space, compilation speed, or availability in a particular environment. Strategy B languages have only one community per language, with a few splinter groups; that's what makes them such juggernauts today.
But to write your code for Chicken or Racket or Chibi Scheme involves more than a cold-blooded decision about the advantages of these particular environments. Technical factors may control the choice in some circumstances. But where they don't, people end up deciding based on essentially tribal factors, the same that make people fanatically loyal to vi or Emacs (or, in my case, "ex").
That's not necessarily a bad thing. But it would be a good thing, unqualified, if some of the library code available to Chicken programmers was also directly available, without fuss, to Racket or even Chibi Scheme programmers. Essentially everything new in R7RS-small is in pursuit of that goal one way or another. Likewise, the packages in R7RS-large (which is not yet fully specified) are meant to help at a higher level with that interoperability goal.
3 comments:
Where would you put Smalltalk in this?
I feel strange being so late I'm after the spam.
Lua does not seem to fall into any of these categories. There is a single dominant implementation, although LuaJIT has a significant presence. But Lua's standard library is very small and there is not much commonality of choice beyond it.
The primary Lua implementation chooses C90 as a constraint. (The exception is dynamic loading on platforms which support it.) "As portable as C" has opened a lot of niches in non-desktop and embedding applications. But given those limits, listing the contents of a directory has to be third-party, and lposix and luafilesystem are both in use.
The standard Lua environment is austere, and really too austere to get anything done; print({1,2,3}) prints "table: 0x2586af0". As a result people build their own little libraries and object systems. There can be compatibility issues between subsystems, but less than you'd think.
Since most people end up writing their own library and object system once or twice, I've joked that this is like Jedi building their own lightsaber. It's not hard to do, gives confidence you understand the core language, and is a nice dopamine rush. This has some kind of sociological effect on the community but I don't fully understand it. This is my reinvented wheel; there are many like it, but this one is mine.
John Dougan: I don't know enough about the current state of the Smalltalk community to say, but I think it's an A, maybe without all the third-party libraries.
Nop: Lua specializes in compactness, which disguises its fundamental identity as a B; you can't have a large standard library where your main target is embedding.
Post a Comment