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.

[2.7182]

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:Pffft.

[phil_aychio]

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.

[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.

[wed128]

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.

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.

[Ukab the Great]

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

Re:Pffft.

[Ukab the Great]

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

Re:Pffft.

[Ukab the Great]

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

Re:Pffft.

[david.emery]

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

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.

[jd]

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:Pffft.

[2.7182]

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

Re:Pffft.

[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.

Re:Pffft.

[tqk]

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: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.

Re:Pffft.

[Grishnakh]

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 hardware into things at all. That's fine if you're writing OS device drivers or whatever, but for a high-level user application you really shouldn't be worrying about how the hardware works internally. The programming language is supposed to be a way of telling the computer in a completely logical way, that can't be misinterpreted (like natural languages), exactly what you want it to do, to get certain output out of it. How to translate that into commands the hardware understands is supposed to be the job of the compiler, and the people that write the compiler. Instead of expecting every high-level programmer to understand various details about the hardware, let the compiler people be the experts in that domain, and translate the desires of the app developer into the most efficient machine commands. Furthermore, with modern hardware as fast as it is, a 5% improvement in performance shouldn't be something you sacrifice easy code-ability and easy maintainability for.

2) Hardware changes, and software is run on different hardware all the time. Writing something to run well on one kind of hardware or system may not work so well on another kind of system. Just look at what happened with the multi-core mini-revolution. All these applications written for single-core processors didn't run any better than on older systems because they weren't written for that hardware, and only ran on a single core. If they were written in a language that fully isolated the programmer from the details of the hardware, then a simple recompile should allow them to take advantage of multiple processing cores, as the compiler would handle those details by creating separate threads for different parts of the program, rather than expecting the high-level programmer to do this himself.

Of course, this is all in theory. I haven't actually used any functional languages myself, so I can't really speak to how well real-world functional languages would fit the theory described above.

Re:Pffft.

[gbooch]

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.

[ksd1337]

Chuck Norris just glares at the screen, and the computer does exactly what he wants.

Re:Pffft.

[Unknown Lamer]

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 happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch. It even has a powerful imperative operators.

Thanks to macros and the metaobject protocol you can even add new paradigms to the language. Paternalistic, Lisp is not.

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.

Languages like SML and OCaml are actually more optimizable than C. Thanks to providing more type information &c they can take advantage of fancy whole program optimization and whatnot.

The "way hardware works" is an artifact of C being the dominant language. There's no reason hardware couldn't (and it has before) have GC assistance, type checking, capabilities, etc. It's really not appropriate and scalable to view the computer as something that flips bits around a gigantic linear array... it was reasonable to deal with that when you had 4000 words, but not when you have 400000000 words.

Software is nice because you can abstract! Writing programs to a model of an infinite store that Just Works (tm) is beneficial to everyone -- it frees source code from a particular hardware implementation, is easier to reason with, and separates the concern of hardware resource management.

Re:Pffft.

[Pseudonym]

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.

[Waffle Iron]

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.

Re:Pffft.

[iceaxe]

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

Re:Pffft.

[Anonymous Coward]

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.

[drb226]

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:Pffft.

[David Greene]

Compilers are crappy, for the most part, which is why Fortran is still used in maths. The level of effort that has gone into understanding how to compile Fortran programs is enormous

You don't know what you're talking about. The reason people use Fortran is because it compiles so well to the hardware and the reason it compiles so well is that it has well-defined, compiler-friendly semantics at the procedure boundary. Namely, harmful aliases are forbidden.

In that sense, functional languages are also easy to compile because side-effects don't exist. Compilers aren't crappy, language sematics are and C has some of the worst.

Re:Pffft.

[Pseudonym]

I don't know where you got the 90% figure from. Nowhere, I suspect. The performance hit depends crucially on what you're doing. Most programs that you will write in your career are not CPU-bound.

You also have to weigh that against the fact that a program written in a higher-level language will often have subtly different behaviour. For example, the type system of a Haskell-like language may not let you avoid checking the error condition of some I/O operation where C would. So the C program might be faster than the high-level program, but it may also contain a bug which the high-level program doesn't.

The central point is correct, though. Using high-level languages is a tradeoff, and it's part of the job of the engineer to evaluate the tradeoff rationally.

Re:Pffft.

[martin-boundary]

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:Pffft.

[Waffle Iron]

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:Pffft.

[Smallpond]

This is not exactly true. Many programs acquire bugs as they age. The original developers are gone, and the new maintainers less knowledgeable, less proficient and less enthusiastic.

Re:Pffft.

[DragonWriter]

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 COBOL hasn't been the first choice for new development of much of anything for quite some time, most of remaining COBOL applications are in that kind of environment, and so they work really well.

That's not really a testament to COBOL.

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

I don't think that's really true. There's obviously some learning curve, but its hardly the case that programming knowledge is all (or even mostly) tied to a particular language.

Re:Pffft.

[shutdown -p now]

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:Pffft.

[b4dc0d3r]

Joel disagrees, bug fixes tend to accmulate. Things you should never do

The bugs happen when new features are added, same as with the original developers.

Re:Pffft.

[cheekyjohnson]

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).

