What Makes a Programming Language Successful?

danielstoner writes "The article '13 reasons why Ruby, Python and the gang will push Java to die... of old age' makes an interesting analysis of the programming languages battling for a place in programmers' minds. What really makes a language popular? What really makes a language 'good'? What is success for a programming language? Can we say COBOL is a successful language? What about Ruby, Python, etc?"

Comments

The "un-success" of a language

[Slashdot Suxxors]

Is directly proportionate to the amount of /. posts talking down on it.

Fact.

Re:The "un-success" of a language

[TravisO]

Define success? If we're talking about pure headcount then... I'd have to say ease of use and accessibility are the two only factors, because elegance, quality of implementation nor raw speed are factors in PHP nor classic ASP, both of which are/were very popular. All the glory seems to be in web development, people seem to forget that 95% of the developers at Microsoft are still writing C++ and rewrite 15yr old code bases to .NET isn't something MS is considering.

Re:The "un-success" of a language

[hdparm]

One does not learn their trade at a university. University prepares one for learning the trade.

Beards

[AioKits]

I thought it was the beards on the creator(s) of the language that determines the success?

Re:Beards

[Anonymous Coward]

http://maplenewsnetwork.wordpress.com/2008/05/25/the-relation-between-beards-and-the-succes-of-programming-languages/

Re:Beards

[Anonymous Coward]

GOTO BEARDS

Re:Beards

[VGPowerlord]

That article is basically a rip of this one by Tamir Khason. Heck, it's essentially a blatant copy of the 2004 version of Tamir's article with some of the 2008 pictures thrown in!

Off the top of my head?

[steeljaw]

Portability and scalability are what win it for me, I like to write my code once and it's got to be powerful enough to deliver a complex solution.

Re:Off the top of my head?

[OrangeTide]

I'm mainly a C hacker, but I don't get why people would prefer Python over Java. Dynamic typing where you can create new identifiers implicitly is pretty scary to me. I'm not even sure what Python offers over the dozens of other languages that preceded it.

Re:Off the top of my head?

[agrounds]

Portability and development speed are what drive it for me. Most of what I code is for log parsing, network device configuration, and reporting. To that end, I have never seen a need to look too far beyond Perl. It does everything I need with very minimal effort and development time, even for reasonably complex projects. Still, when Perl code becomes too large to work with effectively even after breaking down individual tasks, I change languages.

I think the point is "which tool fits the current need best." Far too many people seem to want to use a hammer when a screwdriver would work better out of potentially misguided allegiances. Languages are no different than any other tool.

I suspect TFA is more 'overrated' than 'insightful' since it makes some gross generalizations, cites search results as indicators of popularity, and completely neglects some of the nicer features of the popular scripting languages.

Re:Off the top of my head?

[SatanicPuppy]

Well, it's got a better object model than Java, and it's a lot faster to code with. Java just isn't appropriate in every situation.

Python also plays well with C, so it's often used in concert with C for interfaces, etc.

Re:Off the top of my head?

[amccaf1]

I'm mainly a C hacker, but I don't get why people would prefer Python over Java.

I'm having similar questions, only wondering why people would prefer Ruby over Java. I've had to start learning Ruby for a variety of reasons so I've been reading Ruby tutorials off and on for a week or so.

I don't think that Ruby is bad, not by a long shot. It's seems fairly decent and it doesn't seem to be lacking anything necessary. I'm just curious as to why someone would pick Ruby over some other language. I'm not quite understanding what the "killer app" of Ruby is. I'm not sure why this language had to be created.

My understanding is that the main reason for choosing Ruby is to use it with Rails (which I have not looked at yet). And yet it's rare for me to read a good word about Ruby on Rails.

Does anyone else get the impression that a lot of these newer languages are simply solutions that are looking for problems?

Re:Off the top of my head?

[Dan667]

I have always thought of computer languages as tools in the toolbox. After understanding the problem and coming up with a plan, the computer language I pick tends to be the best tool to do the job and require the least amount of effort to develop it. Need CAD speed? Use ANSI C. Need text processing? Use perl.

Re:Off the top of my head?

[Schadrach]

Need code that you KNOW has no errors aside from logic errors on the part of the programmer? Use Ada. That's really where Ada fits. You can do very little wrong without the compiler screaming at you and then failing to compile. Like as in, things that cause C "warnings" cause Ada to fail compilation until you fix it. Need to rapidly produce major components, and easily wrap C for the lower level, more performance intensive stuff? Use Python. No, really. That seems to be Python's main niche. It's a great language for writing large blocks of program logic very quickly, is poor at low-level stuff, but can trivially wrap C to do the things it is very poor at.

Re:Off the top of my head?

[Maljin Jolt]

I'm not even sure what Python offers over the dozens of other languages that preceded it.

I will show you. It is that lispilly haskellish funkshunional coding style available in python. Can you do it in C?

#!/usr/bin/env python
 
import sys
 
def main ():
  return reduce(lambda b,c:(lambda x:(lambda r=sys.stdout.write(chr(x)):x)())(c+b), [32,40,29,7,0,3,-67,-12,87,-8,3,-6,-8,-67,-23])
 
main()

Re:Off the top of my head?

[ShieldW0lf]

The thing that makes a programming language successful is the existence of a large group of programmers who are familiar enough with the language to use it. That's pretty much it.

If I can start a project in a particular language, get hit by a bus half way through, and finding someone else to sit in my seat and finish the project isn't a problem, then the language is a success. If I don't have that confidence, then the language is nothing but an interesting curiosity for academics.

Pretty cut and dried.

Re:Off the top of my head?

[jcgf]

