How To Make Good Languages Fail

Languages that are "critic favorites" but fail in the marketplace perhaps fail for reasons that can be identified. The reasons are not meant to be value judgements, but rather identify popularity patterns. Here are some suggested patterns:


Contested:

Smalltalk: the primary control structures are
	<condition> ifTrue: [<true_case>]

<condition> ifFalse: [<false_case>]

<condition> ifTrue: [<true_case>] ifFalse: [<false_case>]

<condition> whileTrue: [<loop>]

<index> timesRepeat: [<loop>]

<collection> do: [<loop>]

(<start> to: <finish>) do: [<loop>] "extremely rare"

<start> to: <finish> by: <step> do: [<loop>] "almost never used"
(For examples of actual code, see http://www.cc.gatech.edu/classes/AY2000/cs2803ab_fall/SqueakBasics.html). Furthermore, many basic conditional cases are factored out by means of polymorphism and/or overloaded methods, where possible.

Scheme: The major conditional forms are
	(if <condition>
	  (<true_case>)
          (<false_case>))

(cond ((<cond_1> <block_1>) (<cond_n> <block_n>) (else <default_block>))

(case <variable> (<value_1> <block_1>) (<value_n> <block_n>) (else <default_block>)))

(do ((<variable_1> <init_1> <step_1>) (<variable_n> <init_n> <step_n>)) (<terminating_condition> <final_value>) <loop>)
The italicized parts are optional. The (do) loop is the only iteration construct; there is no equivalent of (while) in the standard, even though it is easy to code one as a macro. Recursion is strongly preferred, and there is a special form, the 'named let', for using TailRecursion to implement iterative algorithms (see SchemeIdioms for an example of this). Furthermore, higher-order functionals such as (map) are often used to eliminate the need for explicit iteration.


Reserving the right to change my mind: I used to think this way, but now (14 Dec 2004) I feel the argument is wrong. Just because a language is not super-popular doesn't mean it is better. In fact sometimes WorseIsBetter. On the other hand, I still think one premise of this page is not well defined. That is, what does it mean for a language to fail? -- JimmyCerra

Previous Discussion:

Backed by a small clique that seemingly claims the language is God's language. Of course, every modern language starts with a small group of programmers, by definition. They remain unpopular when the initial group actively retards the evolution of the language. -- JC

Examples please?

Evolution isn't necessarily progress. After all, hominids evolved towards stupidity to give rise to chimps. If someone doesn't control change to a language, it becomes a morass of contradictory features like C++.

:I think your example is wrong - the general opinion is that chimps split off from other hominids before they became smart. The principle is fine, though.

The real question is why users would prefer a crappy language whose evolution is "responsive" to their needs over a language that's already close to perfect. Why would you want to tie yourself to a language that needs to be improved to be usable over one that doesn't?

My key point here is that it's not a defect of the initial users or the language designer. It's a defect of the vast unwashed hordes of programmers. -- RK

How do you objectively say that any particular language is close to perfection? Suppose that most programmers can't program effectively in a programming language (for its domain); doesn't that imply it is flawed? After all, I think the ultimate purpose of any programming language is to make it easier to write and maintain programs. If it is a chore to write (reasonable) programs with a language unless one is an "elite" programmer, then it becomes costlier to develope in and thus less useful. In other words: If it ain't easy, it ain't working! How do you determine if a language fails? -- JC

End Previous Discussion


Give it a learning curve that is either too steep or too short.

This last part is likely to be controversial, but it is my experience that successful languages - C, Java, Visual Basic - are relatively easy to learn the basics of programming in, but are difficult to master to any meaningful degree. This means that once a critical mass of users begins to develop, you end up with two groups - a large number of inexpensive journeyman-level programmers, and a one or two very expensive master-class programmers, who run the project, break log-jams in the project, fix the showstopping problems, etc. Conversely, many of the other languages have some BarrierToEntry, usually an unfamiliar conceptual framework, but can be quickly understood in detail once this obstacle is overcome. This results in a much smaller group of very expensive programmers, none of which are necessarily master level. For large projects, this is often seen (sometimes correctly) as too expensive an approach, especially since managers as a rule would prefer a large number of PlugCompatibleInterchangeableEngineers to a small group of specialists.

''But does this relates to the language itself? Maybe a simple enough language can succeed if you provide the wanna-be-gurus with large and complex libraries to learn? What if the language is as simple as possible but with dark spots? i.e. provides call/cc'' -- GabrieleRenzi

Hard to say. Part of the issue, I suspect, is economic rather than technical: if the language is too easy to work in effectively, and especially if it does not have a lot of places where hidden bugs can go unnoticed until after deployment (requiring repeated bug fix upgrades, which earn more money for the programmers on each iteration), then the programmers using it are risking putting themselves out of work, just as an auto manufacturer would if they built cars to last twenty years with minimal service. Thus, there is a market/evolutionary pressure that favors languages (and software products in general) that are 'good enough', but not 'too good'. If this is in fact what is happening, then it could be seen as an aspect of the WorseIsBetter phenomenon. -- JayOsako


Put it in the hands of illiterate programmers whose ability to learn has been hobbled.

Put it in the hands of inexperienced programmers and hide the manual.

Add "compatibility" baggage to improve "interoperability" or "portability" and then make this baggage a requirement for all future development.
For the opposite view see e.g. BeingPopularEssay.
See also: IfSmalltalkIsSoGoodWhyDoesNobodyUseIt, SocialProblemsOfLisp

EditText of this page (last edited January 3, 2013) or FindPage with title or text search