Why We Need More Programming Languages

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.'"

Comments

Pffft.

[epiphani]

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

Re:Pffft.

[Xanny]

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.

[wed128]

C is like Oil Paints. Python is like water-soluble markers.

You can make artwork with both. you can also make a complete mess with both. This argument is silly.

Re:Pffft.

[pclminion]

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.

No, we don't

[Anonymous Coward]

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

Re:lets reconstitute the ADA committee

[mbkennel]

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.

Query Languages

[Tablizer]

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:Talk about missing the point.

[Pseudonym]

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.