I hate any language that places significance on whitespace (if they would have just put a complex type into C we could have killed fortran before the 77 version and this Python shit wouldn't be here but alas).

I also only find Monty Python mildly amusing at best (the jokes are funny but go on for too long and I'm growing tired of all the idiots that quote it all the time).

Fact - C is the best language of all time. If your program is more than a few lines of bash it should be in C. Ritchie is God (yeah that's right, capital 'G') and Stroustrup should be shot for sacrilege!

To mod troll or funny; that is the question. The thing is I'm not kidding.

Re:Off the top of my head?

[p3d0]

I'm mainly a C hacker, but I don't get why people would prefer Python over Java. Assuming that's an honest question...

I wouldn't write a large system with Python, but I use it a lot for quick (say up to 1 kLOC) programs because it has a clean, pseudocode-like syntax for expressing algorithms that is terse without being cryptic. It has enough error checking to help me avoid a lot of mistakes, but not so much that it slows down my hacking. It doesn't necessarily have the best regular expression syntax, or the best performance, etc. etc., but it suits me for the scripts I write.

Re:Off the top of my head?

[Firehed]

return reduce(lambda b,c:(lambda x:(lambda r=sys.stdout.write(chr(x)):x)())(c+b), [32,40,29,7,0,3,-67,-12,87,-8,3,-6,-8,-67,-23])

And this is why God invented comments.

Re:Off the top of my head?

[geekoid]

And the advantage of it being a sloppy maintenance nightmare developed by noobs.

Where the hell do you get C and bloat together? If anything written in C has bloat, the developer should be promoted away from coding immediatly.

Re:Off the top of my head?

[Kupek]

You've probably never done any coding in Python. Check out the book Dive Into Python (it's free and online): http://www.diveintopython.org/ Even browsing through it will give you a better idea of what Python is good for.

Personally, I think of Python as a prettier and more coherent version of Perl.

Re:Off the top of my head?

[OrangeTide]

Well I think Java's object model is superior. Perhaps it's only a matter of taste rather than cold hard logic.

Re:Off the top of my head?

[jcgf]

They would be just as clear if you used a regex library and didn't manually parse the characters or something silly.

Re:Off the top of my head?

[rawler]

When someone ask me, I'd say Java has more or less managed to hit exactly the sour-spot between a quick, agile and productive language such as Python, and a performant and lightwheight language such as C/C++.

If any language manages to find a good compromise in between, though, I would say it's D. I find the Design-By-Contract features to be brilliant, it's flexibility and power is close to Ruby/Python (and combines some of the best aspects of both), while performance and memory-use is fairly close to C++ (and waay better than Java).

Re:Off the top of my head?

[OrangeTide]

People are quite capable doing quick things in Java without pulling in giant bloaty enterprise frameworks. Plus Python is bloat, I think it's like 40M+ installed.
As for banging out quick projects, I tend to do them in C or shell scripts because I know they will either become real projects or they need to be understood by all.

Also doing things in a scripting language and having C do the heavy lifting... sounds like Tcl, Lua, JavaScript. Python offers nothing new there.

Re:Off the top of my head?

[goombah99]

I hate any language that places significance on whitespace I used to feel exactly the same way. Then I got used to it and man is it such a good idea. It not only is easy to scan, but it has the effect of making everyone's code look the same. That is, I can scan your code almost as easily as I can scan mine.

Yaml does the same thing with whites space and the power of it is really evident when you compare it to JSON or XML. indeed you can put XML and JSON or HTML right into YAML without doing anything other than indenting it. No quoting, escapes, etc. so the other code looks "native" to the reader not encoded.

So I totally understand your fear of it. But it's just not justified and you are missing out on a big deal in language enforced, clean coding style that pays big dividends.

Re:Off the top of my head?

[CarpetShark]

Yes. For a mixture, D seems like the ideal option, but it's so lacking in libraries that it's next to useless for the moment.

Re:Off the top of my head?

[AnomaliesAndrew]

I tend to agree with you that personal preference is one of the biggest factors in the choice of a language... but it's the strengths and weaknesses inherent in any language (or more so the language's purpose) that also shapes this. I rarely use only one language/model anymore.

For instance, in my day to day life, I see a clear distinction as to when procedural/object oriented languages such as C, PHP, and Java should be used, and when a relational language like SQL should be used, and I rarely confuse those two classes of programming. Markup languages (though hardly programming languages) like HTML and CSS also have their essential and distinct roles. Were I forced to select only one, I'd probably quit programming!

Programming languages are just tools to get the job done. When was the last time you saw a carpenter with only a chisel?

Everybody's so quick to get into pissing matches.

(Forgive any flawed terminology, I was just speaking casually.)

Re:Off the top of my head?

[jcgf]

I can't tell if you're being serious or if you are trying to mock the way Christians try and convert me all of the time.

Re:Off the top of my head?

[gbjbaanb]

"this load of crap", sir, is the latest cool new thing. Why else would microsoft spend lots of ther precious development and research resources on adding lambda functions to C#, creating F# and why Haskell is now the de-jour of forums and blogs around the world.

Why, I believe you are one of those old style programmers who believe in making things simple, easy to read and maintain, straightforward to develop and simple to understand. How will you appear superior to your colleagues and peers if you write code that they can understand? You have no clue, sir, of the need nowadays to preen your feathers by appearing to "grok" something as obtuse and needlessly obscure as this kind of coding style.

If your code is so simple, and anyone can understand it, then there is no reason why it can't be shipped offshore to Elbonia. So, get with the program and spend at least an hour a day "refactoring" your code to the required level of spaghettiness. Thank you.

Re:Off the top of my head?

[tzot]

People are quite capable doing quick things in Java without pulling in giant bloaty enterprise frameworks. Plus Python is bloat, I think it's like 40M+ installed.

As for banging out quick projects, I tend to do them in C or shell scripts because I know they will either become real projects or they need to be understood by all.

Um. Great information. Python is like 40M+ installed. On Windows? Linux? Bloat compared to, say, Java? Do you include the quite extensive library under your 'bloat' characterization?

As far as quickies go, a change of email software on a client site required the old mailboxes to be converted into maildirs. While their admin searched in the web for an appropriate program, I coded a script in 15 minutes (that's three versions of the script; one to convert to maildir, one to include saved mail folders from the user home directories, and one to make sure that already read messages remained marked as read for the new POP/IMAP software.

It's obvious that everyone chooses their own tools. Python works for me on many levels. Sorry it doesn't for you.

Re:Off the top of my head?

[OrangeTide]

Bloat compared to Lua or C. and 40M on Linux. Although JVM+classes(about 75M) aren't all that large either until you install J2EE.

qmail comes with the utility, written in C, do convert mbox to maildir. You wasted your effort for not using google hard enough.

I've heard stories identical to yours from Perl users. I just don't see the hype when people have been doing the same thing in other languages for years.

Re:Off the top of my head?

[naasking]

Killer apps are overrated. Ruby is an expressive language, period. Studies have shown that software developers can only write a few lines of correct code per day. Making those lines count for as much as possible is important from a correctness, and a maintainability perspective.

Furthermore, application complexity increases non-linearly with lines of code. The fewer the lines of code, the more maintainable and understandable the program.

This is one reason why C is a poor choice of application language, because it requires verbose solutions, and why OCaml is a better choice.

So the winning factor of Ruby over Java is its expressiveness. The big downside is the loss of static typing, and the subsequent loss of certain pre-runtime guarantees. If we could have both, we'd have a real killer language.

Re:Off the top of my head?

[Yath]

Java is a fraction the complexity of C++. I understand that was one of its main missions - to be as powerful as, but easier to use, than C++.

Ruby is an order of magnitude lower in complexity compared to C++. Whereas Java continues to mix objects and immediate values (e.g., int and Integer types), Ruby has only objects. Java's mixed model has a cost when programming. You may reply that the immediate int gives you a speed and optimization advantage, and that is true, but it misses the point. Java gave up speed compared to C++ to make things easier on programmers, and Ruby simply continues in that vein. You can't criticize Ruby for continuing what Java accomplished to a much lesser degree.

There are numerous other examples - Ruby's iterators, for example, are a generation past what Java has to offer. You can find plenty to appreciate in Ruby vs. Java before you even start to talk about advanced language concepts like closures.

Does anyone else get the impression that a lot of these newer languages are simply solutions that are looking for problems?

I hear only complacency in the above comment. You've learned a language well, and find it hard to imagine a better way. Well, your lack of imagination does not equal evidence.

Re:Off the top of my head?

[Just Some Guy]

import crypt;_=r'KZ[i.KqX8jDtA6Uwv!V01d?&iQ#bs,aL\yP<hkAFJ:TE{';print ''.join([crypt.crypt(''.join(x),'ks')[2:5] for x in zip(_[::3],_[1::3],_[2::3])]).replace('/',' ')

Re:Off the top of my head?

[epukinsk]

I'm having similar questions, only wondering why people would prefer Ruby over Java... My understanding is that the main reason for choosing Ruby is to use it with Rails...

I always thought Ruby was just popular because of Rails, but I've been starting to write more Ruby code lately, and I'm starting to see some benefits of the Language itself. Namely:

Ruby is REALLY good for unit testing.

You may or may not be into unit testing, but if you are, Ruby really shines here. It shines because everything is mutable in Ruby. If a class has a method defined, you can change it on the fly. This makes many developers cringe because it seems so messy: "What do you mean the behavior of the method changed in the middle of execution?!!!"

And that's a well-founded fear. Changing object functionality on the fly when what you really need to do is design your objects better is BAD. VERY BAD. But there are a few places where it's just The Right Way To Write The Code. Like any language construct, *cough* GLOBALS *cough*, it can be used for good or evil.

Where Ruby's mutability can be used for Good is unit testing. Specifically, for creating mock objects. Say you have a method A which relies on method B that you're already testing elsewhere. You want your test to tell you whether A is broken, not whether (A OR B) is broken.

In most languages this is hard or impossible, because it means reaching inside the execution of A and temporarily changing the functionality of B. But in Ruby (with Rspec) it's easy:

it "A should work without testing B" do
    SomeBigNastyObject.should_receive(:B).with('somedata').and_return('someresult')
    MyObject.A.should == 'whatever_a_returns'
end

Note that my specification of SomeBigNastyObject just has the normal definition of B. The should_receive method is added by Rspec, and that method CHANGES the functionality of B so that it just returns the right value.

And if you write your test this way, the SomeBigNastyObject.B method is never called! It just works as if B returned 'someresult'. In addition, this test makes sure that that method WAS, in fact called, and called only once.

This really is the way unit tests should be written, and Ruby does this really well. You can do it in Java with the Reflection API, but it's messier.

Erik

Re:Off the top of my head?

[bob.appleyard]

You can't do lambda calculus in Python. I tried, it gave me idiotic syntax errors. Something about the lambda keyword being a crippled piece of shit.

Re:Off the top of my head?

[kellyb9]

Java just isn't appropriate in every situation. No programming language is.

Re:Off the top of my head?

[emilper]

lambda (functions) - kinda old, like 50, 60 years, if I remember well

Haskel suddenly very popular ? - the hordes of VB programmers got woken up to the world of threads

Elbonia - you're late, now Elbonians ship spaghetti code back to the less muddy countries

What makes programming languages popular ? - libraries ... now I'll shut up and go back improving my code spaghettizer ...

Re:Off the top of my head?

[WaKall]

To be fair, chisels aren't Turing-complete.

When's the last time you saw a contractor with 7 power-drills all made by different manufacturers?

The answer is somewhere in between - one language isn't enough, but many languages are indeed superfluous.

Re:Off the top of my head?

[fyngyrz]

C is perfectly capable of many of the most useful object oriented techniques. Objects with methods and locals, classes (instantiating objects from models), inheritance -- all of these are easily and efficiently implemented in C without library or compiler-generated overhead. All the while, the programmer can remain in complete control, and the application can remain fast and lightweight. You can't do everything; there are some object-oriented paradigms that don't fit, but frankly, they're not critical. The important parts are easily managed.

Re:Off the top of my head?

[WGR]

Killer apps are overrated. Ruby is an expressive language, period. Studies have shown that software developers can only write a few lines of correct code per day. Making those lines count for as much as possible is important from a correctness, and a maintainability perspective. That implies that you should be programming in APL.

There is much more to good programming languages than short code.

This is one reason why C is a poor choice of application language You are under the mistaken impression that C is an application language. It is not. It is a system programing (high level assembler) language. That is why so much buggy code is written in C. It has none of the proper error checking built in to it that an application language should have. This provides the ability to get closer to the machine than other languages, but that is the role os system langages, not application languages.

Re:Off the top of my head?

[Kazoo the Clown]

That implies that you should be programming in APL.

I AM programming in APL, you insensitive clod!

Re:Off the top of my head?

[The boojum]

Exactly. That's really it for me. I used to do a lot in Java, but these days C++ and Python are my languages of choice. I feel like they complement each other well, and I've had good success at using Python to generate C++ in some interesting cases (e.g., cross-"assembling" a program written for another architecture into C++ to emulate it). Java seems to fall in the middle of the development speed vs. execution speed continuum and seems to combine the worst features of each.

If I'm going to bother with a language that requires an explicit compilation step and is more verbose, I might as well just use C++ and at least get the raw execution speed, lower memory requirements of C++, and easy distribution of the executables. If I'm willing to accept a language that runs more slowly and is harder to distribute to end users, why not just use something that's more concise, gives me a REPL and lets me iterate the development more quickly.

About the only feature from Java that I occasionally miss in C++ is reflection. But I find avoiding that usually keeps my architectures cleaner anyway.

Re:Off the top of my head?

[agbinfo]

PHP:

echo str_repeat ("Hello World!\n", 3);

to Ruby:

print "Hello World!\n"*3

to Perl:
print "Hello World!\n" x 3;

Re:Off the top of my head?

[RAMMS EIN]

``I don't think that Ruby is bad, not by a long shot. It's seems fairly
decent and it doesn't seem to be lacking anything necessary. I'm just
curious as to why someone would pick Ruby over some other language. I'm
not quite understanding what the "killer app" of Ruby is. I'm not sure
why this language had to be created.''

Ruby was inspired by a number of good and useful programming languages, such as Lisp, Smalltalk, Perl, and Python. It combines the good features of those into a single language. The result is a language that is very powerful, has clean syntax, is easy to get started with, and allows a little code to do a lot of work.

As for a killer app, I don't think there really is one. Ruby is and has always been a general-purpose language. It got its 15 minutes of fame with Rails, but that has since been cloned in other languages. Nowadays, Ruby is just good at many of the same things Perl is good at, and good at many of the same things Python is good at. I personally prefer Ruby, because it is a very well thought out language and, coming from Lisp, it feels natural to me. Still, I don't think Ruby is that much better that people should or will be switching in droves. It's an incremental improvement over already good and useful languages, not a revolution.

Now, for some specifics.

From Perl, Ruby takes first-class regular expressions. Many Ruby modules are also ports of Perl modules.

From Python, Ruby takes clean syntax. There's quite a lot of competition between Ruby and Python, so I imagine there is a lot of "me too" on both sides.

From Smalltalk, Ruby takes the object system (everything is an object, every object belongs to a class), and blocks (kind of like anonymous functions, but with special syntax). Blocks, especially, are very powerful, as you can use them to (almost, I have to say as a Lisp programmer) implement your own control structures; loops, iterators, etc.

From Lisp, or maybe from other languages that have these features, Ruby takes garbage collection, anonymous functions, dynamic typing, call/cc, symbols as first-class values, printing of objects in Ruby-readable form, a read-eval-print loop (enter code, have it evaluated and the results printed) and probably a bunch of other features I am too tired to think of right now (but not macros, alas).

Ruby also has exceptions, the printf family of functions, and a number of other features commonly found in modern programming languages.

The kicker is that it has all this in a single, coherent language, with a syntax that is easy to understand and learn, and few great pitfalls. Mostly, whether you already know a programming language or not, you can just start coding in Ruby, and it will be easy. There aren't lots of irritating silly parentheses in Ruby, neither is there a difference between scalar and list context. No buffer overflows, no integer overflows, no memory leaks. You don't need to change the way you think, you don't need an IDE. It's easy to get started with, and yet doesn't suffer from problems that languages that are easy to get started with usually have: bad design, limited expressive power, only really being suitable to one domain, etc.

Finally, some code, just for kicks:

# Define an array with first names and one with last names
first_names = [ 'Alice', 'Bob', 'Charlie', 'Deborah', 'Eve' ]
last_names = [ 'Cooper', 'Jones', 'Smith' ]

# Define a class Person
# Each person has a first name and a last name
# which have to be passed to the constructor
# and can be accessed using an accessor
class Person
def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

attr_accessor :first_name, :last_name
end

# Add a pick method to the class Array
# The pick method returns an element from the array at random
class Array
def pick

Re:Off the top of my head?

[abdulla]

People often go on about the "compiler generated overhead" in C++, which always made me believe that function pointers would be just as fast or faster than virtual functions. So I went along with this belief and passed function pointers around instead of just having a virtual function in a base class - I'm talking about one particular situation here where I had the choice of the 2 and I wanted maximum performance, this isn't something I blindly do all the time, virtual functions are infinitely useful and function pointers are a pain in the ass. However one day I thought I'd benchmark the 2 for the hell of it and challenge my assumptions. Turns out, at least with GCC 4 under Linux, virtual methods are significantly faster, especially when optimisations are turned on. So sometimes it's not compiler generated overhead, but rather compiler enabled optimisation due to better object model integration. If you want objects, use C++ - C with GLib is a horrible, horrible hack.

Re:Off the top of my head?

[m50d]

Also doing things in a scripting language and having C do the heavy lifting... sounds like Tcl, Lua, JavaScript. Python offers nothing new there.

Sure, it's an incremental improvement on what's come before. Many of the best things are. Python is mostly Tcl done better, without the odd parse semantics and with working OO in everywhere. It also incorporates some nice functional programming aspects, giving you the best of all worlds. The only thing that's actually *new* is probably the incredibly pure syntax; initially offputting perhaps, but really nice when you start using it. You make a lot fewer syntax-based errors because there just isn't enough syntax to trip over.

Bottom line, Python is the nicest way I've found of turning an algorithm into working code. I can and have read a specification and written out the python code and have it work first time, which is not an experience I've had with any other programming language.

Re:Off the top of my head?

[fyngyrz]

Most of the overhead I've observed has been in much larger executables. Not speed; compilers tend to be awesome at unrolling loops and all manner of other trickery that you wouldn't generally do by hand (because it'd be insanely ugly and hard to understand.)

On your other point, though, I find using functions inside structures (essentially objects) as methods to be so simple as to be absolutely painless. I wonder what you're running into with your virtual functions.

Definition:
struct foo
{
long l_foo;
float f_foo;
int (*function_foo)(struct *foo,int a,float b);
};

Use:
struct foo myfoo;

init_foo(&myfoo); // initialize foo, set function pointer, variables, etc ...
(*myfoo.function_foo)(&myfoo,1,2.0f); // use method

Re:Off the top of my head?

[fyngyrz]

It has been my consistent experience that the more you depend on other people's APIs, the more...

• ...your project grows in distribution requirements and annoyances
• ...bytes your EXE consumes
• ...bugs you can't fix accumulate
• ...code accumulates which you don't actually understand
• ...subtle bugs creep in because you don't understand what you've included
• ...you have trouble making things portable
• ...legal coercion you are subject to
• ...obligations you have to 3rd parties increase
• ...you have trouble maintaining the code
• ...compatibility and functionality between different port targets diverges

Consequently, despite the dangling (and mostly illusory, IMHO) temptation of saving time, I'd just as soon write as much of an application as I can. After decades of writing my own stuff, I have a lot of things I can use, that I *designed* to be usable, in other projects that don't suffer from any of the above problems. I don't mind writing things, either, programming is sort of a zen thing for me. What I mind is not getting it to work correctly and being unable to fix it because some of it is out of my control. Now *that* tweaks my nose. Yes, I'm definitely a control freak.

YMMV, of course. This is just me.

I don't really get the Java hate around here

[JohnnyBGod]

Java's well organized, has a great standard library and is (mostly) consistent with itself. Its only problems, as far as I can see, was that it was initially slow and that it marketed itself as a web language, when there were better choices for that.

Disclaimer: I've only coded in Java since 1.5.

Re:I don't really get the Java hate around here

[Z00L00K]

Which is when Java started to be really good.

Before 1.5 it was harder to avoid those dreaded ClassCastException:s that you could get from Lists and Maps.

But it's still the NullPointerExceptions left to take care of.

Re:I don't really get the Java hate around here

[CastrTroy]

PHP is badly organized, has a long history of importing third party components for what should be included in the base, and is completely inconsistent with itself in many ways. Hasn't caused any problems in popularity for them. I would say by virtue of PHP and all the other popular languagues, that it should be easy to get started (free compilers and runtimes), that it should run on multiple platforms, and that it should be easy to install. Nothing gets you more popularity than millions of newbies trying your tool and being able to get it working that they continue to use it even when they get good, simply because it is what they are used to.

Re:I don't really get the Java hate around here

[Anonymous Coward]

Are you saying that dealing with different versions of C libraries is somehow easier?

Re:I don't really get the Java hate around here

[Jack9]

the fact that it can happen at all is unacceptable.

Same with any interpreted language. PHP, Python, same problem if you are using deprecated accessors. Heck, even the MySQL connector worked differently in PHP3

Are you really suggesting that every time there's a new version they change the name of the language? What about changing the name of every program you write just because you altered the API? Why would you say it's unacceptable?

Re:I don't really get the Java hate around here

[Chabil Ha']

ClassCastException and NPE are the easiest to avoid. With adequate unit testing, those are the easiest problems to find.

While Generics add a lot of protection by making your List strongly typed, using instanceof checks will protect your code when using a List.

Re:I don't really get the Java hate around here

[bjourne]

Disclaimer: I've only coded in Java since 1.5. ... Which suggests that you haven't coded for very long. It is not that Java is bad per se, it just that the competition beats it. Try Python, PHP, Ruby, Erlang, Bash, Lisp or any other really-high level language. You'll be pleasantly surprised and maybe you will also see why people dislike Java.

Re:I don't really get the Java hate around here

[hesiod]

Dealing with specific libraries that usually only matter while creating the program itself (on the developer side) is completely different than requiring the end user of professional software to install one specific version of the client-side environment.

And the point of software is the usage, not the creation. So dealing with issues during creation is the developer's problem. It needs to be usable by the client.

Re:I don't really get the Java hate around here

[hackstraw]

I have some java hate, but java today is not the java of 1997. Its core class libraries are complete and I would assume consistant.

My first experiences with java were the stuff that ran like crap as the so called end-all-be all write once run anywhere GUI language. That is not true today. Java is now a middleware language. Its become glue, and more behind the scenes than it was back in the day.

So, what makes a programming language successful? Well, of course, its success!

No, seriously, today, a programming language becomes and _stays_ succesful if it meets these criteria. 1) Does it have a good user community and is is still used for new projects and not just "legacy" ones? 2) Does it have extensibility and interoperability? That is a BIG one. CPAN, libraries, JARs, APIs, all of those additional features determine a successful programming language.

Today, the most successful programming languages are FORTRAN (its a science and engineering thing, and its not going away tomorrow), C/C++, JavaScript, Java, python, .NET, perl, (does SQL fit in here?), and I guess some ruby, I have little exposure to ruby, and its the newest kid on the block I listed, so the jury is still out on that one.

Programming languages come and go. The way I see it, the real question, is how are we going to get any/all of the above languages take advantage of the trend towards distributed and SMP systems?

_NONE_ of the languages listed there do this particularly well, and there have been TONS of new languages to fix these problems, but to date, we are left with threads, OpenMP, and MPI, and some lesser known languages like Erlang, Titanium, High Performance FORTRAN (or did they give up on that one?), and the like.

I see programming going through a needed paridigm shift "Real Soon" (TM) to address these issues. Along with the development tools as well. Computers are bigger and more complex than they were yesterday, and the languages have not yet caught up to this complexity.

Maybe Ada will come back to life and fix all of this? I don't think so.

Re:I don't really get the Java hate around here

[hesiod]

> Why would you say it's unacceptable?

I am talking about the client here. Having a minimum JRE version is fine, but did the Java developers remove features from the language and not leave and backwards-compatibility hooks in it? That's the only reason I can see why a Java software package would require a version LOWER than "current."

If you write a new version of a programming language you created, and old programs do not work AT ALL, then you have done something wrong. Adding features, improving efficiency, etc is fine (great). Removing functionality does not make sense.

Re:I don't really get the Java hate around here

[visible.frylock]

Dont get the hate? It's the unnecessary complexity

Maybe this has gotten better since the time I was trying to get into Java (~3-4 years ago). But, for better or worse, first impressions are really important. And this kind of code is exactly what I think of when I think Java. I have some really bad memories related to Java (Swing, AWT, type conversion exceptions, Gui layouts (looking at you gridbox)). Some will leave and never come back. Some will try to come back and see if things have improved. Of those, some will return and some won't find anything to persuade them to change. Related to the topic at hand, the life cycle of a language and how it's managed can have a huge impact on the size, scope, and makeup of its userbase.

Oh, and I tried to blockquote that code here but the lameness filter stopped it ;)

Re:I don't really get the Java hate around here

[hardburn]

Does java.io still make you jump through 15 different object declarations just to read a file line-by-line? It's bad huffman coding built into the class design like the above that made me get away from Java.

Re:I don't really get the Java hate around here

[hesiod]

> > is (mostly) consistent with itself
> With itself.

When I see "itself" I consider "Java 1.4.02_09" and "Java 1.4.02_12" to be within the realm of "itself". Yet these two versions (just as an example pair, my argument is not exclusive to just those exact versions) have compatibility problems. Or rather, the developer of the software we use has those problems. But the fact that upgrading by an extremely minor amount (I'd say a 0.0.0.03 version increase is extremely minor) can break an application tells me that there is something wrong with the underlying program.

Re:I don't really get the Java hate around here

[Em Ellel]

So now I'm always wary about using Java applications, since they can easily get tied to a specific JRE and if that JRE has security flaws, you're SOL. Same can be said of ANY language that evolves. I am currently battling an app parts of which require Python 2.3, parts 2.4 and parts 2.5.

The bottom line is that no language will ever make the programmer smart. If the programmer is dumb enough to use some esoteric/ undocumented/ unsupported part of the JVM (Sun has a number of those, but no, it is NOT easy to get stuck on a specific JVM rev unknowingly) - thats the programmer's fault. If the app is supported (or at least open sourced) fixing this sort of a dependency on a particular version should be quick and easy. If you do not have code and the app is not supported, then you really shouldn't be running it in the first place! Sounds like the app was abandoned long before you realized it.

-Em

Re:I don't really get the Java hate around here

[Kentaree]

Java is designed to be backwards compatible (painfully so in fact). I can't say I've ever seen a problem with Java running an app compiled for an older version, and it's definitely not supposed to happen.

Re:I don't really get the Java hate around here

[the_lesser_gatsby]

How does an instanceof protect your code any better than a ClassCastException? Both ways you're throwing an exception at runtime which has to be handled at some level.

A ClassCastException recast to whatever Exception you want (or inspected as is at your exception handler level) is exactly the same as an instanceof test.

Re:I don't really get the Java hate around here

[Rary]

... Which suggests that you haven't coded for very long.

Actually, it suggests that he hasn't coded Java for very long.

Regardless, if you're building a web application, you're probably not going to build it in Bash. The right tool for the job, and all that.

It's silly to say "Language A is better than Language B". What makes more sense is "Language A is better than Language B at task X."

Java is the right tool for many jobs. It'll die shortly after C dies (in other words, not anytime soon).

Re:I don't really get the Java hate around here

[JustinOpinion]

Agreed,a language being easy to install and start using can give it a huge boost in usage.

I would also note that community can have a huge effect. Obviously the size of a community will have a strong effect on whether usage of the language remains, grows, or shrinks. After all, you are more likely to learn a language if you hear about it, if it's used in many other projects, etc.

Additionally, community is important in terms of the amount of support you get. Languages with strong communities will have thousands of online tutorials, excellent forums that provide responsive help, freely available code snippets, plenty of libraries and add-ons, and so on. This kind of 'free support' is often more useful than even careful and exact core documentation.

As a personal example, I (have to) use a programing environment called "Igor Pro" at work. The language syntax bothers me a bit--but on the other hand it is specialized to do some of the things we need it to. But what I really hate about it is the lack of community. When I Google for an answer to a problem I'm having, I get nothing. When I try to find a pre-made package for a non-core feature, it doesn't exist.

Compare that to solving the same programming problem in, for example, Python. Even if it's not the optimal language, the fact that I get find tons of help online, and that there are so many community-developed packages and libraries, means that I can often solve the problem much faster.

When evaluating new languages (and new software products), I always take the time to find out what the community is like. It can make all the difference.

Re:I don't really get the Java hate around here

[lkcl]

see http://norvig.com/python-lisp.html section 10

the author looks like he is inexperienced, and unaware of the function "reduce", which was added initially as a patch to python 1.5 by an experienced lisp programmer (along with map, lambda and filter) and so his example in section 10 could be replaced with:

from operator import add
reduce(add, [1,2,3])

but the point of mentioning this is that java is extremely verbose - and consequently cumbersome.

there is a class of programming language which python 2.x, lisp, smalltalk and other extreme-OO languages fall in to, which have an incredible elegance of expression and a level of empowerment that is wayyyy beyond anything else.

it is not possible to count python 3000 in amongst those languages with extraordinary power, because the developers - primarily guido - believe that the functional-language-based primitives (map, lambda, reduce, filter) are "unnecessary".

i initially thought that this was a joke - it was announced on april 1st.

unfortunately it turns out to be true. the removal of these key features is profound: the language (python 3000) is dead before it is completed. it's difficult to explain but these functional-language primitives are extraordinarily powerful, providing a kind of "zeroth dimension" of data manipulation.

on a single line, you can do incredible data manipulation. i regularly do things like this:

from string import strip
for l in open("file.csv").readlines():
      l = l.strip() # take off newline especially
      l = l.split(',') # split by comma
      l = map(strip, l) # strip white space
      l = map(int, l) # convert everything to ints

of course you could fit that all on one line but i deliberately kept it to 4 lines in order to include the comments. you could also equally do this:

    l = l.strip().split(',')
    l = map(lambda x: int(x.strip(), l)

the flexibility is just... amazing, in python.

the other thing about python is that it tends to be self-documenting, and also, there appears to be a tendency of coders to actually write _some_ documentation.

that, and the fact that it is possible to walk the source code (or, more usually, the object-code) and 'read' it from inside a program, such that you can access the documentation strings and in fact the entire program...

so things like happydoc can auto-generate you HTML documentation, by walking the code itself and collecting all the module, class and function documentation strings - just .... just... incredible!

i regularly do things like this:

import os
print os.path.__doc__

i don't bother to look up online how the function os.path works, i print its documentation string!

you just don't get these kinds of things with java.

Re:I don't really get the Java hate around here

[Em Ellel]

> is (mostly) consistent with itself

Are you serious? Where I work, we regularly use at least three Java applications, and each one requires a particular version of Java, none of which are the same. One of them requires Java 1.5, while another one will break completely if Java 1.5 is installed. It's a nightmare! And while yes, the version requirements may be the fault of the developers, the fact that it can happen at all is unacceptable. Erm, you must be running windows and don't have a sysadmin with a clue. You can run as many versions of JDK in parallel as you want and they will not interfere with each other. Its not rocket science, just set a few env variables. Thats actually one of my favorite things about Java - you are never tied to a "system" install of JVM - in fact you don't even need root privileges to install JVM.

-Em

Re:I don't really get the Java hate around here

[quanticle]

Dealing with specific libraries that usually only matter while creating the program itself (on the developer side)...

Now that's nonsense if I've ever heard it. If that were true, Linux distros wouldn't need package managers.

Re:I don't really get the Java hate around here

[Daniel Dvorkin]

no.the.main.problem.with.java.is.the.length.of.the.class.path.you.have.to.type.to.do.anything();

Re:I don't really get the Java hate around here

[leighklotz]

see http://norvig.com/python-lisp.html section 10

the author looks like he is inexperienced, and unaware of the function "reduce", ... (along with map ...) Maybe you should send the author a note about map and reduce. As director of Research at Google, he's probably in a position to influence some of their programmers to make use of map and reduce.

Re:I don't really get the Java hate around here

[Em Ellel]

If the developer is not supposed to use it, it should not be present at all. Of course I have never implemented my own programming language, but it seems like a good idea... Its not that they should *never* be used, just probably not in commercial/production code. There are plenty of cases where those parts of JVM are very useful, especially in internal and one-of processes. You can gain a lot of performance among other things. A friend of mine is doing the NetFlix challenge and has to use all sorts dark corners of JDK to squeeze it for performance. Its just that if you use it, it becomes non-portable support nightmar. But if you don't care about support (as is valid in some cases) - it is fine.

-Em

Re:I don't really get the Java hate around here

[Anonymous Coward]

I'm always surprised by people so vehemently blasting Java with an attached list of alternatives that includes Ruby. I like Ruby a lot, and use it and Java both on a daily basis, and I would say that yes, I prefer Ruby, but every language has its frustrations and Ruby's standard libraries pale in comparison with Java's. They are in places incomplete, inconsistent, and very often poorly documented, whereas Java has arguable *too much* completeness (to the point of bloat), few cases of inconsistency, and stellar documentation. A great language with an average standard library versus an average language with a great standard library? This is a close race, and very much up to individual choice.
 
I don't have enough experience with the others on your list to vouch for them, but I often see Ruby on these lists and my experience with both doesn't bear it out.

Re:I don't really get the Java hate around here

[maxume]

Are you talking about the section 10 labeled "Python Pre-2.1 did not have lexical scopes."?

If so, your criticism is bizarre, the example is written to illustrate that "Python Pre-2.1 did not have lexical scopes.", not to illustrate the shortest way to rewrite the built-in sum function (you realize that right, that the idiomatic implementation of sum in python is the built in function?).

The reason map and reduce aren't cared about is that most people have an easier time with list comprehensions. Your code:

        l = l.strip().split(',')
        l = map(lambda x: int(x.strip(), l)

can be written as:

        l = [int(x.strip()) for x in l.strip().split(',')]

in python 2.4 onwards. Obviously, you could put that on as many lines as you wanted. If you are worried about performance, generator expressions are very similar to list expressions but lazily evaluated:

        g = (int(x.strip()) for x in l)

g would then create items as they are called for by some consumer (for instance, a for loop or a container object).

Re:I don't really get the Java hate around here

[Otter]

it is not possible to count python 3000 in amongst those languages with extraordinary power, because the developers - primarily guido - believe that the functional-language-based primitives (map, lambda, reduce, filter) are "unnecessary".

1) Those capabilities will still exist in the base language, just with different syntax.

2) If you want the old syntax, it will be available in a standard library.

Save your hysteria for something genuinely catastrophic, like the loss of the print statement.

Re:I don't really get the Java hate around here

[willyhill]

In more ways than one, PHP and MySQL are the Visual Basic and Access of the open source world.

They're not very good (or weren't for a long time), they feel cobbled together at best. But they work. They're fast, have a low learning curve, they're accessible and essentially cheap and/or free. They're easy to deploy and shove into production fresh off the prototype phase.

They have large numbers of people who use them as their primary tools. A large percentage of these people are not exactly what you'd call professional developers (I am not a developer, but I've worked closely with them throughout my career), yet they get "the thing" done somehow, and those systems tend to stay up there driving business for a long time.

