Why New Programming Languages Succeed Or Fail

snydeq writes "Fatal Exception's Neil McAllister discusses the proliferation of programming languages and what separates the successful ones from obscurity. 'Some people say we don't need any more programming languages at all. I disagree. But it seems clear that the mainstream won't accept just any language. To be successful, a new language has to be both familiar and innovative — and it shouldn't try to bite off more than it can chew. ... At least part of the formula for success seems to be pure luck, like a band getting its big break. But it also seems much easier for a language to shoot itself in the foot than to skyrocket to stardom.'"

Re:Compatibility or conversion

[haystor]

I suspect that the "Java failed" post was a sarcastic counter example of a language that stood on its own.

Java is unusual because it had a billion dollar marketing push explaining how it would change everything. Managers were taking Java classes to learn how it would change everything. None of this was aimed at the enterprise. It failed to be adopted most places it was aimed and somehow backed into the enterprise area due to lack of competition among Microsoft alternatives.

So the answer as to why Java didn't fail is probably that Sun bought it a place at the table. On its own merits, I don't think it would have gotten anywhere.

Needs to fill a need

[tomhath]

Lopes observes that few successful modern languages have roots in academia. An academic herself, she's naturally dismayed....Successful languages have a niche

That's really the heart of it. No matter how "good" a language might be from an academic's perspective, it has to be actually useful to be used.

C was (and still is) a great alternative to Assembly

Java succeeded mostly because it was Not Microsoft, but in part because C++ is a miserable language and the world was ready to replace COBOL, ALGOL/JOVIAL, and FORTRAN.

Ada failed for many reasons, but mostly because it was just glorified Pascal and had all the limitations that made Pascal a good student language but lousy for real work.

Lisp, Perl, Javascript, Python, etc. all fill niches; some niches bigger than others.

Re:Compatibility or conversion

[Kjella]

Which is why COBOL is still alive, too much legacy code and too many libraries to re-implement. That doesn't really say much about new languages though, C to C++ is more the exception to the rule here in that it was an extension to C but C itself kept living its own life. Most other languages just grow and grow with one new feature here and one there and a few things deprecated but never really gone. And that's really why most new languages appear, to get rid of all the crud. To get rid of all the legacy code. To get rid of unsafe methods, stupid interfaces, stupid syntax, stupid keywords, inheritance systems, constructors/initialization and whatnot. I program in Qt/C++... but I'd just love to redo it without all the C-isms and take the best from Java and C#, it'd just be a helluva job. Many of the popular languages have had a huge corporation backing them - Sun for Java (now Oracle), Microsoft for C#, it's not just a language but today I'd also expect a fairly complete standard library (which is why I said Qt/C++, I'd not do plain C++) and that's a lot of work.

Re:Compatibility or conversion

[serviscope_minor]

It seems nice when you first read about it but ends up a maintenance nightmare.

No, it doesn't. Anyone who understands C++ reads operators just like functions.

You see +, and translate it in your head to a call to a function called "plus" (technically operator+()).

Well, guess what, no language prevents you from giving functions stupid names. You can write a function in any language called "add" which doesn't add things. Just as in C++ you can write a function called operator+() which doesn't add things. There is *no* difference.

Operator overloading when done well vastly decreases maintainance required because the code becomes much, much simpler to read.

Re:Compatibility or conversion

[Greyfox]

I'm not sure you can say that. I went to college back in the late 80's and early 90's and was subjected, among other things, to Ada. The military apparently liked Ada mostly for its extra-strong typing. You really don't want to find out that your programmer made a type error when the missile is already in flight, I guess. I've done a lot more with C than C++, but have already had C++ catch enough obscure type errors with the code I'm using to experiment that I'm pretty much sold on the language. Enough to add it to my toolbox anyway. It's hard to say whether I'd do that if I didn't have the advantage of 20 years of programming in a similar language. I certainly didn't with Ada. But I think C++ can stand on its own. There are fairly few things you really need to pick up to be able to program well with it.

The main one is: Avoid template fuckery. You know that book by Alexandrescu? Don't do that! Well unless you're writing Boost. It's too easy to abuse for no real gain, like the Singleton pattern. Most programming teams will refuse to allow you to use a singleton now, even when it's justifiable, because of the abuses to the pattern. If you're factoring primes with recursive templates at compile time, you're creating a maintenance nightmare and future generations of programmers will curse your name. Though I still think it'd be a fun exercise to do a compile time matrix multiply library...

Not that you can completely avoid using templates in C++. But if you avoid it for as long as you reasonably can, your chances of actually using them well when the time comes are much better. You'll probably still get burned by odd template rules, but at least most of your code won't have that problem.