What Makes a Programming Language Successful? 1119
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?"
Back to Basic (Score:4, Interesting)
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.
SOME Answers: (Score:3, Interesting)
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 (Score:5, Interesting)
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.
Re:I don't really get the Java hate around here (Score:1, Interesting)
So the network security guys require all computers to be scanned for insecure software. This specific JRE gets tagged as insecure, and the machine gets dropped off the net until we "upgrade" Java.
Except that upgrading Java causes the application to crash. It will ONLY work with that one specific patch level of Java. (Yes, I tried.)
Since we were still in the trial phases, we just dropped the application and replaced it with another one that DIDN'T require Java. Problem solved.
Of course, I doubt the specific security flaw was actually an issue because this was a web service or something that shouldn't do anything with graphics. But arguing that is a losing battle, especially because it did have a Swing-based GUI somewhere.
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.
The "scripting" vs "compiled" canard again??? (Score:3, Interesting)
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.
Re:Back to Basic (Score:5, Interesting)
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.
Perhaps a better measurement than /. popularity (Score:5, Interesting)
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:Off the top of my head? (Score:5, Interesting)
Here we go again... (Score:2, Interesting)
Re:Beards (Score:2, Interesting)
Ruby and Python making Java die? Ha! (Score:2, Interesting)
Python and Ruby are not going to push Java away. For one thing, they are SLOW which automatically disqualifies them in a lot of areas (like high-performance computing). Also, Python interpreter is STILL single-threaded.
Besides, JVM can serve as a platform for many languages. My favorite one is Scala (which is now often deemed as a 'Java killer').
Re:I don't really get the Java hate around here (Score:4, Interesting)
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 (Score:2, Interesting)
Dont get the hate? It's the unnecessary complexity [slashdot.org]
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 ;)
Its partly the API... (Score:4, Interesting)
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:... Evolution... (Score:3, Interesting)
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.
Re:I don't really get the Java hate around here (Score:2, Interesting)
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 (Score:5, Interesting)
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
Irony (Score:5, Interesting)
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.
Re:grmbl. (Score:3, Interesting)
Re:Back to Basic (Score:5, Interesting)
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 [wikipedia.org]."
Re:... Evolution... (Score:3, Interesting)
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.
Re:I don't really get the Java hate around here (Score:5, Interesting)
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.
Re:Back to Basic (Score:3, Interesting)
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.
readability (Score:2, Interesting)
python falls into the same category as LISP, scheme and smalltalk: incredibly incredibly powerful.
it is very difficult to write unreadable code in python, for two key reasons:
1) the indentation method
same number of tabs (or spaces) indicates a block - FORCES programmers to make their code "tidy". many programming languages are absolutely xxxxing awful and impossible to read due to inadequate use of white space.
2) compactness and elegance.
key to python's readability is the lack of messing about and the use of english words. 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.
by the 90s, this was completely unnecessary, and so languages like python are not only highly readable, but also due to having similar OO capabilities as the other elegant languages (lisp, scheme, smalltalk) you can do more with less code.
result: less code on-screen, therefore you don't end up wading through pages and pages of code.
overall... there's just really... no comparison to any other programming language.
_especially_ java.
what is good (Score:1, Interesting)
solve your programming
problem with a minimum of effort.
Solving your problem means a lot if different things.
In my opinion, software that forms the foundation of other software should be strongly typed. Maintenance becomes a nightmare without such typing.
For end-programmer applications, I would think that anything that allows you to be done as quickly as possible is best.
Not a developer, but a user (Score:2, Interesting)
I am not a developer. I don't know all the insides of Java, C#, C++, Python or Ruby. Yet, I have to use these languages and other tools on a daily basis to make a living as somebody who works in the field of integration and system engineering. Programming languages for me are just like tools. I would like to use something that is easy to learn and that gets a job done. That's why I hate C++ and that is why I see Python and Ruby pushing Java out at least in many areas where performance and ability to multi-thread are not the top priorities.
Please spare me the inner details of every language and pros and cos and what is pure object oriented and what is not. I get paid to accomplish things and not to debate about the purity of a programming language. In the environment where you have to make two applications and throw one away, Python really shines. It is a great language for prototypes. It is easy to learn, relatively fast for what I need to do and it can be hooked up with Java or C++ without too many issues. The way I think about it, a language is like a tool. Many years ago everything had to be done by hand and then we developed power tools. I know some purists who love to build furniture and other objects using old school approach (no nails, just glue and hand work). Good for them. I like to use the latest tools that are proven to make my work easier. I don't doubt that Java will be alive and well many years from now, but it is very refreshing to have other high-level alternatives.
Re:Quck! (Score:2, Interesting)
Another related case (Score:5, Interesting)
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:
Smalltak is a huge success and also a failure (Score:5, Interesting)
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:Back to Basic (Score:2, Interesting)
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 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.
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:What makes a programming language successful? (Score:3, Interesting)
Re:Aging Engineers (Score:3, Interesting)
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:Off the top of my head? (Score:5, Interesting)
Re:Ruby and Python are ex-parrots, not Java (Score:3, Interesting)
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.
Re:Off the top of my head? (Score:2, Interesting)
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).
Language vs class of work (Score:3, Interesting)
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:Off the top of my head? (Score:3, Interesting)
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? (Score:5, Interesting)
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? (Score:1, Interesting)
Thank you.
I know all the little ruby people will take offense, much like all the little perl people did 10 years ago whenever you said something negative about a regular expression (the ones that knew "regex" was shorthand for "regular expression".) Java was sort of the first language to launch with marketing, it was a language that was marketed, had some thought leaders, they quickly put together some conferences and stuff, did everything to "make it popular." Ruby is trying to do the same thing but the community is a bunch of misfits and insecure little twats.
Not just do they want to be different, there is peer pressure that they attempt to apply to get others in their tribe to feel insecure about not being different.
The language is nice, but every damn time the big differentiating factor is a closure and iterating through a set. How about something like reversing the bytes in a file or calculating prime numbers or something.
The other thing to me, is there are companies trying to do all ruby solutions, like Twitter or Penny arcade, and without exception they need to invoke other solutions. What's the allure when you have to write C code anyways? At least in Java there is a chance that there is a pure java solution that will perform, it seems exceedingly rare for people to write much C to speed up Java applications anymore. With Ruby, Python, PHP, it's the norm. I guess that's technically a language implementation problem rather than a language problem but the lack of good implementations is of concern.
Re:I don't really get the Java hate around here (Score:3, Interesting)
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).
This is rediculous (Score:3, Interesting)
Meanwhile, Java is the most widely used programming language ever, at around 20%.
http://radar.oreilly.com/archives/2006/08/programming-language-trends.html [oreilly.com]
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.
Re:Irony (Score:1, Interesting)
And some kid comes along and replaces it all with simple and easy understand PHP in three weeks. I made a good living for about four years replacing bloated Java systems that had failed with a triaged (toss features that weren't necessary) version in PHP for a fraction of the man hours. I got pretty good at replacing systems at less than 1% of the original man-hours. With the four programmers I had we successfully replaced nine relatively large systems written in Java at an average of 1/100 the time spent on the failed system.
> the entire build process was so complicated it no longer could be run or debugged within an IDE
Funny you should mention build problems, I sold my part of the PHP business due to a dispute with my partner, and I am now working as a contractor to help fix problems with failing C#/.NET web-based systems. I'm seeing even small companies that can't even compile their software in Visual Studio. Even msbuild at the command line is failing more often than not for some of the larger projects. Projects that should take two minutes (going by how long the number of lines would take to compile in Java) sometimes take four hours or more to compile with
Re:All Programming Languages Suck (Score:3, Interesting)
Re:Aging Engineers (Score:3, Interesting)
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).
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++.
Often overlooked in Java (Score:3, Interesting)
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 [wikipedia.org], 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.
Decrease in IT spending (Score:3, Interesting)
Re:I don't really get the Java hate around here (Score:2, Interesting)
Popularity of what? I've seen various statistics, and the job trends and book sales figures (for two examples) disagree with this assessment.
Python == Basic !?!? (Score:3, Interesting)
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.
Things that make a language "Good" (Score:3, Interesting)
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
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.
Re:Off the top of my head? (Score:5, Interesting)
Re:Off the top of my head? (Score:3, Interesting)
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:
// initialize foo, set function pointer, variables, etc ... // use method
struct foo myfoo;
init_foo(&myfoo);
(*myfoo.function_foo)(&myfoo,1,2.0f);