It's just funny that the very phenomenon that for years and years the platform and language purists argued was one of the Really Bad things about Windows is actually now coming to Linux in a big way. What those elitists never realized is that most developers just want to get the business of business done, cash a paycheck and go home to their families. They don't care that there are 19 different ways of escaping a string in the runtime library. No one cares about that, as long as the platform continues to deliver, even if it just sort of limps around.

All those thousands and thousands of clueless VB/Access/VBA developers don't suddenly become little Donald Knuths because they're looking at a KDE desktop and using Emacs to code curly braces in PHP.

Re:I don't really get the Java hate around here

[Z34107]

I was going to rant about how that was not true about C, but I stopped myself. C went through a bunch of iterations (AT&T, K&R, others still way before my time) before it became an ANSI standard.

So, I guess the lesson is to use a language that has stopped evolving. I can write POSIX code on a Windows box (Vista + Visual Studio 2005) and compile it and execute it on both Windows and Solaris. (The labs I had to do involved forking, signals, semaphores, and sockets.) With very few exceptions (our Solaris box evidently supported a pause() command) I could compile the same client/server code on both OSes with correct behavior.

Is Python still evolving? Is Java still evolving? I guess the lesson here is to stay away from them. C (and C++ especially) have a lot of nice libraries; if you have to hack a single line of Python out in a 1000 lines of C, save those thousand lines of C in a proper library and #include next time.

Then again, I'm also a "tools for jobs" kind of guy - I'd much rather write the one-line Python program than the 1000 line C program. But then again, is saving 999 lines of code worth the chance of it breaking in Python 2.6?

Re:I don't really get the Java hate around here

[dk.r*nger]

Set the JAVA_HOME environment variable to the path of the JRE you want to use. It's commonly done in a .bat file launching the application.

Re:I don't really get the Java hate around here

[hesiod]

> That was mostly a joke.... mostly ;-)

Sorry, I fractured my funny bone after my first post today required me to repeatedly rush to clarify every letter I wrote. :)

> Beat them up to explain what it does.

