Slashdot Mirror
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?"
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.
.NET. I haven't reviewed a .NET application this year.
.NET a very distant second.
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%
* 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
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.
Andrew van der Stock
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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#).
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.
“Common sense is not so common.” — Voltaire
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
RelevantElephants: A Somatic WebComic...
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.
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."
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
see http://norvig.com/python-lisp.html section 10
.... just... incredible!
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
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.
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.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
Well I think Java's object model is superior. Perhaps it's only a matter of taste rather than cold hard logic.
“Common sense is not so common.” — Voltaire
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.
Higher Logics: where programming meets science.
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.