Why We Need More Programming Languages 421
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.'"
Re:Pffft. (Score:2, Interesting)
The reason (Score:5, Interesting)
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.
Re:Pffft. (Score:5, Interesting)
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:Just Let the Dinosaurs Die (Score:5, Interesting)
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.
Re:Pffft. (Score:4, Interesting)
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:lets reconstitute the ADA committee (Score:2, Interesting)
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.
Query Languages (Score:5, Interesting)
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.
Python is a bad example (Score:5, Interesting)
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).
Re:Pffft. (Score:5, Interesting)
no, but really, C is a good, but old language.
Cobol's even older. And Fortran's long been known to perform math calculations better than most other languages (though that may not still be true). Yada yada.
What I wonder about is, whatever happened to Black Box programming? Why do we need to care what language is used, as long as we understand its interface? Systems programming in C regularly calls assembly for the grottier hardware specific bits. Pretty much any modern language can call a function's object code written in another language.
Yeah, let's just keep on reinventing wheels. That's always worked so far.
Re:The reason (Score:4, Interesting)
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.
Re:Pffft. (Score:3, Interesting)
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:3, Interesting)
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 compilers that have shown themselves to produce code which is rather fast.
4. Minimizing execution time and memory usage aren't always the main requirements for a program. Functional programming is well suited for guarantees of correctness, for example.
Re:Query Languages (Score:3, Interesting)
Re:Pffft. (Score:3, Interesting)
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 faster on N CPUs because they lack side effects. I don't buy it. If it were true, functional languages would have dominated performance rankings years ago.)
Re:lets reconstitute the ADA committee (Score:3, Interesting)
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 day.
If you're curious, try GNAT, the GNU Ada Compiler, which happens to be part of GCC. The concurrency model ( something akin to message passing ) alone is worth taking a look, especially if you've been bitten by pthreads, semaphores, mutexes and shared memory.
Re:Pffft. (Score:2, Interesting)
C++ is popular because it lets you code in a relatively high-level way - OOP, refcounting smart pointers (and even GC if you really want it), standard collections and algorithms etc - while still producing very fast and memory-efficient code. When speaking of Java, C# etc, "almost as fast as C" is more hype then truth. With C++, it's more truth than hype. Especially now that C++11 is out with move semantics, and compilers are picking it up rapidly, STL became much more efficient - to the point where it's hard to match even with hand-written C code.