I'm pretty sure it is just a pretty face EXE that runs different EXEs that run javaw with the jar files as arguments... Yes, I know this sounds wrong. No, they are not that great at what they do. We are probably their worst customer from their POV, because I have a tendency to ask a lot of questions like "what in the world possessed you to do that?" and pointing out when something they did was a Very Bad Idea(tm)... which is uncomfortably common.

> Chances are it will respect the env variables you pass into it.

Given their history I doubt it, but it doesn't cost me anything but frustration to ask (our support contract is up to date). :)

> is the app a WAR/EAR file for a web app or is it an applet?

Sorry, I have no idea how to determine WAR/EAR. I had to look them up just to know what the acronyms meant. There are multiple programs involved here. The one I am referring to in this post, mostly, is a collection of JAR files that are installed locally, and are standalone applications. There is one launch EXE, and for each program it launches, there is another EXE in the same folder as a JAR.

For other apps, I just know that we open up a web page and it wants java to be there. How it reacts depends on the program. The most important one of these web apps attempts to install JRE 1.4 if it doesn't already exist (even if 1.3 does exist).

Re:I don't really get the Java hate around here

[leomekenkamp]

Today, the most successful programming languages are (...), .NET, (...) (does SQL fit in here?) (...) .NET is not a programming language but a platform. SQL is a query language and not a programming lanugage (Turing machine stuff etc). Java does thread-handling quite decently, it is just too difficult to grasp for most programmers.

Re:I don't really get the Java hate around here

[owlstead]

I've had the same issues with C/C++ and a lot of other languages though. Most Java programs run fine on the latest JDK, and some run up to 20/30% faster on JDK 1.6. There are a few frameworks that try to cope with this problem, such as the OSGi framework for Java and assemblies for .NET. But it is a complex problem and I don't think *any* language has solved this problem completely. It might not even be completely solvable, come to think of it.

My code compiled against 1.2 still runs fine in JDK 1.6 though. So I cannot call that horrible or anything.

Re:I don't really get the Java hate around here

[chromatic]

You'll note that despite those two great features, Perl continues to lose popularity, mostly to Python.

Popularity of what? I've seen various statistics, and the job trends and book sales figures (for two examples) disagree with this assessment.

Re:I don't really get the Java hate around here

[maxume]

I was responding to the complaint about map going away. Idiomatic python for what the original poster is doing would be more like

import csv
reader=csv.reader(open("file.csv"))
# header=reader.next()
for row in reader:
# row is a list of strings from the columns in the csv file.
# convert to int
row=[int(c) for c in row]

grmbl.

[thhamm]

What Makes a Programming Language Successful?

those who don't know how to use it.

Re:grmbl.

[pdq332]

I'm not sure if that was meant as a joke, but I happen to agree with you for the following reason: a programming language is successful when it opens up the field to low to mid grade programmers. These may be people who are professionals in other areas and are just dabbling with a specific task, incurious people who are just trying to make a living, or newbies. If the programming language has constructs and tools available that support these people, then the cost of producing programs goes down and the language becomes more widely adopted by industry. On the other hand, while quality, fully functional and maintainable programs will still be written by experts, experts can bend any Turing complete language with appropriate I/O libraries to their will. (As well, experts can turn any simple system into an overdefined complicated mess.) The one thing which seems to make no difference to the success of a programming language (but I really really really wish it did) is the ease of deployment, versioning, packaging and runtime configuration. It's time consuming on the order of requirements gathering to successfully plan and execute deployment for anything other than a statically linked executable.

Back to Basic

[Z00L00K]

Python et.al. are all languages that we who were there in the 80's remember with a combined horror/amusement when we had to write programs in Basic.

The lack of type-safe variables, the possibility to write unreadable code, hunt for bugs that are caused because two files are incompatible. Interpreting languages has been tried before, and they are never working for large projects that shall live for a long time and has to be maintained by a lot of different programmers.

Java may be a bastard of Ada, but at least it has some type checks built in. However, it's a bit weak on the side where the user can't control memory management in a good way. Another weakness is that methods can't be declared to allow/disallow the return of 'null' values to be detected at compile-time.

Re:Back to Basic

[SatanicPuppy]

I think you've got Python confused with Perl. Python was first released in 1991, and one of its core tenets is a formatting structure that makes it a lot more difficult to write illegible code. So I'm just going to assume you were talking about Perl, and I'm going to assume that you're not as ill-informed as it appears.

Perl is what it is: A quick and dirty language for generating practical programs. It's ugly, it's hard to maintain, and it makes a lot of peoples lives a lot easier by making operations that are extremely complicated in other languages quite trivial to code. Comparing it to C is not an apples to apples comparison. Comparing it to BASIC is like comparing a Pineapple to a Raisin.

Re:Back to Basic

[D Ninja]

the possibility to write unreadable code Hate to break it to you, but that's a possibility in any language.

Re:Back to Basic

[SatanicPuppy]

It is strongly typed, however it doesn't use type declarations, so some people make the mistake of assuming because it doesn't ask, it doesn't care.

Python assumes you know what the hell you're doing, so it won't throw errors if you create two variables, put an Int in each one, and do an Int operation on them, all without declaring a type...It'll figure out the type by context.

However, if you try to multiply an Int by a String, it'll throw the same type errors any other strongly type language will. They call it "duck typing."

Re:Back to Basic

[chrysalis]

Then you didn't understand that BASIC evolved.

The GfA-Basic, Omikron Basic and the Fast Basic on Atari were really good, and except OO aspects, those BASICs don't lack anything that Python has.

Not suitable for large projects?

There were commercial games written in GfA and Omikron. There were complex utilities. There were demos (self-promotion: check out the Bee Forol Demo by Sector One).

BASIC=spaghetti code is a cliché. When I dig into some PHP and Python code nowadays, there is still plenty of horrible code that no one but the original author can actually understand. Not that BASIC code was always elegant, but it was just the same thing: anyone could write either elegant code or horrible code, regardless of what the language looks like.

Re:Back to Basic

[D Ninja]

John put the CD in the cabinet and then sold it.

Faulty pronoun reference. Which one am I talking about? You'll never know. (And if you pick one, I'll just say it was the other one.)

Re:Back to Basic

[KillerEggRoll]

The lack of type-safe variables,

What is your concept of type safety? Declaring types for variables sure as hell doesn't guarantee the validity of the memory contents in languages like C/C++ (defeated all the time with casting!). My guess is that your objection is to dynamic typing - a concept separate from strong typing. Duck typing supports a different philosophy for development - you should program to an interface rather than to a type. It promotes the same benefit of algorithm reuse as you would get from C++ templates and Java generics.

the possibility to write unreadable code

The next argument I could conceive is whether it is more beneficial to perform static or runtime analysis. Pushing decisions to runtime allows reflection, language constructs treated as first-class objects, and other features that are WAAAAAYYY more meta than anything you get out of the box from C++ and Java. That means you have concise and elegant syntax for expressing higher order concepts and abstractions. This in turn means that you will generally have highly readable code that has less boilerplate and more problem-solving code.

the possibility to write unreadable code, hunt for bugs that are caused because two files are incompatible. Interpreting languages has been tried before, and they are never working for large projects that shall live for a long time and has to be maintained by a lot of different programmers.

I would be interested in case studies on the success, or lack thereof, of dynamic languages in large projects. I certainly have a success story of my own in what I would regard a medium-sized project. I think other factors (performance, programmer skill, etc.) limit the uptake of dynamic languages in areas traditionally dominated by static languages.

Re:Back to Basic

[Anonymous Coward]

No, he described strong typing. There is no implicit casting from one type to another going on in Python. Weak typing involves implicit casting of types under certain operators.

Static and dynamic typing are orthogonal to strong and weak typing. Statically typed languages have their type integrity constraints checked at compile-time. Dynamically typed languages do at least some type checking at run-time, usually because resolving a given object's type is undecidable (until it is decided by actually running the code).

Python has a Strong Dynamic typing system. So does Ruby. Except, this is just an implementation detail, since these languages support the actors model of object orientation, which means that Actors/Duck Typing is the appropriate model for the type system.

Re:Back to Basic

[morgan_greywolf]

"Strong typing" and "weak typing" mean a lot of different things to a lot of different people. Those who feel Python programs are difficult to maintain because they are not statically typed like Java or C don't get Python. Consider:

>>> def func(a,b,c):
... return (a+b)*c
...
>>> func(1,2,3)

(the 'return' line is idented even if you can't tell :)) versus:

>>> func("apples"," and oranges ", 3)
'apples and oranges apples and oranges apples and oranges '

But, also this:

>>> func ("apples","oranges","grapes")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in func
TypeError: can't multiply sequence by non-int of type 'str'

What's important to understand is that there IS type checking, but you have to understand that ad-hoc polymorphism creates power. With power may come confusion, but that is the fault of the programmer, not the language.

Re:Back to Basic

[slackergod]

My company currently maintains two large python applications (40-50 LOC, not including custom support libraries). One of them is 6 years old, the other 2 years old. On our development team, we have familiarity with Java, C, C++, Perl, and the concensus is that we've had less maintenance work under python then the other languages.

If you add in the time spent on prototyping and testing, python has saved us way more time and effort.

Regarding type checking and reliability... You need to read up on the idea of "duck typing", Python's philosophy is that actual types get in the way, it's protocols and interfaces that matter. And after 7 years of python programming, I'd have to agree with that philosophy.

All of the critical parts of our apps have had unittests written (which catch semantic glitches at a level typechecking never will)... We've actually spent some time _removing_ type checking from the system, and replacing those lines with hasattr(obj, "append") calls, or creating synthethic protocol tests, allowing our implementations of various inputs to be widely varying: Jython implementations, CPython objects, who cares, they all LOOK the same.

OTHO, maybe you're trolling.
"Python looks like Basic" indeed.
Out of all the languages, I would have
never been reminded of that one.
Javascript maybe (especially considering what prototype.js has going on)

Re:Back to Basic

[shutdown -p now]

Please note that at all points in time the interpreter knows the type of variable a.

No, it knows the type of value that 'a' has; but that can change at run-time. Variables themselves do not have types in Python.

But yeah, the other poster got it right. It's really static vs dynamic typing rather than strong vs weak. Sorry for the confusion.

Easy.

[SatanicPuppy]

Power: What can it do?
Performance: How fast can it do it?
Ease of Development: How fast can quality code be turned out by regular programmers?

Most modern languages fail on a couple of these. C is first class in Power and Performance, but it's not Easy. Ruby is okay in Power, and its very Easy, but it's slow. Java is Powerful, but doesn't match C for Performance, and it's not the quickest for development.

I'm sure many fanboys will disagree with my analysis. They'll say "Regular programmers don't matter (C)" or "It's NOT SLOW (Ruby)" or "Development is too quick! (Java)".

Really though, that's what it comes down to. The problem is, that there are unfortunate tradeoffs that have to be made. Most languages have a strength, but they all make sacrifices to be strong.

Re:Easy.

[jez9999]

C#:

Power: Pretty powerful, unless you want to tinker with an OS kernel or something.
Performance: Very good, even for a garbage collected language.
Ease of development: Very easy, if you have a decent IDE.

Re:Easy.

[hoppo]

For many, if not most, organizations, portability provides very little value. If I'm running a public website, it is unlikely I will swap out OS and web server platforms at will, and even more unlikely I will run some kind of heterogeneous environment. If I'm marketing commercial software, I'm likely to either pick a supported OS platform for a rich application, or market the software as a service and access the services through thin clients (either web or simple GUI applications). Either way, I'm not looking to find a 100% portable language. First, it doesn't exist, and a 90% portable language doesn't do me much better than one that is not portable at all.

Think the fourth consideration should instead be the agility of the language. How easy is it to write code orthogonally? Is there a convenient facility for writing unit and integration tests? Can builds and testing be easily automated? .NET is a real standout with this consideration. Java and RoR are also top players. With these platforms, you can easily maintain a codebase of high quality. As software systems grow in complexity, and with software development trending toward more agile methodologies, stability and regression testing become more important.

In fact, I'm a little surprised I haven't seen this mentioned at all in this discussion.

Aging Engineers

[avandesande]

I think many people fail to recognize that the average age of software engineers has gotten higher and that many have realized that most of the pitfalls in software development have little to do with the language chosen. I would rather concentrate on good engineering practices and refining familiar modules I have developed than learn a new language.

Re:Aging Engineers

[sheldon]

My father, just before he retired, got into a big argument with the kids. They had an embedded system, 32K onboard memory, everything was written in straight C.

The kids wanted to do OOP. My father felt there wasn't enough memory to do this effectively and it was foolish.

The reality was, that the kids just wanted to pretend they were doing OOP. They still used straight C, they just created structs and organized functions in files as if they were classes. It was actually rather clever and made it easier to maintain.

It's hard as you get older, I think, you hear about some new idea as the silver bullet and your immediate reaction is negative because you've heard this so many times before. But you have to have an open mind, and watch and see what is happening.

Otherwise you'll end up as a COBOL developer.

Re:Aging Engineers

[ardor]

I mean 1,000 lines of C++ and C# compared... I'd expect to see fewer errors in the C# and less severe errors when I find them.

Depends on your skills. C# is a safer environment, but C++ has immensely more expressive power. With modern and well-coded C++, these 1,000 lines may equal to 10-20,000 lines of C#/Java. Unfortunately, the ugly C++ syntax and its C cruft make unlocking the true advantages of C++ a black art.

A trivial example is the STL. Java/C# containers don't come even close to the STL's power. Go further and look at Boost.MPL/Fusion/Proto, and you'll see stuff you simply cannot do with Java/C#.

Well. If it were by me, Lisp would be king. But its not a perfect world :)

Re:Aging Engineers

[burris]

The reality was, that the kids just wanted to pretend they were doing OOP. They still used straight C, they just created structs and organized functions in files as if they were classes. It was actually rather clever and made it easier to maintain.

I was under the impression that this is how all quality contemporary software development in the C language was conducted. Maybe the kids weren't as clever as they were up to date.

Re:Aging Engineers

[UnderCoverPenguin]

The reality was, that the kids just wanted to pretend they were doing OOP. They still used straight C, they just created structs and organized functions in files as if they were classes.

You don't need an object oriented language to do object oriented programming, just the will and discipline to do it.

FYI, FWIW, the original implementation of C++ was as a preprocessor to C.

OO languages certainly make it easier to do OOP, however, in my experience, the compiled executable is usually much larger than if you "hand code" OOP in a non-OO langage. Of course, in my experience, even hand coded OOP results in larger executables than non-OOP coding.

Re:Aging Engineers

[ardor]

Stuff like this:

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/examples/lazy_vector.html