Re:Pffft.

[Hentes]

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++.

Re:Pffft.

[Mike610544]

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.

With all the disadvantages accounted for, there's still a reason some people use functional languages. There are a bunch of things you can do that are near impossible otherwise.

Re:Pffft.

[jd]

Wait a minute, your other post claimed that the paradigm didn't matter. Now you're claiming that some paradigms prohibit side-effects and thus compile cleaner to modern hardware. You may have a superior UID, but you need to work on your consistency.

You also need to consider that Fortran compilers have been around a very very long time. I don't know if you can find a Fortran IV compiler and a Fortran 2008 compiler that will compile to the same architecture (that age difference is a bit extreme) but I'm willing to bet that if you could find such compilers where both are written by good quality compiler writers (ie: not by someone high on mushrooms getting bored and writing a compiler for the hell of it), that well-written code that can work on both will compile to smaller, faster code using the more modern compiler.

You could argue that this is because compiler writers are better than they were. Well, define "better". Well, they know more about how to convert the Fortran syntax into machine code, what optimizations are suitable and what aren't, etc. Ok, so we have two variables in this - the variable called "experience in Fortran" and the variable called "experience in compiler writing". My claim is that the first variable is not only non-zero but is significant with respect to the second variable. Doesn't have to be larger, just has to be enough that it's demonstrably greater than noise. Your claim, if taken literally, is that the first variable is absolute zero.

Showing that the first variable is not zero requires that you have two compilers of the same age but where one language is newer than another. Ok, we can do this the easy way. Java and ADA are newer than C, so according to my claim GCC's C frontend should produce better code than GCC's Java and ADA frontends. The compiler is the same generation, so the same compiler experience exists for all three. The backend is the same in all cases. The only difference is in how the instructions are handled. Since ADA is actually very good on limiting side-effects, we can also examine the side-effect issue at the same time.

My experience is that GCC's C frontend is the better of the three. It produces smaller code and faster code, despite C's semantics (which, I agree, are absolutely crud). The only way this can sensibly be explained, given that they're of equal compiler generation, is that people know more about how to process C than they do Java (it's way newer) or ADA (which is middle-aged but not used extensively enough for experience to have built up in the community).

Let's now look at compiler technology itself. Much of the optimization is labeled "back arts" because it's not well-understood. Poorly-understood methods used "because they work" and not "because we know why they work" sounds crappy to me. What about code generation? Well, NASA used G95 for a long time rather than GCC's F90 because GCC's Fortran compiler kept blowing up. Sounds like there were problems. Ok, compiler design? Well, you're way old enough to remember the GCC vs EGCS vs PGCC debacle. Sorry, but I can't excuse you there. The sole reason for that ever happening was because each team made some good design decisions and some poor design decisions. If it had been clear-cut, you'd have had the same thing as you had with XF86 vs the original X Consortium, and XF86 vs the new X.Org - a universal and unambiguous switch with no split in the community, merely a split amongst the developers.

