Forgot your password?
typodupeerror
Programming

Why We Need More Programming Languages 421

Posted by Soulskill
from the use-once-then-discard dept.
snydeq writes "Fatal Exception's Neil McAllister writes in favor of new programming languages, given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 — 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'"
This discussion has been archived. No new comments can be posted.

Why We Need More Programming Languages

Comments Filter:
  • Pffft. (Score:5, Funny)

    by epiphani (254981) <epiphani@ d a l . net> on Friday December 09, 2011 @04:58PM (#38318954)

    Only language we ever needed was C. You putzes just aren't using it right.
     
    /flamebait friday!

    • Re:Pffft. (Score:5, Funny)

      by 2.7182 (819680) on Friday December 09, 2011 @05:01PM (#38318990)

      I'll chime in with the correct answer. If we all programmed in Haskell or OCaml the world would be a better place. Lisp even.

      But I won't go on with a full rant. Functional programming is silently winning the war.

      • Re: (Score:2, Interesting)

        by phil_aychio (2438214)
        Programming peaked with COBOL and has been in a downward spiral since. (obligatory "hey you kids get off my lawn" geezer-speak) Hey you kids get off my lawn!
        • Re:Pffft. (Score:4, Funny)

          by david.emery (127135) on Friday December 09, 2011 @05:27PM (#38319284)

          Programming peaked with COBOL and has been in a downward spiral since.

          Exactly! See http://developers.slashdot.org/story/11/12/09/1533252/java-apps-have-the-most-flaws-cobol-the-least [slashdot.org]

          One of the problems with this business is the continuing preference for the "new and shiny" at the expense of proven quality. COBOL is -very good- at a significant class of problems, and there are a lot of geezers who are very good at it.

          One of the problems with new languages is that everyone starts out stupid. Think about C. How much experience do you need, beyond an understanding of K&R syntax, to be an effective C programmer?

          @begin(flamebait)
          Frankly, I think the base topic here, the argument for new languages over improvements to existing languages, is to make everyone equally -incompetent-. Many studies show the "10x difference" between good programmers and bad programmers. Some (significant) part of that difference comes with expertise with tools including programming languages.
          @end(flamebait)

          p.s. if you recognize above as Scribe mark-up, good for you! Do you really think Microsoft Word is an improvement over Scribe?

          • Re:Pffft. (Score:4, Insightful)

            by Pseudonym (62607) on Friday December 09, 2011 @06:19PM (#38319920)

            If you read the story, you'll note that the COBOL programs in question have been around for three decades or so. Most programs which have been continuously used for 30 years tend to be pretty solid regardless of the language.

          • Re:Pffft. (Score:4, Insightful)

            by Anonymous Coward on Friday December 09, 2011 @06:42PM (#38320194)

            One of the problems with new languages is that everyone starts out stupid.

            You clearly don't have a CS background, but rather are a programmer. If you understand the fundamentals you're not going to be "stupid" in any language. Programmers are simply trained to use one or more tools. I have a cousin, for example, who has a Master's degree in Music. Even with an instrument he's wholly unfamiliar with, like an obscure tribal instrument, he can generally figure it out and play it. That's the difference between him and some guy who taught himself to play guitar.

            • Re:Pffft. (Score:4, Insightful)

              by cheekyjohnson (1873388) on Friday December 09, 2011 @09:32PM (#38321878)

              That's the difference between him and some guy who taught himself to play guitar.

              That's the difference between him and some guy who doesn't know anything. His self-taught status is irrelevant as long as he learned the right things (information comes from somewhere, after all).

          • One of the problems with this business is the continuing preference for the "new and shiny" at the expense of proven quality. COBOL is -very good- at a significant class of problems, and there are a lot of geezers who are very good at it.

            COBOL is very good at something any language is good at: that is, once its been used for a long-enough time in an environment with reasonably stable requirements, and the bugs in the code worked out, its very good at plugging away and doing the same thing reliably.

            Since COB

      • Re:Pffft. (Score:5, Interesting)

        by Xanny (2500844) on Friday December 09, 2011 @05:14PM (#38319132)

        There are a few problems with functional programming languages that have prevented their true adoption anywhere.

        1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

        2. Difficulty. 90% of programmers (not on the internet, in general) write code like Fortran when its 2010. The most popular languages now, C# and Java, are popular because they are extremely easy to understand, if not easy to get things done in. You dont need to know lambda calculus or templates or prototyping to understand 99% of C# / java code (yes, I know C# has all of those and java has 2/3 of those). The problem with functional languages is that they always use these paradigms.

        3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.

        4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.

        I mean, I dont use them. Thats personal preference. I like the way C and OO work more than I like dynamic typing and having no data and all the other out of this world paradigms. I really hope that D can achieve what I hope it will evolve into, a language that is hopefully as easy to understand as Python without the boilerplate of Java but with the performance of C. Thats kind of where the end goal of programming languages needs to be.

        • Re:Pffft. (Score:4, Insightful)

          by 2.7182 (819680) on Friday December 09, 2011 @05:30PM (#38319326)
          Do you think OO programming is closer to how the hardware works?
          • Re:Pffft. (Score:4, Insightful)

            by Waffle Iron (339739) on Friday December 09, 2011 @06:21PM (#38319948)

            Do you think OO programming is closer to how the hardware works?

            Yes. In most languages, objects are implemented like C (or even assembly language) structures. The language just adds a hidden pointer parameter to the object's methods. Sometimes method calls are made through indirect pointers. All of this is perfectly compatible with the way real-world CPUs work, including their built-in hardware stacks.

            Functional languages, OTOH, are big on closures and the like. These don't map onto hardware stacks, and there are huge numbers of elaborate hacks in functional language implementations to try to cram the high-level concepts onto the procedural machine without taking the massive performance hit of allocating every value on the heap.

            • That's outdated thinking, I'm afraid. It's very difficult to know just what exactly a modern CPU does during a bunch of cycles - there's parallel pipelines with speculative execution, reordering of instructions for efficiency, cache access contention with multiple processors etc. The old C family of languages is slowly drifting away from the underlying hardware architecture.
              • Re: (Score:3, Interesting)

                by Waffle Iron (339739)

                All of those things work at the tiny level of shuffling around a few dozen opcodes. Moreover, all of that stuff is *completely* hidden from the programmer, and by design it's almost impossible to distinguish the resulting behavior from a strictly serial stream of CPU instructions on one or more independent CPUs. Functional languages can not and do not take advantage of the changes, nor do they map any closer to them than procedural languages.

                (Some argue that functional languages will magically run N times f

        • by Grishnakh (216268)

          4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside.

          There's a couple of problems with this. 1) In theory, high-level programming shouldn't factor the

        • Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)

          To adress some of your points:

          1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for

          • by Pseudonym (62607) on Friday December 09, 2011 @07:02PM (#38320470)

            Performance doesn't matter any more.

            Of course it does. Every programming task has to care about performance. What's changed is that the most important type of "performance" is different for every task. Most of us aren't doing large-scale numeric simulations.

            If you're programming desktop GUI applications, responsiveness is usually more important than throughput. If you're programming mobile devices, battery efficiency is more important than any other consideration.

            I think it was P.J. Plauger who pointed out that if the program to process the monthly payroll takes three months to run, it's useless.

            What I think you meant to say is that for most programs, whether or not they meet their performance criteria is not limited by CPU cycles. That's certainly true. Most programming tasks can afford to spend some cycles if in return for correctness, programmer productivity or ease of maintenance.

          • by deKernel (65640) <timfbarberNO@SPAMyahoo.com> on Friday December 09, 2011 @07:06PM (#38320524)

            Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)

            Really, performance doesn't count, that must be nice. The two worlds that I have lived in (control systems and financial transaction processing) have performance as king because in both cases, meeting specific performance numbers means large explosions or large fines from networks. Those are naming just two areas, there are quite a few other areas, but I can only speak of the two stated above.

            1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for optimizations, but somehow can't provide warnings for all cases where you are (unwittingly) relying on UB.

            I have found that ~90% of the "undefined behavior" is caused by people not properly checking argument values. That is the nature of imperative languages, if you don't know or understand that, I question whether you should be writing code then, sorry.

            2) Really? Haskell or Ocaml do not rely on any of those things you mentioned. Difficult? Perhaps, but see my point #1. Besides, who would you like making your software... someone who's just "learned java" or someone who knows what the fuck they're doing?

            See the above point of my argument...and nice language.

            3) So all FP languages which don't perform as well as C (or order-of-magnitude at least) don't perform as well as C. What an insight. Btw, Haskell is also within OoM of C. Also, see the top of this post

            Sarcasm really doesn't help make your point here.

            4) How hardware works is fucking irrelevant. If compiler for language X can optimize "fib N" to a constant expression it doesn't matter if your C compiler can generate code which executes a million iterations of a fib-computing loop per second. Certainly, we're not quite there yet, but in the C world there's no hope of doing this beyond *really* simple examples (aka not fib), but FP could conceivably get further. (TC is a barrier, but you can still do useful computation even without TC.

            Actually, I have found that understanding just how hardware works makes finding solutions to problems a whole lot easier. Computers function in a particular manor, and I have found that they mirror life more closely than functional languages. Now granted, that is my perception, but the fact that functional languages are still used only in a few disciple sure enforced my opinion.

            After rereading the parent comment, I think your perceived attitude of the author is way out of line. He stated his case clearly AND WITHOUT PROFANITY. I have been developing software for 17+ years, and after all that time, paradigms come and paradigms go, languages come and languages go just like management styles. What matters the most is the person at the keyboard designing and developing the solutions. I can't even count the number of languages that have come and gone through the years, but C and C++ have always been there. I have stopped fighting the fight of "..this language is better because..." and just learned to use both of those languages better. I produce products faster with far fewer defects so I am happy.

            Guess at this point I just need to yell "GET OFF MY LAWN" to complete my old grumpy statements.

        • There are a few problems with functional programming languages that have prevented their true adoption anywhere.

          1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

          Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses [lispworks.com] happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner [dreamsongs.com]. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch [c2.com]. It even has a powerful imperative operators [cmu.edu].

          Thanks to macros [gigamonkeys.com] and the metaobject [alu.org]

        • Re: (Score:3, Interesting)

          by drb226 (1938360)

          As an hobbyist Haskeller, I tend to embrace the unofficial Haskell motto of "Avoid success at all costs!" Responding to your 4 points, though,

          1. Limiting yourself to a functional paradigm has benefits. You can use equational reasoning about code, and the compiler can perform more vigorous optimizations. Plus, for those of us who program for fun, it's...well...fun!

          2. In Haskell it seems there is always something more to learn. Feature or bug, you decide.

          3. Lisp (+ descendants), Haskell, and OCaml have compil

        • There are a few problems with functional programming languages that have prevented their true adoption anywhere.

          That's true (mostly; if you've bought a plane ticket in the last 5 years, there's a good chance that functional code priced your fare.)

          1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

          Are you from bizarro world? You can say a lot of bad things about Lisp, but "limited paradigms" is not one of them (unless you've got extremely specific criteria or don't like parenthesis.)

          2. Difficulty. 90% of programmers ...

          I'll give you that one, functional programming is hard to grok.

          3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead...

          C's going to win on I/O and other low level stuff, but modern Lisp compilers can produce some pretty efficient code.

      • Re:Pffft. (Score:4, Interesting)

        by jd (1658) <imipak&yahoo,com> on Friday December 09, 2011 @05:28PM (#38319296) Homepage Journal

        I'd argue that we need multiple computer languages and paradigms, but that we probably don't need as many as we have. I'm fluent in about 20 computer languages but that simply should not be necessary.

        I'd be quite happy if the world reduced itself to Digital Mars' D, Occam-Pi, Erlang and Haskell. That would give us the necessary mix of procedural, functional and object-oriented languages to cover everything, and these languages are much better at developing correct software than many of the other languages out there. There are many languages which are "good" at something - Fortran is still the language of choice for mathematicians, Forth is brilliant for hardware control and C is good for developing fast general-purpose software - but these are problematic in that they make it very easy to write buggy, unreliable software.

        If you want to narrow the range, then the languages chosen MUST be capable of producing code as powerful and fast as the "best of breed" without having the genetic defects which are the product of the inbreeding that have produced these languages. Haskell and OCaml are great at what they do, and compilers for them could certainly be improved upon to generate much better code, and could easily replace those languages which show definite deformities (Java, Visual Basic, C#, etc) but those alone won't replace the full range.

        Occam-Pi and Erlang are more than capable of replacing C and Fortran for most purposes, including client/server and HPC, but aren't ideal for really low-level stuff and don't have the power of C++ to simplify horribly complex projects. D does, but you can't simply use D because there's a lot in Occam and Erlang for parallel programming that C-based languages just don't have. (Prior "debates"/wars on here over parallel programming and whether or not it's complicated ultimately boil down to the fact that most people insist on using languages that make it far harder than necessary to get results. Always, always, always use methodologies that are suitable for the problem-space rather than try to cram the problem-space to a specific methodology.)

      • Re: (Score:3, Interesting)

        by gbooch (323588)

        I had the pleasure of conducting an oral history with the late John Backus. He reported that functional programming was a failure for the general case, for it was easy to do hard things but hard to do easy things.

        I don't know what war you think functional programming is winning, but it only shows up on the minor sideline of the wars i'm engaged in.

        • Re:Pffft. (Score:5, Insightful)

          by shutdown -p now (807394) on Friday December 09, 2011 @08:31PM (#38321382) Journal

          Pure FP is not winning, but elements of FP have sneaked into all major imperative languages of the day. C# has lambdas for 6 years now, VB for 3 years. C++ has just got them, and Java is getting them in the next release. All these also have (in case of Java, will have) their equivalents of map/filter/reduce.

    • Re: (Score:3, Funny)

      by Anonymous Coward

      You forgot the "++" after the "C".

      That is an important distinction, since C++ is the perfect programming language for all tasks, always has, and always will be.

      • Re:Pffft. (Score:5, Insightful)

        by wed128 (722152) <woodrowdouglass@NOSpAM.gmail.com> on Friday December 09, 2011 @05:14PM (#38319122)

        GP has got it right. Parent is demonstrably wrong.

        For object oriented tasks, Java, C# or Smalltalk are better. For system-level native tasks, C is better.

        C++ reminds me of the wretched alien-human hybrid that got the Flamethrower in the Alien movie.

        • by Guy Harris (3803)

          GP has got it right. Parent is demonstrably wrong.

          Parent was most likely trolling ("always has", for a language that started being developed in 1979 or so?), and you appear to have bitten the hook.

        • Re:Pffft. (Score:5, Insightful)

          by pclminion (145572) on Friday December 09, 2011 @05:39PM (#38319430)

          For system-level native tasks, C is better.

          Just because you're using C++ doesn't mean you need to write some glorious object-oriented dynamically-dispatched exception-throwing operator-overloading dynamically-dispatching self-reflecting monstrosity. C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates. If you don't want to write enterprisey crap, don't. But don't chuck out the baby with the bath water.

        • Re:Pffft. (Score:4, Insightful)

          by Hentes (2461350) on Friday December 09, 2011 @10:18PM (#38322174)

          For system-level native tasks, C is better.

          As C is a subset of C++, it can't possibly be better. Every C program can be written in C++.

          • If we're nitpicking, C is not strictly [att.com] a subset of C++, but it's close enough. Anyway, your argument is flawed. If a feature is unnecessary and makes programs harder to write, debug, and maintain, a language that omits it can be superior to one that includes it. Let's imagine, for instance, a "comefrom" construct that you can insert in arbitrary locations in your code. Would a language that supported "comefrom" be superior to one that doesn't?
    • Ohhhhhh, flamebait Friday!
      So that's why /. publishes Neil McAllister stories on Fridays.
      Another mystery solved.
      Thank you, sir.
    • Only language we ever needed was assembly. You putzes just aren't using it right.

      • Re:Pffft. (Score:4, Funny)

        by Ukab the Great (87152) on Friday December 09, 2011 @05:26PM (#38319270)

        Only language we ever needed was punchcards. You putzes just aren't using it right.

        • Only language we ever needed was vacuum tubes. You putzes just aren't using it right.

          • Re: (Score:2, Funny)

            by Anonymous Coward

            Since someone here called me so old and out of touch that I'm probably still programming an Analytical Engine...

            The only language we ever needed was a gear cutting lathe. You putzes just aren't using it right.

            • by iceaxe (18903)

              I knap my flint analytical engine gears with a sabertooth fang, and only a putz would need anything more.

    • by ksd1337 (1029386)
      Chuck Norris just glares at the screen, and the computer does exactly what he wants.
  • by Anonymous Coward on Friday December 09, 2011 @04:58PM (#38318962)

    Obligatory XKCD. http://xkcd.com/927/

  • 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 — 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves.

    What's wrong, Slashdot? Where's the editorializing [slashdot.org]?

    It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.

    Seriously I'm sick and tired of defending new languages like Clojure, Go, Dart, Ruby, etc. I'm just going to shut up and let the dinosaurs stagnate and get stuck maintaining all the old code for the rest of their unenjoyable never changing ruts.

    • by bonch (38532) on Friday December 09, 2011 @05:15PM (#38319140)

      Seriously I'm sick and tired of defending new languages like Clojure, Go, Dart, Ruby, etc. I'm just going to shut up and let the dinosaurs stagnate and get stuck maintaining all the old code for the rest of their unenjoyable never changing ruts.

      Your criticisms seems to be based solely on whether or not code is old. If the code works, why is that even a consideration for you? Does it have to be new code to be any good? I hope you're aware of how silly that sounds.

      As for languages like Clojure, Go, Dart, and Ruby, those languages have deficiencies that warrant legitimate criticism. If you're sick and tired of defending them, don't read anything on the internet, because you'll never completely avoid criticism of things you like.

    • Get your newfangled wheels here! This time it's in BLUE!

      To be honest I find Python the scariest language. I write some pseudo code and it runs. Worse, it usually runs first time.

  • Easier != Better

  • The reason (Score:5, Interesting)

    by bonch (38532) on Friday December 09, 2011 @05:07PM (#38319050)

    The reason popular languages move more slowly is because established codebases use them. Backwards compatibility is a good thing. If C++ was radically changing all the time, code that compiled a year ago wouldn't run anymore. Stability and predictability are just as important, if not more so, than radical change when it comes to real-world development.

    • The reason popular languages move more slowly is because established codebases use them. Backwards compatibility is a good thing.

      I don't think anyone is arguing against that. I think the point McAllister is making is that without new languages, progress would stall. I don't think McAllister is saying that the conservatism of well-established languages is a bad thing in and of itself, just that it means that progress requires new languages. McAllister explains that this is because newer languages are freer t

      • Re: (Score:2, Insightful)

        by bonch (38532)

        I have to respectfully disagree that progress would stall if there weren't new languages all the time. One can't help but wonder what progress would be made if the effort spent in trendy languages was invested in established languages. If a concept is good, it will appear in whatever the languages the industry is actually using, regardless of whether or not a trendy new language implemented it first. That said, testbeds are certainly a good thing to have.

        • If a concept is good, it will appear in whatever the languages the industry is actually using, regardless of whether or not a trendy new language implemented it first.

          No, it won't. Because if it hasn't been proven good someplace that has the freedom to implement new things without the legacy concerns that -- for very good reasons -- established languages carry, maintainers of established languages won't take the risk associated with implementing it.

          While algorithms -- which can be analytically and quantitat

        • by tomhudson (43916)

          But choice is GOOD! The more choice the better! Look at the reason linux was able to step in the gap when Microsoft introduced Vista, going on to win the desktop wars! Linux won because of all the effort that was expended into making 619 different linux distros with 487 different desktops - there's GOT to be one for every type of user. Can't you see its the same with programming languages?

          Can you imaging what would have happened if all that effort had been concentrated in just one or two distros, and

    • Re:The reason (Score:4, Interesting)

      by mevets (322601) on Friday December 09, 2011 @05:35PM (#38319388)

      You really have me there. I can't figure out if you are poking fun at c++'s inability to keep "hello, world" compatible between versions, or really think that c++ has some sort of track record in consistency.

      C++ is abhorrant; its author should have shot it long ago.

  • by ackthpt (218170) on Friday December 09, 2011 @05:07PM (#38319052) Homepage Journal

    Algol for Web, COBOL beans, Object Oriented PL/1 ...

  • Lets just say that languages designed by committees look that way.
    • by mbkennel (97636) on Friday December 09, 2011 @05:11PM (#38319082)

      The Saturn V was designed by many committees.

      And for the time Ada is not a bad language at all, especially if you're mature enough to know that the quality of the result is more important than you.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        We're about to let out an RFP and SOW for about 3-4 million lines of code in ADA. Not huge, but completely auditable to our certification standards. It might come back in some other language, but we're not interested in paying the added cost of auditing whatever language the winner picks. Yes, aerospace, safety of life critical failure sort of stuff. I'm not interested in the efficiencies of out of order execution or dereferencing; I want completely deterministic results.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        I fully agree. While ADA is a joke for many people, I happen to know ADA quite well since I use it every day for my job in a Big Company. I know quite a few other languages ( from assembly to C++/C#, python and a few functional languages ), and no other language I've used can let me produce such stable & robust software.
        It manages to be easy to read, high-level while close to the metal when you need it to, has concurrency built-in and prevents you from shooting yourself in the head at least twice a da

  • by hoffmanjon (845536) on Friday December 09, 2011 @05:08PM (#38319058)
    Seriously, choices are always better. My tool (normal tools not software tools) contains two different types of hammers, two different wooden mallets, several different screwdrivers....... If you learn to use the right tool for the job, the different choices make since. If you are stuck on the mentality of "All I need is a bigger hammer" and "All I need is XXXX programming language" then you probably are not using the right tool for the job.
  • by ewg (158266) on Friday December 09, 2011 @05:09PM (#38319066)

    It's notable that the Tiobe Index has just one 21st century language among the top ten (C#, 2001). http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [tiobe.com]

    • by Mashiki (184564)

      Shouldn't be a surprise, especially with the amount of hardware still running the world on 30-40 year old tech. As the saying goes: if it ain't broke, don't fix it.

  • ... , just different.
    – The paradigm paradox.

    from www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf (Programming Paradigms for Dummies: What Every Programmer Should Know)

    Probably worth considering before starting to discuss the issue. The conclusion then could be that a more general paradigm shift is needed.

    CC.

  • With C++0x we have the mutually exclusive aims of nice syntax and new features. The comes a point where maintaining legacy support impinges on the cleanliness of the language to such an extent that it becomes counter-productive. The whole point of a programming language is to express problems in a legible way. The new "enum class" syntax is a good example of how things can go wrong.

    It's not C++ itself I have a problem with; it's that improvements to the language are made without breaking legacy support -- n

  • And this ladies and gentlemen, this why I'll never dive into the world of coding aside from minor batch editing with PS commandlets . As an infrastructure system administrator (server, network, workstation, phones act), you have my deepest sympathies. I don't know how you do it. All of those long hours in the night, new programming languages every time someone farts, fear of being outsourced, moving targets and scope creep. Hats off to you all. As far as I'm concerned, screw that!

  • I'll be programming the navigation system on your space shuttle using VB6. Have a nice trip! :)

  • by gestalt_n_pepper (991155) on Friday December 09, 2011 @05:27PM (#38319282)

    No language is perfect. The idiocy of language designs stem from the fact that few, if any programming languages were designed by anyone who had ever read a book on psychology, ergonomics or human factors.

    There's a saying floating around the internet that "Languages should be easy to read and understand and incidentally be compilable by computers." That about sums it up.

    THE COMPUTER DOES NOT MATTER. It is a means to an end. It's only purpose is to serve humans. The languages designed to provide a system level interface to that machine need to be designed around what a human understands, the way a human understands it. Slavish devotion to a hardware design, or even an object model is plain stupid if it makes your product nearly unusable (e.g. the WPF datagrid).

    • by PatDev (1344467) on Friday December 09, 2011 @06:24PM (#38319990)
      The idiocy of this comment stems from the fact that it's author must have no experience in programming language design. We are all quite aware that humans are the primary users of our languages. The problem is that it's not helpful to have the peanut gallery always yelling "that one doesn't make me happy, make it more soft and people-like. I don't want to have to map my mental model - make it map its".

      It's all well and good to say "make it understand English", but there are two primary problems with this. First, natural language programming is hard. Really hard. Just getting a computer to understand English with any reasonable reliability is pretty far in the future, and we can't wait for that. Second, we as humans don't really have much success expressing exactly what we want. It's why the most insidious bugs are not in code, but in specification. We so often don't know quite what we want that restrictive languages are actually beneficial, in that they force us to reason consistently.

      And it's not some "saying floating around the internet", it's a very famous quote from Structure and Interpretation of Computer Programs, a seminal text in basic programming language theory and compiler/interpreter design. Most importantly, it's probably the first book you should read if you want to intelligently discuss this topic.

      Another quote you might find interesting:

      When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

      - Alan Perlis

      In short, from someone who likes to design programming languages - stop assuming that just because the problem is easy to understand that it is easy to solve. We're not all basement-dwelling geeks who think UNIX is the pinnacle of end-user usability and newbs should just get over it. We aren't pretending that there is no problem, and we're not refusing to educate ourselves on how to solve it.

      • by SJS (1851)

        Second, we as humans don't really have much success expressing exactly what we want. It's why the most insidious bugs are not in code, but in specification. We so often don't know quite what we want that restrictive languages are actually beneficial, in that they force us to reason consistently.

        Oh, god, yes.

        One of the more important development skills to have is to be able to extract consistent requirements from stakeholders, and then to be able to write them down in such a way that the requirements will be

  • by MikeTheGreat (34142) on Friday December 09, 2011 @05:29PM (#38319312)

    Is it just me, or has almost every article by Neil McAllister made it to the Slashdot front page?

    I propose
    1) a "slashcallister" because it rolls off the tongue, and can be used to tag these articles (as part of the greater "slashonomy"), so that
    2) McAllister's articles be picked up by Slashdot's server-side RSS reader and auto-posted & auto-tagged, thus creating the Official Slashdot Neil McAllister Channel

  • Query Languages (Score:5, Interesting)

    by Tablizer (95088) on Friday December 09, 2011 @05:31PM (#38319334) Homepage Journal

    We have only ONE relational query language in common use: SQL. We need more options. SQL is hard to extend by DBA's, emphasizes nesting over named-references, has a messy COBOL-like syntax structure, and other annoyances.

    We have bajillion app languages, but very few query language choices. There is the Tutorial-D language family which spawned REL, but it's more of a tight-typing/compiled style.

    We also need something more dynamic. I've proposed a draft query language called "Smeql" (Structured Meta-Enabled Query Language, pronounced "smeegol") for such. You can "calculate" column lists using dynamic queries, for example.

    It's a far far needier field than app languages.

    • Re: (Score:3, Interesting)

      by dezert1 (964839)
      I am incredibly thankful that there is one universally accepted query language (SQL). (Nearly) everybody understands it, and it works (nearly) well with all relational databases. SQL implements 'write once, run anywhere' far, far more effectively than Java ever did. I cannot count the number of instances where either I've shared SQL code that I wrote or somebody sent me where you can just 'drop it in' (for the most part). And with few mods, it works on nearly any relational database. How cool is that?
      • Re:Query Languages (Score:4, Insightful)

        by Archibald Buttle (536586) <steve_sims7@@@yahoo...co...uk> on Saturday December 10, 2011 @08:00AM (#38324566)

        Only in fantasy-land has SQL implemented "write once, run anywhere". You hint at this problem yourself where you say "with a few mods, it works on nearly any relational database".

        Whilst there is an SQL standard, implementations of SQL vary massively. Professionally I've used SQL-Server, Oracle, MySQL, PostgreSQL and SQLite - all have profound differences, and moving anything beyond absolutely trivial SQL code from one to another requires rewriting the query. We're talking about a language here where major implementations don't even agree on string concatenation syntax...

        Every SQL implementation has it's customisations and variations from the standard. It's almost impossible to write any kind of decent SQL code without making use of these custom variations, and thus ruining the portability of the SQL code.

  • by Hentes (2461350) on Friday December 09, 2011 @05:32PM (#38319346)

    Python is actually an example of how can a language continue to develop even after becoming popular. In a brave move, they didn't let backwards compatibility tie them down. By breaking compatibility, the language could continue to evolve: there are many new features in Python3. For this to work without breaking existing stuff, the __future__ module was invented, which allows creating 'forward compatible' code.

    I think we don't necessarily need to constantly switch languages to evolve, getting rid of backwards compatibility is another way to go (or make the language very general like LISP).

  • Names!

    As long as the binary format's correct and/or you're not filling /usr/bin or /usr/sbin, or wherever your OS stores binaries with interpreters... What's the problem? I mean, there's the problem of understanding the intricacies of a given language, but...

    The real problem is that when all the clever names are taken.

  • by scamper_22 (1073470) on Friday December 09, 2011 @05:43PM (#38319484)

    Is there a need for new programming languages? Perhaps. But I don't think this is eternal. Programming is just the ability to express algorithms and logic. It's not an infinite space.

    I think people moan about new languages when they don't appear to bring anything really new.

    Broadly speaking... following one train of evolution.

    assembler - abstract out op codes
    C/C++ - direct hardware access... provides human word abstraction for programming (for loop, switch, variables, classes...)
    java/c# - virtual machine based, easy library integration (just include the lib)

    Those are big significant changes. It is preferable to add new things in these languages via frameworks, new libraries, code generators... for example QT is a huge framework and code generator, but at its core is still C++. You can easily link in any old c/c++ library or source code.

    Creating a new language for syntax changes or anything is where I think people begin to moan.

  • "far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes."

    I think we should apply that concept to human languages.

    And if you dont agree with me then, sof ertes fidods as'd fguw !

  • Just be clear, I'm not calling anyone stupid (remember what Clinton said? no no no, not "I did not have sexual relations with that woman." the other thing he said. about the economy.)

    Two thoughts:

    First, in a way, this is a silly discussion. Of course we need new languages. All interesting software-intensive systems are full of little languages (we just write them ourselves in other standard languages).

    Second, it really isn't about the programming language. Yes, different languages make you think/act/work/ab

  • by codepunk (167897) on Friday December 09, 2011 @07:03PM (#38320488)

    Keep building new languages, I will surely find a way to bill hours for it.

    Java - billable hours and ass loads of hardware
    PHP - quick and dirty web development cleanup billable hours
    Python - one off get it done quick billable hours
    Perl - systems stuff they will have to call me back in to maintain
    Java Script - client hack more billable hours
    C - debugging more billable hours
    Ruby - billable hours for rewrite to address performance issues including a ass load of hardware .NET - perfect for lock in and selling licenses, rewrite in java once it is determined that hey we need to support other platforms.

  • by Required Snark (1702878) on Saturday December 10, 2011 @08:43AM (#38324810)
    You will be better off if you learn a range of programming paradigms. Knowing how to solve programming issues in a variety of ways will help your problem solving in whatever language you are using, even if it does not support the most appropriate paradigm for the job.

    Having said that, the best way to learn different paradigms is to use languages that are different from each other. Learning only languages that share paradigms will not stretch your abilities that much. For example, in the big picture, C++ and Java are not that far apart.

    My personal experience is that Lisp/Scheme is different enough from any of the C derived languages that it forces you to learn to think a new way. Learning Scheme will make you a better C++ coder. I still haven't spent the time to learn Haskell, but I plan to do so. I think it will improve my abilities no matter what I am working on. Lazy, strict functional programming is far enough removed from what I normally do that I expect to learn a lot of new ways to think about coding.

  • by 9jack9 (607686) on Saturday December 10, 2011 @12:40PM (#38326670)

    Now there was a language!

    Turbo Pascal 4.0 was the best. Not because of efficiency, or programming paradigm, or any of that.

    It had an integrated development environment that was a dream to use. The online documentation was helpful. The manual was a masterpiece. It was easy to begin with not very much and to be producing fairly complex results in not much time.

    I am not a programmer by trade. Studied it in school, way back in the 20th century. Since then, every now and then I've done some programming for my own utility or for work projects in all sorts of languages, including programming, macro, and scripting languages.

    Perl 5.2 was the closest I've come to a language I really like since Turbo Pascal. Yeah, the initial syntax learning curve was ferocious, but in the end it wasn't that steep. Sure, no integrated development environment, but a decent text editor was almost as good. The Perl manual pages were masterful. Again, easy to begin with not very much and produce useful results in not much time.

    I'd really like to find my own personal 21st century Turbo Pascal. I don't care about the syntax, although I actually sort of liked the Pascal syntax. I want a tool that is easy to install, that includes a reasonable IDE with conveniences like syntax highlighting and code-completion, useful documentation, and a fairly rapid path from the start line to something useful. I'm willing to give up the IDE if I can get consise and precise syntax documentation and error messages.

    I took a look at Perl 6. I haven't given up on it yet, but it doesn't seem cooked yet. And the documentation left me swimming in a sea of information that never seemed relevant to what i was trying to do.

    I took a look at Clojure. I had a lot of hope for it. I ended up lost in a sea of irrelevancy trying to figure out how to do very basic things.

    Ruby. Couldn't download it. Don't know why. Some website error over a couple of days. Fail. Maybe I'll try again some time.

    Python. There is something that just seems wrong to me about indenting being syntactically significant. But what the heck, I'm willing to set that aside. The documentation isn't bad. My biggest issue with Python is "SyntaxError: bad syntax". That's it? Nearly a hundred years of computer science and the most the computer can tell me about my mistake is "SyntaxError: bad syntax"? I can't even get a "operator expected" message? Okay, so occasionally some sort of indentation error, but mostly just "bad syntax". I haven't completely given up on it, but I got tired of fighting that error message.

    Actually, C# is the best I've found so far. I am really hoping for something better. But I've been able to start from not much and produce small but useful (console) programs in not much time at all. The combination of command-line compiler and my own text editor was enough to get me going. Basic language documentation is woefully deficient, but somehow that wasn't much of a problem. I've developed a love-hate relationship with Visual Studio, though. Can't seem to make it edit just one file, with full syntax and code-completion. It wants "projects" and "solutions". Screw that. I understand the usefulness of that, but if I'm writing a 30 line script that does something useful to some text data, I don't want to go through all the overhead of "projects" and "solutions", I want to create a file, edit, compile, and done. And the on-line help in VS is . . . stupid.

    So, go ahead and jump on me. If any of these are your pet language, and I'm just not getting it, please enlighten me. If you have a different pet language, and I'm just not getting it, please enlighten me.

    But whatever it is it needs to be pretty simple to install the basic environment. Basic documentation needs to be pretty useful. An IDE with syntax-highlighting and code-completion is a big bonus, but I can live without it if there's decent error messages and documentation. And it needs to be useful pretty

  • by volpe (58112) on Monday December 12, 2011 @02:12PM (#38345264)

    Somebody truncated the "like we need holes in our heads" part.

Nobody said computers were going to be polite.

Working...