Generic Programming in general is impossible in C# because of underpowered generics. Unless stuff like

template
void random(Container &container, Accessor const &accessor)
{
    for (unsigned int i = 0; i (i) = typename Accessor::value_type(std::rand());
}

is possible in C#, this argument holds. (Note that this is an artificial example I came up with; for a good example of real-world usage, check out Adobe GIL).

Another example: http://www.gsse.at/multiprogramming/

C++'s true power lies in its templates. Templates are turing complete, meaning that they for a meta language. Using this meta language, I can adapt code to a specific situation. For example, I can have compile-time polymorphism, which is very useful when there is enough information while compiling to choose the actual type. I can have a list of factory class types, and do a call like create_image (img); which gets compiled to the actual creator function ONLY. No virtual functions, the compiler can even inline without problems. Yes, a JIT could detect that function X has been used with the same parameters for 400 seconds, but this way, I can rationalize unnecessary runtime overhead right from the start. Yet another use was to generate code paths that only differed in pixel format type. I wrote a templated version, and iterated over a list of enums at compile-time. This helped a lot in being cache friendly while not requiring to clone tons of code. Using templates, one can write scientific computing code that rivals even Fortran in terms of performance. See: http://www.oonumerics.org/blitz/

I know C# 3.0 has a functional core, and this is wonderful - many problems can be solved much easier and cleaner with functional style. Generic programming and metaprogramming are the things I sorely miss. I would really like to have a language that has all the strengths of C++, minus its weaknesses (most notably C legacy, hideous template syntax, #include files). So far, D is the closest one, but its not there yet. Also, C++ has an ENORMOUS momentum...

Re:Aging Engineers

[ardor]

I thought it gave developers too much rope when it first came out and the rope has only gotten longer. More powerful languages require more studies. The inherent difficulty always increases with increased ability. But there is a lot of accidental difficulty in C++, thats right. Let me emphasize one thing here: I don't think C++ is the pinnacle of programming. Far from it. But its undeniably powerful, and there is no other language that has this amount of expressiveness and range. Java and C# are severely limited in comparison. Python and Lisp are much more flexible, but at the cost of performance. Where else can I write metaprograms that construct a code path at compile-time, for example? With all the compile-time optimizations applied to the result?

I also gave examples already. Try replicating Boost.Fusion or Boost.Proto in C# or Java. Try replicating Blitz++, or Spirit. Try generic programming in C++, then in Java and C# (you'll curse at the latter two's generics). Look up what's possible with C++ metaprograms (-> Boost.MPL & Fusion). Read books from Scott Meyers and Alexei Alexandrescu (especially Modern C++ Design).

If you want to compare LOC, compare an email client written in Java versus one written in C++ --or-- compare an html push app written in Perl versus one written in C++. C++ won't even come close, because, that's not what it was designed for. But using metaprogramming you can write enough tools to come close in C++. You seem to be trapped in arpa/inet.h or land - try writing a HTTP server or an email client in C++ using boost (especially boost.asio), THEN compare the LOC. (In fact, there is a HTTP server example supplied with asio.)

Lets make the comparison fair - write an email client WITHOUT the Java Standard Library. Just a thin wrapper over the socket API and the system, one that equals the C++ stdlib. I even go as far as saying that with asio, boost, and tr1, I could beat Java's LOC WITH its standard library. (Generally, when a problem demands high language expressiveness, Java's LOC count goes through the roof.)

A lot of the arguments against C++ originate from obsolete C++ code and practices. This is 2008, folks. MFC-style C++ has less than 1% in common with modern C++.

From whose point of view?

[mr_mischief]

Not to sound too much like Obi Wan, but many of the truths we cling to depend a great deal on our own point of view and all that.

If I was working for O'Reilly, Manning, APress, Wiley, et al I'd say a successful programming language was one which sold lots of books.

If I was a hiring manager for a large software company, I'd look closely at what language allowed the most cheap new grads to work together an produce something resembling quality code.

If I was teaching intro to computer science, I'd worry about what was preparing my students for the rest of their education.

If I was teaching a certificate-level course to people looking to get into the job market quickly, I'd look for the language with the highest placement rate.

If I was a person of little clue, I'd go largely by the hype. Some would go with the mainstream hype, and some go with the counter cultural "that's the big hype, but our language is better" underdog hype.

As a programmer, I prefer the language that helps me turn customer requirements into working programs that fastest with the least fuss on my part, and allows decent maintenance and customization later.

As the owner of a small boutique programming shop, I want my expressive, powerful language to give me an advantage over others using less expressive languages. I'd like to find others who can use it, but a few is alright as I don't need a huge team to work on programs.

Re:From whose point of view?

[Reverend528]

Not to sound too much like Obi Wan

These are your father's parentheses. Elegant weapons, for a more... civilized age.

Re:From whose point of view?

[rabiddeity]

Hokey lambda calculus and ancient prefix notation are no match for a good printf at your side, kid.

Python's Success..

[neoform]

Python's success is based on how much python coders bash PHP. The more they attack PHP the better the language gets.

Re:Python's Success..

[missing000]

Nope it gets better. PHP sucks!

Quck!

[Anonymous Coward]

Every program on your screen and your OS was written in C/C++

Re:Quck!

[gardyloo]

I use my own OS written in brainfuck, you insensitive clod!

SOME Answers:

[Jack9]

The less cryptic the better. This generally means, be C-like in your operators and be easily readable at a loop level.

Having multiple abstractions available. Multiple ways to do the same complex task efficiently, not just for() or while(). Regex plz.

Being able to access hardware directly. This includes RAM allocation.

Few unexpected side effects. Documentation is important for both adoption and maintenance of programs written in the language.

That's all I got.

Ruby and Python are ex-parrots, not Java

[ajv]

I review code for security flaws for a living. I am a pioneer in this field and have literally written the book on it (the OWASP Guide and the OWASP Top 10 2007). I've been doing secure code reviews for the last 10 years.

I've reviewed 400-500 applications (it's unclear to the total number, but I usually do a review every other week, some shorter, some longer).

I've never reviewed a Ruby application or been asked to review code written in that language. I have been asked to review a Haskell application.

I have reviewed:

* 85-90% Java, usually with shell and ant scripts and occasionally some Perl. Some *years*, this is the only language I am asked to review.
* 5-10% .NET. I haven't reviewed a .NET application this year.
* 5% COBOL. Primarily as a side line - there's a lot of old code to review, but most folks never do.

I've reviewed three PHP applications professionally, all in the last year, even though this is my preferred language to write stuff.

Java is overwhelmingly used in large commercial settings for high value applications, with .NET a very distant second.

I don't get to review that many COBOL or other mainframe apps. I've been doing ground breaking research in this area as there's no advice today. There is a false belief that this code is somehow "safe" as it resides on the mainframe. Nothing could be more wrong.

Ruby and Python, although interesting langauges, has zero commercial penetration, even for worthless brochureware or community apps.

What they do have is an extremely loud fan base. These languages will not kill COBOL or Java any time in the next forty years or so as the fan base is fickle and will move on to the next big thing when it comes along.

Re:Ruby and Python are ex-parrots, not Java

[Jaeph]

You didn't review any C either, yet we all know that the language is out there and being used. Same with perl.

I think your field of work is too narrow to be completely explanatory.

Btw, I do agree with your general point - I don't see python or ruby bumping aside java. But your personal experience, extensive as it appears, is not enough to derive that conclusion

-Jeff

P.S. I really wish java would go. I hate the upper/lower case thing in all the names.

Re:Ruby and Python are ex-parrots, not Java

[Anonymous Coward]

Do you ever think that maybe your survey has a heavy self-selection bias? I mean it seems to me that the most likely candidates for security reviews would be applications that have been around long enough to have somebody in management say, "Hey, we need to have a third party review this!". This explains how FIVE PERCENT of your applications are COBOL while only "three" are PHP. By your analysis, it's as if C/C++ doesn't even exist...

Re:Ruby and Python are ex-parrots, not Java

[DdJ]

Just as an aside, you can use "EasyToReadAndEasyToType" in a language which is not case sensitive. Nothing is stopping you.

The real question is, should "EasyToReadAndEasyToType" be a different symbol from "easyToReadAndEasyToType"?

I happen to think the answer is "yes, it should be a different symbol". But that's a separate issue from whether you can use camel case in case-insensitive languages.

Re:Ruby and Python are ex-parrots, not Java

[ajv]

It's not about the platform, language or the framework that makes an application safe, it's the security engineering that does. If you don't do any, your app WILL be insecure by design and there's no way you can't fix such code.

However, you have a point to a degree - I am initially more productive reviewing frameworks I am familiar with. But that doesn't mean I would be ineffective at reviewing Python or Ruby. It would take me about half a day to spin up in any language or framework as I found things that are missing. And that's the important thing:

I hate reviewing apps with zero security engineering. It's exactly like shooting fish in a barrel, but hopeless as you're not going to get a nice fish stew at the end.

What I look for are meta-issues found in all languages and frameworks. Syntax and functions can be found in online references - if you need them.

There is nothing special about any language as few protect against the security artifacts we look for.

For example, if your code has an access control mechanism, I look at it in situ on a live test app, deciding how best I might attack it, and then research using the code how I can obviate it at different levels:

* Coarse grained - is this feature access controlled at all? This is definitely a problem for J2EE apps that use servlets as folks think presentation level security is adequate. It's not
* Medium grained - does this feature offer different levels of access based upon your role? If so, how does this mechanism work? What do I do to get around it and steal stuff?
* Fine grained - does this feature restrict access to secured resources (direct object references)? If so, how does this mechanism work?

Each of the things we look at are verifying security mechanisms. Knowledge of the language or framework is simply not necessary. If you know what you're doing, you can prove the lack of security engineering by testing the app in situ and then research why it fails. Once I find a weakness, I look at the code to see why the weakness exists. Once I've found the issue, I look further afield for the pattern and then I document the issue. Rarely does an app or framework have just one weakness - they are usually patterns.

Picking up a new language or grammar and framework, like going from Struts to Spring MVC takes about half a day for someone like me who knows multiple languages, both functional like Haskell, or OO languages like Smalltalk or Ada, or scripting dynamic languages like PHP, Ruby or Python, or declarative languages like C or Java. We do not write the app, we are reviewing the app.

Security mechanisms are usually fairly clear if they exist. If they do not make themselves immediately obvious, they are usually missing.

Folks who have the hubris to think their code is somehow safe, like the COBOL folks on the mainframe or your example of not reviewing code if you don't know it well. That's why I turned down the Haskell review as I didn't know it well enough in the time available. If it was a longer review, I would have taken it as I love to learn new languages.

However, fyi, if you paid me to be a developer, I could be immediately productive in the following languages:

