Are there common mistakes that language creators make that prevent or slow the adoption of their language? An example (though perhaps not a good one): they focus more on language semantics than tool support, etc.
|
closed as not constructive by Mark Trapp Nov 15 '11 at 15:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
There are so many ways to kill a language, let's pick a few...
and last but not least
|
|||||||||||||||
|
|
I'd say the number 1 thing is a poor library. Most experienced programmers are capable of reinventing the wheel but are really loathe to do so. As soon as I see a language and think "I can do that in half the code in [favorite high-level language]", I know I'll never give it a real shot. Even worse if I can replace the chunk of code from the new language with a single line of code from my favorite language. This especially applies to dates and string manipulation. *
|
|||||||||||||||
|
|
Designing a language in the first place without having a real clear idea why it's better than existing languages, or without being able to communicate that idea. |
|||||||||||||||||||
|
|
There is a saying in the world of literature that the world would be a much better place if people were only writing books because they have some interesting to say, not because the want to write a book. The same applies to programming languages. The world would be a much better place if people were only creating programming languages because they have something interesting to contribute to the field of programming language design, not because they want to create a programming language. So, to more precisely answer the original question: creating a "new" language which is actually just a repackaging of an old language. This really is a waste of everybody's time. Note that combining existing features in new ways, is contributing something new to the field of programming language design and is a good idea. Some pretty successful languages are basically recombinations of existing features, e.g. Ruby is Smalltalk with Perl features, Pascal high-level syntax, Perl micro-syntax, iterators from CLU, enumerators from Sather, mixins from Flavors, and new in Ruby 2.0 Traits from Squeak and Scala and Classboxes from a research variant of Java. |
|||||||||
|
|
Choosing a bad name. |
|||||||||||||||||
|
|
According to Tony Hoare - inventor of Haskell and other functional languages get this right with For more explanation on languages without nulls, refer to this StackOverflow question. |
|||||
|
|
Designing the language by committee and having it standardized without the corporate backing needed to keep the standard updated. Actually, this only happened once, but it's still a good way to doom a language. |
|||||||
|
|
|||||||||||||||||||||
|
|
In my opinion every language suffers from the fact that reserved keywords or language constructs can irritate you in such a way that you actually need to patch your expression to a state which might be less understandable. This starts for example at the filesystem level (DOS) with reserved words like CON, AUX, etc. to words in languages or scripts (list, static, use, class, etc.) or even SQL. Perhaps you could state that the amount of reserved keywords equals the amount of doom. |
|||
|
|
|
Designing it for guru's rather than the every man programmer. |
|||||||||||
|