Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

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?"
This discussion has been archived. No new comments can be posted.

What Makes a Programming Language Successful?

Comments Filter:
  • by steeljaw ( 65872 ) on Thursday May 29, 2008 @12:17PM (#23587623) Homepage Journal
    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.
  • by JohnnyBGod ( 1088549 ) on Thursday May 29, 2008 @12:17PM (#23587633)

    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.

  • Easy. (Score:5, Insightful)

    by SatanicPuppy ( 611928 ) * <Satanicpuppy@OPENBSDgmail.com minus bsd> on Thursday May 29, 2008 @12:20PM (#23587673) Journal
    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.
  • Aging Engineers (Score:5, Insightful)

    by avandesande ( 143899 ) on Thursday May 29, 2008 @12:21PM (#23587689) Journal
    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.
  • by Z00L00K ( 682162 ) on Thursday May 29, 2008 @12:21PM (#23587691) Homepage Journal
    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.

  • by mr_mischief ( 456295 ) on Thursday May 29, 2008 @12:25PM (#23587747) Journal
    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.

  • Quck! (Score:4, Insightful)

    by Anonymous Coward on Thursday May 29, 2008 @12:26PM (#23587769)
    Every program on your screen and your OS was written in C/C++

  • by CastrTroy ( 595695 ) on Thursday May 29, 2008 @12:27PM (#23587789)
    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.
  • by Anonymous Coward on Thursday May 29, 2008 @12:30PM (#23587839)
    Are you saying that dealing with different versions of C libraries is somehow easier?
  • by confu2000 ( 245635 ) on Thursday May 29, 2008 @12:33PM (#23587893)
    I can think of two ways to judge the success of a language.

    1) If people use it.
    2) If you can find people who will pay you to use it. And assorted corollaries: if people will hire you because you know how to use it, etc...

    Given that programmers need to eat, I'd tend to go with the second though the two are basically related anyways.
  • by Anonymous Coward on Thursday May 29, 2008 @12:34PM (#23587901)
    Maybe it just means people using Python and Ruby have enough confidence in their code (rightly or wrongly) that they don't feel they should pay someone to review it.

    Or, if you make the above information publicly known that you haven't reviewed Ruby or Python code that's a pretty good reason for someone to choose somebody else to review their code. Why would they pick a guy with little experience in that language?
  • by Jack9 ( 11421 ) on Thursday May 29, 2008 @12:34PM (#23587905)

    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?
  • by Chabil Ha' ( 875116 ) on Thursday May 29, 2008 @12:35PM (#23587913)
    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.
  • by agrounds ( 227704 ) on Thursday May 29, 2008 @12:38PM (#23587967)
    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.
  • 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 [python.org], so it's often used in concert with C for interfaces, etc.
  • by bjourne ( 1034822 ) on Thursday May 29, 2008 @12:39PM (#23587999) Homepage Journal

    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.
  • by vivin ( 671928 ) <vivin.paliath@NOsPaM.gmail.com> on Thursday May 29, 2008 @12:42PM (#23588047) Homepage Journal
    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 [codehaus.org], and JavaFX [javafx.com]. 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.
  • Re:Aging Engineers (Score:5, Insightful)

    by sheldon ( 2322 ) on Thursday May 29, 2008 @12:45PM (#23588081)
    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.

  • by pokeyburro ( 472024 ) on Thursday May 29, 2008 @12:45PM (#23588089) Homepage
    What makes a programming language successful?

    Same thing that makes a religion successful. Adherents.
  • by Jaeph ( 710098 ) on Thursday May 29, 2008 @12:46PM (#23588095)
    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.
  • by hesiod ( 111176 ) on Thursday May 29, 2008 @12:47PM (#23588109)
    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.
  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Thursday May 29, 2008 @12:48PM (#23588125)
    Comment removed based on user account deletion
  • by amccaf1 ( 813772 ) on Thursday May 29, 2008 @12:49PM (#23588133)

    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?
  • by amccaf1 ( 813772 ) on Thursday May 29, 2008 @12:54PM (#23588239)

    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.
  • by hesiod ( 111176 ) on Thursday May 29, 2008 @12:55PM (#23588263)
    > > 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.
  • 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.
    There are three languages that can run on the client: Java, JavaScript, and ActionScript. Everything else either must be downloaded and installed before running or requires the delay of a round-trip to the server after each action that the user takes.
  • by Hoi Polloi ( 522990 ) on Thursday May 29, 2008 @12:56PM (#23588277) Journal
    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.
  • by the_lesser_gatsby ( 449262 ) on Thursday May 29, 2008 @12:57PM (#23588315) Homepage
    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.
  • by Rary ( 566291 ) on Thursday May 29, 2008 @12:59PM (#23588349)

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

  • by Dan667 ( 564390 ) on Thursday May 29, 2008 @01:00PM (#23588379)
    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.
  • by JustinOpinion ( 1246824 ) on Thursday May 29, 2008 @01:02PM (#23588403)
    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 [wikipedia.org]" 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.
  • by hjf ( 703092 ) on Thursday May 29, 2008 @01:04PM (#23588439) Homepage
    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.
  • by Anonymous Coward on Thursday May 29, 2008 @01:07PM (#23588511)

    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...
  • FFS (Score:4, Insightful)

    by Pedrito ( 94783 ) on Thursday May 29, 2008 @01:13PM (#23588591)
    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.
  • by wigginz ( 730819 ) on Thursday May 29, 2008 @01:13PM (#23588597)
    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.
  • by ShieldW0lf ( 601553 ) on Thursday May 29, 2008 @01:14PM (#23588605) Journal
    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:Easy. (Score:3, Insightful)

    by jez9999 ( 618189 ) on Thursday May 29, 2008 @01:14PM (#23588611) Homepage Journal
    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.
  • by jcgf ( 688310 ) on Thursday May 29, 2008 @01:16PM (#23588647)

    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.

  • by Chemisor ( 97276 ) on Thursday May 29, 2008 @01:17PM (#23588661)
    > 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.
  • by DdJ ( 10790 ) on Thursday May 29, 2008 @01:18PM (#23588679) Homepage Journal
    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.
  • by quanticle ( 843097 ) on Thursday May 29, 2008 @01:18PM (#23588683) Homepage

    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.

  • by Daniel Dvorkin ( 106857 ) * on Thursday May 29, 2008 @01:19PM (#23588689) Homepage Journal
    no.the.main.problem.with.java.is.the.length.of.the.class.path.you.have.to.type.to.do.anything();
  • Old age (Score:2, Insightful)

    by dukeZ ( 974621 ) on Thursday May 29, 2008 @01:19PM (#23588691)
    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.
  • by Anonymous Coward on Thursday May 29, 2008 @01:20PM (#23588701)

    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.

    Given my choice I would hire an engineer with 5-10 years of experience instead of 5 of those cheap new grads" and save a bunch of money.

  • by Em Ellel ( 523581 ) on Thursday May 29, 2008 @01:21PM (#23588711)

    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
  • by Anonymous Coward on Thursday May 29, 2008 @01:22PM (#23588749)
    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.
  • by ajv ( 4061 ) on Thursday May 29, 2008 @01:23PM (#23588759) Homepage
    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:
  • Camel case sucks (Score:2, Insightful)

    by wtcorrea ( 267172 ) on Thursday May 29, 2008 @01:26PM (#23588811)
    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
  • by Anonymous Coward on Thursday May 29, 2008 @01:28PM (#23588855)
    class extended virtual theGreatEarthNovel::theProblemWithProgramming::theProblemWithProgrammingLanguages::theProblemWithJava tpwj{
          import inside here now system::ontology::basic::directions::fromAndTo::justToTestYourTyping::andYourNerves::To to;
          towards::hardware::ui::screen::virtual::notMobile::notCLI where;
    try::reallyHard::butItIsNP::4.times::atLeast:
          system::interface::ui::utf::orLess::characters::ifFail(opticalRecognition) message;

    message = "Java has no problems";

          system::magic::lostMyYouth::expele::towards(to, where, message);
    else:
          system::core::shit::happens::throw::towards::withMessage("Whoops!");

    } ...I really don't get it when people moan about java.
  • From the article: (Score:3, Insightful)

    by Kingrames ( 858416 ) on Thursday May 29, 2008 @01:28PM (#23588859)
    "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.
  • by SparafucileMan ( 544171 ) on Thursday May 29, 2008 @01:31PM (#23588885)
    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.
  • by Anonymous Coward on Thursday May 29, 2008 @01:36PM (#23588985)
    "Well organized" probably refers to the standard library. "Initially slow" refers to one implementation, and marketing has really nothing to do with the language.

    These things are all important factors when choosing an environment, but they are not the language.

    A programming language is a tool for building abstractions -- that's its primary purpose. And Java fails pretty hard at this. No lambda, no root superclass, no multiple dispatch, no good meta system, no bignums (except through its standard library), no syntactic abstraction, and so on.

    The Croquet Project started out using Java, but had to switch to Smalltalk because Java's meta system was simply too weak. In fact, Smalltalk is more internally consistent, and faster than Java initially (where do you think Hotspot came from?).

    If you have a language which, in the early 1990's and for years after that, can best be described as "worse than Smalltalk [and old hacker favorite] in every way [including performance], except we wrote some neat classes for it", is it any wonder the hacker community holds it in such contempt?

    Exercise for the reader: Write a language today which is just like Python, but semantically weaker, syntactically more verbose, less consistent, and slower, and push it to succeed purely by the marketing force of a big company. See how much love you get from hackers.
  • by geekoid ( 135745 ) <dadinportland@yah o o .com> on Thursday May 29, 2008 @01:41PM (#23589079) Homepage Journal
    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.

  • by sirwired ( 27582 ) on Thursday May 29, 2008 @01:45PM (#23589143)
    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
  • by Prototerm ( 762512 ) on Thursday May 29, 2008 @01:52PM (#23589273)
    Take *that* you young whippersnappers! If you want to program machines, you have to learn to think like 'em.
  • by jcgf ( 688310 ) on Thursday May 29, 2008 @01:57PM (#23589341)
    They would be just as clear if you used a regex library and didn't manually parse the characters or something silly.
  • by Animats ( 122034 ) on Thursday May 29, 2008 @02:01PM (#23589409) Homepage

    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.

  • by OrangeTide ( 124937 ) on Thursday May 29, 2008 @02:03PM (#23589447) Homepage Journal
    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.
  • 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.

  • by goombah99 ( 560566 ) on Thursday May 29, 2008 @02:10PM (#23589527)

    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.

  • by AnomaliesAndrew ( 908394 ) on Thursday May 29, 2008 @02:17PM (#23589655) Homepage
    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.)
  • by Z34107 ( 925136 ) on Thursday May 29, 2008 @02:25PM (#23589757)

    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?

  • by Yath ( 6378 ) on Thursday May 29, 2008 @02:53PM (#23590221) Journal
    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.
  • Ada (Score:3, Insightful)

    by mknewman ( 557587 ) * on Thursday May 29, 2008 @03:04PM (#23590381)
    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
  • Re:Back to Basic (Score:2, Insightful)

    by slackergod ( 37906 ) on Thursday May 29, 2008 @03:16PM (#23590547) Homepage Journal
    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)
  • Actionscript! (Score:1, Insightful)

    by Anonymous Coward on Thursday May 29, 2008 @03:16PM (#23590549)
    really... the reason Java is so popular is because all Universities use it to teach programming. The student are lazy and when they come out and play in reality they stick to what they know...

    My favourite language for quick&dirty app making is Actionscript/flash. No other language comes close in speedyness... You have a vector based paint & sound editing program that can read photoshop files & import just about anything from avi movies to mp3's right next to your code, powered by a nice library... and your app can run in a web page or as standalone on practically all platforms.

    So if someone is about to make a new language, check out the flash system and improve on it - Actionscript sure has it's illnesses.
  • by tachophile ( 847378 ) on Thursday May 29, 2008 @03:18PM (#23590575)
    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
  • by kellyb9 ( 954229 ) on Thursday May 29, 2008 @03:36PM (#23590779)

    Java just isn't appropriate in every situation.
    No programming language is.
  • by emilper ( 826945 ) on Thursday May 29, 2008 @03:53PM (#23591013)
    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 ...
  • Popularity (Score:3, Insightful)

    by kellyb9 ( 954229 ) on Thursday May 29, 2008 @03:53PM (#23591033)

    What Makes a Programming Language Successful?
    I'm going to go with a high rate of user adoption.
  • by Krischi ( 61667 ) on Thursday May 29, 2008 @03:55PM (#23591077) Homepage
    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.

  • by TravisO ( 979545 ) on Thursday May 29, 2008 @03:57PM (#23591107) Homepage
    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.
  • by fyngyrz ( 762201 ) * on Thursday May 29, 2008 @04:08PM (#23591263) Homepage Journal

    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.

  • by owlstead ( 636356 ) on Thursday May 29, 2008 @04:38PM (#23591765)
    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.
  • Java Nukum Forever (Score:3, Insightful)

    by fm6 ( 162816 ) on Thursday May 29, 2008 @04:56PM (#23592021) Homepage Journal
    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.
  • by maxume ( 22995 ) on Thursday May 29, 2008 @05:10PM (#23592203)
    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]
  • by WGR ( 32993 ) on Thursday May 29, 2008 @05:18PM (#23592333) Journal

    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:Easy. (Score:2, Insightful)

    by hoppo ( 254995 ) on Thursday May 29, 2008 @05:34PM (#23592535)
    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.
  • by MOBE2001 ( 263700 ) on Thursday May 29, 2008 @05:38PM (#23592601) Homepage Journal
    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.
  • by The boojum ( 70419 ) on Thursday May 29, 2008 @06:08PM (#23592931)
    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.

  • by agbinfo ( 186523 ) on Thursday May 29, 2008 @06:31PM (#23593231) Journal

    PHP:

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

    print "Hello World!\n"*3
    to Perl:
    print "Hello World!\n" x 3;
  • by m50d ( 797211 ) on Thursday May 29, 2008 @07:09PM (#23593689) Homepage Journal
    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.

  • bloat vs big (Score:5, Insightful)

    by MtHuurne ( 602934 ) on Thursday May 29, 2008 @07:09PM (#23593695) Homepage

    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.

  • by Grapedrink ( 1298113 ) on Thursday May 29, 2008 @10:56PM (#23595571)

    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.
  • by hdparm ( 575302 ) on Friday May 30, 2008 @04:55AM (#23597177) Homepage
    One does not learn their trade at a university. University prepares one for learning the trade.

"Floggings will continue until morale improves." -- anonymous flyer being distributed at Exxon USA

Working...