J2EE - Since Java was first released. Major frameworks include Struts, type 1 JSP with JSTL, Spring MVC, Struts 2.0, and JSF
PHP - Since PHP 3 .NET (C# and VB.NET) since .NET 1.0

Could code if absolutely required:

COBOL - 12 months review only experience
RPG - 12 months review only experience
Perl - 15 years experience
Shell scripts - 15 years experience
Ruby with RoR - tested it out for a new version of my forum (UltimaBB/XMB) but it was too slow
C - since 1985. Co-wrote the Matrox millennium driver for XFree86 back in the day
C++ - since CFront was a bastard child
Ada - since 1990. Still have fond memories
Pascal - since 1985, haven't used it for a while

Languages that I don't suck at but wouldn't claim any particular skills:

Re:Ruby and Python are ex-parrots, not Java

[140Mandak262Jamuna]

Andrew San, You have a /. id 5K. It is beneath you to take the bait from AC trolls. Still, thank you for taking time to explain your stand.

Re:Ruby and Python are ex-parrots, not Java

[ajv]

Fair point - my list is not a scientific survey and was never intended to be.

It is skewed towards high value applications - those apps my customers are prepared to pay me to review over a large number of years. There's a significant difference between that set and the total set of applications I *could* review.

There's plenty types of apps I rarely see, such as open source apps (although I am working on one right now) or scientific apps.

Some folks in my field specialize in embedded platforms (usually written in assembler, C or Ada). I have reviewed such apps last couple of years, including EFTPOS terminals as used by about 1/4 of Australian businesses (written in C with some concurrent extensions), and power meter readers used by plenty of US utilities (Windows CE based, written in C++). These two reviews are such a tiny minority of my work, they barely rate in my list.

Although I am able to do code reviews in pretty much any language, I have specialized in high end financial and logistics applications, those that power the world economy. Some of the apps I've reviewed process literally a couple of trillion dollars per day in transactions. These apps are written primarily in Java and COBOL with a smattering of stored procedures (PL/SQL ~= Ada or DB2's stored procedures, generally written in a DB2's SQL dialect).

If you want a scientific survey, SourceForge used to have a project statistics page detailing what languages are in use. This would be a good metric for open source projects. It would be a terrible metric for closed source / proprietary apps.

Yes, sure, it is the evil gang...

[JamesP]

that is going to kill poor Java

It is not the fact that it is overly verbose, too rigid, and is bloated as as a puffer fish on helium.

Re:Yes, sure, it is the evil gang...

[hjf]

yeah, you know, 'cause when you have 50 programmers on a project, C l33tnesses like

while (x-->0) { blah; }

are so cool and easy to understand. and malloc()s make memory management so easy and cross-platform. and clustering is for wussies, if you need more than a core2duo on Linux, is because you're unl33t or because you need to do some routines in über-ELITE assembler.

now when you program in Java you forget all that crap, you just code. need a bigger app? J2EE it and run it on a cluster. add nodes a needed to keep performance. node dies? no problem, J2EE takes care of it.

migrated from mysql to Oracle or DB2? no problem, just let Hibernate know about it.

tired of Windows Server and want to run opensolaris, linux or OS X Server? no problem, just drop your EAR/WAR on the new server and relax. it's working.

wanna add more coders to your project? point 'em to the javadoc and let they read through the verbose (and thus self-explaining) code.

strong typing is there to keep you from doing stupid things. you can always tell what the program IS going to do in all situations, because you HAVE to specify all situations.

but you're too cool for java. lemme know when banks switch their systems to LAMP and we'll talk.

The "scripting" vs "compiled" canard again???

[tyler.willard]

Jesu effing Christo.

One thing ain't got nothing to do with the other.

I can't decide which is worse, this particular bit of idiocy or the all-to-common: "dynamic vs strong typing" arguments.

Actually, maybe I'm being to hasty.

The conflation of runtime implementation details with language capabilites, or the above-mentioned typing confusion, does provide a quick and easy way to tell that someone doesn't know what the hell they're talking about.

Perhaps a better measurement than /. popularity

[klubar]

Don't count out the "dead" languages... IBM estimates that more than 30 billion transactions occur within Cobol programs every day. By contrast, Google averages about 150 million searches each day, or about .5% of Cobol's daily workload.

Rather than a "gee I need a cool website for my mom" choice, perhaps the number of transactions or dollar value would be a better count.

Cobol would probably win, followed by java and the Microsoft languages (C++, C#).

Re:Perhaps a better measurement than /. popularity

[Hoi Polloi]

From a business perspective there is something to be said for older languages.

1. They have highly experienced developers that are widely available.
2. Apps written in them are generally older and have been time-tested and are reliable.
3. The language and its behavior is well understood and is well honed.
4. Many libraries are available

Changing to the latest and greatest language demands that you have a damn good reason. Hopefully you just have to port an existing app but you'll have to start all over with QA testing, security analysis, etc. Usually the reasons for changing are:

1. The pool of developers for that language has gotten too small to continue development and/or maintenance.
2. Hardware changes demand it.
3. The performance gain from changing is too big to ignore.
4. Compatability reasons with other apps, major customers, etc.

Making a programmer feel cutting edge isn't a good reason.

Re:Perhaps a better measurement than /. popularity

[ardor]

Repeat after me:

C++ is NOT a "Microsoft language".

Re:Perhaps a better measurement than /. popularity

[klubar]

Sorry, I should have said the .net languages/environment of which C++ is one.

Java's not going to die

[vivin]

I just started at a new job at the beginning of this year after quitting from my last job where I barely got to do any programming. The place where I work now is a Java shop. I was getting back to Java programming after a hiatus of a few years. For the last few years I mostly doing Perl with a smattering of C (PHP and Javascript on occasion). My experience with Java was mainly from college and a few odd projects I did here and there. The language had changed quite a bit over the last few years and to be honest, I surprised myself by being happy to get back to it (I had some sort of vague dislike for it for a period of time).

The company sponsored a trip to JavaOne at San Francisco earlier this month, for the Dev Team. I also got to go. This was my first time at JavaOne. It was amazing, exciting, and I learnt a LOT of new stuff. The main thing I got from there was that Java, far from being a programming language, is also a platform. There are a lot of new things being built on TOP of Java. For example, Groovy, and JavaFX. Java now has excellent support and frameworks to roll your OWN domain-specific languages.

Python and Ruby are not going to push Java out of the way. For example, you have mergers of Java with these languages (Jython and JRuby). Essentially you have Python and Ruby using Java resources and libraries. I think instead of "dying", Java is just going to evolve into a stable platform that lets you build stuff on top of it.

Expert@work ...

[foobsr]

TFA: "Some languages made strange mistakes. For example Python is a great language but the idea of using indentation as block demarcation really is a cannon ball chained to its feet. While most of the pythonistas defend this idea with a lot of energy, the truth is this feature makes it really a dangerous tool in big, world wide distributed projects - and most important enterprise projects are big and distributed."

Elsewhere: "Python Creator Guido van Rossum now working at Google"

Well. Now I finally know how Google is dangerous.

CC.

What makes a programming language successful?

[pokeyburro]

What makes a programming language successful?

Same thing that makes a religion successful. Adherents.

Re:What makes a programming language successful?

[bsDaemon]

yes, but magic incantations in C are more likely to produce real-world results. The TechnoGods help those who help themselves, after all.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Its partly the API...

[itsdapead]

Obviously there's more than one factor to a language's success, but the breadth and quality of the libraries and application frameworks is a huge factor - if you "know a bit" about programming then I'd say that learning your way around a new API is just as much work as learning a new language.

A big plus for C was that it always came with a substantial standard ("de-facto" to start with, then ISO) library based on the Unix API so it was great for writing portable programs - c.f. Pascal where ISTR the core language couldn't even open a named file. C++ was largely popularized by application frameworks like MFC and OWL, and Delphi did the same for Pascal.

PHP is pretty fugly as a language but comes with a huge library of functions and add-ons that are just what the doctor ordered for web scripting - and when people talk about Ruby, do they really mean Ruby or do they mean Rails?

I don't know about Python - it seems to be a secret society rather than a language and you can't join unless you pass this initiation test where someone tells you a corny joke (stolen from an ancient email circular about Unix and Makefiles) about a language which uses leading whitespace to delineate blocks. I always laugh and fail the test, so I've no idea what the real language is like. :-)

Re:Ruby and Python making Java die? Ha!

[amccaf1]

Sorry, but this article presumes too much.

Python and Ruby are not going to push Java away.

I think you are actually agreeing with the article.

TFA:

Lately I seem to find everywhere lots of articles about the imminent dismissal of Java and its replacement with the scripting language of the day or sometimes with other compiled languages.
No, that is not gonna happen.

Re:... Evolution...

[netsavior]

Although oddly enough the languages for which I speak are things like C#

Have you seen the new 3.0 libraries?? MS Application blocks look a lot like J2EE when it first came out + the best of Jakarta that we have all been using for almost a decade. Don't get me wrong C# does a lot of "good" stuff... but a lot of its most "innovative" stuff is just finally bringing it up to snuff with the way we have all been using J2EE since the dot com bust.

Irony

[w3woody]

Ironically the biggest problem I've had with Java is that, because it is relatively easy for developers to write code using an IDE such as Eclipse or NetBeans in the core language itself, but there are tons of various classes even within the core JRE, many programmers I know who write Java have created a sort of "ecosystem" of artificial complexity.

For example, I worked on one project which was a client/server system which handled maybe 10 transactions per second, with each transaction translating into maybe one or two table updates. The application could have been put together using something simple, like Tomcat and MySQL on the back-end, and something easy to use like an XML/RPC link to the client side. (There were only something like 10 remote procedure calls being made, and this was an internal application, which means the total audience was perhaps 100 people.)

But rather than keep the whole thing simple, we had a whole bunch of "Architecture Astronaut" wannabes who started tossing in third party frameworks like there was no yesterday, without carefully thinking if the framework was needed, and if so, how best to integrate the framework. Before we knew it, the server was broken into 8 separate EJBs, Hibernate and Spring were called in to handle the server side coding framework, and the entire build process was so complicated it no longer could be run or debugged within an IDE--apparently someone on the project didn't understand ant and used makefiles for part of the build. And to top it off, because so many different frameworks were thrown in for no good reason I can determine (there were something like 40 third-party jar files in the build directory), there were all sorts of runtime problems as each jar file was not designed or tested on the full range of Java 1.4 - 6.0 environments.

Now if this was my first exposure to Java, I'd say that while the core language itself wasn't bad, the entire Java ecosystem sucked hard core. But no; it was the developers: rather than keep it simple, they used the 'refactor' button in NetBeans about 100 times too many, until what should have been a one person-three month job turned into half a million lines of crap, that, to their credit, limped along okay.

Depends on what you want ...

[Anonymous Coward]

PHP - Great if you want to get web apps up FAST.
C++ - Great if you want to write OS-dependant apps.
Java - Great if you want to hire a bus-load of CS majors fresh out of university tomorrow.
C# - Great if you want to replace your old VB projects.
Perl - Great if you want to keep your job intact, as no one else will ever able able to read your code.
Python/Ruby - Great if you want to impress PHB's who buy into hype and buzz-words.

That said, the fact that Google apps runs python may see a major shift from PHP in the next few years. It's the only reason I'm starting to learn it. So far, it seems to be a cross between "Perl I can read" and "not quite Java".

(my captcha is develop ~ how apropos)

Oh No!

[bledri]

Essentially this means that Python isn't really feasible to write any larger system and expect it to hold water over several years, or even decades.

Quick, sell your Google stock!

There is a lot of solid Python code out there. The best way to write Python is to also write unit tests. Which is a good practice in any language.

Re:... Evolution...

[nuzak]

Java has generics. Unfortunately they're erased, so they're basically nothing but syntax sugar for runtime casts when you want to use generics from another jar. To add further insult, the compiler yells at you whenever you dare to accomplish such feats of reuse, so most of us have to pepper our code with annotations to shut up the stupid warning about erasure.

Java is now adding "closures", which may or may not actually act as static closures, but may just be syntax sugar for anonymous functions instead. We may see them next year if we're really lucky. Meanwhile C# has LINQ, which is statically typed throughout. C# has a BDFL in Anders Helsburg, Java has a committee that puts Ada's to shame.

Grace Hopper & John Backus didnt have

[peter303]

John McCarthy did. They were inventors of COBOL, FORTRAN and LISP - three languages still in use from the 1950s.

Re:Grace Hopper & John Backus didnt have

[morgan_greywolf]

They were inventors of COBOL, FORTRAN and LISP - three languages still in use from the 1950s.

Yes, only by people who either have finger worn down to stubs, have difficulty forming complete sentences, or have worn out the ( and ) keys on their keyboards.

The Graph

[skeeto]

I found it interesting in this graph in the article that, beginning around 2004, the popularity of Python closely follows the popularity of Delphi. Is this some kind of flaw in the methodology in how the data was collected, like too small a sample size (as Delphi has nothing to do with Python I think)? Or is there some overall pattern causing this? A few others are pretty close in some spots, too, in terms of first derivatives.

Note that the server isn't really /.ed at the time I am writing this, but is throttling itself based on limitations of the hosting account (says only 10 concurrent servings). If you keep trying (aka refreshing the browser) you will get the image I linked to above.

Knuth said that the most important thing is...

[dapyx]

...the name!

The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language.
--Donald Knuth

My god People Know The Answer

[guysmilee]

My god People Know The Answer ... the answer is beyond simple ... and any other answer is simply BS ... 1.) Clear, simple, and familiar grammar/semantics in the core language. 2.) Simple well documented techniques for creating multiple domain specific extensions (i.e. libraries). 3.) Multi-platform compiler/interpreter support. Now stop wasting my time with this trivial crap ...

FFS

[Pedrito]

Java isn't going to die any more than C. Nor will Python or Ruby die any time in the foreseeable future.

Anyone can play Devil's Advocate and make one language look better than another from some point of view, but the fact is, different languages have their different pluses and minuses. I'm sure Ruby and Python have their pluses, but I don't see them being used NEARLY as much as Java. And take into consideration that Ruby has been around just as long as Java and Python has 4 years on both languages. If they were going to kick Java's ass, it would have happened by now.