The compiler "crisis" caused a split in the community because each option had benefits the others didn't and the others weren't able/willing to produce something similar on their system. If compilers were truly modular, the PGCC optimizations could EASILY have been merged into EGCS and activated solely for those platforms those optimizations applied to. Didn't happen. The extra facilities being developed for "mainline" GCC could also have been merged into EGCS - some were, but others were rejected. In a modular design, you can't "reject" a module, you can merely not add it into th

Re:Pffft.

[shutdown -p now]

How is map/filter/reduce functional programming?

They are higher-order functions. Heavy use of HOF is one of the hallmarks of functional programming.

If you wish to dispute that claim, can you give your definition of FP first? Because there isn't a definite one that is universally accepted, and the pedantic one like "whenever functions are first-class values" is so general that it is essentially useless.

Map, for instance, is just syntactic sugar around 'foreach' and a sequence generator.

Well, duh. Or, alternatively, foreach is just syntactic sugar for map. And, generally speaking, any functional program can be written as imperative one, and vice versa. Point being?

Re:Pffft.

[vAltyR]

No, the problem with purely functional languages is that they are incomplete and do not cover all useful paradigms sufficiently. If a language makes you write anything out longhand, it failed to properly provide an expressive form for the paradigm.

Hasn't stopped Java. They like to call them "design patterns" rather than "failures of notation," though.

Re:Pffft.

[Sloppy]

If C++ is so bad, why is it so popular?

Same reason as perl: because people are vile, sick bastards.

No, we don't

[Anonymous Coward]

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

The reason

[bonch]

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:The reason

[mevets]

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:The reason

[tomhudson]

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 maybe 1 or two desktop environments? 99% of the market wouldn't have found anything useful! Why, Windows would still be #1, and Apple with their FreeBSD-based OS would have absolutely creamed Linux. Linux would have only had maybe 1% market share.

And instead of the Free APP Internet Grand Distributed Open Group Share model (FAppInG DOGS), and the Universal Internet-Secure Adaptive Bittorrent Extensible Open Transfer Code Hive (aka U-IS-A-BEOTCH) to distribute everything everywhere for free, we'd have had developers leeching money - maybe even thousands of dollars a month if we count everyone - off of people by actually SELLING stuff through company stores from Apple and Microsoft. That would have totally turned the Cathedral vs Bazaar argument on its head! Worse, it would have invalidated BOTH models!

We can't have that. Everyone knows that developers don't want to make money selling software - they only want to make money competing with everyone else trying to sell support for the original software they sweated and bled for! It's the only way!

So please, get with the program, learn your new language of the week - it's the only way we'll continue to progress. After all, how else are you going to get people to soak up all those cpu cycles in their 16-core machines in 2016? Think of the POWER you'll wield when "Hello World!" takes up 4 cores!!!

And if that's not enough, think of the children in 3rd-world countries who won't have their 16-hour-a-day jobs because people won't need to upgrade their hardware every 4 months! And all those people in eastern Europe and India who depend on being able to buy the latest O'Reilly book so companies can continue to outsource your job, giving you more leisure time!

After all, not everyone can actually learn how to program ... so we need languages for the masses. If you throw enough different languages at some random text, ONE of them is bound to be able to compile it. After all, it worked for perl!

Just recycle the old ones ..

[ackthpt]

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

Re:Just recycle the old ones ..

[iceaxe]

I like my aspect oriented punch cards.

Use the right tool for the job

[hoffmanjon]

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.

Re:Use the right tool for the job

[k3vlar]

I'd take having to buy a new set of Torx drivers over having to pry open something that's been glued together. At least the guy before you was kind enough to use screws in the first place.

Tiobe Index reflects conservatism

[ewg]

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

Re:All you need is PERL

[ackthpt]

and C#

And something client side. Something better than Javascript.

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.

Re:Just Let the Dinosaurs Die

[bonch]

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.

No, we need one *better* language, not "more"

[gestalt_n_pepper]

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).

Slash-CAllister

[MikeTheGreat]

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

Re:lets reconstitute the ADA committee

