Hi Steven, It's not just about how pretty the syntax is. Firstly, on average, the more lines of code you have, the more bugs you have. So unless you do something $stupid, reducing the number of lines you write probably reduces the number of bugs you write. Of course, refactoring existing code to make it smaller (less repetitive) won't reduce the number of bugs, as refactors preserve behaviour, but it can still be worth it because the bugs tend to show themselves more clearly.
Secondly, certain languages make it harder than others to move from a mess to something sane. E.g., Java 1.4 with its untyped collections; if you get a ClassCastException because an unexpected object was added, and want to prevent this from happening again, you can either make some collection types that check the class of the objects being added, or write a, say, FooList, that delegates to a List. Java 5 makes this much easier, just add generics and follow the compile errors. Some languages/libraries make it harder to get into the mess in the first place. I work with a large Swing application that has quite a number of EDT violations (GUI components accessed off the event dispatch thread), which means that there are occasional race conditions, etc. It's very hard to fix that without breaking stuff. .NET, however, throws an exception if you instantiate a GUI component off the event thread, making it harder to actually build up the incorrect code in the first place. (incidentally, the Substance LAF does that for Swing) > I feel, if you know your tool well, you'll deliver well, and the > possibility of a language failing you is not with its syntax, but with > the limits of the platform it runs on (For instance, poor integration > with features of the native operating system). I feel this pain daily. The app I mentioned earlier can read MJPEG, MPEG-4 and H.264, output AVIs, burn CDs and playable DVDs, and of those only MJPEG is supported by Java (though we're still using ffmpeg's implementation of that, for no particular reason). All that said, the language still matters, because I spend most of my time reading it. (If anyone can get ffmpeg compiled to Java bytecode via lljvm-gcc or similar, holler) Ricky. -- Ricky Clarkson Java and Scala Programmer, AD Holdings +44 1928 706373 Skype: ricky_clarkson On Mon, Sep 13, 2010 at 6:08 AM, Steven Herod <steven.he...@gmail.com> wrote: > I've worked on projects with a couple of hundreds of thousands of > lines of PHP in a 'mission critical' environment. > > I've also done work with Java, Ruby/JRuby or Groovy/Grails, JavaFX and > most recently Salesforce.com's Apex. I've not touched Scala beyond > starting to read a book on the subject. > > None of these long conversations about various pros and cons of > languages tend to resonate with me, mainly because in the long run, I > just don't think it matters. > > Sure, you have to write boilerplate in one language, but in another, > you have to put up with terrible (or non existent) tooling or crummy > documentation. > > I don't think any language is a silver bullet. Problems don't get > solved, they get moved. The best you can ask for is that the problems > you really care about get solved, and the ones you don't care about > you can live with. And I guess, after all these posts on "lang a vs > lang b" its what I'd like to see more of. > > i.e. If your problem is x, then language y offers you the following > benefits issue. (Problem x being 'CRUD web app', 'Desktop > application', 'Message processing system') > > I feel, if you know your tool well, you'll deliver well, and the > possibility of a language failing you is not with its syntax, but with > the limits of the platform it runs on (For instance, poor integration > with features of the native operating system). > > Sure, one language may be more elegant than another, but I think > that's just programmer ego and most of the time, in the commercial > world, it doesn't matter how beautifully you've implemented it, but > rather, did you get it done at all. > > Anyway, there are far smarter people on this list than I. Perhaps I'm > not intellectually capable of engaging an the deeper merits of many of > these concepts that get argued about - when you eventually all reach a > conclusion, I expect I'll see the results in the "Developers wanted" > section of my local employment website. > > Until then I hope to stay out of the way. :) > > On Sep 13, 1:49 am, Cédric Beust ♔ <ced...@beust.com> wrote: >> On Sun, Sep 12, 2010 at 8:46 AM, Serge Boulay <serge.bou...@gmail.com>wrote: >> >> > The syntax issue is not a problem. I'm just so use to statically typed >> > languages and the tools built around them that I never really considered >> > anything else. I think I identify more with the work you are doing with >> > Mirahhttp://www.mirah.org/wiki/MirahFeatures. >> >> Same here. To me, Ruby has become the replacement of shell, so that whenever >> I need to write a script that is going to manipulate some files, do some >> filtering (great for log files for example) or something simple like that, >> Ruby is my default language. >> >> But because of the fact that it's dynamically typed, I would never consider >> for anything longer than a few hundreds of lines, especially with a team of >> more than one person. >> >> And Charles, I'd like to emphasize that what you did with JRuby is >> absolutely outstanding. >> >> -- >> Cédric > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