I suspect the article is wishful thinking (though I can't read it 'cause the site didn't survive this post). I don't know why people have to make such a big deal about this stuff anyway. Languages evolve and new languages and paradigms will be created in the future. Computer programming is still in its infancy. There's a good possibility that 20-30 years down the road, none of these languages will be around. They may be completely replaced by some far more powerful paradigm we can't even imagine yet.

These kinds of predictions are old and pointless.

Java Cannot be 100% Replaced

[wigginz]

What's wrong with Java? Sure I can't slap together a web 2.0 site in 1 day like I could with .net 3.0 or Ruby, but they can't enable a high availability transactional based middle ware system. Java has so many great uses beyond simple web apps, it will always have a place in the enterprise and mobile devices.

Re:Languages and technology stacks

[Chemisor]

> And repeat smart things like not treating arrays as first-class entities?
> Honestly, C is full of design errors.

Come back when you know how the computer works, grasshopper. C doesn't treat arrays as "objects" because the computer doesn't do that. If you want higher level abstractions, use C++, where you have the nice vector class that does what you want.

Old age

[dukeZ]

From the initial take, the intent of the article could easily be construed to say Java will die. But I thought was interesting that it would be from old age, not from some challenger language.

In many regards, concerning its lifetime, C has been/will be around for a very long time too... Which, I think, is probably one of the signs of a good language. Because if it was so horrible/people could not get their stuff done reliably, no one would use it.

Another related case

[richg74]

One of the author's suggestions in TFA is that functional languages have a hard time succeeding because of their concise, "math-y" syntax. Speaking as someone who has been in software development since the System/360 days, and also a sometime math teacher, I think he's absolutely right. Expressing things in mathematical terms is powerful, elegant, and concise; what is isn't is intuitive, at least for the majority of people.

Consider a much earlier example of a math-like language: APL. It allowed concise programs and elegant expression (especially of mathematical ideas, like matrices); it ran in the then-mainstream environment (IBM mainframes); and, it was sponsored by the industry's 800-pound gorilla. And it was the best language for creating write-only programs that I have ever encountered -- think Perl with an extra helping of math and a non-standard character set thrown in. The worst programming assignment I ever had (although I did complete it successfully) was debugging and fixing a financial modeling package written in APL. My take on it was that the programmers who had written it originally fell mainly into two categories:

• Those who were confused by the syntax and concepts
• Those who used the syntax in a contest to see who could be "cutest"

Neither is really what you want going on in an important enterprise-level project.

Smalltak is a huge success and also a failure

[Grapedrink]

It's hard not to turn this discussion into a war and I do believe that even from a qualitative perspective, this discussion is entirely subjective. Let me preface my comments by saying I work primarily in C#, Java, Ruby, and Python in my job, and previously was a C, C++, Fortran, and Assembly programmer. I know about a dozen more languages as well, so I feel I've at least had exposure to many languages to guage success from a developer's point of view. Generally, I think being good at a certain job/task makes a language successful. There is a corollary that one should pick the best tool for the job, not because it's the "best" language. C++ is successful because it was very fast at the time, had a lot of features people wanted, and was relatively easy to learn. Would I do a web page in C++ these days? Probably not.

If I had to pick a language to discuss and deem successful, it would be either Smalltalk or Lisp. Some people find either of those esoteric or "weird," but I rather enjoy writing code in both. Interestingly enough, in many respects neither language is particular successful in a commercial sense, but very much so for most implementations.

I'll stick to Smalltalk because it's a good example for this discussion. It's a case where popularity in my mind is not equal to success. Smalltalk works because it is simple (there are really only 6 keywords or so and not even really keywords at that) and is designed impeccably. If success is related to imitation and admiration, then Smalltalk is up there. Of course in itself, the language is derivative, but it's well-known enough to claim/steal credit for one of the best implementations of existing ideas. I have to laugh at other languages, especially Ruby, Python, C#, and Java as they are adding language features or libraries that emulate things that have existed in Smalltalk for 20+ years. That's rather laughable, but also an indicator of success.

As the Smalltalk saying goes, "Files? How quaint." The language just proves you can design something successful by simplifying and focusing on enabling people to design and use their brains. I feel like I can focus on code rather than language constraints. Smalltalk coding is like teaching them to farm rather than giving them food. There are obvious merits to both approaches. The fact that the language is still around 20+ years later and gaining momentum speaks volumes.

I think what makes it unsuccessful is that a lot of people have no idea it exists in the first place and how it really works. They might look at it and say, "yeah that looks something like Ruby, so what's the point." Usually I find it's lack of understanding of not only Smalltalk, but the fact that the development environment in many ways is the language. Most Smalltalk implementations simply don't have the problems in file-based languages like disorganized code, "too many classes," etc. So many of the plights in other languages don't happen in Smalltalk because of the design and that to me is success, regardless of the number of commercial installations.

Another issues that has halted the language's success in commercial spaces has been ugly UI. Until recently, most implementations have looked awful. Squeak used to look like a child's toy without customizations (still does to some degree, but there's 100s of customized images floating around the internet now). Visual Works looks like an ugly ms-app sometimes, but is a huge leap over the past. Gemstone Smalltalk has no real UI (but can use Squeak). The list goes on, but the point is that even in dev environments, eye candy has a big influence.

It gets even weirder when you look at Smalltalk and languages from the perspective of supporting products. Databases are probably the biggest, and Smalltalk can work with just about everything, but the simple support for the RDBMS is pitiful compared to most popular languages. Especially in recent years, a lot of that has to do with the Smalltalk view. In the Smalltalk world, it seems stupid not to use an object database at this poin

Re:Smalltak is a huge success and also a failure

[Grapedrink]

Frankly, "Smalltalk is successful" is nothing more than a sham. You yourself listed 12+ 'language killer' problems with Smalltalk, agree that basically nobody ever used it and that it is old and outdated... but you still call it a 'success'? ! /boggl You obviously have a decent background and I agree with some of the tings you said, but overall I'm going to have to question what you wrote.

No, I was saying Smalltalk is successful to me for some of the reasons I listed. I said it was not successful in terms of industry and popular terms. I don't think the 12+ language killers you are referring to are problems. Personally, those are likely the reasons I love the language.

Fileless language? Brilliant IMO and forces people to be organized in a structured way. VM? Great idea, makes deployment a snap, restore the state of your dev environment, etc. Need I remind you how VMs in general are all the rage now? Lack of extensive keywords? Makes it simple to learn and extend because the language is essentially written in itself, no weird dropping to C or other languages (see Ruby) causing all kinds of issues.
Outdated? It's updated more or less daily and even has several new web frameworks (just not 2.0 buzzword oriented like Ruby on Rails sorry, etc.).
Frankly, I find Smalltalk to be way ahead of the curve as far as keeping up with the rest of the pack in most areas because there are some great coders that share their stuff and churn it out quick, and the rest was already implemented in the past few decades anyway. How many times can we reinvent a datetime library? Lots of major changes != good language.

If you think no one ever used it, then you really lack an understanding of the language and its history. It's certainly more of a niche language than PHP, but it's not exactly an experimental research language either. I think you might be equating your own personal exposures to general usage.

In general, your first sentence sums it up. Smalltalk is successful because it implements both existing and new ideas well to the point where at least the ideas got more exposure, adoption, and notice. You can wrap all the features in a language you want, but the wrong blend makes it taste terrible. Smalltalk did quite a nice job and that's the reason people give it credit and other languages follow suit. Did you ever stop and think maybe there is a reason people give it credit? Note that I never claimed it was original as you pointed out.

As an aside, my favorite language for code reasons is actually Lisp, but I find developing in Smalltalk is much easier because of the philosophy and design on the language. I find Lisp more powerful, but less clear and about equally expressive for most things. I'd choose Lisp if I was going purely on language design, and Smalltalk for actual implementation from code to deployment. For me, Lisp tastes great but has a bit of an unwanted after taste in some areas. It's a personal thing.

Anyway, again, for me both Smalltalk and Lisp are successful because they help me do great work vs. other languages. I don't consider most popular languages successful because I'd rather die than write code in them, but unfortunately it's hard to escape reality when you're selling your services in the open market. I don't see how you can call Smalltalk a Sham unless you're trying to troll. All languages are good in some way, but we all have our preferences.

Camel case sucks

[wtcorrea]

Here is what some really smart people have to say about this:

• "The use of internal upper-case letters is ugly; it conflicts with the conventions of ordinary language; and it leads to cryptic names, hence the possible errors (compare aLongAndRatherUnreadableIdentifier with an_even_longer_but_perfectly_clear_choice_of_name)."
  Bertrand Meyer
  Object Oriented Software Construction, 2nd Ed., p. 881
  
• "You should use names like ignore_space_change_flag; don't use names like iCantReadThis."
  Richard Stallman
  GNU Coding Standards
  
• "I eschew embedded capital letters in names; to my prose-oriented eyes, they are too awkward to read comfortably. They jangle like bad typography."
  Rob Pike
  Notes on Programming in C
  
• "Mixed-case names are frowned upon."
  Linux Torvalds
  Linux Kernel Coding Style
  
• "Your choice of uppercase or lowercase letters can have a dramatic effect on legibility. In general, use downstyle (capitalize only the first word, and any proper nouns) for your headlines and subheads. Downstyle headlines are more legible, because we primarily scan the tops of words as we read."
  Patrick Lynch and Sarah Horton
  Yale C/AIM Web Style Guide
  

From the article:

[Kingrames]

"Reason number 2: Too much noise is distracting. Programmers are busy and learning 10 languages to the level where they can evaluate them and make an educated decision is too much effort."

okay, if you can't bother to learn more than 1 language, then you can't really call yourself a programmer.

There is Only 1 Rule: My Time is Important

[SparafucileMan]

I'll take any language that can let me write, read, and understand as fast as the speed of computers is progressing, i.e., exponentially.

I don't give a crap if language xxxxxxx is more efficient, more hardcore, etc. You know why?

Because I don't want to spend a year writing an application in C for efficiency and find out at the end that for a mere $1,000 I could have written the same thing in Python in a month and just bought a faster computer 11 months later.

YOUR time is linear, while the computer's is exponential. You'd be a fool to not take advantage of that and, frankly, type safety, efficiency, platform independence, programming style, power, etc. etc. can all go to hell. Just give me a beautiful language.

Re:Wow, I am a little Amazed

[thepacketmaster]

If anyone thinks COBOL is a dead language, simply because the current majority of programmers don't know it, think again. COBOL is alive and well, with new programs being made for it every day. Mainstream programs running on wintel/unix systems don't use it, but it is the choice for governments/banks/large organizations. Why? Because it has a history, it is stable and reliable, and it is simpler for someone unfamiliar with a program to learn how it works. Every cheque that is processed today still goes through a sorter powered by a COBOL system.

As the author mentions, a new programming language is only useful if it addresses a much needed gap in other languages. Java addresses the gaps of memory management, complexity, and cross-platform. Java now has a huge install base, and is serving as a relatively stable language that can do whatever the imagination desires. It's maturing every version, giving it more credibility. It's pretty tough to compete with that.

Learning a new language simply to follow a trend is the sign of inexperience (not youth). Old or young doesn't play into it (although you feel it does). If a new programming language does the exact same thing as another, there is no point to migrate to it. Time and costs simply don't warrant it.

I can agree that learning several languages is an advantage. It helps focus your understanding of programming concepts by having to deal with them in different ways. But if you look people that know multiple languages, the languages are probably going to be from different categories: a low-level language, a high-level language, a scripting language, a compiled language, a web-friendly language, etc.

Btw, the languages I know (and the order I learned them in) are: BASIC, Assembler, C, Unix Shell scripting, C++, Perl, PHP, Java, COBOL. (Yes, I just recently learned COBOL for a new job)

LOL perl

[Anonymous Coward]

I was on an old dial up bbs once having a fierce argument and was deep into a paragraph lambasting my foe, when a nearby thunderstorm injected about 4 lines of pure static garbage characters into my text, and the techy walked by, glanced at my screen and said "taking up perl?"

Re:All Programming Languages Suck

[SQLGuru]

So, basically, what you're saying here is: GET ON MY LAWN! or something like that?

a GOTO statement

[circletimessquare]

hands down, if your programming language doesn't have a GOTO statement, it is a miserable failure

COBOL a success? Why is this even a question?

[sirwired]

I am completely confused as to how the author can even ask the question "Is COBOL a success?"

Is COBOL old? Certainly.
Is COBOL outdated? Yes.
Has COBOL since been replaced by better languages? Yep.
Would you be insane to start a new, large, application from scratch using COBOL? Of course.

But "Is COBOL a success?" Without doubt, yes. Countless millions (perhaps) billions of lines of production COBOL code are still in use. It is still the core behind many of the applications that run our day-to-day lives. These applications have been running for decades with downtime records that would put an average "Web 2.0" app to shame.

Certainly, IBM deserves a lot of credit for this, maintaining pure 100% backward compatibility for those apps for the last forty years or so, but some credit is due to the language itself.

SirWired

Sorry, but

[AnotherUsername]

Fact - C is the best language of all time. 10 Print "BASIC is the Best Language of All Time"
20 GOTO 10

As you can clearly see,
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time
BASIC is the Best Language of All Time

Assembly Language FTW

[Prototerm]

Take *that* you young whippersnappers! If you want to program machines, you have to learn to think like 'em.

The language situation is not good

[Animats]

It's not a very good article. For one thing, measuring language use by search engine hits is silly. Just because it's the easiest way to get a number doesn't mean anything.

The current situation in programming languages isn't very good. It's been 52 years since Backus invented FORTRAN, and we still don't have it right. Let's look at what we've got.

• C and C++ These two languages dominate the hard-compiled field. Yet they're not very good. Every time a computer crashes, the lack of safety in C or C++ is usually at fault. A whole generation of programmers thinks it has to be that way, although it doesn't; Modula III, Delphi, and Ada were all hard-compiled languages with safety. But their supporting organizations (DEC, Borland, and the DoD Ada center) tanked. C++, incidentally, is unique in having hiding ("abstraction") without memory safety. Nobody tried that before C++, and nobody has repeated that mistake.
• C# As a language, C# isn't bad. Unfortunately, it's tied closely to Microsoft's bloated ".NET" environment. The language itself is fast, hard-compilable, and safe. It needs garbage collection, but so be it.
• Java An OK language buried under a mountain of mediocre libraries. The language itself isn't bad, but the amount of cruft that comes with a Java project is incredibly large. This may be because the language is free but the cruft is profitable.
• Perl It's an awful language syntactically, and it's slow, with a naive interpreter. But it does work well and it's very portable.
• Python Python is a nice little language held back by shoddy library maintenance. Python's support libraries (database access, SSL access, web services, etc.) are each maintained by one or two people, with no release coordination. As a result, there's no such thing as a useful "Python distro" that just works out of the box. So web hosting services don't support Python well. Perl handles this little management problem much better, and that's why Python hasn't displaced Perl.
• Matlab Matlab? Yes, Matlab. Most engineering computations today are done in Matlab. It's an awful language, and the stock implementation is inefficient, but it's easy to do number-crunching. Matlab is what replaced FORTRAN in engineering. There's some good work on hard-compiling Matlab for parallel hardware, so the speed problem is being addressed.
• Javascript The language of "Web 2.0". How did we let that happen? Amusingly, enough work is going into speeding up Javascript that's it's probably going to be the fastest of the "scripting" languages in a year or two. It's a mediocre language (the Self object model was probably a mistake, and the scoping rules are weird) but it's good enough.

So that's where we are. No really good hard-compiled language in wide use, and the major scripting languages each have some tragic flaw.

Language vs class of work

[mlwmohawk]

Another set of reasons why some languages survive and some don't may be the types of applications they can be used for.

The C and C++ tool set is *never* going away. You can't, in any practical sense, write an OS in java. C and C++ are *the* standard for writing system level software. Most all system software is written in one of them and they are tightly coupled. There is no other language currently or on the realistic horizon that can replace their functionality.

Java, on the other hand, is popular, but has plenty of practical competition, from C#, to perl, to even PHP. Hell, even visual basic has a VM environment.

As a system level guy, I have little use for Java, C#, perl, or the others except as needed for glue between system level code.

Re:Opinions Are Like @ssholes

[neokushan]

Not knowing what exactly "COSA" was, I did the sensible thing and wiki'd it.

Much to my surprise, it redirected me to an article on Sex Addicts Anonymous (I kid you not, try it yourself: wiki COSA).

Upon seeing this, I can't see how it will help computing at all. Hardcore programmers aren't supposed to get laid at all, let alone get laid so much it becomes a problem. But then maybe that IS the problem, maybe all the REAL programmers are off bonking so much, they don't have time to write a decent C++ library for perfect multithreading....

Ada

[mknewman]

Ok, I'm going to chime in on this. What makes a good programming language is Strong Typing, Bounds Checking, strong compiler time checks and easy maintainability. One of my favorite languages was Ada, back in the 80's, because it made it very difficult to write bad code. I also used a version of GCC called EGCC which did the same sorts of checks and added run time checks, but it also never caught on. Coming from a Quality Assurance background, Ada satisfies the Maintainability, Portability and Reliability requirements. I was very happy to program in it after coming off Pascal and Modula-2. Marc

A combination of 5 things

[tachophile]

In no particular order:

1) Development speed
2) High number of areas the language works well for
3) Low barrier to entry (ease to learn, expense and ease of setting up an initial dev environment to evaluate the language, community support...)
4) Available (cheap) Libraries
5) Industry Buzz

Re:readability

[Just Some Guy]

BASIC and PASCAL etc. are of the "functional programming" ilke

BASIC and Pascal are procedural.

as is SQL

SQL is declarative.

LISP, SCHEME and SMALLTALK were all developed when space was at a premium. so, you kept the source file small by using as obtuse-as-possible a syntax.

That's not why they're that way at all.

Python's a great language, but that's no reason to get sloppy about the details.

This is rediculous

[sentientbrendan]

A lot of noise comes up about these various flash in the pan languages periodicallly, but if you look at a chart of language uses, even python that has been around for 10 years or more has only a few percentage points marketshare.

Meanwhile, Java is the most widely used programming language ever, at around 20%.

http://radar.oreilly.com/archives/2006/08/programming-language-trends.html

Whereas C and C++ hover around the 10 or 20% range.

I use python for some small utilities, and in fact I do expect python's usage to increase over time. However, expecting java or c++ to die, is like expecting English and French to die, and some Esperanto to take over.