[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.

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:Query Languages

[dezert1]

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? If you want to do more with SQL, some databases include a programming language in which SQL can be nested, thus giving you lots of power at the loss of compatibility. Shortcomings aside, I'll never complain about wanting another query language.

Re:Query Languages

[Archibald Buttle]

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.

Python is a bad example

[Hentes]

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:The idea of "Language 2.0" is evil

[RyuuzakiTetsuya]

The only language where this is a real problem is javascript.

For web server side scripting, you can replace say. PHP with Python or Ruby with relatively little pain. Sure, you're rewriting all of your logic, but, in the end, moving languages is only as massive as the size of your projects.

For stuff that's more bare metal, replacing anything with anything else this is true too; assuming the linker gives you a binary in the required binary format. Not a big deal right?

The problem with Javascript is that it's the only language we have for web frontend development, and it's horrible too. It's deceptive. It looks simple, but making dynamic changes to HTML entities requires having some idea how classes work so you can do operations on the DOM. Sure, there are frameworks that might simplify this stuff, but, for artistic and creative people(read: largely bad at math), this is problematic. It's very CS202 and having to think rather linearly.

Re:Runs anywhere

[Chrisq]

Easier != Better

Except when it does.

That's the case with women and emergency exits.

Only if it brings in something 'new'

[scamper_22]

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.

It's Not The Programming Language, Stupid

[gbooch]

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/abstract in fundamentally different ways, but ultimately it is the programming model of the surrounding libraries that has a greater impact on one's productivity.

Re:No, we need one *better* language, not "more"

[PatDev]

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.

Re:Talk about missing the point.

[David Greene]

Performance doesn't matter any more.

Oh really? Is that why I just spent the bulk of the last two months optimizing a set of applications for a supercomputer?

Performance doesn't matter everywhere, but it certainly does matter in lots of places. Quite a bit.

Re:Talk about missing the point.

[Anonymous Coward]

There isn't a thing Emacs can't do, still there isn't a thing I can do with Emacs.

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.

keep building them I will keep using them

[codepunk]

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.

no stinking language

[findoutmoretoday]

Most of the time I just want to sit on top of a database where most of the code is in triggers - calculated fields, a cross between a database and a spreadsheet.  And then some screens stuff to display that data. 

Re:Talk about missing the point.

[deKernel]

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.

Re:lets reconstitute the ADA committee

[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 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:radical change

[Andreas Mayer]

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

I like English better because "fuck off" is more succinct.

Re:Some thoughts

[jd]

Compiler architecture should be piped, with optimization as the absolute final stage. Compilers really aren't that modular, as demonstrated by the fragility of the API linking the frontend to the backend of GCC. Frontends have to be modified frequently to work with GCC, which would obviously not be the case if they were loosely coupled. This "steady refinement" (the word you want is "reification") is a bloody stupid description and if you don't understand the problem with early optimization you should go back to Software Engineering 101. You're a three digit UID, you really aught to have not only got the Dragon Book and understood it, but moved well beyond that point. Indeed, I'm fairly certain from your comment that you have.

You've also been around far too long to not know that whilst you can translate any paradigm into any other paradigm, the entanglements between logic and data differ between paradigms and that entanglement remains because it's built into the semantics of the programs.

The special purpose hardware for LISP was much faster than the general purpose hardware, and the Colossus computer rebuild proved something like 20x faster than the Pentium 1 for cracking Enigma codes because it was designed with that problem-space in mind and the Pentium wasn't.

The compiler's job is indeed to map the semantics, but where the semantics are highly inefficient on that architecture the compiler can't map any better than that. THAT is why code for the Itanium 2 and later has generally been horrible. The original processor design bugs were ghastly but were largely removed by the second iteration. However, compilers simply couldn't map the code to the architecture. That argument has been had already and you can look back through the Slashdot archives for it.

If semantics were sufficient and compilers were that great, we'd never use a programming language at all. Z would be sufficient. That defines all the semantics you need and compilers are quite capable of turning Z into instructions. Chances are that although there are hundreds of thousands of Slashdot readers, less than a dozen have ever programmed in Z*. Even hand-turning Z into code is so painful and difficult that you will find professors in computer science (including Linus' old lecturers) stating that it simply cannot be done for any program of any complexity. In fact, I seem to recall one of them posting just that on Slashdot as a rebuff to my complaint that too few people knew Z. (Compared to how long either of us have been on the system, these discussions are "new" so you've doubtless seen them.) If you haven't tried Z, I strongly recommend trying it out. It is by far the most powerful of all the Formal Methods ever developed, anything you can ever write in C can be written in Z (and vice versa), it is absolutely superb for creating provably-correct semantics, but nobody would dream of converting Linux into Z (they could, and it would let you eliminate all the bugs in the logic, leaving only bugs caused by hardware weirdness) because it's just too hard. Nor would anyone dream of writing a complex HPC application in Z, because although you can convert to C you can't convert a convoluted Z program to a C program that is high performance. In theory it would be great - HPC computers aren't cheap to run, so programs that will run correctly first time and every time would obviously be a Good Thing**. In practice, HPC programmers avoid Formal Methods like the plague. You cannot turn a Z program into a fast program.

*Software Engineering lecturers will likely barf at my claim Z is a programming language, but the fact is that that is exactly what it is. Programming is not distinct from pure maths, it is - and always has been - a subset of pure maths. A programming language is merely a mathematical representation of a problem in a form that uses a specific syntax that can be reified into a form that will run on a Turing-complete system. The fact that some syntaxes are supplied with popular compiler vendors is immaterial. Because compilatio

Yes it can

[Goonie]

If we're nitpicking, C is not strictly 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?

Re:Talk about missing the point.

[Darinbob]

Performance matters when so many apps clearly have paid zero attention to it. Students were trained "don't optimize prematurely" but they only remember "don't optimize", without even stopping to think if the rule of thumb is even valid. Word is damn slow. Excel is damn slow. Browsers are damn slow. Web sites that browsers go to are damn slow. Operating systems are damn slow.

Why is it that with these incredibly fast computers we have today that so many things feel like they run more sluggishly than they did twenty years ago? (not everything, some places do take performance seriously, but as a whole it's overlooked)

But the wannabe programmers just say "we can get a faster machine and more memory".

Re:The idea of "Language 2.0" is evil

[Wrath0fb0b]

For stuff that's more bare metal, replacing anything with anything else this is true too; assuming the linker gives you a binary in the required binary format. Not a big deal right?

This is a joke right? You think writing tooling for a build process onto the metal is no big deal? Besides a good compiler and linker, you need build tools, debuggers, simulators. Oh, and you'll need to port all your external interfaces and drivers to the new language (or write a shim layer in the old language). While you are doing the interfaces, make sure that it has the same semantics for dealing with the hardware or be prepared to spend a while looking at coredumps.

Yeah, a piece of cake.

Re:No, we need one *better* language, not "more"

[SJS]

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 correct and the stakeholder will agree with them.

When it comes to programming languages, give me a language suited to the problem (all the one-language bigots can go pound sand) that's easier to debug than to rewrite. Large, hairy, complex solutions should eventually result in a new programming language that makes those sorts of things much smaller, far smoother, and simpler.

Don't think languages, think paradigms

[Required Snark]

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.

Languages don't have to change slowly

[svick]

I don't think languages have to change slowly. It all depends on the way they are developed.

Look at C#. It's quite a young language, but it changed tremendously since it started. And now languages like Java and C++ are trying to catch up with it, at least in some aspects (like lambdas).

In version 1.0, it was mostly a copy of Java, with some enhancements, like properties and delegates. Over time, generics, lambdas (that can be manipulated programatically) and optional dynamic typing were added. And the upcoming version 5.0 will have much better support for asynchronous programming than other languages. All those changes are very useful and can change the way you program.

I think this proves that popular languages don't have to change slowly. And you can even keep backwards compatibility while doing it.

I Miss Turbo Pascal

[9jack9]

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

Incomplete subject line

[volpe]

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