Programming languages should die

There are too many programming languages, and almost all of them must die.
There is no reasons (other then historic) for most of them.

The only exceptions:
C++ (upcoming version) – when you need uncompromising performance. Kind of multiplatform multiparadigm assembler.
Python – pseudocode, when you want only a proof of concept or when speed isn’t important, or for education.
Haskell – when you want to enjoy the process of writing code.

Although Paul Graham says LISP is the only computer programming language so far to be discovered, rather than invented, it is wrong. With all the respect to Lisp/Scheme and their elegance, those cannot be not quick enough (beeing dynamic-typed) nor pure enough (like Haskell), so they must die.

Here is a “proof” that Haskell is not “invented” but “discovered” – Curry-Howard isomorphism – it is just a notation of mathematical concept.

So is also SQL and Prolog, but those those, of course, should die, too.
SQL probably can be replaced by library (e.g. Haskell), LINQ, Google’s MapReduce. Everything done in Prolog is can be quite easy done on any functional language, but not vice-versa. It is good only for very specific tasks, and I don’t believe in domain-specific languages.

Undoubtfully, C#, Java and Delphi/(Object) Pascal, D etc. must die – there is no real reason for them to exist – they are too close to C++, but with many compromises.

Lua is similar to but worse than Python – and  thus must be replaced by it.

(Visual) Basic, Fortran and Cobol should never been born at all:  It’s well known that teaching Basic is a crime, and that the inventor of Fortran regrets about it.

Algol, Pl/2, Modula, Ada etc.  were important once, are obsolete.

So  are C with classes, Objective-C, Smalltalk and even Eiffel, with all the respect.

Perl is write-only language. It is not necessary. “Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line noise with a mission in life.” Awk, Bash-scripts etc. – all can be easily replaced by, say,  Python. They can be implemented as a library, no need for separate language.

There is no reason to use ML, OCaml, F# – if you want to write functional-style – use Haskell, otherwise – don’t pretend (or use Python or use Boost).

I  can continue: Forth is write-only, assemblers aren’t portable (use C++), PHP is inconsistent etc.

JavaScript/ActionScript (EcmaScript) ? Nice language.  But die anyway!

Tags: , ,

14 Responses to “Programming languages should die”

  1. Igor Says:

    Idiot asshole!

    You must die…

  2. jrharshath Says:

    All in good humour, I take it..

  3. oyd11 Says:

    C# – is not a C++ relative, it’s more related to your haskell!!1
    It’s a testbed language for your LINQ et al.
    other languages have their contexts, cultural and otherwise (forth, actionscript)

  4. Dave Bayer Says:

    For what it’s worth, I’ve explored dozens on languages, and converged on exactly your list of three. Nevertheless, it’s healthy to have the others, let natural selection sort this out. It would have saved me a tremendous amount of time if you’d told me this ten years ago, and if I’d believed you. But, like teenagers, it doesn’t work that way.

    Lisp and scheme represent the lambda calculus, in code. In the ensuing 50 years, logicians have moved on, unifying the lambda calculus with type theory and category theory. Haskell represents this unification, in code.

    Only Haskell makes writing parallel code as easy as falling off a log. Add a couple of lines, and I’m at 1.85x speed on a two-core MacBook. When 32 cores become commonplace, there will be a general upheaval, leaving Haskell on top.

  5. C# versus C++ « Komap’s Blog Says:

    […] versus C++ By komap In my previous post I’ve tried to explain why I think there are too many programming languages, and stated that […]

  6. Tavs Says:

    If those three were the only languages left, I’d immediately quit programming to pursue a career as a male prostitute in Singapore, especially for the C++ part.
    C++ sucks! :p

    http://yosefk.com/c++fqa/

    • komap Says:

      Nice FQA, I agree with many points, C++ really sucks, I’m fully aware of this simple fact.
      However, it is still usable (especially C++0x / boost) best choice for certain things. It may be wrong choice for most of applications, but it’s power, flexibility, low-level features and templates (in the hands of experienced programmer with good libraries) can make miracles.

      For it’s niche, (relatively cross-platform low-level libraries etc) only C can be compared to it , and I defenitely prefer C++ over it, and I do understand Straustroup’s design principles.

      • Tavs Says:

        Let me assure you I’m not going to start a lang-war on your blog. Anyway, I’d like to address a few points.
        The efficiency from C++ derives from two features. Firstly its low-levelness.
        Templates don’t make my code more efficient. Nor C++ object semantics and compilation model, which are both broken. Therefore C++ efficiency do not excuse its huge shortcomings.
        Secondly, the compilers. The community behind C++ has been large since its inception thanks to C “compatibility”.
        Consequently there’s been a lot of effort poured into C++ compilers. It’s no wonder that C++ compiles to more efficient code than equally low-level languages (Ada/GNAT, Oberon) which are less known and have smaller communities. To restate the point: there’s nothing “magic” about C++ that makes its compiled code more efficient except the compilers themselves.
        The features you stated are, or can be, found in any language given a sufficiently _developed_ compiler. As for its “niche”, remember that standards like EC++ and the Haiku OS, programmed in C++, ban the use of Templates and exception handling, to the point that C++ becomes syntactic sugar for C structs with vtables.
        As for understanding Bjarne Stroustrup desing, well, I understand it too, and I find it extremely flawed.

        In the end, however, that’s a matter of tastes, for which there’s no accounting ;)

        Nice blog, btw!

  7. Asm_Writer Says:

    I have used many programming languages over time, and written compilers for most of them. That said; C has a simple eloquence about it, C++ is very poorly designed and only holds its fallowing because of its relation to C, Pascal is well thought out, and assembly is not as unportable as most make it out to be.
    As to compiling high level languages; Pascal translates to machine code more directly (on most CPUs) than any of the C variants (and Pascal has built in string handling giving the compiler writer the ability to make additional and simple optimizations), Java compiles to an inefficient byte code (by its definition [it is not Java if compiled to native code]), Object Pascal is almost as effecient as Pascal at translation to Machine language, Oberon has a very poor way of handling classes making translation poor, C++ and Objective C require some mechanisms for handling classes that reduce the efficiency of translation, C is not as efficient as it appears for compiling.
    As to Assembly: assembly is as efficient as the programmer is at optimizing code, and portability; to port assembly usually all that is needed is to directly translate the mnemonics (witch can easily be automated) and write separate modules for system calls and Hardware access.

    • komap Says:

      Thank you for your comment and your “programming languages efficiency summary” :)

      As for the Assembly:
      Not only it is non-portable (as you’ve mentioned) and takes longer to develop and difficult to maintain , but I’m also very skeptical about whether you can really get more performance than compiler, (unless you are genius, which probably you are). Writing Assembly for modern CPU and estimating it’s performance requires extreme professionalism and deep knowledge of the programmer, and even than compiler has an advantage. Even for simple processors many factors (e.g. pipeline, delay slot, limited number of registers, cache issues) compiler often can generate code more optimal than human, and it especially true for messy asm such as modern Intel processors.
      It’ really unhuman to write complex things on assembler; let the compiler do it’s dirty job,

Leave a reply to oyd11 Cancel reply