It doesn't even *matter* that much if there's some language out there that's so much better than C++ or Java (which is debatable, but functional programming fanatics will scream so loudly about it so I'm not going to bother to argue the point), but that fact that such a vast volume of existing code is written in c++ and java, and there are so many tools and libraries written to support c++ and java development, makes it a *huge mistake* to start some kinds of large software development projects in some other languages, where all of these things will need to be written from scratch at enormous expense.

Projects written in non mainstream languages tend to either fall into a specific program domain the language was designed for, or tend to be very small scale, and usually both. There are very few good *general purpose* langauges that scale up and have good library and tool support. Read: There are *two* of them.... well, three if you consider c#, which I don't, because it is proprietary.

Popularity

[kellyb9]

What Makes a Programming Language Successful? I'm going to go with a high rate of user adoption.

Python 3000 still has FP concepts

[Krischi]

You could write your example just as easily like this:

l = [int(x.strip()) for x in l.strip().split(',')]

This version is arguably *easier* to read than your map-and lambda-based example. Map and filter are pretty much superseded by list and generator comprehensions (in fact, generator comprehensions allow for transparent lazy evaluation and are heavily used in good Python frameworks). reduce() is easy to provide on your own if you really need it, since functions are fist-class objects in Python, but even so I agree with Guido that explicit accumulation loops are easier to read than most reduce() expressions.

The only thing that I could conceivably miss are lambda functions. They do occassionally make for tighter and more readable code, but locally defined closures serve the same purpose, so again, there is no loss of expressiveness.

Re:All Programming Languages Suck

[cjonslashdot]

I agree. Procedural programming is the fundamental problem. Arguing about which procedural language will succeed is like Neanderthals arguing which kind of stone will succeed the one before it. And OO languages are procedural languages in disguise. As Anonymous Coward says, we need to get out of the procedural trap. This is why programs have so many bugs. Let's stop hacking and looking for the next great tool, the next fad, and what our friends are using. Let's look at what approach is truly best.

Re:Opinions Are Like @ssholes

[clampolo]

Not knowing what exactly "COSA" was, I did the sensible thing and wiki'd it.

I got the same wiki about sex addiction. After looking at his crackpot site I found out that this miracle called COSA is just a fancy name for graphical programming and data-driven languages (basically what LabView does.) Or what a schematic diagram does.

Guy clearly never used a schematic diagram or he'd know how painful they are compared to doing the same thing in a normal language like VHDL. Need to add an extra input to one of your functions? UH OH!! Time to tear up all your connectors and sit for 1/2 hour redrawing lines. Same thing would take 5s (literally) in VHDL.

Hopefully, the hospital this guy escaped from finds him and returns him to his cell.

Often overlooked in Java

[ttfkam]

I love dynamic languages as much as the next guy, but there is one major item that I think make Java shine: explicit typing in the interfaces. No seriously, hear me out.

One of the great things about languages like Python is that you can shove just about anything anywhere provided the method signatures and properties match what's being executed. But what about when you didn't write the code? Plone (for example) has gotten much better, but when developing for it, it was often a PITA to find out what features were available from the return value of a given function or what features you should be putting into an object. Yes, I know, the documentation for that CMS has improved greatly in the last couple of years, but I got burned a few years back. And I blame the language.

With Java and interfaces, the objects and values passed to and fro are all documented by design. Javadoc, as often as people like to malign it, is so much better than nothing at all and worlds better than competing code documentation generators for languages like Python, Ruby, or Perl.

"Just look at the Python object definition," you say? The problem is that coders tend to mutate the object during runtime, adding *public* properties and methods on those objects. In addition, there are often methods and properties that are completely useless to the given job at hand. Are they needed in a given instance? You cannot know by looking at the object definition. You need a published interface for that, and that's what Java's interfaces do.

At less than five thousand lines of code, any language would work except maybe for Brainfuck, but that's a whole other can of worms. Once your codebase grows and, more importantly, gets more people involved in its development, documentation becomes all the more important. No, Javadoc isn't the "end all, be all" solution for project documentation by a long shot, but a hell of a lot better than nothing, and without explicit interface definitions, no automated documentation engine will help one bit with real problems.

Java Nukum Forever

[fm6]

Your disclaimer is relevant, since you never got to experience most of Sun's big mistakes. Some of them will never go away, like the fact that some of the original library writers didn't understand the difference between byte streams and character streams. But all in all Java has a certain maturity it lacked when Sun was overselling it as the solution to all our problems.

But that's not why Java is in no danger of dying. Like any other software technology, programming languages are subject to lockin, that combination of cultural habits and legacy installations that keeps software around long after it's. Languages seem to be more subject to lockin than other technologies: unless it's a total failure right out of the gate, it soon develops a culture that maintains it, and a big body of software that must be maintained, and is too expensive to rewrite in a more modern language.

Consider FORTRAN. It was the very first high-level language (1953) and is full of design mistakes that reflect a total ignorance of artificial linguistics and compiler design theory by its inventors. (Not the designers' fault, these fields hadn't been invented yet.) And yet it remains the language for heavy-duty numerical processing. A lot of hard science and engineering grad schools rebel when told to learn it, but learn it they do.

Ironic story: I was working for Sun's Java org in 1998, when a corporate reshuffle caused our group to be given responsibility for maintaining Sun's FORTRAN compiler. Everybody's response was: What? Why the heck do we even have a FORTRAN compiler? Answer, the people who buy high-end computers for science and engineering won't even look at your platform if it doesn't have a FORTRAN compiler.

So Java (and FORTAN) will live forever. And centuries from now, newbie programmers will be wondering about those weird classes that are used to handle standard input and output.

Decrease in IT spending

[koehn]

One of the reasons that Java became so popular was that it was new during a time that business was making enormous investments in IT. That time has passed, and business is less likely to invest in new languages, tools, etc, regardless of their merits.

Python == Basic !?!?

[weston]

Python et.al. are all languages that we who were there in the 80's remember with a combined horror/amusement when we had to write programs in Basic.

You have got to be kidding me.

This is a mistake on the order of "Cats are mortal. Aristotle is mortal. Therefore, Aristotle is a cat."

I'm not a particularly big user of Python, but I know enough to know the comparison with Basic is pretty shallow. There's an interpreter, and there's divergence from C syntax. I think that's about it. And there's all kinds of stuff in Python, Perl, Ruby, and even *PHP* that you could never dream of doing in any Basic I saw during the 1980s.

The lack of type-safe variables,

Type safety. Okay. You're one of those people. You're hereby sentenced to read all of Steve Yegge's blog posts for a year.

Alternatively, you're welcome to cite studies indicating higher productivity for type safe languages.

the possibility to write unreadable code

Which language have you found it impossible to write unreadable code in?

hunt for bugs that are caused because two files are incompatible.

Right. Like there exists a language that addresses this problem.

Interpreting languages has been tried before,and they are never working for large projects that shall live for a long time and has to be maintained by a lot of different programmers.

"Implementations with feature X have failed, therefore any implementation with feature X will fail." That sword can be wielded equally well against compiled "type safe" languages.

The fact that a language has an interpreter that implements it really doesn't have much to do with whether or not it can be compiled. Python can be compiled to Java class files, for instance, and probably a few other targets I don't know about. So can Javascript. Probably Ruby, too.

And as for large, sustainable projects You're posting on a system that's over 10 years old that's built in Perl. You've probably bought books or something else from a bigger site that uses it too. I've worked on a system that predates Slashdot that had a codebase that was 10% Perl and it's still going strong. This is to say nothing of highly visible examples of development in PHP of all things.

I have nothing against compiling when the situation demands it, and I can respect the fact that automatic tools for catching certain kinds of mistakes are helpful. That's not really a function of type safety, however. Ask Perl or PHP (and probably the others) to warn you if you've misspelled a variable or done other "bad" things with it, and they will, for example. But moreover, it's been a long time since most of the mistakes in my programming had anything to do with whether or not I fed the right variable the right type of primitive or reference, and I suspect the same is true of most experienced programmers.

Re:All Programming Languages Suck

[MOBE2001]

Since state is encapsulated atomically, the interpreter is assured that function calls cause no side-effects,

This is an often repeated claim of Erlang fanatics. The truth is that, in Erlang, the functions themselves are the states. To say that there are no side effects in Erlang is a lie. Functions affect other functions (states) and if they are called in the wrong order, bad things will happen. Another problem with Erlang and functional programming in general, is that it does not support fine-grain parallelism. There are a lot of highly useful things that cannot be properly parallelized without fine-grain parallel processing, things like search and sort routines (I am still waiting for an effective parallel quick sort routine in Erlang). A third problem with Erlang is that, like multithreading, it is not deterministic. Determinism an essential requirement of reliable software. In addition, functional programming is not intuitive and many programmers find it hard to get used ot. So you people in Sweden and at Ericsson should stop promoting Erlang as the solution to the parallel programming problem. It is not.

Things that make a language "Good"

[bill_kress]

Depends I suppose. There are multiple worlds at play here. In one corner, there are the new kids just coming into programming, those on small teams, web developers, thrill seekers. They are looking for languages that offer minimal keystrokes, neat features, quick prototyping (rails!), minimal configuration, etc.

For these people, maintainability isn't really even a remote consideration. For them the critical measurement seems to be the ratio of:

  (functionality * fun cleaver features) / (keystrokes * prototype dev time)

They often get bogged down in their own code after the first few releases, but the people who started the project and chose the language are often off to another by this time, and if not they rarely even recognize the additional time spent to repair something later. (and to tell you the truth, if you used prototype development speed to sell the project and delivered the initial prototype and the customer bought it, there is a valid argument that they did the right thing even if it moved time and problems to later in the project cycle)

Another very large (and very quiet) group is more interested in a formula like this:

    (Maintainability * Stability * Consistency * Comprehensibility) / (cleaver features ^ 2)

Note that there is absolutely no concern for how much you type here. Typing speed has no relationship whatsoever for how long it takes a large project to come out--it's an inverse relationship in fact. Having to learn something new just to save a few keystrokes is a huge negative (multiply learning time by the 500 people on your team, it becomes like a manyear per feature easily)

This group is huge--it's virtually every team I've worked with, and, of the ones I've known, maybe 2% twitter, blog, read blogs or listen to podcasts. They are not involved in the community, they just work and go home to their families. They are typically comfortable with Unix and A few read /. (the exception that makes the rule)

They are generally developing in pre java-6, and often pre java-5. Sometimes because they have to, but often because of stability and huge retesting requirements to ceritfy a new development tool.

In my realm they are almost always Java or C++, although the latter is getting more rare. I'm sure in windows they are almost all using C#.

They usually aren't interested in learning about other languages or complicating the one they are using (although they will use the features if available).

This group ranges from uncreative programmers who struggle with concepts like OO or Generics or (in some cases) pointers and boolean math to are excellent all-around programmers; and many used to be in the first group.

Most are just good programmers that want to go home at 5:00 and spend the night with their families instead of jumping straight on the computer to learn a new technology.

Personally I think this latter group is quiet enough that the industry writers, bloggers and podcasters don't realize they exist, but I'd guess that they are at least 70% of the programmers out there.

If it wasn't for Java and C#, they would probably be using ADA or C++. Ruby and Python would never be considered.

bloat vs big

[MtHuurne]

Not every big library is bloated. It's only bloat if it has a poor size to functionality ratio.

For example libc is small, but it does not include XML parsing, HTTP support, SHA1 and MD5 sums, the ability to read compressed files etc. Sure there are libraries for that, but you have to pick and add them yourself. So libc is small not because it is amazingly efficient, but because it is limited in scope.

Personally, I like big standard libraries like Java and Python have. You pay for it in the initial install, but once that is in place, your application has access to a huge amount of functionality without having to add a lot of external dependencies.

Um, you're confused.

[Estanislao Mart�nez]

You don't seem to be very clear on the differences between strong vs. weak type systems, and static vs. dynamic types.

Python is strongly typed. In every place where a Python program can have a type error, the result is defined: some sort of exception is raised immediately, and can be handled regularly through the exception handling system, or to propagate uncaught and kill your program immediately and in a clean fashion.

C is weakly typed. Many kinds of type error can happen at runtime that will leave your program in an undefined state, which may continue indefinitely. E.g., you can do pointer arithmetic and read data from random locations in memory, and interpret it as any type you want instead of what it's supposed to be.

Python is a dynamically typed language. A valid Python program may not contain enough information to infer the type of the values that are assigned to its variables at runtime; or, in other words, any variable may be assigned any value of any type, values in Python must be tagged with their types at runtime, and Python runtime systems need to check the types of arguments at runtime are compatible with the types of the operations applied to them.

C is a statically typed language. The C compiler must be able to determine, at compilation time, the type of every variable, and every expression must type-check for a program to be valid. The way C ensures this is by requiring type declarations on every variable and function. However, that's not essential; languages like OCaml and Haskell are smart enough to infer the types of most of your variables and functions without declarations.

Now, having said all that, let's quote you:

Python assumes you know what the hell you're doing, so it won't throw errors if you create two variables, put an Int in each one, and do an Int operation on them, all without declaring a type...It'll figure out the type by context.

The main problem with this statement here is that you're not specifying what you mean by "context" here. There are two kinds of context that could be relevant: (a) compilation context; (b) runtime context. As it turns out, Python (because of dynamic typing) is allowed to use (b) to figure out the type. However, a language like OCaml can also "figure out the type by context," in the very different sense that it can analyze the program well enough at compilation to figure out that the variables are bound to ints, without your telling it. (And to make it more complicated: an implementation of a dynamically typed language is not required to check types at runtime in every case. A technique used by optimizing compilers for dynamically typed languages is to perform incomplete type inference on programs, figure out the types of variables as best as possible, and use this information to remove runtime type checks where the compiler can prove that they will always succeed. See this blog post for examples of people who've tried to do this for Python in various ways.)

However, if you try to multiply an Int by a String, it'll throw the same type errors any other strongly type language will. They call it "duck typing."

The phrase "multiply an Int by a String" turns out to be ambiguous. Most of the people who responded to you thought about it in terms of syntax: "foo" * 7. The thing is that Python overloads the * operator, and dispatches it to different concrete operations, depending on the type of the arguments. What Python does do is, when applying a concrete operation, throw the type errors.

But also, that is not what the term "duck typing" means. Read your own link. What you're mentioning is just plain old dynamic typing--raise a type error at runtime when the tagged type of the arguments does not match the type required by the operation.

God invented comments and the Devil countered with

[patio11]

Perl.

"Go ahead, take a bit of the apple. There is more than one way to do it."

Next thing you know there are two naked Perl programmers standing around, who quite sensibly made the decision to cover up because "naked Perl programmer" is a scary, scary concept.