Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming

Why New Programming Languages Succeed Or Fail 274

Posted by samzenpus from the failure-to-thrive dept.
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.'"
This discussion has been archived. No new comments can be posted.

Why New Programming Languages Succeed Or Fail More

Why New Programming Languages Succeed Or Fail

Comments Filter:
  • Everyone knows it's the Amount of Facial hair [microsoft.co.il]

    • Re: (Score:3, Funny)

      by wilfie ( 622159 ) *
      I dread to think what Grace Hopper looked like.

      • Re:Nah! It's Facial hair... (Score:4, Funny)

        by red_dragon ( 1761 ) on Friday March 16, 2012 @08:47AM (#39375899) Homepage

        I dread to think what Grace Hopper looked like.

        Clams may have beards too, y'know.

      • There's plenty of women in the history of science, and in computer science. They're all ... well they're not beauty queens. In fact there's very few beautiful women in science at all, and of course very few beautiful men (or so I hear from ...).

        And this is good. It means that they actually did something important, were actually capable of doing interesting things.

        • Re: (Score:2)

          by jejones ( 115979 )

          Ada Lovelace, judging by portraits, was no slouch for looks. I vaguely recall reading secondary sources, but I can't cite them. Ditto for Sonja Kovalevsky (for her, there's photographic evidence).

          That said, you're right. Beauty doesn't matter in this context.

      • Re: (Score:2)

        by mcgrew ( 92797 ) *

        Actually, she wasn't that bad lookijng, but I'm having a hard time finding photos of her when she was young. This photo [computerhistory.org] looks like she's maybe 50 or so.

      • I dread to think what Grace Hopper looked like.

        Grace: When will professional women be treated with respect?

        Master Po: Patience Grace Hopper. If a man dwells on the past, then he robs the present. But if a man ignores the past, he may rob the future. The seeds of our destiny are nurtured by the roots of our past.

        Grace: Whatever.

  • Compatibility or conversion (Score:3, Insightful)

    by sunderland56 ( 621843 ) on Friday March 16, 2012 @08:18AM (#39375719)
    Don't expect me to port existing code to your new language. Either make it compatible - i.e. an old language with new features - or provide me with an automated conversion tool.

    c++ would have died within months if it didn't accept existing c code.

    • So why the fuck do we have Python, Java, and C#? (Score:3, Insightful)

      by Anonymous Coward

      What you say is utter bupkis and bullshit. There are many relatively modern languages that have become very popular without having any sort of real compatibility with C, C++, or any other programming language.

      Just look at Perl, Python, Ruby, Java and C# for some examples. Those have all arisen in the last 20 to 25 years, well after C was extremely well established. While they can call out to external C code with varying degrees of difficulty, they aren't code-compatible with C in any way. SO HOW IN THE FUC

      • Re: (Score:2)

        by Sique ( 173459 )

        Because for instance, Perl can interface with C libraries? (just write the right lib.xs for your C lib.)

        • Yeah, him saying "call out to external C code with varying degrees of difficulty" is purely disingenuous. There is NO difficulty; it may be slightly tedious, but really, no, it's not a big deal. It's quite easy to get a Java/Ruby/v8 (node.js) application bound to an existing C/C++ code-base.

      • Re: (Score:3, Insightful)

        by Nursie ( 632944 )

        Eh... java has JNI and Python has fairly trivial native bindings.

        In fact an awful lot of the power of Python comes from the ease in which you can string together a bunch of stuff that uses the sophisticated underlying C libs in a RAD style. It's part of the beauty of the whole thing, and part of the major appeal of python.

        So your rant is totally off target.

    • Re:Compatibility or conversion (Score:5, Insightful)

      by betterunixthanunix ( 980855 ) on Friday March 16, 2012 @08:28AM (#39375779)

      Don't expect me to port existing code to your new language

      Who says you need to port anything? If the language has a foreign function interface, you can just maintain the old code and build on top of it.

      • That's the great thing about the JVM ... you can try out different paradigms, but you can always reuse the code, no matter if it is written in Java, Jython, JRuby, or any of the more experimental languages I don't even know about.

        • sorry, real java doesn't work that way. old java has problems running under newer jvm, old j2ee running under new j2ee. write once, run anywhere, for a while until it doesn't
          • First of all, "Write once, run anywhere" never meant to apply to all versions. It meant to apply to different platforms. By your logic, no language could every grow as backwards and forwards compatibility must be maintained at all times. Second for the most part, java is fairly backwards compatible. I don't know what kind of code you are writing but programs I wrote 10 years ago still compile and run.
            • I am in fact testing legacy java code for migration to newer j2ee platforms for a very large corporation, it's a sordid mess. Plenty of other languages have far less issues for ten year old code.
              • So it has nothing to do with the quality/purpose of code someone else wrote. It's all Java's fault. It's the same story for every language.

          • I don't think people program in "old java" anymore. That's like saying people still use K&R C -- no, largely, we upconvert it to modern conventions.

    • Re: (Score:2)

      by dargaud ( 518470 )
      Yes, or at the very least, make it very easy to link to and call other languages. Mathlab/Mathematica can call C libs rather easily. C can call Fortran and Pascal. But some won't mix and that's a big show stopper. Another issue I think is with languages that give you too much leeway. If you can redefine the syntax, the operators, how they work, etc, then another programmer, even familiar with the language, will have no idea what you wrote. Case in point, C++ where you can overload '+' to operate 30 differe

      • Re: (Score:2)

        by tibit ( 1762298 )

        One would hope that a particular library/framework that is being used would be familiar to the people who maintain the code. If that's the case, then I don't see how operator overloading would be considered a drawback. Alas, IMHO C++ operator overloading is, to an extent, a crutch needed because the language is not very expressive. For example, in C++ the most concise way of setting up a constant type-safe matrix might be like this (this syntax is from eigen):
        Matrix m;
        m 1, 2, 3,
        4, 5, 6,
        7, 8

      • Re:Compatibility or conversion (Score:5, Interesting)

        by serviscope_minor ( 664417 ) on Friday March 16, 2012 @10:13AM (#39376877) Journal

        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 (Score:4, Insightful)

          by ultranova ( 717540 ) on Friday March 16, 2012 @11:42AM (#39378263)

          Anyone who understands C++ reads operators just like functions.

          This is precisely the problem with C++: it's impossible to say what any given line of code actually does without examining every line the compiler has seen before, including other included files.

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

          By definition, if you're using a feature "well" you're using it in a way that's doing more good than harm. That doesn't mean that the feature is good.

    • Re: (Score:3)

      by DarkOx ( 621550 )

      The limits that would impose on syntax and underlying data models would essentially stop all real evolution in this space. Thank your lucky stars this attitude is not pervasive or we'd all be working with slightly improved BASIC, FORTRAN, COBOL, and Ada environments today. The lucky ones would be maintaining code bases comprised of horrible COBOL to C conversions. If you have been in the retail or finance industries you have encountered some CBOL at some point.

      No if anything new languages should provide

    • Nonsense. One of a programmer's favorite past-times is to rewrite a program in a new language.

      Why? Because it gives us a chance to ditch some of the *shudder* old hackish code. A clean break, with an explanation that "what once was, is no longer."

      All of this, of course, while being paid. ;-)

    • Re:Compatibility or conversion (Score:5, Interesting)

      by Kjella ( 173770 ) on Friday March 16, 2012 @09:04AM (#39376045) Homepage

      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: (Score:2)

      by dskzero ( 960168 )

      Don't expect me to port existing code to your new language.

      This part made me laugh so much.

    • Re: (Score:2)

      by Hentes ( 2461350 )

      Most new languages have some sort of foreign function interface so compatibility not that important.

    • Re:Compatibility or conversion (Score:5, Interesting)

      by Greyfox ( 87712 ) on Friday March 16, 2012 @10:33AM (#39377179) Homepage Journal
      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.

  • Objective-C (Score:5, Insightful)

    by cerberusss ( 660701 ) on Friday March 16, 2012 @08:32AM (#39375805) Journal

    What you can also do, is promise great riches, as in the case of Apple/iOS/Objective-C.

  • There is no magic formula. (Score:5, Insightful)

    by ledow ( 319597 ) on Friday March 16, 2012 @08:35AM (#39375815) Homepage

    There is no magic formula. But there are some simple things that I find help me that have NOTHING to do with the language itself, or it's technical advantages/disadvantages. Strangely, they correlate in no way to popularity of the languages

    You need a single document to sell me your new language. If you can't explain the concepts, basically, to a programmer in a page or two (enough that if you try to sell EVERYTHING I get bored reading the document as a whole), then it won't wash. If I can't understand why I should use your language, I won't. (Spreading it across a Wiki doesn't count, unless that Wiki has a complete copy available as a PDF or something readable.)

    Your documentation should also help when I have a "how the hell do I do X?" question.

    You shouldn't just assume that your way is the best. Ever. Just don't. It'll annoy me.

    You shouldn't just assume that I'm happy to spend a year learning the quirks of your language.

    I should be able to knock up a quick sample program, that uses one of your new features, and understand it in a matter of minutes. Literally. Minutes. Including downloading and installing your compiler / interpreter and getting it running.

    Google sort of understood this with Go: http://golang.org/ [golang.org] They have all of the above, and even an online "compiler". They fail a tiny bit with "what's new" and selling the language, really, which is a bit of a shame, but they do a good job.

    Ruby does okay too.

    But PHP, one of the most popular languages, has a web-site that doubles as a bomb-site. It's hideous and has always put me off, even if they do have some of this information hidden away. It's not selling the language at all(presumably because they're "big enough" for everyone to just know about it). It's like reading a security/release-mailing blog sometimes.

    C# doesn't sell the language at all, anywhere, online as far as I can tell. The first hit is Wikipedia. The next few are resource sites.

    As far as I can see, C# succeeded because it was backed by a big company. By contrast, Go is still pretty obscure (which shows you there is no magic formula - Go aces a lot of the checklists but still lingers in the background). PHP succeeded because it was quick, simple, powerful and "came first" in terms of web scripting. It also created one of the web's largest security nightmares, which was something it was supposed to replace (Perl CGI).

    C was popular because it was unique at the time, and powerful. C++ was popular basically because C was (that doesn't mean it didn't have advantages too, but it got popular by riding along - not by it's own merit at first, but that's what HAS kept it in place ever since).

    There's no way to predict a success. Ruby / Rails came out of nowhere as far as I'm concerned and Ruby's been around since the 90's (Has it? Really? Bloody hell! Where was that hiding?). But things like Haskell were around too in that time and have never really caught on.

    It seems the criteria are "ready - while being in the right place and right time", and almost the inverse of what you'd expect given a look at how much they want to ease programmers in. It seems that if you want to stand a good chance of being the next-big-thing, make an awful website, don't put up examples, make the simplest thing complicated or impossible, make an horrendous security mess, and then put it online. Then find the next fad, say your language is perfect for it, and push it everywhere you can.

    • Re:There is no magic formula. (Score:5, Insightful)

      by jbolden ( 176878 ) on Friday March 16, 2012 @08:52AM (#39375941) Homepage

      But things like Haskell were around too in that time and have never really caught on.

      Huh? When Haskell came out it was a replacement to Gopher, a language not even terribly popular with the functional community. Haskell is now by far the #2 most popular functional language, passing even languages like Mathematica. Haskell has become the primary language of compiler design with ideas from Haskell leaking into most compilers including most importantly the Visual Studio compilers. Ideas from Haskell have led to whole new classes of languages like Scala and Clojure. Ideas like lazy data structures are become standard approaches in many languages.

      Further Haskell has completely altered the entire way people think of functional programming. Monadic methods are now standard in most functional languages.

      In what sense is Haskell not a huge success? Sure it isn't the mainstream language of choice, but then again a language that isn't good with interactive I/O is going to be unsuited for most day to day programming problems.

      • Re: (Score:3)

        by psmears ( 629712 )

        Huh? When Haskell came out it was a replacement to Gopher,

        I think you mean Gofer [wikipedia.org] - which was an implementation of (an early draft of) the Haskell language. NB most of the innovations you mention (e.g. lazy data structures) were around before Haskell came on the scene :)

    • Re: (Score:2, Insightful)

      by buchner.johannes ( 1139593 )

      I was making a similar point here [slashdot.org] in a similar recent discussion [slashdot.org], saying that syntax isn't enough to capture the success of a language. You need to look at how accessible it is.

      For me, there are three important points to discuss programming languages:

      1. Syntax
      2. Access
      3. Community

      ad 1) We know all about and can analyse the syntax. Fine. All the discussion happens here.
      ad 2) But what does the finest Haskell help me if I can't access a CD, Bluetooth or a XMPP serve

    • To be honest, I think C# was a big success partly as you say because Microsoft rammed it down everyone's throat with .net, and partly because it made Java programmers not wet themselves with fear.

      I'd personally say it's 50/50 between those two. I know a lot of people who learned Java first that are absolutely petrified of ever having to actually understand how a computer works. C# appeals to that in a big way.

      • Well, one can program .net in lots of languages -- I've done it in Ada and Python, for example -- so MS didn't exactly ram C# down anybody's throat. But it does integrate particularly well with .net, and .net did make life a lot easier for MS Windows programmers. So yes, being backed by a big corporation helped, but so was J#. I reckon it also succeeded by making it easy (relatively familiar syntax for C++ and Java programmers) to do a job that enough people wanted to do (program MS Windows).

    • I HATE language selling sites. Many a new language or framework has a VERY nice presentation site telling you that THIS is the answer to your problems, this language will screw your gf, kill your dog and set your house on fire, letting you concentrate on the essentials of life. Coding.

      PHP is totally different, it doesn't sell itself, it has no slick presentation, just every function described in clear plain English (and many heathen tongues like Dutch for those who were not blessed by god to be born in the

  • It's all about the tools (Score:4, Insightful)

    by CastrTroy ( 595695 ) on Friday March 16, 2012 @08:35AM (#39375825)
    Whether or not a programming language succeeds has a lot to do with how available the tools are. The language must have a good IDE, quality debugger and profilers. If it doesn't have these tools, it's not much use to serious projects. Nobody wants to write a serious application without the use of a modern debugger. If the tools aren't available, are difficult to set up, or cost too much, people won't start using your language. There's plenty of free and really good languages with great tooling out there that you'd have to come up with something pretty extraordinary to succeed without a proper toolset around you language to succeed. Oh that and a big API that does a lot of the work for you. Nobody wants to write all their own libraries for doing things that should be included in the API.

    • Re:It's all about the tools (Score:4, Insightful)

      by jbolden ( 176878 ) on Friday March 16, 2012 @08:42AM (#39375865) Homepage

      I don't see any evidence that's the case. The whole debugger / IDE culture was built around a small subset of languages; essentially Algol syntax with static typing like C++, C#, Objective-C Java and Visual Basic.

      On the other hand the major languages that have become popular in the last 15 years are often dynamically typed: Perl, Python, Ruby, PHP, Java Script. They don't have good debugger / IDE's as the technology doesn't exist yet.

      Certainly the wealth of wonderful debuggers has helped the static languages. But they aren't a necessary condition.

      • Lack of proper debuggers are what keep me away from languages. Javascript without a debugger is fine if you want to write simple event handlers, but if you want to do a fully javascript driven site like GMail, then you're going to need the use of debuggers. Also, I'm pretty sure debuggers exist for all the languages you mentioned, so I'm not even sure what your exact point is.

        • Re: (Score:2)

          by jbolden ( 176878 )

          Some level of debugging exists and there are semi-GUIs. But the kind of integrated syntax checking, debugging, IDE that exists for static languages don't exist for any dynamic languages. No one has figured out how to make them.

          • Re: (Score:2)

            by dkf ( 304284 )

            No one has figured out how to make them.

            The concept might not even make sense. OTOH, the dynamic languages are much better at supporting an interactive model of development: try some things out at an interactive prompt, and cut-n-paste the stuff that works into a script file. Dress it up a little and you're good to go. It's a fast way to make something that works.

            • Re: (Score:2)

              by jbolden ( 176878 )

              That's part of the problem. No one is quite sure what the proper analogies are. Komodo (Perl GUI) about a decade ago started in the right direction. I wish it had been more popular.

          • Smalltalk? (Score:2, Informative)

            by Anonymous Coward

            No debugging/syntax checking IDE for dynamic languages? Not if you count Smalltalk as dynamic. Smalltalk works arguably better for debugging, syntax checking, and more than static languages because of the VM concept.There can be a slight delay, especially if connecting to a VM remotely (Gemstone for instance), but Smalltalk's IDE even lets you program in the debugger. You haven't seen real TDD unless you've seen someone writing an entire app in the Smalltalk of choice's debugger. It also supports things lik

            • Re: (Score:2)

              by jbolden ( 176878 )

              Point well taken about Smalltalk,. I'd agree that Smalltalk was a huge innovator on IDE/Debuggers. In general too many things resolve runtime for debugging in the classic sense to work well. So I give the static languages the credit for GUI/Debugger.

              That being said there is no static language (except possibly Haskell) I'd rather write in that Smalltalk.

          • PHP has a built-in debugger, which NetBeans integrates with fine. Firebug has a debugger for javascript that works quite well, although you need to understand how functional languages work to really use it well. Syntax checking works as well as it does for any language. Can you actually point out something specific that Eclipse C++ does that Eclipse Javascript doesn't do? Or something that NetBeans Java does that NetBeans PHP doesn't do?
      • Javascript and PHP both have decent debuggers, not outstanding but they work. PHP has about a dozen IDEs ranging from ok to great. Dynamic typing doesn't really impact a debugger, all variables still have a type, it just isn't determined until the variable is set and it can change during execution. No different than a base pointer in C++ or a variable of type Object in Java.

        Also never write Javascript as Java Script. It confuses people who may think that Javascript is related to Java, and shows your

        • Re: (Score:2)

          by jbolden ( 176878 )

          Point well taken about the space in JavaScript. Though in all fairness Netscape/Sun created the confusion by renaming LiveScript as part of their whole Java and browsers as a replacement for desktops.

          As for a PHP IDE that is great, great compared to the static IDE's like Visual Studio, XCode...? Which ones? Your comment below makes me think you don't get the static advantages:

          Dynamic typing doesn't really impact a debugger

          I don't think you get how static language debugging works. If I have a function

    • Re: (Score:2)

      by gtall ( 79522 )

      Bingo! And for those reasons you state, Haskell fails. Haskell is a wonderful language until you attempt to do anything. The problem with Haskell is that it is essentially an academic's language with no support environment save some silly command line crap.

    • Seriously tho' - python, for example, is successful without having a good IDE. There are some IDEs that some people would argue are good - but most of the people writing python are using emacs or vi.

      I'm also rather sceptical about the need for a good debugger. Most of the time I find writing a couple of simple unit tests and a putting in a couple of diagnostic prints is fine for figuring out what's going on (and you have the tests forever, which means that changes are less likely to introduce bugs in existi

    • Re: (Score:2)

      by Hentes ( 2461350 )

      If the language is popular enough, people will write the tools for it.

      • It seems like a chicken-egg problem.

        It's only worth it, if the competing languages suck too much. But languages has gotten much better in the last two decades, so the bar has been raised pretty high.

        • Re: (Score:2)

          by Hentes ( 2461350 )

          The tools don't necessarily have to be written in the language itself, and while the bar of a language has been raised, developing an IDE have also become much easier. Nowadays it's trivial to write an Eclipse plugin for a language.

  • Advice (Score:3)

    by icebraining ( 1313345 ) on Friday March 16, 2012 @08:50AM (#39375921) Homepage

    People posting hypothesis of what makes a language successful: if it predicts that Modula is extremely popular and PHP is essentially unknown, maybe you should revise it instead of blindingly post it just because you'd like that to be true.

  • A language will succeed if it is pragmatic, scratches an itch, is more productive than what exists already, is well supported preferably by multiple vendors, is cross platform, is simple to learn and offers familiarity with what has gone before. The further away from these ideals a language is the less likely it will be to succeed.

  • Needs to fill a need (Score:5, Interesting)

    by tomhath ( 637240 ) on Friday March 16, 2012 @08:59AM (#39376001)

    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.

    • Ada did not fail at all. (Score:5, Informative)

      by master_p ( 608214 ) on Friday March 16, 2012 @09:34AM (#39376303)

      Ada did not fail at all. It is used for exactly what it was designed for: mission critical defense applications.

      Ada was not designed for intranet or web or mobile or desktop applications, although it can do those things really well.

    • Could you expand on the Pascal limitations things? I used Pascal when i was student, even in the industry (petroleum refinery) and I never encountered any kind of limitations.

      Now i use more frequently Python for 3 main reasons:
      * Avalability of powerful libraries
      * For a same functionality program writing from 2 time to 10 time less lines of code than Pascal, Java or C/C++.
      * Cover my old needs of Pascal (writing applications) plus writing some quick&dirty little scripts to help here and there

      There is stil

    • but in part because C++ is a miserable language

      No it isn't.

      It's a great language which standardises a bunch of things that people were doing anyway in C and gives them a common syntax. It also very expressive while maintaining high performance.

      I keep trying to find languages better than C++ (it certainly has its share of warts), but I keep coming back to it, because often there is no better alternative.

      And it's just got a whole lit better.

  • Popularity is all about making it EASIER.....and FASTER, to produce stable, fast, and reasonable footprint applications.

    If a new language doesn't do that on its own, then it needs a platform or set of tools to make that happen.

    If a new language just lets you do the same things, but in a different way, with maybe 1 or 2 things being better then there is no motivation to learn it, use it or make things for it.

  • Because excluded middle.

  • At least Brainfuck never caught on!

  • Carnegie-Mellon has dropped OOP from their CS requirements because they felt that the OOP model was not appropriate for modern needs. Linus Torvalds says "C++ is a horrible language." In the January issue of IEEE Computer there is an article "The Java Tree Withers - The java report card: infrastructure gets a D, code reuse gets an F".

    Programming languages drive devices. I'm doing heterogenous parallel processing in C and CUDA. Multicore and massivelly parallel concurrency is absolutely the future and if you

    • Re: (Score:3)

      by TheSync ( 5291 )

      Carnegie-Mellon has dropped OOP from their CS requirements

      Wow, and they are replacing it with imperative & functional programming [i-programmer.info].

      I think it is a crime to let people out of CS school without knowing Java/C++ in this day and age. OOP has issues (I still think OO is a cult :) but you have to realize that there are a lot of practical and theoretical work done in OOP.

      Also I was taught some functional programing in C. You don't really need a special language. Teaching someone Standard ML is a waste of the

  • Modularity (Score:3)

    by Hentes ( 2461350 ) on Friday March 16, 2012 @10:23AM (#39377013)

    I find that the most important feature of a language is modularity. Have a big standard library, make it easy to use third-party libraries, including foreign ones and make it easy to create libraries.

  • medicine (Score:3)

    by Tom ( 822 ) on Friday March 16, 2012 @10:26AM (#39377073) Homepage Journal

    I personally think that programming languages are a lot like medicine.

    Your new language doesn't just have to solve a problem or two that you see with programming language, it has to do it better than existing languages while having less "side-effects" (quirks, difficulty, weaknesses).

    If the advantages it provides aren't big enough to cover the costs (like learning a new language, using a new compiler, writing plugins to syntax-highlighting, etc. etc.) then they simply don't matter.

  • Usability trumps consistency (Score:3)

    by gestalt_n_pepper ( 991155 ) on Friday March 16, 2012 @11:49AM (#39378403)

    Make a programming language that's readable by humans, and have the language map concepts to code in the way humans think about things and it will be wildly popular (PHP, VB-anything, C#, Javascript/DOM). Make the programming language terse, efficient and mathematically consistent and it will be wildly popular - among mathematicians and gradually abandoned by most of the rest of humanity (e.g. Fortran, Powershell, C).

    In the former cases, the machine does the heavy cognitive lifting. In the latter, you're expected to do it all. Guess why PHP is more popular than C++? Yes, PHP is sloppy, inconsistent and as random as the people who use it. That's the majority of folks who have to get some work done. As awful as the language is, it rules the web along with vb/asp and javascript.

    Getting the picture?

  • Why success? Sometimes it's money. (Score:4, Informative)

    by Animats ( 122034 ) on Friday March 16, 2012 @12:02PM (#39378667) Homepage

    Java succeeded because Sun 1) gave it away, and 2) threw money at giving it away. Remember "applets"? Java was supposed to be the programming language of the Web. That didn't work out. It ended up being the new COBOL, which was not Sun's intent.

    Some languages fail, or get stuck, because the designer is in love with their own implementation. That happened to Pascal and Python. Wirth's own Pascal implementation was a cute little recursive-descent compiler that generated RPN byte codes, like a Java compiler. Wirth resisted changes to the language that would allow programming in the large. ISO Pascal reflects his biases. So Pascal became stuck in an educational niche. The original Macintosh software was all written in an extended Pascal, as was much '80s software. But everybody had a different dialect - there was Turbo Pascal, Clascal, and a few others. They never merged.

    Modula, Wirth's second try, was also crippled in certain ways. Modula 2 was better. Modula 3 was good enough to be used to write an operating system kernel. Unfortunately, Modula 3 was only used with DEC, which died after being acquired by Compaq.

    Python has some of the same problems. The feature set of Python reflects what it's easy to implement in a naive interpreter, like von Rossum's CPython. Internally, everything is an object, even integers and floats, and object access involves dictionary lookups. This makes CPython slow. Every attempt to speed up Python substantially has hit a wall, including Google's "Unladen Swallow" effort. (PyPy is making progress, but it's taken a decade and requires an incredibly complex internal combination of interpreters and compilers.)

    The biggest disappointment to me has been that we're still stuck with C. C has two killer bad design decisions - the language doesn't know how big arrays are, and the "pointer=array" thing lies to the language. Both reflect how things are done in assembler, and the fact that the original compiler had to fit in a 128K PDP-11. Most of the millions of buffer overflows and crashes that occur daily can be traced to those two design decisions. (C++, as I point out occasional, tries to paper over these problems with collection classes. But the mold usually seeps through the wallpaper, since most operating system and library calls want raw C pointers.)

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close