Groovy on Rails (Grails) 0.1 Released

Discussions

News: Groovy on Rails (Grails) 0.1 Released

  1. Groovy on Rails (Grails) 0.1 Released (139 messages)

    Grails, which could be the Java community's answer to Ruby on Rails has had its first public release with Grails 0.1. Grails is built on open source technology such as Spring, Hibernate and SiteMesh and offers a Rails-like environment that integrates seamlessly with the Java platform allowing developers to utilise their existing investment in Java and the JDK.

    Grails also offers idioms familiar to us in the Java community including:
    • AOP-Style Interceptors
    • Dynamic Tag Libraries
    • JSP & Groovy Servers Pages (GSP) Support
    While there has been a lot of hype from former Java developers who switched to Rails, lack of good integration with Java has been a major obstacle preventing any possibility of Rails taking over from Java on the 'low end' as Bruce Tate would say. JRuby also isn't there yet. Another issue is that it's a completely different language.

    Grails addresses these two issues, and may be the Java community's answer to Ruby on Rails, if people can trust Groovy itself. Richard Monson Haefel put out a thought piece claiming that "Groovy will awaken and effectively take over as the dominant dynamic programming language after it becomes a JCP standard."

    Other integrated RAD platforms in Java that people have been talking about include RIFE and Trails.

    Download Grails.

    Threaded Messages (139)

  2. wow ![ Go to top ]

    In comparison to the Groovy, Ruby is powerful still?
  3. Groovy[ Go to top ]

    Groovy!!!!

    I like the idea of something similar to Ruby, but that lives in the Java ecosystem so to speak. Wonder going foward say 10 years how much development will shift from Java to Groovy??
    Where java becomes something the 'old farts' use.
  4. Groovy[ Go to top ]

    Grails is clearly a clone of Rails, and they've done a commendable job of bringing this simplicity to the Java/Groovy world. I'm really impressed and plan to play around with this when I get home.

    Now for the other side of the coin...

    As much as I'm in favour of simple frameworks like this, I really wish that they were named a little more uniquely.

    The development community for almost every popular language in use today is currently being inundated with frameworks like this and if people continue to name them similarly to what's already out there (Rails, Grails, Trails, etc...), they could be doomed to fly under the radar and fade into obscurity. It's hard to take something seriously when it's named with an obvious rip-off.

    So it would be nice to see people make a little effort when naming new frameworks/products. A unique name goes a long way.
  5. Groovy[ Go to top ]

    It's hard to take something seriously when it's named with an obvious rip-off.So it would be nice to see people make a little effort when naming new frameworks/products. A unique name goes a long way.

    True, but at this point, Rails has become a brand of sorts, so calling it Grails will instantly let people understand what it is about. Perhaps the Grails team should change the name before 1.0 - after they have already gotten some momentum.

    Floyd
  6. Groovy[ Go to top ]

    It's hard to take something seriously when it's named with an obvious rip-off.So it would be nice to see people make a little effort when naming new frameworks/products. A unique name goes a long way.
    True, but at this point, Rails has become a brand of sorts, so calling it Grails will instantly let people understand what it is about. Perhaps the Grails team should change the name before 1.0 - after they have already gotten some momentum.Floyd

    Seems the RoR people already have their panties in a twist. Me thinks their might be something to Grails.

    http://www.jroller.com/page/sdevijver?entry=groovy_on_rails_in_not
  7. Groovy[ Go to top ]

    It's hard to take something seriously when it's named with an obvious rip-off.So it would be nice to see people make a little effort when naming new frameworks/products. A unique name goes a long way.
    True, but at this point, Rails has become a brand of sorts, so calling it Grails will instantly let people understand what it is about. Perhaps the Grails team should change the name before 1.0 - after they have already gotten some momentum.Floyd

    On the other hand, it brings up memories of rip-offs like Adibas, PLIMA and Looto :)
  8. wow ![ Go to top ]

    In comparison to the Groovy, Ruby is powerful still?
    in my oppinion, groovy, besides the fact that it doesn't really exist, is crap.
  9. It's a reach[ Go to top ]

    With Java 1.6 we'll begin to have real support for scripting languages on the Java platform with the scripting language API. Groovy is one. Maybe Ruby should be one.

    I don't know, I think Ruby on Rails and Ruby are as much about ways of thinking, i.e., attitude and perspective, as they are about syntax and APIs. For example, Java programmers go ahead and try to configure *everything* with some metadata XML documents. RoR jumps to the more experienced (in my opinion) idea of "convention over configuration," which is not a language feature or API so much as a way of thinking.

    Ditto for Groovy and Ruby as languages: these are open source projects and they attract an open source mentality at their core, i.e., the people willing to produce the frameworks, tools, and language runtimes that everyone else exploits (for better or worse). As soon as you unleash the Leviathan of the Java world on the RoR concept you contaminate it with the wrong motives, wrong people, wrong intentions -- IBM, BEA, Sun, all these guys will latch onto anything that looks like it can make money. And once they do they set up JCPs and consortiums and specs and suck the life out of them.

    I am glad to see Groovy still breathing. If nothing else it'll make Fate Hani eat his words (I'm sure he won't mind, he seems like a good guy at heart) about Groovy as a "failed JSR." If it does fail it's at least in part because the oligarchic JCP abandoned it becuase it didn't look like a money maker.
  10. chasing RoR[ Go to top ]

    How I wish I could edit my hastily written and sloppy postings. Sorry. Anyway, I think it's kind of lame to be chasing someone else all the time and re-implementing their good ideas on your platform. It's better to be the other way: generating good ideas and having other people copy you.

    Now a bunch of people are going to chase RoR with Grails? Why? Maybe just learn RoR and Ruby and see what happens. Maybe you don't have to suck everything that's good onto the same language platform. I don't know.

    Just imagine when something blows up in Grails and you have to dig down through a gigantic stack trace, through Groovy's runtime, then through Jetty and Sping, then into Hibernate ... come on . . . that's going to be a painful experience.
  11. Not sure I agree with the statement. Creating truly original ideas is very hard and most people are really just rehashing the same old ideas. ROR has made incremental improvements over existing systems, but it borrows heavily from existing ideas and concepts. Without prior work, I seriously doubt ROR would be what it is today.

    my bias 2 cents

    peter
  12. I totally agree with Peter on this. We always encouter the same ideas fitted in a particular context. Furthermore, it's not always the creator of the idea who realizes the best implementation.

     - Yagiz Erkan -
     http://blog.decaresystems.ie
  13. I totally agree with Peter on this. We always encouter the same ideas fitted in a particular context. Furthermore, it's not always the creator of the idea who realizes the best implementation. - Yagiz Erkan - http://blog.decaresystems.ie

    ...nor is it the early bird that gets the worm. When you look at all kinds of frameworks that have been built in the recent years, the original creation almost always loses for a reason or another.

    Not that Ruby itself is bad, but it might be the reason why Ruby on Rails never makes it to the big leagues. No commercial support, no proper VM, lack of important libraries etc. You could think of a lot of reasons why Grails might beat RoR in its own game, but who knows.
  14. ...nor is it the early bird that gets the worm.

    :) Let's say "The second mouse gets the cheese!" :)

     - Yagiz Erkan -
     http://blog.decaresystems.ie
  15. Surely you jest[ Go to top ]

    Not that Ruby itself is bad, but it might be the reason why Ruby on Rails never makes it to the big leagues. No commercial support, no proper VM, lack of important libraries etc. You could think of a lot of reasons why Grails might beat RoR in its own game, but who knows.

    This is a joke right? You can't actually be serious. No commercial support, like Linux or Perl you mean? No proper VM? Since when does a language need a "proper VM" to succeed? Smalltalk has always had a fine, as in way better than Java's, VM but it didn't take the world by storm. What "important libraries", i.e., ones that you need to solve the problem at hand, are missing from Ruby? Until there are commercial Grails applications deployed in the real world Grails isn't even in the game.
  16. Surely you jest[ Go to top ]

    No proper VM? Since when does a language need a "proper VM" to succeed?

    Depends what you want it to succeed at. My belief is that a really successful general purpose language should not lack performance. I guess a "proper VM" should include performance.
    Smalltalk has always had a fine, as in way better than Java's, VM but it didn't take the world by storm.

    Not really. It has a variety of VMs, some free, some commercial, some fast, some slow. What it has lacked was a good performance inexpensive cross-platform VM.
    What "important libraries", i.e., ones that you need to solve the problem at hand, are missing from Ruby?

    Well, something like native threads would be an idea, for a start.
     
    Until there are commercial Grails applications deployed in the real world Grails isn't even in the game.

    It has the performance and feastures of the JVM and the rich library of Java. Seems to me like it has a good start.
  17. Not really. It has a variety of VMs, some free, some commercial, some fast, some slow. What it has lacked was a good performance inexpensive cross-platform VM.

    I can only assume that you mean FSF's gcj, since the proprietary VMs are neither very cross-platform, nor inexpensive (for commercial use of their code).

    cheers,
    dalibor topic
  18. Not really. It has a variety of VMs, some free, some commercial, some fast, some slow. What it has lacked was a good performance inexpensive cross-platform VM.
    I can only assume that you mean FSF's gcj, since the proprietary VMs are neither very cross-platform, nor inexpensive (for commercial use of their code).cheers,dalibor topic

    By 'cross-platform' I mean the ability to develop and deploy on more several platforms. The context was a discussion of Smalltalk. There are quality cross-platform VMs, like VisualWorks, but using them involves considerable expense. This is why Smalltalk did not succeed in the way that Java has, in my opinion. I am not sure what you mean by 'very cross-platform', but my meaning was that code on one platform will run unchanged on another. Even if this works for just a few platforms (Windows, Linux, MacOS/X), this gives a tremendous advantage, obviously. As for 'commercial use of their code', well, I am developing commercial Java applications and websites. There is no charge for use of the VM, so I assume you are talking about re-using the source code for the Java implementation? Well, I have never come across a need to do that in my work....
  19. Not that Ruby itself is bad, but it might be the reason why Ruby on Rails never makes it to the big leagues. No commercial support, no proper VM, lack of important libraries etc. You could think of a lot of reasons why Grails might beat RoR in its own game, but who knows.

    Although not being a Ruby not to mention RoR fanboy myself, and having seen RoR fail us on a project, I can't help but point out the fallacy in your argument there.

    Ruby itself is definitely not bad, and it's arguably far better than Groovy as a language. Groovy is (arguably) 0 and Ruby is 10-11 years old. If Grails were to beat RoR at its own game, as you say, that would probably have nothing to do with the language itself.
    There's a lot more involved here than Ruby vs Groovy. Groovy as bad as it is builds
    upon the Java VM and all the libraries available to it. Ruby on the other hand has far less commercial support behind it, Rails the same, and it shows.
    The commercial support and proper VM arguments are truly unfounded. Look at the history of Linux, look at PHP. None have the commercial support Java enjoys and are both very successful technologies and with far more users than Java. Granted, both Linux and PHP have come to have commercial support behind them, but it's taken them more than a decade to get about where Java was in its early days in terms of money and people involved. A very successful decade as well.
    Also, like another poster has mentioned, since when did super performance VMs have become a requirement? Java had traction from its early days when I think it's fair too say that even the code Turbo Pascal put out kicked the living shit out the VM (ok maybe not, but you get the point). On the other hand few people seem to know more about how PHP runs apart from some form of bytecode pre-compilation and the Zend engine - and guess what, nobody seems to give a shit about that and PHP is an awfully popular programming language and the past year has brought at least three of the "big league" boys behind it: Oracle, IBM and Sun (JSR 223 is initiated and lead by Sun).
    What super-duper VM was behind Visual Basic, and in the long run if you'd have to choose between the global success of VB versus VB.NET (that does have a proper VM behind it) in terms of programmers and code base - which one would you place your bets on?

    It's sad to see so many people have been brainwashed in the Java ecosystem. I've been programming Java for the past 5 years professionally and I too had come to a point where I would judge and measure everything in terms of Java, but I got past that sad intellectual stage. A lot of people have as well (rarely do we know see the flaming and flamboyant .NET versus Java wars these days). But like they say, a sucker is born every day, and it seems that the people that were able to see more than one side of the story have slowly been taken over by the java-heads. By the way, this little rant is not necessarily aimed at the the parent post's author.
  20. It's sad to see so many people have been brainwashed in the Java ecosystem.

    I am shocked, shocked to find that brainwashing is going on here! ;)

    Anyway, here's my April 1st proposal:

    Why don't all the various Rails-alike framworks gang together and submit a "Jails" JSR and make it a JCP approved standard?

    cheers,
    dalibor topic
  21. Also, like another poster has mentioned, since when did super performance VMs have become a requirement?

    Performance of VM-based languages has always been an issue, which is why so much work has been put into improving this.
    Java had traction from its early days when I think it's fair too say that even the code Turbo Pascal put out kicked the living shit out the VM (ok maybe not, but you get the point).

    Turbo Pascal was fast, and had a superb compiler.
    On the other hand few people seem to know more about how PHP runs apart from some form of bytecode pre-compilation and the Zend engine - and guess what, nobody seems to give a shit about that

    Of course they do! That is why there are so many products available to try and help with PHP performance.
    PHP is an awfully popular programming language and the past year has brought at least three of the "big league" boys behind it: Oracle, IBM and Sun (JSR 223 is initiated and lead by Sun).

    for a niche use - scripting some web pages.
    It's sad to see so many people have been brainwashed in the Java ecosystem. I've been programming Java for the past 5 years professionally and I too had come to a point where I would judge and measure everything in terms of Java, but I got past that sad intellectual stage.

    My view is that developers should never get to that stage: We should always be reviewing other languages and techniques.
  22. Also, like another poster has mentioned, since when did super performance VMs have become a requirement?
    Performance of VM-based languages has always been an issue, which is why so much work has been put into improving this.
    An issue, yes, to different extends to different languages. I think that the VM performance obsession is so much stronger in the Java ecosystem than it is in other environments; it's part of the Java mindset. You'll be pressed to find a decent Java programmer that can't talk coherently about it for five minutes. In fact, I think you wouldn't consider him a decent Java programmer in the first place if he wasn't able to! There's plenty of other programming language communities that have the same mind-set, some even to larger extents, but it's not a qualifying criteria for widespread use and popular success, in my opinion.
    Java had traction from its early days when I think it's fair too say that even the code Turbo Pascal put out kicked the living shit out the VM (ok maybe not, but you get the point).
    Turbo Pascal was fast, and had a superb compiler.
    ...not. It was fast if by that you mean the IDE performance and the compile times compared to BCC. But code output?
    I don't know what you were programming back in the day in Turbo Pascal, but I was in the demo-scene, writing 3D engines and 2D effects. I was forced to learn assembly because of the poor compiler performance (bless borland for that!) and nobody, I mean nobody in the scene was using pascal, unless they were ASM wizards and wrote most of the code in that and used pascal to glue things together. The optimiser was crap compared to the then-newcomer GCC (DJGPP) and Watcom C/C++ compiler. The moment we rewrote the engine in C and compiled that with DJGCPP we effectively dropped all the assembly from the code because GCC was doing a much better job than I was. It was a bit embarrassing to see that <tt>-O2 --fast-math -fomit-frame-pointer -funroll-loops</tt> was running circles around my optimised MMX code :) By the way, I was really good at this too, it landed me my first job when I was 19 - at UbiSoft!
    On the other hand few people seem to know more about how PHP runs apart from some form of bytecode pre-compilation and the Zend engine - and guess what, nobody seems to give a shit about that
    Of course they do! That is why there are so many products available to try and help with PHP performance.
    I'm sorry but that's just not true. There were a couple attempts at building PHP accelerators, but they faded away a couple of years ago. Zend is basically the only company to provide a performance suite for PHP now. Also please note that these products are simply about pre-compilation, transforming large pages with php code and/or smarty templates into a more compact, alternative form, reducing mainly parsing time, not instruction execution. I think the only attempt to do something meaningful about PHP's VM (except of course the work that Zend puts into it on a regular basis) is the Quercus engine from Caucho, that implements PHP ontop of the Java VM.
    But even if there were 30 products aimed at improving PHP's performance, think of all the millions of PHP programmers that merrily churn out
    site after site after site and to whom "optimisation" means "search engine optimisation", "design pattern" makes them think of oriental motifs and "MVC" is probably how the Europeans call the DMV. Yet they are the justifying numbers and the driving force behind PHP's success as a language for building web sites.
    PHP is an awfully popular programming language and the past year has brought at least three of the "big league" boys behind it: Oracle, IBM and Sun (JSR 223 is initiated and lead by Sun).
    for a niche use - scripting some web pages.
    You think so? Take a look at the Oracle PHP developer center. Doesn't really look like a "oh yeah, so, like, you could also use PHP to script some pages as well" to me. Enterprise, experts, technical whitepapers, even oracle application server appears on that page. Here's the description of the zend core for oracle:
    Zend Core for Oracle, developed in partnership with Zend Technologies, supports businesses using PHP with Oracle Database for mission-critical Web applications. It provides a seamless out-of-the-box experience delivering a stable, high performance, easy-to-install and supported PHP development and production environment fully integrated with the Oracle Database.
    Sounds pretty serious doesn't it? The marketing message is PHP+Oracle = performant, integrated, mission critical, supported. I don't see any niche use, no hint at PHP being appropriate just for scripting some pages. This is big-time, 1st league player endorsement, no matter what one would think of PHP. The IBM press release regarding the Zend Core for IBM is again full of enterprise, support, soa, business-critical, integration, DB2 and other big words.
    And no, I don't have any commercial interest in PHP nor any other programming language.
    My view is that developers should never get to that stage: We should always be reviewing other languages and techniques.
    Definitely. I've come, over the last 5-6 years, to perceive this as an almost organic requirement.
  23. Also, like another poster has mentioned, since when did super performance VMs have become a requirement?
    Performance of VM-based languages has always been an issue, which is why so much work has been put into improving this.
    An issue, yes, to different extends to different languages. I think that the VM performance obsession is so much stronger in the Java ecosystem than it is in other environments; it's part of the Java mindset.

    In my view, it should be part of the mindset of anyone working in a language intended to be general purpose. I have been so deeply frustrated over a long time with working in languages that just don't made the grade in terms of speed - where you are trying to justify to a customer that speed really isn't that important, whereas competitors working in, say C++, can provide something 5-10 times faster This has been such a painful experience in the past that I have a strong bias against the use of any language that can't provide performance.
    There's plenty of other programming language communities that have the same mind-set, some even to larger extents, but it's not a qualifying criteria for widespread use and popular success, in my opinion.

    And in my opinion and experience, it is vital; otherwise you are often falling back to other languages, or perhaps possibly non-portable libraries, to give the muscle an application needs.
    Java had traction from its early days when I think it's fair too say that even the code Turbo Pascal put out kicked the living shit out the VM (ok maybe not, but you get the point).
    Turbo Pascal was fast, and had a superb compiler.
    ...not. It was fast if by that you mean the IDE performance and the compile times compared to BCC. But code output?I don't know what you were programming back in the day in Turbo Pascal, but I was in the demo-scene, writing 3D engines and 2D effects.
    And I have used high-performance numerical applications written in Turbo Pascal - no speed issues at all.

    I may be that you are talking about fundamentally different uses, but I have never in my work come across any performance issues with Turbo Pascal - I am not denying you may well have; but for general purpose use, it seems fine.
    On the other hand few people seem to know more about how PHP runs apart from some form of bytecode pre-compilation and the Zend engine - and guess what, nobody seems to give a shit about that
    Of course they do! That is why there are so many products available to try and help with PHP performance.
    I'm sorry but that's just not true. There were a couple attempts at building PHP accelerators, but they faded away a couple of years ago. Zend is basically the only company to provide a performance suite for PHP now.
    It is true. There aren't just accelerators, and there are more accelerators than Zend. IonCube, for example. There are wide range of tools for performance analysisis and improvement. A quick google search shows this.

    Mblockquote>But even if there were 30 products aimed at improving PHP's performance, think of all the millions of PHP programmers that merrily churn outsite after site after site and to whom "optimisation" means "search engine optimisation", "design pattern" makes them think of oriental motifs and "MVC" is probably how the Europeans call the DMV.
    Yes, but this still contradicts the points that no-one cares about performance.
    for a niche use - scripting some web pages.
    You think so? Take a look at the Oracle PHP developer center.
    Doesn't really look like a "oh yeah, so, like, you could also use PHP to script some pages as well" to me. Enterprise, experts, technical whitepapers, even oracle application server appears on that page. Here's the description of the zend core for oracle:
    Zend Core for Oracle, developed in partnership with Zend Technologies, supports businesses using PHP with Oracle Database for mission-critical Web applications. It provides a seamless out-of-the-box experience delivering a stable, high performance, easy-to-install and supported PHP development and production environment fully integrated with the Oracle Database.
    Sounds pretty serious doesn't it? The marketing message is PHP+Oracle = performant, integrated, mission critical, supported. I don't see any niche use, no hint at PHP being appropriate just for scripting some pages.
    OK, then show me PHP for real-time development; for game development; for mobile devices; for numerical work. Sorry, but scripting web pages IS a niche, no matter how scalable and robust a language is for that use.
    My view is that developers should never get to that stage: We should always be reviewing other languages and techniques.
    Definitely. I've come, over the last 5-6 years, to perceive this as an almost organic requirement.
  24. Steve, please read my original reply, as we seem to deviate strongly from that.
    I understand and agree with your opinion on performance; again that has nothing to do with the fact that a performance-oriented mindset is NOT mandatory for popularity, which is the ONLY point I'm trying to make.
    I'm not advocating this approach, but merely stating it as a fact.

    You say you've used numerical performance apps written in TP; I've written high performance apps in TP and the only way to do it is to get down to assembly. Changing to a C/C++ compiler made all the difference in the world, even for a then inexperienced C programmer. Granted, for general stuff TP was ok. Far from superb though; superb is an _optimising_ compiler that also fares good against competition.

    Regarding PHP acceleration and performance work. Dig a bit deeper than the google search page. IonCube's work on the accelerator was updated in 2003 and then 2005 for PHP 4.4. It's mostly dead, if not, it's at least fading away. The Turk MMCache thing likewise. Broken links, PHP 4.3, last released in 2003. Steve, you're obviously not up to date with this stuff, why bother? And ALL these tools mainly provide pre-compilation or encoding. I have used them in the past. Have you? These and NOT VM improvements. Seems that the only work in that direction, coming from Caucho, you've ignored and sent me back to google; well take a look for yourself. Far from a wide range is it?

    Also you say that whatever contradicts the point that no-one cares about performance. I never said that Steve; read carefully, I said no-one gives a flying buck about how PHP works. Nobody sits around talking about the PHP VM, like the Java heads do. Of course they care about performance, damn it, stop twisting things around.

    I was going to reply to each of your replies individually but realised that there's really no reason to do so. Most of the things you say are either very true and I agree with them, but they have little to do with the point I was making (like the importance of performance), or are not as informed as it would have been required to actually make for an entertaining argument (like the turbo pascal performance and the php performance tools).

    Anyway... thanks for the reply, and have good one!
  25. Steve, please read my original reply, as we seem to deviate strongly from that.I understand and agree with your opinion on performance; again that has nothing to do with the fact that a performance-oriented mindset is NOT mandatory for popularity, which is the ONLY point I'm trying to make.I'm not advocating this approach, but merely stating it as a fact.

    And I disagree; I don't belief is is a fact; for one thing depends what you mean in terms of popularity. Java has far more use than PHP, as does C and C++; that is also because they are more versatile; but I remember the major performance issues with Java when it first appeared - I was a serious critic myself.
    You say you've used numerical performance apps written in TP; I've written high performance apps in TP and the only way to do it is to get down to assembly. Changing to a C/C++ compiler made all the difference in the world, even for a then inexperienced C programmer. Granted, for general stuff TP was ok. Far from superb though; superb is an _optimising_ compiler that also fares good against competition.

    Fair enough - by superb, I meant easy to use, fast and producing code that was efficient (for me!). Compared to, say, Microsoft's C++ compilers in the 80s, for example.
    Regarding PHP acceleration and performance work. Dig a bit deeper than the google search page. IonCube's work on the accelerator was updated in 2003 and then 2005 for PHP 4.4. It's mostly dead, if not, it's at least fading away. The Turk MMCache thing likewise. Broken links, PHP 4.3, last released in 2003. Steve, you're obviously not up to date with this stuff, why bother?

    Ouch!
    And ALL these tools mainly provide pre-compilation or encoding. I have used them in the past. Have you?

    No, I don't use PHP that much, but you are still missing the point; or at least the point I am trying to make.... that performance of PHP is a concern. This may not be the point you were making, but it is the point I am replying to :)
    Steve; read carefully

    Ouch again!
    I said no-one gives a flying buck about how PHP works. Nobody sits around talking about the PHP VM, like the Java heads do. Of course they care about performance, damn it, stop twisting things around.I was going to reply to each of your replies individually but realised that there's really no reason to do so.

    I was not trying to twist things around, and I apologise if this was the impression I gave. The context of the discussion about PHP followed directly in the same paragraph from your statement: "Also, like another poster has mentioned, since when did super performance VMs have become a requirement?". So, I assumed you were still discussing the matter of 'super performance VMs', and hence performance of languages.

    You later continued on what I assumed with the same subject with statements like: " The marketing message is PHP+Oracle = performant, integrated, mission critical, supported."
    Most of the things you say are either very true and I agree with them,

    Excellent :)
    but they have little to do with the point I was making (like the importance of performance), or are not as informed

    Ouch yet again! [how much more can I take?]
    as it would have been required to actually make for an entertaining argument (like the turbo pascal performance and the php performance tools).

    I think we were talking at cross purposes in both subjects - for example your definition of 'superb compiler' was different from mine; but then we had significantly different uses. For numerical work, GUI work, and even device driver writing, I found the Turbo Pascal to be fast, small, easy to use and effective, so I stick by my judgment, but I understand your opinion.
  26. The commercial support and proper VM arguments are truly unfounded. Look at the history of Linux, look at PHP.

    Surely Linux and PHP have their merits, but that is not the point. Technical merit never means that much in the end games. Just look at Windows; Linux could have beaten it by technical merits 10 years ago already. Other unix clones could have beaten Linux by technical merits, but did not.

    You absolutely have to have commercial backing to compete and win! Commercial backing means credibility and visibility. In fact, you need big backers, preferably a few of them. If you are not perceived credible, you are not. I would even go as far as to say that only a marginal group of programmers has even heard of Ruby, let alone know what it is. You absolutely need marketing and public visibility.

    To compete with the likes of Java in the spaces where Java exists prominently, you need a comparable VM. Otherwise you have to accept the fact that things like Ruby will only exist in niche spaces, and it will never get out of there. Ruby/RoR will end up being the 'niftier PHP'.

    The difficulty however is, that it is far easier to fix the complexity issues in software and frameworks than it is to make fast VMs. Ruby needed the fast VM yesterday. Now, there are Java clones of RoR already available. That's where it is all going to boil down to.

    Frameworks like Grails do not even have to be particularly prominent to tax the future programmer population for Ruby. Where are the Ruby programmers going to come from? .NET ...nah. Java? Maybe, but if Java guys see that there is no reason to switch, they won't. It's tough going.
  27. I with most of what you're saying.
    Technical merit never means that much in the end games.
    This is also the base of the argument I made against a previous poster's claim that in order to succeed Ruby needs a strong. You also seem to think that it does. So does Steve. So do I if the question is "is Ruby (or python or php) able to get a strong bite out of Java's playground". We agree on this one; unfortunately that's not what I was saying; merely that in order to be a successful programming language and development platform an uber-VM is not required. Compared to the commercial backing that Java has had from day one, I think it's very fair to say that PHP is a very, very succesful programming language, for web sites. For web sites. Nevertheless, that IS success. And it's been officially ratified as such with the IBM and Oracle announcements and backing. Guys, PHP is a very successful language. It doesn't do everything Java does and surely never will. It will never go mobile, there'll never be a hardware chip that will run PHP bytecode. As you say, "To compete with the likes of Java in the spaces where Java exists prominently, you need a comparable VM"; I think we all agree on this one.

    These contenders don't need to play in the same space as C++, .NET and Java do to be successful, even hugely so. And the degree of success they attain, again, is not a merit of their VM, but that of ease of use, tools, libraries etc. I don't think there's any reason to disagree here.

    Regarding RoR it has a long way to do. We do all our work in Java here, and at one point we had to build a back-office for a large and complex system. Right around the height of the RoR hype. We gave it a spin, and it was all fine and dandy for a while, things were happening rather quickly compared to the usual development pace in Java/Tapestry/iBatis. I did have to go down into the guts of ActiveRecord and fix some queries related to oracle synonyms support, but hey it was a new product let's give it a break. Two weeks in the project the main dev wasted half a day trying to find and integrate an appropriate date selector/picker for a report he was building and got so frustrated during the process that RoR was scrapped, we hired a very good PHP programmer and rewrote the whole thing. Ruby/RoR has failed us not because of performance reasons, but because of a date picker. There were only a couple of these available, they were odd to install and change to suit particular needs, whereas PHP doesn't have these sort of issues. This might seem like an odd decision, but we perceived this as a clear indication of things to come, and I think we've made the right decision.
  28. Compared to the commercial backing that Java has had from day one, I think it's very fair to say that PHP is a very, very succesful programming language, for web sites. For web sites. Nevertheless, that IS success.

    Yes, you are right, but I think this needs to be refined a bit. PHP is very successful for some types of website, especially where a reasonably thin layer of functionality needs to be placed over a database. Of course, you will probably say I am out of date, and prove otherwise :)
    And it's been officially ratified as such with the IBM and Oracle announcements and backing.

    Perhaps because it is good at being a reasonably thin layer over a database :).
    And the degree of success they attain, again, is not a merit of their VM, but that of ease of use, tools, libraries etc. I don't think there's any reason to disagree here.

    Even with all this, developers do often get to the stage of having to write additional code in other languages if the VM (or runtime, or whatever...) is not capable enough.

    I came across a blog entry about this a short while ago. A developer had purchased a significant product written in PHP. They were keen on using PHP because of the portability. Anyway, it turned out that a small part of the application was written in a 32-bit library for Linux. Well, there goes the portability! My impression is that this kind of layered development - most in the slow/easy language but key parts in something with more muscle - happens a lot, and for me at least it is a real barrier to acceptance of such supposedly easy to use languages. I have less objection to such mixed language projects when the languages can be well integrated and you don't lose portability (which is why I am following JRuby and groovy with interest - but what I am interested in those? Because of the quality and performance of the VM!).
    Two weeks in the project the main dev wasted half a day trying to find and integrate an appropriate date selector/picker for a report he was building and got so frustrated during the process that RoR was scrapped, we hired a very good PHP programmer and rewrote the whole thing. Ruby/RoR has failed us not because of performance reasons, but because of a date picker. There were only a couple of these available, they were odd to install and change to suit particular needs, whereas PHP doesn't have these sort of issues. This might seem like an odd decision, but we perceived this as a clear indication of things to come, and I think we've made the right decision.

    I think many projects like RoR go through this stage at the start - there is an attitude of 'hey dude, it's open source - you can always write your own date picker!'.
  29. (which is why I am following JRuby and groovy with interest - but what I am interested in those? Because of the quality and performance of the VM!)

    Are you following YARV with interest then?
  30. (which is why I am following JRuby and groovy with interest - but what I am interested in those? Because of the quality and performance of the VM!)
    Are you following YARV with interest then?

    No. It is only at version 0.4.0. If it shows signs of approaching version 0.9 or 1.0 I may take an interest, especially if it includes good integration with other languages. However, JRuby should (I hope) soon have the ability to produce Java-bytecode classes from Ruby classes. I think that should have more impact on the wider acceptance of Ruby than any attempt to develop a new new VM.
  31. I came across a blog entry about this a short while ago. A developer had purchased a significant product written in PHP. They were keen on using PHP because of the portability. Anyway, it turned out that a small part of the application was written in a 32-bit library for Linux. Well, there goes the portability! My impression is that this kind of layered development - most in the slow/easy language but key parts in something with more muscle - happens a lot, and for me at least it is a real barrier to acceptance of such supposedly easy to use languages.

    The above is not a common scenario with PHP though. I've yet to see an open source PHP project that employs bits in native code speciffic to that application, and I've seen a lot of them. What I'm saying here is this is not the norm, quite the exception.
    This could also happen to Java as well. I remember 3-4 years ago I had to provide a web frontend to a GPS tracking system. The device in the vehicle was really quite interesting, it was custom made (by us) and included a cpu from ajile that ran java in the iron. We had to implement a DHCP client, IP and UDP from scratch, over a serial line that linked the cpu's board to a GSM/GPRS module. Quite interesting and fun indeed, but that's not the story here; we had somewhere around 2GB of compressed TIFFs maps of the UK in great detail, resolution somewhere around 5 meters I believe. It would unpack to somewhere around 32GB of raw RGB data. A web frontend employed the netscape liveconnect thing that links java to javascript - I can't remember what this did really, but it was something very similar to the way axaj works today, anyway it was used to fetch coordinates from the server and move an html layer with the vehicle icon upon the map in the page. The image files were also pre-scalled in /8 /4 /2. As the object left the frustum the page had to reload with a new section of the map. This is where the sh*t would hit the fan. The Java image APIs and codes would load in memory and decompress the whole file taking up hundreds of megabytes of RAM. Imagine what happend when the square on the screen had to be constructed from 2 or 4 different maps! Thrashing, that's the word, VM thrashing.
    The libtiff (the C library) API provided means to read horizontal slices from the TIFF files, and allowed me to decompress only those. So I wrote this C++ class that would receive the GPS coordinates, a zoom level, width and height and would return a chunk of RGB data. This was capable of handling a few hundred calls for different parts of the map per second on the same hardware. The Java VM back then was not significantly slower than it is now, not enough to make a difference anyhow. It was the libraries that were lacking. So anyway I used swig to generate an interface for the native code and tested it with both Java and PHP. Then the project died :)
    As I can't remember the point I was trying to make when I started writing this (just kidding) I'll wrap this up saying that I agree with everything you say in there, but notice that having native code in php apps is a very, very rare thing to come by, and I'm looking forward for jruby to get better as well. Not groovy though :)
    Cheers!
  32. The above is not a common scenario with PHP though. I've yet to see an open source PHP project that employs bits in native code speciffic to that application, and I've seen a lot of them. What I'm saying here is this is not the norm, quite the exception.

    But, you see (and this explains my strong feelings about this issue), I have seen this sort of thing happen often enough with sluggish languages in general, and I have had enough personal experiences of this, that even though it is the exception, you hit that exception often enough that it is a real nuisance. I believe that you can really start to lose the supposed coding speed advantages of some of these languages if you have to support and maintainlibraries in C or C++.
    This could also happen to Java as well.

    Absolutely - it even happens with C++! My point is that as languages get higher performance, this happens far, far less. For me, Java is now fast enough that I am confident that I won't need to drop out to C or C++ for almost anything - especially not in an area of particular interest to me - numerical work.
    I'll wrap this up saying that I agree with everything you say in there, but notice that having native code in php apps is a very, very rare thing to come by,

    Not so rare - this PHP app I mentioned was a well known one!
    and I'm looking forward for jruby to get better as well. Not groovy though :)Cheers!

    I think that when JRuby eventually compiles to class files, it will be a new 'killer' language for the VM, and Groovy (which seems to me to be an ugly mix of BeanShell and Ruby) will get sidelined.
  33. I think that when JRuby eventually compiles to class files, it will be a new 'killer' language for the VM, and Groovy (which seems to me to be an ugly mix of BeanShell and Ruby) will get sidelined.

    Completely agree on both accounts!
  34. You maybe right about Groovy being sidelined, too early to say , but I personally disagree that Groovy is ugly.

    To me it seems to be a cross between Java and Python, and I found its syntax a very easy learning curve coming from Java.
     
    Of all the languages I've ever seen (can't comment on Ruby I'm afraid), I've found Java the easiest on the eye, and for me Groovy is a more concise version of Java - it's how I wish the syntax of Java could be.
  35. You maybe right about Groovy being sidelined, too early to say , but I personally disagree that Groovy is ugly.To me it seems to be a cross between Java and Python, and I found its syntax a very easy learning curve coming from Java.&nbsp;Of all the languages I've ever seen (can't comment on Ruby I'm afraid), I've found Java the easiest on the eye, and for me Groovy is a more concise version of Java - it's how I wish the syntax of Java could be.

    Groovy tries to do far too much in my opinion.... and in doing so it looks to me like it is a series of kludges - the way that 'def' has to be used (sometimes!), and the weird closure syntax, for example.

    I would definitely have preferred something simpler like a hypothetical 'BeanShell++', (perhaps with closures, but definitely with operator overloading).

    I can really recommend looking at Ruby; it took some time for me to get to like it, but if you want to use a dynamic language, it is (in my view) far more consistent and elegant than Groovy. Much of the current interest in Ruby is because of RoR (which, I admit, I am not a fan of), but the language deserves a wider appeal amongst users of dynamic languages.
  36. [...] a hypothetical 'BeanShell++', (perhaps with closures, but definitely with operator overloading)
    Blasphemy! ;)
    I can really recommend looking at Ruby; it took some time for me to get to like it, but if you want to use a dynamic language, it is (in my view) far more consistent and elegant than Groovy. Much of the current interest in Ruby is because of RoR (which, I admit, I am not a fan of), but the language deserves a wider appeal amongst users of dynamic languages.
    This sums up perfectly my views on the subject as well.
  37. [...] a hypothetical 'BeanShell++', (perhaps with closures, but definitely with operator overloading)
    Blasphemy! ;)

    Perhaps! But one of the few situations where I am strongly in favour of the use of a dynamic language is for customisable business logic such as the production of information for reports. I think this sort of code needs to be clear and potentially readable by non-developers. I want to be able to use normal math operators to add BigDecimals, for example.

    [If there is one thing I would add to Java 7, it would be to allow the use of math operators with java.lang.Number subclasses, to make Java into a sensible language for expressing financial calculations]
  38. [...] a hypothetical 'BeanShell++', (perhaps with closures, but definitely with operator overloading)
    Blasphemy! ;)
    Perhaps! But one of the few situations where I am strongly in favour of the use of a dynamic language is for customisable business logic such as the production of information for reports. I think this sort of code needs to be clear and potentially readable by non-developers. I want to be able to use normal math operators to add BigDecimals, for example.[If there is one thing I would add to Java 7, it would be to allow the use of math operators with java.lang.Number subclasses, to make Java into a sensible language for expressing financial calculations]

    I'll definitely give Ruby a look...

    When you talk about java.lang.Number operator support, would this do? (output from the groovyConsole):

    groovy> def num1 = new java.lang.Integer(123)
    groovy> def num2 = new java.lang.Integer(456)
    groovy> println num1 + num2

    579
    groovy> def num1 = new java.math.BigDecimal(123)
    groovy> def num2 = new java.math.BigDecimal(456)
    groovy> println num1 + num2

    579

    I completely agree with you about scripting languages being useful for non-technical people writing small pieces of logic, the best I've seen for this yet is Drools 3's support for Domain Specific Languages when writing rules.
  39. I'll definitely give Ruby a look...When you talk about java.lang.Number operator support, would this do? (output from the groovyConsole)

    def num1 = new java.lang.Integer(123)
    def num2 = new java.lang.Integer(456)
    println num1 + num2

    It isn't perfect. I would rather have everything automatically an object, as with Ruby or Smalltalk.
  40. [...] a hypothetical 'BeanShell++', (perhaps with closures, but definitely with operator overloading)
    Blasphemy! ;)
    Perhaps! But one of the few situations where I am strongly in favour of the use of a dynamic language is for customisable business logic such as the production of information for reports. I think this sort of code needs to be clear and potentially readable by non-developers. I want to be able to use normal math operators to add BigDecimals, for example.[If there is one thing I would add to Java 7, it would be to allow the use of math operators with java.lang.Number subclasses, to make Java into a sensible language for expressing financial calculations]

    That was a wink there! I'm a C++ fanboy and if I had my way I'd never code in Java again, _ever_. Speaking of operator overloading, have you seen the Boost/Spirit parser? If not check it out and get ready to be blown away by pure black magick.
  41. That was a wink there!

    I know :)
    I'm a C++ fanboy and if I had my way I'd never code in Java again, _ever_.

    Maybe I just don't have the intelligence for C++ - I have too often just got confused beyond tolerance by what is happening even with 'a = b' in some situations! I get to the stage where I am wondering why I need to know so much to get things working!
    Speaking of operator overloading, have you seen the Boost/Spirit parser? If not check it out and get ready to be blown away by pure black magick.

    I will take a look; however, just the first sentence on its website (the bit after 'Welcome to Spirit') leaves me feeling intellectually intimidated :)
  42. The above is not a common scenario with PHP though. I've yet to see an open source PHP project that employs bits in native code speciffic to that application, and I've seen a lot of them. What I'm saying here is this is not the norm, quite the exception.
    But, you see (and this explains my strong feelings about this issue), I have seen this sort of thing happen often enough with sluggish languages in general, and I have had enough personal experiences of this, that even though it is the exception, you hit that exception often enough that it is a real nuisance. I believe that you can really start to lose the supposed coding speed advantages of some of these languages if you have to support and maintainlibraries in C or C++.
    This could also happen to Java as well.
    Absolutely - it even happens with C++! My point is that as languages get higher performance, this happens far, far less. For me, Java is now fast enough that I am confident that I won't need to drop out to C or C++ for almost anything - especially not in an area of particular interest to me - numerical work.

    Hi Steve,

    I've seen you use this argument about performance before, and I must admit I just do not understand it. For frameworks like RoR the target domain is web based CRUD applications, where the complexity of numeric operations seldom exceeds calculating someones age from their date of birth :^).

    Whether a technology is performant depends on the application surely. For example if I was writing a chess application in Java, then my application would struggle to beat an application written in C/C++ on similar hardware. In this scenario Java may be considered "non-performant".

    As a student I was allways told that technology selection should occur following an analysis of the problem domain and not before. Horses for courses.

    With the speed of modern hardware; the number of problem domains where dynamic languages can be considered performant and applicable is growing. I would argue that the standard web CRUD application falls well within the remit of most native dynamic languages.
    I'll wrap this up saying that I agree with everything you say in there, but notice that having native code in php apps is a very, very rare thing to come by,
    Not so rare - this PHP app I mentioned was a well known one!
    and I'm looking forward for jruby to get better as well. Not groovy though :)Cheers!
    I think that when JRuby eventually compiles to class files, it will be a new 'killer' language for the VM, and Groovy (which seems to me to be an ugly mix of BeanShell and Ruby) will get sidelined.

    I mentioned native dynamic languages above. I've read in several places that the JVM implementation is closely tied to the Java language. This means getting the JVM to run a dynamic language, supporting all the native features of a language like Ruby and still being backward compatible with Java is extremely difficult and will neccesarily lead to poor performance for the dynamic language.

    So I'm not holding my breath waiting for JRuby or any JVM based dynamic language. If performance is truly important as you claim then the only viable option is to use is a native VM (aparently the CLR suffers from the same limitation too).

    Paul.
  43. Hi Steve,I've seen you use this argument about performance before, and I must admit I just do not understand it. For frameworks like RoR the target domain is web based CRUD applications, where the complexity of numeric operations seldom exceeds calculating someones age from their date of birth :^).

    The key word here is 'seldom'. I'll give a real-world example (without mentioning names). A dynamic-language based website gradually got extended and more features added. One of those features was a calculation of product availability, which involved a complex calculation which depending analysing a large list of requirements and conditions. It worked well while the product range was small, but as the product range expanded the website started to slow down. Eventually, after a product promotion, the website was taking up so much processor power it could not cope and (because it was hosted on a shared server) had to be shut down.

    The problem was resolved simply - by recoding the same algorithms in Java. The huge performance boost meant that the calculation could continue to be performed, even with much higher traffic.

    The moral of this story is that 'seldom' can turn up more often than you expect.
    Whether a technology is performant depends on the application surely. For example if I was writing a chess application in Java, then my application would struggle to beat an application written in C/C++ on similar hardware.

    Perhaps, but it is likely to be within a few percent, which means little disadvantage to using Java.
    Horses for courses.With the speed of modern hardware; the number of problem domains where dynamic languages can be considered performant and applicable is growing.

    And I disagree, as the processing requirements of modern applications increases at the same time. (As in my above real-life example).
    I would argue that the standard web CRUD application falls well within the remit of most native dynamic languages.

    It may do, but in my view it is a gamble that it will. If you lose that gamble, you have a messy situation. I have lost that gamble before.
    I mentioned native dynamic languages above. I've read in several places that the JVM implementation is closely tied to the Java language. This means getting the JVM to run a dynamic language, supporting all the native features of a language like Ruby and still being backward compatible with Java is extremely difficult and will neccesarily lead to poor performance for the dynamic language.

    Well, JRuby seems to be making a lot of progress, and in fact there may be many features that run a lot better that in current implementations of Ruby, such as threading.
    So I'm not holding my breath waiting for JRuby or any JVM based dynamic language. If performance is truly important as you claim then the only viable option is to use is a native VM (aparently the CLR suffers from the same limitation too).Paul.

    Perhaps, but I am only intending to use dynamic languages for very limited situations - I rely on Java for performance. Personally, I am not holding my breath for native VMs - they seem to have been in very early beta for a very long time.
  44. Hi Steve,I've seen you use this argument about performance before, and I must admit I just do not understand it. For frameworks like RoR the target domain is web based CRUD applications, where the complexity of numeric operations seldom exceeds calculating someones age from their date of birth :^).
    The key word here is 'seldom'. I'll give a real-world example (without mentioning names).

    Hi Steve,

    I understand what you say, but I can't see how you can make such a blanket decision across a broad range of application domains. It sounds like the same argument used against Java by C++ programmers back in the late nineties.

    I still believe that developers need to make language choices on a per project basis. None of us can read the future, and trying to future proof applications for unforseen (performance) requirements is a bad idea IMO. In my experience such an approach normally leads to over engineered solutions that cost today in preparation for a future that may never materialise. My view is to build the simplest (cheapest)thing that can possibly work today.
    Perhaps, but I am only intending to use dynamic languages for very limited situations - I rely on Java for performance. Personally, I am not holding my breath for native VMs - they seem to have been in very early beta for a very long time.

    Native VMs in early Beta? What do you mean? I have found the Ruby VM to be very stable. I think the same can be said for Python and as you know Smalltalk VMs have been around a very long time.

    Mixing Dynamic and static languages in the same application is an interesting approach. As well as for "user defined" business logic (as you describe), people are experimenting with using dynamic languages to script together Java components. Both Spring and Picocontainer allow for this.

    Paul.
  45. Hi Steve,I understand what you say, but I can't see how you can make such a blanket decision across a broad range of application domains.

    Because Java is a great general-purpose language and can be used over such a broad range. This is great for productivity, as it leads to 'transferrable skills' that can be used for all sorts of development projects.
    It sounds like the same argument used against Java by C++ programmers back in the late nineties.

    And to a large extent, I think they were right. Java took a long time to come up to a reasonable standard in terms of performance. I remember looking at the earliest Swing applications and thinking it was some kind of joke because it was so slow.
    I still believe that developers need to make language choices on a per project basis.

    And I believe that is a very poor way of working, as it means that there is a lack of code and expertise re-use. I have seen such approaches lead to a constant 're-inventing of the wheel' in different languages.
    None of us can read the future, and trying to future proof applications for unforseen (performance) requirements is a bad idea IMO.

    How can it possibly be, when all you need to do in principle is to use the right language and libraries? Development with Java is not hard, honestly!
    In my experience such an approach normally leads to over engineered solutions that cost today in preparation for a future that may never materialise.

    Depends what you mean by over-engineered. For example, some developers might consider using an ORM to be over-engineering. On the contrary, I find it leads to simpler and faster development.
    My view is to build the simplest (cheapest)thing that can possibly work today.

    And my view is that good development is providing your client with a product that has some degree of robustness and future-proofing.
    Native VMs in early Beta? What do you mean? I have found the Ruby VM to be very stable. I think the same can be said for Python

    Sorry, but VMs stuck at version 0.x (like YARV) are not something I intend to use for serious applications. You may want to risk the use of such products; I don't.
    Smalltalk VMs have been around a very long time.

    Yes, but we were taking about performance, remember?
  46. My view is to build the simplest (cheapest)thing that can possibly work today.
    And my view is that good development is providing your client with a product that has some degree of robustness and future-proofing.


    OK. Now I understand. You want to future proof your apps. This is why we have such differing views. There is a school of thought that sees this as a very bad idea (see XP Explained by Kent Beck). I tend to agree
    Sorry, but VMs stuck at version 0.x (like YARV) are not something I intend to use for serious applications...Who mentioned YARV? I thought we where discussing Ruby versus JRuby.

    Paul.
  47. My view is to build the simplest (cheapest)thing that can possibly work today.
    And my view is that good development is providing your client with a product that has some degree of robustness and future-proofing.
    OK. Now I understand. You want to future proof your apps. This is why we have such differing views. There is a school of thought that sees this as a very bad idea (see XP Explained by Kent Beck). I tend to agree
    /blockquote>
    No. He wants some degree of future proofing. While we cannot see the future, we can see the past. And he, as have I and others, have seen that most applications change, grow and need to be maintained. So why not use something now that is more flexible in the long wrong but might not be as quick (or seem to be) on the front end but is more than good enough.

    There is another school of thought - "Those who don't learn from the past, are doomed to repeat it".
  48. No. He wants some degree of future proofing. While we cannot see the future, we can see the past. And he, as have I and others, have seen that most applications change, grow and need to be maintained. So why not use something now that is more flexible in the long wrong but might not be as quick (or seem to be) on the front end but is more than good enough.There is another school of thought - "Those who don't learn from the past, are doomed to repeat it".

    Yes! This is exactly my view. And, I consider that being able to go to a client and say 'our development language choices and techniques mean that the application will grow with your company and your requirements' is a positive marketing strategy. So far, my clients and employers have definitely not wanted software that is 'just enough to get things working and no more' - they are wiser than that.
  49. btw, I meant "long run" not "long wrong". :0

    Anyway, software development is a "pay now or [more]pay later". Not a "pay now and maybe pay more later".

    But I don't think either of us is advocating over-engineering.
  50. No. He wants some degree of future proofing. While we cannot see the future, we can see the past. And he, as have I and others, have seen that most applications change, grow and need to be maintained. So why not use something now that is more flexible in the long wrong but might not be as quick (or seem to be) on the front end but is more than good enough.There is another school of thought - "Those who don't learn from the past, are doomed to repeat it".
    Yes! This is exactly my view. And, I consider that being able to go to a client and say 'our development language choices and techniques mean that the application will grow with your company and your requirements' is a positive marketing strategy. So far, my clients and employers have definitely not wanted software that is 'just enough to get things working and no more' - they are wiser than that.

    I agree. Doing the simplest thing is good at the design level but not at the architectural level. I would never pick the technology I choose just based on simplicity. XP has some good ideas at the design level but you still need to have a decent architecture. From what I know, this is one of the main complain against XP.
  51. OK. Now I understand. You want to future proof your apps. This is why we have such differing views. There is a school of thought that sees this as a very bad idea (see XP Explained by Kent Beck). I tend to agree

    Yes, and I disagree with that school of thought. I know of that particular guideline of XP, and I think it is mistaken. The reason is that I have personal experience of the costs and problems that can result if you follow it.

    Like any technique, building future capacity into your apps can definitely be over-used, but that is no reason to abandon it altogether.
    Sorry, but VMs stuck at version 0.x (like YARV) are not something I intend to use for serious applications...
    Who mentioned YARV? I thought we where discussing Ruby versus JRuby. Paul.
    Ruby as it is now is not really a virtual machine (at least as I understand it) - it is an interpreter. I'm assuming a VM emulates some sort of machine code, and the language is translated to that machine code, before JIT compilation or translation to native code. That is what I consider a VM to be, so that is why I assumed you were discussing YARV, Parrot etc.
  52. None of us can read the future, and trying to future proof applications for unforseen (performance) requirements is a bad idea IMO.
    How can it possibly be, when all you need to do in principle is to use the right language and libraries? Development with Java is not hard, honestly!

    Wow. I didn't realize just how easy future proofing was!

    Is there ever a situation where the right language is anything but Java?
  53. None of us can read the future, and trying to future proof applications for unforseen (performance) requirements is a bad idea IMO.
    How can it possibly be, when all you need to do in principle is to use the right language and libraries? Development with Java is not hard, honestly!
    Wow. I didn't realize just how easy future proofing was!Is there ever a situation where the right language is anything but Java?

    What I meant was that you can gain an automatic performance improvement simply by coding in Java as against, say, Ruby. I don't know about you, but having a language with implementations from multiple vendors helps future-proofing as well, in my experience.

    Of course there are situations where Java is not right. Python is my preferred language for writing small scripts. Its rich OS interface libraries are superb.
  54. The problem was resolved simply - by recoding the same algorithms in Java.

    Did they recode the entire app in Java? Or just the performance sensitive part?
  55. The problem was resolved simply - by recoding the same algorithms in Java.
    Did they recode the entire app in Java? Or just the performance sensitive part?

    All of it. Maintaining large applications with significant proportions of mixed languages can be messy. Using Java also allowed the migration of the app from a single-vendor solution.
  56. Sorry for all the separate posts. But:
    Whether a technology is performant depends on the application surely. For example if I was writing a chess application in Java, then my application would struggle to beat an application written in C/C++ on similar hardware.
    Perhaps, but it is likely to be within a few percent, which means little disadvantage to using Java.

    Horses for courses.With the speed of modern hardware; the number of problem domains where dynamic languages can be considered performant and applicable is growing.
    And I disagree, as the processing requirements of modern applications increases at the same time. (As in my above real-life example).

    Sorry, but you can't have it both ways here. If the processing requirements are increasing so much that we always have to squeeze the most performance out, then we should be using C. Or, conversely, if you allow yourself to make a judgement call that for your class of apps, Java is fast enough most of the time, then there can likewise also be classes of apps where a dynamic language is fast enough most of the time. There's always a balance to be struck between performance and productivity.

    For example you mention poor Swing performance. On the Macintosh at least this was solved not by improvements to the VM, but by having the the Mac Swing implementations make native calls. Is that a knock against Java? Did Sun make a mistake by not 'future proofing' their original all Java implementation? Is only Sun allowed to use JNI? Does every use of JNI invalidate using Java?

    Or, do you code in the language that is most productive and fast-enough for the vast majority of your use cases, and reach out to a faster language for the hard bits, like Sun does?
  57. Sorry, but you can't have it both ways here. If the processing requirements are increasing so much that we always have to squeeze the most performance out, then we should be using C.

    But that is the advantage of Java these days - you can have it both ways - ease of development and performance. The number of situations where C/C++ is needed is declining.
    Or, conversely, if you allow yourself to make a judgement call that for your class of apps, Java is fast enough most of the time, then there can likewise also be classes of apps where a dynamic language is fast enough most of the time. There's always a balance to be struck between performance and productivity.

    But this is where I have significant disagreement with some proponents of dynamic languages - I contest the assertion that there is a significant productivity benefit, especially for substantial applications. As I often state, the debate about whether dynamic languages are really more productive has been going on for decades, with no winner.

    Personally, I find Java with Eclipse or NetBeans to be far, far more productive that Ruby or Python.
    For example you mention poor Swing performance. On the Macintosh at least this was solved not by improvements to the VM, but by having the the Mac Swing implementations make native calls. Is that a knock against Java?

    No - native calls can make use of specialised hardware - and even C software uses that.
    Did Sun make a mistake by not 'future proofing' their original all Java implementation? Is only Sun allowed to use JNI? Does every use of JNI invalidate using Java?Or, do you code in the language that is most productive and fast-enough for the vast majority of your use cases, and reach out to a faster language for the hard bits, like Sun does?

    No, I don't. Because Sun has reached out for the hard bits I don't have to! They have done the work for me. Java is fast enough.

    I am not saying Java is perfect, or fast enough for everything. Of course it isn't. But there is a sliding scale. With Java I know that it is fast enough for virtually everything I will do - from small web apps to high-performance distributed numerical work (something I hope I can get back to sometime!). It is a fine replacement for C++. This is simply not true for, say, Ruby or Python.
  58. Hi Steve,

    I'm very suspicious of any "one solution fits all" approach. Let me give an anectdotal example. Recently we had a request for a defect tracking system for our assets. Faults on the assets needed to be logged and remedial action tracked.

    The immediate assumption was to use Java with a web front end. Budget was allocated and an elaborate plan put in place. A bit of lateral thinking by a colleague of mine spotted that Bugzilla met all the requirements needed. In his spare time over a couple of weeks he used the bugzilla customization "language" to develop the app, meeting all the requirements. Within weeks the app was out there delivering real business value in a fraction of the time and costs envisaged by the original plan.

    The example you give IMO could be the same. The PHP solution may have been timely and cheap, delivering real business value in a short time. At a later stage a more performant solution may have been needed, but I'm sure that the original PHP solution had more than paid for itself by then.

    Unix people have been using this approach for years. First a quick an dirty solution using say a shell script. This may be good enough and never get replaced, but if needs must a more complex and expensive "C" solution is always possible in the future.

    There is a business imperative behind this approach. In the final analysis the business should at least be consulted on these decisions, rather than assuming that Java is always best. Most businesses cannot predict next week never mine a year down the road, hence the agile tennent of designing for today.

    Paul.
  59. Hi Steve,I'm very suspicious of any "one solution fits all" approach. Let me give an anectdotal example. Recently we had a request for a defect tracking system for our assets. Faults on the assets needed to be logged and remedial action tracked.The immediate assumption was to use Java with a web front end. Budget was allocated and an elaborate plan put in place. A bit of lateral thinking by a colleague of mine spotted that Bugzilla met all the requirements needed. In his spare time over a couple of weeks he used the bugzilla customization "language" to develop the app, meeting all the requirements. Within weeks the app was out there delivering real business value in a fraction of the time and costs envisaged by the original plan.The example you give IMO could be the same. The PHP solution may have been timely and cheap, delivering real business value in a short time. At a later stage a more performant solution may have been needed, but I'm sure that the original PHP solution had more than paid for itself by then.Unix people have been using this approach for years. First a quick an dirty solution using say a shell script. This may be good enough and never get replaced, but if needs must a more complex and expensive "C" solution is always possible in the future.There is a business imperative behind this approach. In the final analysis the business should at least be consulted on these decisions, rather than assuming that Java is always best. Most businesses cannot predict next week never mine a year down the road, hence the agile tennent of designing for today.Paul.

    You talk about two different things. Supporting an existing software is something I would be comfortable with but I would never support more then 1 or 2 development platforms. Application development costs are small compared to expertises and maintenances cost. Of course, consultants usually don't care about those costs. When they talk about productiviy, they talk about development productivity but in the long run it's not necessarily the cheapest choice. As I said earlier, XP mantra is not applicable at the architectural level since the costs of a mistake there are way bigger. Just think of the headaches having to maintain a ruby,php and java-enabled application server. You triple the expertise needed.

    For instance, where I work we have systems running on various DB : Oracle 9i and 10g, Sysbase, Access (beurk). We are trying to only support Oracle by next year so we can focus on our current development environment.
  60. Triple Expertise[ Go to top ]

    Just think of the headaches having to maintain a ruby,php and java-enabled application server. You triple the expertise needed.

    Any developer worth his salt shouldn't have any problem flipping between programming languages at will, and learning new ones at a drop-of-a-hat.

    That's not saying that it's a good idea to cobble together an application with a pile of random languages. But I think the need to standardize on a single language is driven more by lack of skilled and/or motivated people than by the complexity associated with it.
  61. Triple Expertise[ Go to top ]

    Just think of the headaches having to maintain a ruby,php and java-enabled application server. You triple the expertise needed.
    Any developer worth his salt shouldn't have any problem flipping between programming languages at will, and learning new ones at a drop-of-a-hat.That's not saying that it's a good idea to cobble together an application with a pile of random languages. But I think the need to standardize on a single language is driven more by lack of skilled and/or motivated people than by the complexity associated with it.

    I agree that a decent developer should be able to learn new languages and techniques quickly, but I also think that a decent developer should also build up a library of re-usable code, templates and techniques. In order to do this, it is inevitably preferable to focus on one language.
  62. Triple Expertise[ Go to top ]

    I agree that a decent developer should be able to learn new languages and techniques quickly, but I also think that a decent developer should also build up a library of re-usable code, templates and techniques. In order to do this, it is inevitably preferable to focus on one language.

    No, no, no!

    Programming in only one language leads to closed mindedness. That's very bad. There are a lot of paradigms in dynamic languages that can be effectively applied to Java, just not quite as elegantly (but probaby in a much more performant manner).

    A programmer's mental representation of a program should be above the code. Think of it like having a mental compiler. You can think at a level above the code and then mentally translate it into whatever language you are using. Learning (and using) new languages with different styles makes you add new constructs to that meta-language in your head. At first, when you move from one language to another, it may be frustrating because you may have a mental construct that is explicitly represented in one language but not in another. But that doesn't mean it can't be applied effectively, chances are it can, it will just lack the syntactic sugar of the source language.
  63. Triple Expertise[ Go to top ]

    >No, no, no!Programming in only one language leads to closed mindedness. That's very bad. There are a lot of paradigms in dynamic languages that can be effectively applied to Java, just not quite as elegantly (but probaby in a much more performant manner).A programmer's mental representation of a program should be above the code. Think of it like having a mental compiler. You can think at a level above the code and then mentally translate it into whatever language you are using. Learning (and using) new languages with different styles makes you add new constructs to that meta-language in your head. At first, when you move from one language to another, it may be frustrating because you may have a mental construct that is explicitly represented in one language but not in another. But that doesn't mean it can't be applied effectively, chances are it can, it will just lack the syntactic sugar of the source language.

    I agree with you. I did not say that a developer should only ever develop with one language. I chose my words carefully, and said 'focus on one language', which is not the same as using one language exclusively. What I am objecting to is the idea that the language and toolset should be entirely different for each project that a developer approaches; the idea that 'this is a PHP project' or 'this is a VB project' etc. I think it is far better for a developer to build up a library of techniques, templates and classes that can be re-used. That library may well include some degree of mixed language use. For example, I am currently working primarily in Java, but with the odd bit of JRuby, for things like expressing financial logic in an elegant manner. (However, I am against significant use of mixed language development as I believe it leads to maintenance problems).
  64. Triple Expertise[ Go to top ]

    I think it is far better for a developer to build up a library of techniques, templates and classes that can be re-used. That library may well include some degree of mixed language use. For example, I am currently working primarily in Java, but with the odd bit of JRuby, for things like expressing financial logic in an elegant manner. (However, I am against significant use of mixed language development as I believe it leads to maintenance problems).

    Steve, you're obviously a smart guy, but now you've totally lost me. First off, what if the majority of your app was financial logic. I'm not saying it is, but there are such apps out there. Would it make sense, at least in that case, to code the app in Ruby?

    Earlier you railed (no pun intended) against using multiple languages in one app. You recited an anecdote about a team rewriting an entire PHPP app in Java, because one algorithm was too slow. You apparently approved of that strategy, to avoid the plague that is multi-language programming. I hope they consulted with the business about that expensive decision. (Now of course I don't know the specifics -- maybe there were other problems with PHP for that app. But my point is having to break out of the main language for one bit is not enough to justify a complete rewrite.)

    Furthermore you've argued multiple times that Java with the right toolsets is just as productive as Ruby or other dynamic languages. So why use JRuby? Apparently you feel it's more productive for those bits of the app. (If it's just personal preference then it's an irresponsible decision.) If it's OK to write an app mostly in Java with bits of Ruby, what's so bad with writing an app mostly in Ruby with bits of Java (or language X) for performance? I'm not saying that it makes sense for your projects, but it might in other environments.

    Finally, if you're really concerned about minimizing the number of languages involved in a project, you should be all over Rails. In a typical Java web app you have to know Java, HTML, XML, JSP, and Javascript. Now I'm not saying that's hard, but it is several languages. With Rails, especially 1.1., it's Ruby everywhere -- Ruby for config, Ruby for the schema (via migrations), Ruby for queries, Ruby for Javascript (RJS). (You still have to know HTML though.)

    My point is not to start a Ruby vs. Java war. There are things in both to like and dislike. Look at Django if you like Python, and models that drive the schema. Whatever. But it just seems like this topic is a really bugaboo for you, and you're contradicting yourself left and right.
  65. Triple Expertise[ Go to top ]

    Steve, you're obviously a smart guy, but now you've totally lost me. First off, what if the majority of your app was financial logic. I'm not saying it is, but there are such apps out there. Would it make sense, at least in that case, to code the app in Ruby?

    No, because I had very specific reasons for using Ruby in certain parts of this app (see below).
    You recited an anecdote about a team rewriting an entire PHPP app in Java, because one algorithm was too slow. You apparently approved of that strategy, to avoid the plague that is multi-language programming.

    No, I never actually mentioned the language it was developed in, and I said that I approved of the strategy primarily in that case because it changed the implementation language from a single-vendor one to one supplied by multiple vendors (Java/JSP).
    I hope they consulted with the business about that expensive decision. (Now of course I don't know the specifics -- maybe there were other problems with PHP for that app. But my point is having to break out of the main language for one bit is not enough to justify a complete rewrite.)

    The decision had already been made to switch to Java for that project some time ago, for a range of reasons, including the ability to give us a wider choice of operating systems on which to host the system, and also to allow it to be integrated into future developments. There were far more reasons than just the performance of one small part of the appliction.
    Furthermore you've argued multiple times that Java with the right toolsets is just as productive as Ruby or other dynamic languages.

    Yes.
    So why use JRuby? Apparently you feel it's more productive for those bits of the app. (If it's just personal preference then it's an irresponsible decision.) If it's OK to write an app mostly in Java with bits of Ruby, what's so bad with writing an app mostly in Ruby with bits of Java (or language X) for performance? I'm not saying that it makes sense for your projects, but it might in other environments.

    No, you are misunderstanding. I am not using JRuby because of the productivity - I have a very specific reason: Expressing small parts of the business logic that may need to be viewed and changed by people who have experience of dynamic languages and scripting, and who don't want or need to know how to rebuild entire Java applications.

    These people would, I am sure, far rather see something like a tax calculation expressed in JRuby, than in Java where things would look something like the following horror:

    BigDecimal rate = new BigDecimal("17.5");
    BigDecimal result = amount.multiply(rate);

    This also means that they can alter the calculation just by editing a JRuby script, and not have to rebuild the entire application. (I am not saying the the rebuild would not be fast - just that they don't want or need to know how to do this).
    Finally, if you're really concerned about minimizing the number of languages involved in a project, you should be all over Rails. In a typical Java web app you have to know Java, HTML, XML, JSP, and Javascript. Now I'm not saying that's hard, but it is several languages. With Rails, especially 1.1., it's Ruby everywhere -- Ruby for config, Ruby for the schema (via migrations), Ruby for queries, Ruby for Javascript (RJS). (You still have to know HTML though.)

    And you also need to know SQL. And you need to know JavaScript if you want fancy functionality. Not that different then, is it?
    My point is not to start a Ruby vs. Java war. There are things in both to like and dislike.

    Indeed - I like Ruby a lot; I just don't believe it is generally suitable for my development.
    Look at Django if you like Python, and models that drive the schema. Whatever. But it just seems like this topic is a really bugaboo for you, and you're contradicting yourself left and right.

    No - I think you are misinterpreting what I am saying - perhaps because I have not been sufficiently clear.
  66. Triple Expertise[ Go to top ]

    These people would, I am sure, far rather see something like a tax calculation expressed in JRuby, than in Java where things would look something like the following horror:

    BigDecimal rate = new BigDecimal("17.5");
    BigDecimal result = amount.multiply(rate);

    This also means that they can alter the calculation just by editing a JRuby script, and not have to rebuild the entire application.

    OK, but just be careful with that stuff. Readable syntax, easy readloading, having the ability to respond to change requests quickly -- sounds kind of agile to me. If you're not careful your developers and users might start demanding clear code and quick turn arounds everyone, and then where will you be? Gosh, you'd have to write most of the app in Ruby! Can't have that!

    ;)

    best regards,

    Steve M
  67. Triple Expertise[ Go to top ]

    Doh! Should read

    'quick turn arounds everywhere' (not everyone)
  68. Triple Expertise[ Go to top ]

    These people would, I am sure, far rather see something like a tax calculation expressed in JRuby, than in Java where things would look something like the following horror:BigDecimal rate = new BigDecimal("17.5");BigDecimal result = amount.multiply(rate);This also means that they can alter the calculation just by editing a JRuby script, and not have to rebuild the entire application.
    OK, but just be careful with that stuff. Readable syntax, easy readloading, having the ability to respond to change requests quickly -- sounds kind of agile to me. If you're not careful your developers and users might start demanding clear code and quick turn arounds everyone, and then where will you be? Gosh, you'd have to write most of the app in Ruby! Can't have that!;)best regards,Steve M

    I think you are missing my point again. I did not imply that I did not get ability to respond to changes quickly, and agile development, from Java. The only reason to use JRuby in this circumstance was to get clear code for this particular very small part of the program, and rapid turnaround for changes for someone who does not know Java and does not know my Java IDE.

    I work with other people who do know Java and my IDE (NetBeans) and we both get rapid and responsive development with Java.
  69. Triple Expertise[ Go to top ]

    Just think of the headaches having to maintain a ruby,php and java-enabled application server. You triple the expertise needed.
    Any developer worth his salt shouldn't have any problem flipping between programming languages at will, and learning new ones at a drop-of-a-hat.That's not saying that it's a good idea to cobble together an application with a pile of random languages. But I think the need to standardize on a single language is driven more by lack of skilled and/or motivated people than by the complexity associated with it.

    I wasn't speaking about language but development environment, ie the apps server. I have no problem to use any language as long on as it runs on the JVM because I know it will run on my environment and if I need too, I'll be able to rewrite it in the language I choose.
  70. Hi Steve,I'm very suspicious of any "one solution fits all" approach.

    I am not saying that. I am just strong against the idea of picking and choosing languages for different projects, and it is my belief that there is too much emphasis in IT for 'quick and dirty' (or even 'quick and clean') solutions that have no provision for possible future developments.
    Let me give an anectdotal example. Recently we had a request for a defect tracking system for our assets. Faults on the assets needed to be logged and remedial action tracked.The immediate assumption was to use Java with a web front end. Budget was allocated and an elaborate plan put in place. A bit of lateral thinking by a colleague of mine spotted that Bugzilla met all the requirements needed. In his spare time over a couple of weeks he used the bugzilla customization "language" to develop the app, meeting all the requirements. Within weeks the app was out there delivering real business value in a fraction of the time and costs envisaged by the original plan.The example you give IMO could be the same.

    Re-use is good - in fact, it contradicts the XP practice of developing just for the current projects.
    The PHP solution may have been timely and cheap, delivering real business value in a short time. At a later stage a more performant solution may have been needed, but I'm sure that the original PHP solution had more than paid for itself by then.

    But that is exactly my point! Considerable resources need to be invested in the 'at a later stage'. For some projects, it doesn't matter if they have paid for themselves or not - the process of migrating to a new technology, possibly with new hosting, can be considerable, and can leave clients feeling like they have been cheated by the original developers. Also, I think that these days, a Java developer who can't deliver a timely and cheap solution does not have sufficient knowledge of current Java technologies and tools.
    Unix people have been using this approach for years. First a quick an dirty solution using say a shell script. This may be good enough and never get replaced, but if needs must a more complex and expensive "C" solution is always possible in the future.There is a business imperative behind this approach. In the final analysis the business should at least be consulted on these decisions, rather than assuming that Java is always best.

    As someone with (at the last count) 25 years experience of Unix, I have seen the awful results of such 'quick and dirty' solutions. They can be productive (I do this sort of thing), but should be used lightly and with care, and (most importantly), the appropriate limits of their use should be understood.
    Most businesses cannot predict next week never mine a year down the road, hence the agile tennent of designing for today.Paul.

    The reason for using technologies which are scalable and that don't lack performance is exactly because you can't predict the future. You can design for today knowing that you have built-in capabilities for the future.

    Replace the word 'hence' in the above statement with 'which is why you should not follow' and I will agree with you :)
  71. Hi Steve,

    Two points. I agree with Erik, that the implementation language should be/is often the least difficult obstacle facing the developer. Good developers move across languages all the time (e.g JSP, JavaScript, XML, Java etc just within Java web apps).

    The most important aspect of getting a working solution is in the analysis and design IMO. Having something working quickly allows you to gain real feedback on what adds business value and what doesn't. You also get feedback on what design approaches work and which do not. These hard earned assets are re-usable in any new re-implementation, so re-implementing a solution in a technology better suited to new emerging requirements should take a fraction of the time of the original. Also if no new requirements emerge then you've saved the speculative costs of a more complex and extensible solution in the first place.

    It is an economic argument, that requires judgement on a case by case basis. Without a concrete example it is hard to make a call. My point is that you can't decide ahead of time before exploring the requirements of each particular project.
    Re-use is good - in fact, it contradicts the XP practice of developing just for the current projects.



    BTW. Using a DSL (you could consider the Bugzilla customisation API a DSL) is not anti-agile in anyway. A DSL is a technology (Just like Java or EJB). My point is that you choose the right technology (most productive, simplest, sufficiently performant, etc) to suit your problem.

    Using standard technology dispite the application will lead to over engineered solutions, which is the main criticism of the "standard" J2EE technology stack (JSP, Servlets, EJB's etc) as applied in many instances.

    Paul.
  72. Hi Steve,Two points. I agree with Erik, that the implementation language should be/is often the least difficult obstacle facing the developer. Good developers move across languages all the time (e.g JSP, JavaScript, XML, Java etc just within Java web apps).The most important aspect of getting a working solution is in the analysis and design IMO. Having something working quickly allows you to gain real feedback on what adds business value and what doesn't. You also get feedback on what design approaches work and which do not. These hard earned assets are re-usable in any new re-implementation, so re-implementing a solution in a technology better suited to new emerging requirements should take a fraction of the time of the original. Also if no new requirements emerge then you've saved the speculative costs of a more complex and extensible solution in the first place.It is an economic argument, that requires judgement on a case by case basis. Without a concrete example it is hard to make a call. My point is that you can't decide ahead of time before exploring the requirements of each particular project.
    Re-use is good - in fact, it contradicts the XP practice of developing just for the current projects.
    BTW. Using a DSL (you could consider the Bugzilla customisation API a DSL) is not anti-agile in anyway. A DSL is a technology (Just like Java or EJB). My point is that you choose the right technology (most productive, simplest, sufficiently performant, etc) to suit your problem.Using standard technology dispite the application will lead to over engineered solutions, which is the main criticism of the "standard" J2EE technology stack (JSP, Servlets, EJB's etc) as applied in many instances.Paul.

    Again I think you are confusing what Steve and I are against, correct me if I am wrong Steve. For my part, I am against having to maintain a lot of development environment, ie different type of application servers. Developers always forget about the cost of maintaining the infrastructure. I wouldn't be comfortable to maintain more then one clustered application environment.

    Where I work, I am in the development support team. We have a standardized architecture because developpers are kind of new to Java and so I need to be able to understand applications quickly if a bug arise. But I don't have any problem if they use another language for some tasks as long as it is running on the JVM and well known (Groovy, JRuby, ...). I think it's worth it in a some cases (testing for instance). In my opinion, it's the team choice to evaluate the cost involved and not an organization choice.

    What I need is to know is they'll be able to use any common libraries we have built upon time, run on our application environment and knowing that if I need too I can always translate the code in another language.
  73. The most important aspect of getting a working solution is in the analysis and design IMO. Having something working quickly allows you to gain real feedback on what adds business value and what doesn't. You also get feedback on what design approaches work and which do not.

    I partly agree. I can't see how this is an argument for or against Java, as you can certainly get things working quickly in Java.
    These hard earned assets are re-usable in any new re-implementation

    No, I really don't think that this is true. I may have a design approach in PHP or JSP that is totally innapropriate with use for, say JSF. One of my current projects involves web-based image processing. The technique I use involving Java is simply not going to with with Ruby.
    so re-implementing a solution in a technology better suited to new emerging requirements should take a fraction of the time of the original. Also if no new requirements emerge then you've saved the speculative costs of a more complex and extensible solution in the first place.

    But this is where I really disagree. Solutions involving Java need not be complex.
    It is an economic argument, that requires judgement on a case by case basis. Without a concrete example it is hard to make a call. My point is that you can't decide ahead of time before exploring the requirements of each particular project.

    My point is that is it unwise to assume that the requirements of a project will remain fixed. If they change sufficiently, then your judgment about the development techniques and languages to use could be wrong, and this could be a costly mistake.
    Re-use is good - in fact, it contradicts the XP practice of developing just for the current projects.
    BTW. Using a DSL (you could consider the Bugzilla customisation API a DSL) is not anti-agile in anyway. A DSL is a technology (Just like Java or EJB). My point is that you choose the right technology (most productive, simplest, sufficiently performant, etc) to suit your problem.Using standard technology dispite the application will lead to over engineered solutions, which is the main criticism of the "standard" J2EE technology stack (JSP, Servlets, EJB's etc) as applied in many instances.Paul.

    My point is that Java can be simple and productive and not over engineered. (I certainly don't think it is appropriate to call JSP and Servlets 'over engineered'!)
  74. The most important aspect of getting a working solution is in the analysis and design IMO.

    Yes!!!
    Having something working quickly allows you to gain real feedback on what adds business value and what doesn't. You also get feedback on what design approaches work and which do not.

    Depends on the applicaiton Most of the time all you get is feedback related to user satisfaction. Business value is much harder to measure. In order to deliver value, business practices need to change in order to leverage the application. Often times on initial deployment, actual business process execution gets worse, because people try to cram their old way of doing business into an application that implements a new way of doing it.

    Also, depending on which stakeholders provide feedback, it's very easy for an application to start veering away from where it needs to go to provide true business value. Departments want to maintain their empires. Individuals want to remain the sole-source for doing a particular task. And most of the time, users just want to minimize their day-to-day pain, and the efficiency of the business is a distant second (if even that) in their priorities.

    In other words, I trust users to provide excellent feedback on things like usability, and that's important. But more often than not they can't be trusted to know how an application is supposed to fit into the business outside of their own realm.

    IMHO, that's one of the biggest weaknesses of agile development. It makes it too easy for the ship to veer off course due to individual interests.
  75. blockquote>Having something working quickly allows you to gain real feedback on what adds business value and what doesn't. You also get feedback on what design approaches work and which do not.
    Depends on the applicaiton Most of the time all you get is feedback related to user satisfaction. Business value is much harder to measure. In order to deliver value, business practices need to change in order to leverage the application. Often times on initial deployment, actual business process execution gets worse, because people try to cram their old way of doing business into an application that implements a new way of doing it.Also, depending on which stakeholders provide feedback, it's very easy for an application to start veering away from where it needs to go to provide true business value. Departments want to maintain their empires. Individuals want to remain the sole-source for doing a particular task. And most of the time, users just want to minimize their day-to-day pain, and the efficiency of the business is a distant second (if even that) in their priorities.In other words, I trust users to provide excellent feedback on things like usability, and that's important. But more often than not they can't be trusted to know how an application is supposed to fit into the business outside of their own realm.IMHO, that's one of the biggest weaknesses of agile development. It makes it too easy for the ship to veer off course due to individual interests.
    I agree, I think this is one opf the biggest weaknesses in software development in general.

    Craig Larman has done studies that show that over 60% of requirements specified upfront by users ard very little if any business value at all. I think this is the strongest argument for small incremental delivery going.

    Rather than asking users to guess what will add value, we deliver what they see as their highest priority needs and allow them to use it. Alistair Cockburn suggests that releases should occur once every 1-3 months. Feedback from real world experiences with release X are feed into determining the requirements for release X + 1.

    That way the user community is in the driving seat and do not need to guess everything they think they'll need upfront. Also if we start off heading in the wrong direction, we can correct in response to real world feedback.

    How do you define business value? This is a tricky one. I personally haven't seen a fool proof way to determine ROI. What I tend to do is create a customer team. This team contains all the major stakeholders (users, customer (buget holder), etc). At the head of this team is the product owner (usually the customer). He/she is responsible for the final say on the content and the order of the product backlog ( a prioritised list of all the requirements envisioned).

    This product backlog is owned by the product owner and he/she can change it at any time. We bucket items on the list into releases and work to implement the backlog from the top down, releasing at regular intervals.

    I'm yet to come across a better way of dealing with this issue - after all it is up to the business to decide exactly what it is they want. Often we include a business analyst on the customer team to help them decide.

    If something you do works for you then I'm more than happy to hear it.

    Cheers,

    Paul.

    BTW. One of my pet hates is software developers that always have an answer. IMO the most powerful phase in software development is "I don't know". How do we know what will add value to a business? We don't. When I hear talk of "software architecture" and big upfront, top-down software solutions, I always think "here we go again, software people trying to tell business people how to run their business". I'm strongly against "architecture" and big upfront design like "SOA". IMO software should be developed bottom up using real end users and gaining real user feedback in an incremental and iterative fashion. IMO architecture should emerge over time from the natural coalescing of real applications that meet reals needs, rather than being imposed upfront and top down by some master architect.

    I could rant forever on this subject, but in short this is why I support small, simple incremental solutions using the simplest and most productive technology available at the time. I leave architecture to discover and evolve itself through customer lead feedback and iterative releases/refactors.

    Paul.
  76. Craig Larman has done studies that show that over 60% of requirements specified upfront by users ard very little if any business value at all. I think this is the strongest argument for small incremental delivery going.

    Sounds about right to me. Can you point me to those studies? I'd like to show them to my boss!
  77. Craig Larman has done studies that show that over 60% of requirements specified upfront by users ard very little if any business value at all. I think this is the strongest argument for small incremental delivery going.
    Sounds about right to me. Can you point me to those studies? I'd like to show them to my boss!

    Hi Stephen,

    I tried to find a reference to the studies on Craig's website:

    http://www.craiglarman.com/

    Couldn't find one. But I'm sure he supplies references to the studies in his book:

    "Agile and Iterative Development, A Manager's Guide".

    The book makes real good reading, it busts a number of the commonly held myths that dominate software development today.

    Paul.
  78. Craig Larman has done studies that show that over 60% of requirements specified upfront by users ard very little if any business value at all. I think this is the strongest argument for small incremental delivery going.
    Sounds about right to me. Can you point me to those studies? I'd like to show them to my boss!
    Hi Stephen,I tried to find a reference to the studies on Craig's website:http://www.craiglarman.com/Couldn't find one. But I'm sure he supplies references to the studies in his book:"Agile and Iterative Development, A Manager's Guide".The book makes real good reading, it busts a number of the commonly held myths that dominate software development today.Paul.

    Indeed a very good book :) I have bought all Craig Larman's books and never been disappointed. He's such a good writer.
  79. IMO software should be developed bottom up using real end users and gaining real user feedback in an incremental and iterative fashion
    ....
     IMO architecture should emerge over time from the natural coalescing of real applications that meet reals needs, rather than being imposed upfront and top down by some master architect.I could rant forever on this subject, but in short this is why I support small, simple incremental solutions using the simplest and most productive technology available at the time. I leave architecture to discover and evolve itself through customer lead feedback and iterative releases/refactors.Paul.

    I tend to agree. It is just that we disagree about which simple and productive technologies to use.

    I use primarily Java, JDO and JSF(+facelets). I get fast development, rapid response to changes, fast development, and easy (and fast!) testing.

    But, I also get database portability and high performance as well, and the customer gets a system that they know they can easily apply future scalability solutions to if they need to (for example, the JDO system can run on database clusters).
  80. blockquote>I tend to agree. It is just that we disagree about which simple and productive technologies to use.I use primarily Java, JDO and JSF(+facelets). I get fast development, rapid response to changes, fast development, and easy (and fast!) testing.But, I also get database portability and high performance as well, and the customer gets a system that they know they can easily apply future scalability solutions to if they need to (for example, the JDO system can run on database clusters).
    Hi Steve,

    I'm suggesting that their could be significantly faster development, significantly more rapid response to changes, aswell as database portability, and sufficient performance using alternatives to Java.

    I understand that the improvement would need to be significant to warrant a a wholesale change.

    I think were we differ is that I am open to exploring alternatives to my current encumbant technology (Java) and you have already concluded that Java does everything you need (well sort off) and you don't need to seriously consider anything else.

    I see the momentum with Ruby building and I believe that Ruby is just a trojan horse for a number of other dynamic languages. Ruby like all new bandwagons will be miss-used and abused, but there will also be well informed people that adopt Ruby and gain significant commercial advantage as a consequence.

    Java has had over ten years to prove itself and amongst its strengths it still has a number of key weaknesses at its core (e.g over complex and brittle component model, no late binding, static class/type/interface coupling between objects, poor meta model and hence poor support for internal DSLs, no closures, no continuations, etc).

    I am willing to accept that these weaknesses present opportunities for alternative languages under the right set of circumstances, you seeminlgly do not. Then again I'm not sure what you are saying, because as Stephen has pointed out some of the points you are making appear contradictory.

    Paul.
  81. blockquote>I tend to agree. It is just that we disagree about which simple and productive technologies to use.I use primarily Java, JDO and JSF(+facelets). I get fast development, rapid response to changes, fast development, and easy (and fast!) testing.But, I also get database portability and high performance as well, and the customer gets a system that they know they can easily apply future scalability solutions to if they need to (for example, the JDO system can run on database clusters).
    Hi Steve,I'm suggesting that their could be significantly faster development, significantly more rapid response to changes, aswell as database portability, and sufficient performance using alternatives to Java.I understand that the improvement would need to be significant to warrant a a wholesale change.I think were we differ is that I am open to exploring alternatives to my current encumbant technology (Java) and you have already concluded that Java does everything you need (well sort off) and you don't need to seriously consider anything else.
    No - I haven't said that. I have already said I am using other languages. Developers should always be considering other languages.
    I see the momentum with Ruby building and I believe that Ruby is just a trojan horse for a number of other dynamic languages. Ruby like all new bandwagons will be miss-used and abused, but there will also be well informed people that adopt Ruby and gain significant commercial advantage as a consequence.Java has had over ten years to prove itself and amongst its strengths it still has a number of key weaknesses at its core (e.g over complex and brittle component model, no late binding, static class/type/interface coupling between objects, poor meta model and hence poor support for internal DSLs, no closures, no continuations, etc).

    I think you need to review how little Ruby is, in fact, used before you call it a trojan horse for other languages. It is a beautiful language, and is much discussed, but it is questionable how much is it actually used.

    Java has certainly proved itself - which is why it is the most popular development language, and is still growing in use. How much more does it need to prove itself?

    Java is certainly a limited language in many respects, but many of the things you consider weaknesses are either wrong or considered strengths by others. You can't say that there is an overly complex and brittle component model unless you specify which of the many component models present in Java you mean. Some of us consider static coupling to be a major advantage, speeding development.
    I am willing to accept that these weaknesses present opportunities for alternative languages under the right set of circumstances, you seeminlgly do not.

    Sorry, but this isn't the case. I am willing to accept any alternative language that has the strengths of Java as my general-purpose language. I have been through these before, but to review, they are multi-vendor support, low cost, high performance and high cross-platform portability. These are my criteria for a general purpose language. I have already discussed in this thread that I use alternative languages under different circumstances - JRuby for some business logic; python for system scripting.
    Then again I'm not sure what you are saying, because as Stephen has pointed out some of the points you are making appear contradictory.Paul.

    Sorry, but no - I have apparently cleared up what was thought to be contradictory in subsequent posts, and there has been no comeback from those posts, so I don't accept that I am saying contradictory things. If you think I am, say why yourself - you can't rely on posts by others to which I have already responded.

    To avoid going over old ground, surely things can be summed up like this: I think Java is a very fast language for development with the right APIs and tools; you don't, mainly because you had a bad experience with EJB 2.x; and from that, you are extrapolating to the rest of Java. I think static typing is a major benefit in testing and building robust programs; you don't - you think that XP development is a satisfactory substitute. I think that using Java gives a developer a built-in advantage in terms of potential future performance and maintainability of applications; you think you don't need to bother with these things - just put something together in Ruby that is enough to keep the customer happy, and let them worry about performance issues if or when they happen. I think that keeping one language for general purpose development is a good idea because it allows developer to build up resources and skills and libraries for future use. You think you should stick to the XP principle that future use of code is inappropriate.

    A fair summary?
  82. Hi Steve,

    Thanks for clearing things up. I think I understand your point of view much better now.

    BTW the component model I was refering to was EJB.

    Cheers,

    Paul.
  83. Hi Steve, Thanks for clearing things up. I think I understand your point of view much better now.BTW the component model I was refering to was EJB.Cheers,Paul.

    I know :) It is a shame that Java has been tarnished by EJB for so many people.
  84. You think you should stick to the XP principle that future use of code is inappropriate.A fair summary?
    You got me mostly right. As I understand it XP says design for today refactor for tomorrow. This works if your code today is clean and of high quality, lending itself to easy refactoring.

    As for the re-use of code in the future. All the agile practices I know of make a distinction between application code and re-usable librairies and API's.

    The idea is that you mine re-usable code from stable application code. So App A and App B contain common functionality. When both apps are stable, then the teams are in a position to share code. Both apps are refactored to use a common interface to the common code and then one of the implementations is shared.

    The advantage of this approach is that you only attempt to share stable code, and the design of your API is allowed to emerge through shared requirements and refactors. Once you are sharing the code it means that the overall code base is less hence easier maintenance, but the downside is that there is now a dependency between the shared library and both apps. So if you need to change the libray for App A, it also means that you need to re-test app B. This is why I say that redundnacy is not necessarily a bad thing.

    BTW if you have just used an API in a single app then it is not a re-usable API (by definition). The chances are that when you try to use the same API in a third App it will require changes yet again (less changes this time though), and potentially changes to the dependent applications A and B or re-testing at least.

    Re-use across applications has implications.

    Paul.
  85. You think you should stick to the XP principle that future use of code is inappropriate.A fair summary?
    You got me mostly right. As I understand it XP says design for today refactor for tomorrow. This works if your code today is clean and of high quality, lending itself to easy refactoring.As for the re-use of code in the future. All the agile practices I know of make a distinction between application code and re-usable librairies and API's.The idea is that you mine re-usable code from stable application code. So App A and App B contain common functionality. When both apps are stable, then the teams are in a position to share code. Both apps are refactored to use a common interface to the common code and then one of the implementations is shared.The advantage of this approach is that you only attempt to share stable code, and the design of your API is allowed to emerge through shared requirements and refactors. Once you are sharing the code it means that the overall code base is less hence easier maintenance, but the downside is that there is now a dependency between the shared library and both apps. So if you need to change the libray for App A, it also means that you need to re-test app B. This is why I say that redundnacy is not necessarily a bad thing.BTW if you have just used an API in a single app then it is not a re-usable API (by definition). The chances are that when you try to use the same API in a third App it will require changes yet again (less changes this time though), and potentially changes to the dependent applications A and B or re-testing at least.Re-use across applications has implications.Paul.

    An interesting post. When I am developing, I often get the guilty feeling that I should be doing things in a far more XP manner......
  86. Bambi versus Godzilla[ Go to top ]

    Hi Steve,

    Came across this blog entry and thought you and others would find it very interesting:

    http://www.cabochon.com/~stevey/blog-rants/bambi-meets-godzilla.html

    We've spent a lot of time arguing the technical merits of one language versus the next, but in the end does commercial success have much to do with technical merit?

    Perl as mentioned in the article along with Visual Basic are good examples where technical merit didn't play a big role.

    Ultimately I agree with the article that marketing and culture are significant factors. Which is why I feel that the Ruby community stand a good chance of success where others have failed (e.g. Python, Smalltalk and of course the grand daddy of them all LISP).

    There are at least 4 new Ruby books in the pipeline this year and more scheduled. The pragmatic programmers are doing a very good job at marketing Ruby. All it needs now is for a commercial vendor to realise that bringing Smalltalk like tooling to Ruby could mean instant commercial success (much like IBM did when creating VisualAge/Eclipse for Java) and who knows where Ruby could be in a couple of years time.

    BTW there may be something in your point of hosting Ruby on the JVM (an instant ubiquitous market if nothing else). But technically isn't this approach bound to be very slow? My view is that once people have tasted JRuby/Ruby they won't think twice about ditching the JVM if they can find the appropriate tooling, libraries and frameworks in native Ruby.

    Paul.
  87. Bambi versus Godzilla[ Go to top ]

    There are at least 4 new Ruby books in the pipeline this year and more scheduled. The pragmatic programmers are doing a very good job at marketing Ruby.

    I'm not so sure. Have a look at the TIOBE index. Ruby barely registers.
    All it needs now is for a commercial vendor to realise that bringing Smalltalk like tooling to Ruby could mean instant commercial success

    No, it needs a lot more than that. After all, Smalltalk had Smalltalk tooling, and that did not help! As discussed in other threads, the way Ruby works means that many of the Smalltalk-type tools just won't work with the language.

    In my view, the Ruby language needs more features in order to be taken seriously as a full-strength commercial language. Internationalisation for example.
    BTW there may be something in your point of hosting Ruby on the JVM (an instant ubiquitous market if nothing else). But technically isn't this approach bound to be very slow?

    Why?
    My view is that once people have tasted JRuby/Ruby they won't think twice about ditching the JVM if they can find the appropriate tooling, libraries and frameworks in native Ruby.Paul.

    Sorry, but I think that is a very mistaken point of view. Integration with Java is a huge selling point, as it allows the use of very powerful products. For example, I am currently using JDO 2.0 from some small JRuby scripts. I get the ability to script in a dynamic language while using a very high-performance ORM.

    I think developers are far more likely to move the other way - to increased use of the JVM and JRE - once a good dynamic language like Ruby is implemented. After all, if they want to get increased performance they can code classes in Java, rather than having to write in C or C++ as with native Ruby. There is an obvious portability advantage.

    Also, how long do you think it is going to take for the richness of Java's tooling, libraries and frameworks to be implemented in native Ruby?
  88. Bambi meets Godzilla[ Go to top ]

    There is an obvious portability advantage.Also, how long do you think it is going to take for the richness of Java's tooling, libraries and frameworks to be implemented in native Ruby?
    Well it took Java at least 6-7 years to reach the richness of Smalltalk's tooling, and yet that didn't stop people adopting it. Who knows how long it will take Ruby.

    BTW:You didn't comment on the non technical issues that effect commercial success as raised in the article.

    Paul.
  89. Bambi meets Godzilla[ Go to top ]

    There is an obvious portability advantage.Also, how long do you think it is going to take for the richness of Java's tooling, libraries and frameworks to be implemented in native Ruby?
    Well it took Java at least 6-7 years to reach the richness of Smalltalk's tooling, and yet that didn't stop people adopting it.

    It stopped me, and (I suspect) plenty of others. Until Java had decent performance and good IDEs I was not going to touch it.
    Who knows how long it will take Ruby.

    If it ever happens.
    BTW:You didn't comment on the non technical issues that effect commercial success as raised in the article.Paul.

    No. I disagree with huge amounts of it, so to comment on it would take a long post.
  90. Well it took Java at least 6-7 years to reach the richness of Smalltalk's tooling, and yet that didn't stop people adopting it.
    It stopped me, and (I suspect) plenty of others. Until Java had decent performance and good IDEs I was not going to touch it.

    So Steve you was a late adopter of Java? What were you using before and why did you move?

    I was an early Java adopter. I knew that it wasn't as advanced and as forward looking as Smalltalk, but just the inclusion of garbage collection would mean a big productivity improvement over C++. Also I knew it would be a relatively easy sell to my company (even then it took me two years to convince them to adopt it).

    BTW: A while ago you asked me to find a quote from Alan Kay with regards to OO and Java. Well I've found a couple:
    I invented the term "Object-Oriented", and I can tell you I did not have C++ in mind. --AlanKay

    and...
    Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS. -- AlanKay

    Beyond the Java world, Croquet as gone to release 1.0. Check it out:

    http://opencroquet.org

    A dynamic component model facilitating replicated objects across a WAN in a shared 3D space with portals to other spaces and no central servers (peer-to-peer). The movie "The Matrix" is here!

    The weaknesses I mentioned in Java (also C#, C++ etc) have been a real obstacle to moving computer science forward IMO. The sad thing is that late binding was delivered in Lisp over 40 years ago and built upon in Smalltalk. What is happening in Croquet today just wouldn't be possible without it (there is currently work in progress to allow you to program Croquet in other dynamic languages other than Smalltalk, like Python, and even JavaScript, sadly Java is just not feasible).

    I'm seriously getting into Croquet - it has simply got to be the Operating System and World Wide Web of the future.
    The best way to predict the future is to invent it. -- Alan Kay

    http://www.iam.unibe.ch/~denker/old/AlanKayQuotes.html

    Paul.
  91. Business Value[ Go to top ]

    Craig Larman has done studies that show that over 60% of requirements specified upfront by users ard very little if any business value at all. I think this is the strongest argument for small incremental delivery going.

    I'll buy that.
    Rather than asking users to guess what will add value, we deliver what they see as their highest priority needs and allow them to use it.

    User perceived value and business value, IMHO, are only weakly correlated. I've yet to meet a user who is happy with SAP, but I've seen plenty of evidence of business value. Of course I've also seen it wreak havoc on productivity.

    In general I'd say user perceived value is necessary buy not sufficient to produce business value.
    That way the user community is in the driving seat and do not need to guess everything they think they'll need upfront. Also if we start off heading in the wrong direction, we can correct in response to real world feedback.

    But in my experience where the user wants to go and where the sponsor (entity with the $$$) and/or champion (executive advocate) wants to go are often at odds.
    At the head of this team is the product owner (usually the customer). He/she is responsible for the final say on the content and the order of the product backlog ( a prioritised list of all the requirements envisioned).

    Ahhh, here's the difficulty. I can certainly see how that would work. In my environment, there's too big of a gap between the user (or the manager of the users and the champion. The user has 12 people under him. The champion has 12,000.
    If something you do works for you then I'm more than happy to hear it.

    Navigating a project with incremental deliveries can be like finding your way through a dark forest, or it can be like finding your way through an obstacle course with a big visible flagpole.

    The flagpole is clear objectives as to how an application is expected to change the business. In lean terminology, you have your current state value stream, and you have your target state value stream. You should also have a plan beyond "build a webapp" as to how to get there. The application is supposed to enable the target state.

    So in the end you have 3-5 slides and maybe 10 pages that are the bible for your project. 80% of it is business-process focused. The other 20% identifies the parts of the process that can benefit from automation.

    I won't launch a project without it. Unfortunately I can't avoid getting added to projects mid-stream.
    How do we know what will add value to a business? We don't. When I hear talk of "software architecture" and big upfront, top-down software solutions, I always think "here we go again, software people trying to tell business people how to run their business". I'm strongly against "architecture" and big upfront design like "SOA".

    I expect the business to be able to tell me how both how it runs and how it expects to run. That expectation is rarely met, at which point I figure out how it is run and propose a way for it to run better. At first people find this at best annoying and at worst offensive. Afterall, they just want a webapp to do X, so why am I asking them how they do business? But in the end they usually appreciate it.

    Now, I'll admit, sometimes I feel like I spend more times squashing ideas than implementing them. If I were a consultant or contractor and I probably wouldn't do that, because I'd make most of my on the implementation, not the response to the RFP.

    As for the technical architecture, I think some upfront design is needed. Things like security, maintainability, and supportability need to be baked in from the start. Integration among enterprise systems also isn't something to be taken lightly. Consequently, I think there needs to be some up-front design ahead of time. I wouldn't call this "big up-front design." More like setting up design guidelines.
  92. Business Value[ Go to top ]

    Rather than asking users to guess what will add value, we deliver what they see as their highest priority needs and allow them to use it.
    User perceived value and business value, IMHO, are only weakly correlated. I've yet to meet a user who is happy with SAP, but I've seen plenty of evidence of business value. Of course I've also seen it wreak havoc on productivity.In general I'd say user perceived value is necessary buy not sufficient to produce business value.
    This is where we get into the soft touchy feely zone where people reside. Try imposing a solution onto users that they don't like. The result - they don't use it, a sure way of achieving zero business value.
    That way the user community is in the driving seat and do not need to guess everything they think they'll need upfront. Also if we start off heading in the wrong direction, we can correct in response to real world feedback.
    But in my experience where the user wants to go and where the sponsor (entity with the $$$) and/or champion (executive advocate) wants to go are often at odds.
    At the head of this team is the product owner (usually the customer). He/she is responsible for the final say on the content and the order of the product backlog ( a prioritised list of all the requirements envisioned).
    Ahhh, here's the difficulty. I can certainly see how that would work. In my environment, there's too big of a gap between the user (or the manager of the users and the champion. The user has 12 people under him. The champion has 12,000.
    If the product owner is at 12,000 feet that points to an organisational problem. How can you be seriously engaged and accountable for buying and/or commisioning software 12,000 feet below you. Sounds like some delegation is call for I think.
    If something you do works for you then I'm more than happy to hear it.
    Navigating a project with incremental deliveries can be like finding your way through a dark forest, or it can be like finding your way through an obstacle course with a big visible flagpole.The flagpole is clear objectives as to how an application is expected to change the business. In lean terminology, you have your current state value stream, and you have your target state value stream. You should also have a plan beyond "build a webapp" as to how to get there. The application is supposed to enable the target state.So in the end you have 3-5 slides and maybe 10 pages that are the bible for your project. 80% of it is business-process focused. The other 20% identifies the parts of the process that can benefit from automation.I won't launch a project without it. Unfortunately I can't avoid getting added to projects mid-stream.

    Alistair Cockburn talks about something similar. He calls it a 360 degree view at the start of a project.
    How do we know what will add value to a business? We don't. When I hear talk of "software architecture" and big upfront, top-down software solutions, I always think "here we go again, software people trying to tell business people how to run their business". I'm strongly against "architecture" and big upfront design like "SOA".
    I expect the business to be able to tell me how both how it runs and how it expects to run. That expectation is rarely met, at which point I figure out how it is run and propose a way for it to run better. At first people find this at best annoying and at worst offensive. Afterall, they just want a webapp to do X, so why am I asking them how they do business? But in the end they usually appreciate it.Now, I'll admit, sometimes I feel like I spend more times squashing ideas than implementing them. If I were a consultant or contractor and I probably wouldn't do that, because I'd make most of my on the implementation, not the response to the RFP.

    A pragmatic way forward, but it is worth remembering that you are not the business, and if you take on the responsibility for defining what's need then it follows that you are also responsible for delivering business value (and the person to blame when business value is not realised). In the final analysis the business must take responsibility for their own destiny. It is their business and their choice to utilise software. Whether they are successful is ultimately their responsibility.
    As for the technical architecture, I think some upfront design is needed. Things like security, maintainability, and supportability need to be baked in from the start. Integration among enterprise systems also isn't something to be taken lightly. Consequently, I think there needs to be some up-front design ahead of time. I wouldn't call this "big up-front design." More like setting up design guidelines.

    Thinking ahead is a good thing, and anticipating what will becoming down the pipe can't be bad. I think my point has more to do with emphasis. Even with things like security, if you really think about it is almost impossible to determine what is needed across an entire organisation, and what users see as security varies on a per application basis (for example non-repudiation, authentication, authorisation, anti-spoofing etc, some or none of the above).

    If you have a design that is loosely coupled and you have application components that are highly cohesive, then retrofiting security or application integration should be relatively easy. The cost of speculatively providing these facilities across the board can be huge.

    Scrum adresses this problem, by having concurrent design. Application teams communicate on a regular basis with each other(once a week). Through this communication they identify common requirements and opportunities for code and technology sharing across applications and teams.

    In the final analysis my experience has shown that redundancy between teams is not necessarily a bad thing. Once applications are stable and working opprotunities for re-use and sharing can be exploited safely through refactoring. Trying to plan it all upfront seldom works IMO. Re-using software that is unstable and is changing constantly is a configuration nightmare.

    Paul.
  93. Business Value[ Go to top ]

    A pragmatic way forward, but it is worth remembering that you are not the business,

    I am not the business, but I am part of it.
    and if you take on the responsibility for defining what's need then it follows that you are also responsible for delivering business value (and the person to blame when business value is not realised).

    Yes.
    In the final analysis the business must take responsibility for their own destiny. It is their business and their choice to utilise software. Whether they are successful is ultimately their responsibility.

    And as I said, I am part of the business. My responsibility is to deliver information systems that deliver maximum value for minimal cost, including operational and support costs, not just initial implementation costs.

    I think failure to take responsibility for the business value delivered by an application and it's lifecycle costs is a cop-out.

    I agree with agile methods for working on the details, but an application's mission should be defined from the onset. Development should be tracked in relative to how close the application comes to achieving it's goals.
  94. Business Value[ Go to top ]

    blockquote>I think failure to take responsibility for the business value delivered by an application and it's lifecycle costs is a cop-out.I agree with agile methods for working on the details, but an application's mission should be defined from the onset. Development should be tracked in relative to how close the application comes to achieving it's goals.Hi Erik,

    I understand your approach and I must admit I've had to take this approach in the past too just to get stuff done.

    A couple of points to think about though:

    1. Wouldn't the end result be much better if your customer/end users got more involved and took on more responsiblity for defining/prioritising requirements? Studies have shown (Alistair Cockburn), that the number one success factor in software projects is end user/customer involvement.

    2. You assume that the goals of a project are fixed or can even be precisely known at the outset. What about the scenario when the goals change half way through, or when the intial goals turn out to be inappropriate and new goals are identified through early releases and early end-user access/experience?

    I'm not knocking what you are doing, I'm just saying that with more collaboration with the customer/end users things could be a whole lot better. The problem though is getting them to commit the time to work with you right? (I know even with XP this is still a problem).

    Paul.
  95. Customer Collaboration[ Go to top ]

    I'm not knocking what you are doing, I'm just saying that with more collaboration with the customer/end users things could be a whole lot better. The problem though is getting them to commit the time to work with you right? (I know even with XP this is still a problem).

    Two things:
    1. My boss also owns the group that is in charge of process improvement for a significant portion of our overally organization. I'm not part of that group, but it gives me a significant amount of latitude in doing that type of exercise. In other words, I'm probably in a relatively unique position.
    2. You shouldn't confuse what I'm doing with not having the intense involvment of the stakeholders. Concurrently developing a "business process" and an application through exploratory methods leaves too many free variables.
    3. Many of the applications I work on are analytical in nature. It can take a couple months to just work out the math that goes behind the application logic. In these cases there is a *right* and *wrong* answer, and it's not easily validated. Testing can easily take much, much longer than coding.

    From what I've read, agile methods position the working application as the common understanding and communications method between the users and the development team. The users express what they want, the developers implement what they understand that to be, and then they talk about the result and iterate towards a more common understanding.

    Instead, I choose to take it upon myself to thoroughly learn the discipline I'm automating. It's kind of like an actor who is about to play a construction worker going out and working as a construction worker, or following around a cop, or whatever.

    Someone on the team needs a deep understanding of the entire picture. That's my job.
  96. Someone on the team needs a deep understanding of the entire picture. That's my job.

    Understood. Sounds like the programmer who goes off and works with the end-users for a week or two to gain their perspective.

    It sounds like your approach works well for you. I did miss-understand you. Your description of the "standard" agile approach is accurate, and if what you do works better in your enviroment then thats got to be the right thing to do.

    Thanks for sharing it.

    BTW. The good thing about agile is that the team are in control, if any of the standard practices prove not to work for your team (as discovered during your end of iteration retrospectives) then feel free to try something else.

    Paul.
  97. Where are the Ruby programmers going to come from? .NET ...nah. Java? Maybe, but if Java guys see that there is no reason to switch, they won't. It's tough going.

    Amen!
    Welcome to the dustbin RoR!!!
    Wonder going foward say 10 years how much development will shift from Java to Groovy??
    Where java becomes something the 'old farts' use.

    The 'old farts' are already coding in Ruby and RoR :)
    (Bruce,Geary and Fowler)

    Profile for the Future Java Developer
    Cockiness -- Birthright
    GroovyNess -- Being Installed
  98. Where are the Ruby programmers going to come from? .NET ...nah. Java? Maybe, but if Java guys see that there is no reason to switch, they won't. It's tough going.
    Amen!Welcome to the dustbin RoR!!!
    Wonder going foward say 10 years how much development will shift from Java to Groovy?? Where java becomes something the 'old farts' use.
    The 'old farts' are already coding in Ruby and RoR :)(Bruce, Geary and Fowler)Profile for the Future Java DeveloperCockiness -- BirthrightGroovyNess -- Being Installed

    Bruce isn't that old. Besides, don't make fun... you will be old in no time flat. Time catches up with us all.

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  99. Grapple[ Go to top ]

    Its like naming microsoft Grapple!
  100. It's a reach[ Go to top ]

    On the contrary scott, I'm doing the exact opposite of eating my words. I predicted that most of the original culprits for this trainwreck would jump ship (sorry for the mixed metaphors) and move onto bigger and better things. You'd be hard pressed to find a single person of the starting crew still participating.

    I have always said that putting a bunch of open source shiny objects monkeys together would result in a spectacular failure. It has, they all left, and the incompetents were left trying to pick up the pieces.

    The expert group in fact can't even get its act together sufficiently to post any info on the JSR page on their progress (or lack thereof, more accurately). It became, as expected, a bunch of individuals contributing for a few weeks/months, then sailing off into the sunset. I dare anyone to say with any amount of conviction that the project is doing anything beyond limping along at this point.

    Blaming the JCP just goes to show how ignorant you are of how the whole thing works. JSRs are run by the spec lead and expert group, the JCP itself does next to nothing in the running of a JSR beyond voting on whether to approve its various milestones. So saying that the JCP abandoned groovy is akin to blaming your government every time you don't get a pay raise.

    At the end of the day, you open source zealots need to learn that enthusiasm is no substitute for hard work.
  101. It's a reach[ Go to top ]

    On the contrary scott, I'm doing the exact opposite of eating my words. I predicted that most of the original culprits for this trainwreck would jump ship (sorry for the mixed metaphors) and move onto bigger and better things. You'd be hard pressed to find a single person of the starting crew still participating.I have always said that putting a bunch of open source shiny objects monkeys together would result in a spectacular failure. It has, they all left, and the incompetents were left trying to pick up the pieces.The expert group in fact can't even get its act together sufficiently to post any info on the JSR page on their progress (or lack thereof, more accurately). It became, as expected, a bunch of individuals contributing for a few weeks/months, then sailing off into the sunset. I dare anyone to say with any amount of conviction that the project is doing anything beyond limping along at this point.Blaming the JCP just goes to show how ignorant you are of how the whole thing works. JSRs are run by the spec lead and expert group, the JCP itself does next to nothing in the running of a JSR beyond voting on whether to approve its various milestones. So saying that the JCP abandoned groovy is akin to blaming your government every time you don't get a pay raise.At the end of the day, you open source zealots need to learn that enthusiasm is no substitute for hard work.

    Hey JCP fluff boy,

    If the JCP process is so cool, why did it produce EJB 1.0 and for that matter EJB 3.0. Why did EJB 3 take three years? Why does it suck?

    RoR is a square turd.
  102. It's a reach[ Go to top ]

    If it [Groovy] does fail it's at least in part because the oligarchic JCP abandoned it becuase it didn't look like a money maker.

    I want to second Hani on this - the efforts in any JSR are due to the participants in the JSR. The only way the JCP can really effect the progress of a JSR is to vote it down at one of the process "checkpoints".

    geir
  103. that only works in specific cases[ Go to top ]

    With Java 1.6 we'll begin to have real support for scripting languages on the Java platform with the scripting language API. Groovy is one. Maybe Ruby should be one.

    I don't know, I think Ruby on Rails and Ruby are as much about ways of thinking, i.e., attitude and perspective, as they are about syntax and APIs. For example, Java programmers go ahead and try to configure *everything* with some metadata XML documents. RoR jumps to the more experienced (in my opinion) idea of "convention over configuration," which is not a language feature or API so much as a way of thinking.

    Ditto for Groovy and Ruby as languages: these are open source projects and they attract an open source mentality at their core, i.e., the people willing to produce the frameworks, tools, and language runtimes that everyone else exploits (for better or worse). As soon as you unleash the Leviathan of the Java world on the RoR concept you contaminate it with the wrong motives, wrong people, wrong intentions -- IBM, BEA, Sun, all these guys will latch onto anything that looks like it can make money. And once they do they set up JCPs and consortiums and specs and suck the life out of them.

    I am glad to see Groovy still breathing. If nothing else it'll make Fate Hani eat his words (I'm sure he won't mind, he seems like a good guy at heart) about Groovy as a "failed JSR." If it does fail it's at least in part because the oligarchic JCP abandoned it becuase it didn't look like a money maker.

    convention over configuration works in very specific cases. I think there are plenty of cases where one prefers convention over configuration, but there's a ton of cases where that totally falls apart. Say I build a service which is "co-branded", so a large part of deploying the same app for another "co-brand" is configuration.

    The whole idea that one should have sane defaults for common properties is old. To propose using convention to define a set of guidelines for default values feels half-baked to me. Take a compiler for example. It totally makes sense to have default values so that if an user doesn't set the options, the application just works. Now say I write a cross language compiler that takes a bunch of .txt files and generates executable code. In this specific case, having defaults by convention is stupid. A user has to provide the proper configuration values.

    Very few of the ideas in ROR feel new to me. What is different is doing it in a langauge that isn't mainstream. I wish Grails good luck and hope they succeed. Even though I no longer do Web interfaces, I do see value in providing different ways of doing the same task. Developers are quite diverse and no single approach will work for everyone for all situations.

    peter
  104. It's a reach[ Go to top ]

    For example, Java programmers go ahead and try to configure *everything* with some metadata XML documents. RoR jumps to the more experienced (in my opinion) idea of "convention over configuration," which is not a language feature or API so much as a way of thinking.

    Talk about generalization. For instance, Maven 2 is all about convention over configuration, Struts Shale too, JUnit has been like that for year (the testXXX methods, don't know about the 4.0 thought), way before Rails appeared.
  105. Javascript on Rails[ Go to top ]

    If we're going to talk about different Java-related RoR frameworks, there's Trimpath Junction, too.

    I haven't checked it out yet but it's intriguing since I'm more familiar with Javascript than Groovy.
  106. I think Web 2.0 is here .
    With the advent of RIA like Flex,JNCP, thinlet etc
    we should be looking into providing a solid framework for
    RIA which is easy to develop, faster in access .
    Bring something like Flex in Java world.
    Right now there are SwiXML, JNCP, Java webstart etc.
    but unless we find a way of eliminating the painful process of JRE download (Thinlet has made good inroads)
    Microsoft technologies will take over
  107. About Grails[ Go to top ]

    Having read a lot of the posts on here it seems mostly about the name copying Rails and about Groovy FUD which is a shame. It is in some senses unfortunate that the names are so similar, but it is a good starting point for Grails as people will know what its about from day 1. As Floyd predicted long term we may change the name because we are most definitely not chashing RoR and there are some fundamental differences between Grails and Rails (although clearly the framework is inspired by Rails).

    There are some fantastic ideas that have come out of the development on Grails that you want see in Rails such as Dynamic Tag Libraries, GORM built on Hibernate, built in support for transactional Services and some great features planned in the RoadMap so they really are very different in many ways. But I guess the main goal for me with Grails was my existing investment in Java. Grails integrates seamless with Java in many ways:

    - You can inject Java services in Grails controllers with Spring
    - You can created your domain model in Java and map it with Hibernate and STILL use dynamic methods (save(),delete() etc.) on these java classes as these are injected at runtime
    - You can use JSP as a view tech (with support for others like freemarker/velocity etc. planned) as well as GSP
    - You can deploy Grails as a WAR onto any JEE application server
    - And of course because you are in the JVM you can use whatever third party Java libraries you want

    And Grails doesn't force you to use the whole stack, you could just use the controller view layer on existing java services, you could just use the Hibernate integration to script Hibernate.. there are really plenty of options.

    In terms of Groovy, Groovy has received unwarranted criticism recently for such a young language. I would like to have seen the state of Ruby when it was only 2 and a half years old. It is the only language on the JVM that has the same feeling as Ruby, but with a Java feel and without the warts from Perl. The Groovy team have achieved fantastic amounts in the time and the work is on going to improve it. Thanks to Jochen, John Wilson, Dierk and Guillaume from the Groovy team for all their support in helping Grails reach 0.1

    PS A slight correction the The Server Side posting, is that the name is now simply Grails (without the "on Rails" bit) as requested by the David HH from Ruby on Rails.
  108. About Grails[ Go to top ]

    And Grails doesn't force you to use the whole stack, you could just use the controller view layer on existing java services, ...

    This is actually very important, IME. I worked for a company developing an application generator tool, and 90% of interest in our business came from people with all the back-end and middleware stuff they needed, but no simple way to put a UI on it all.

    So I think it is important to be able to generate views that are service-oriented, rather than domain-model-oriented. This might have to include some form of page flow and state/continuation handling.

    Just some thoughts...

    BTW, I have used Grails and *really* liked it.

    Regards
    Kit
  109. Groovy FUD and Rails copy-cat[ Go to top ]

    I'll admit it, I was on the "Groovy FUD" bandwagon until... I actually tried using it. After forcing myself through the learning curve barier (which took about a day) I was honestly surprised at how intuitive and natural it is to program in that style.

    I had a hard time going back to Java which I could do certain things.

    But, it isn't there yet -- debugging IS a nightmare the error messages are practically uselese, etc.

    As for Grails I though "oh great, a Rails copycat" -- then I actually looked at it. It appears to take the concept from Rails but looks like it is definitely its own thing.

    I'll be giving it a try on a small personal project but there is no way it will be ready for anything larger than that until the errors and debugging problems with Groovy itself are fixed. IDE support is critical in enterprise world too (I know Groovy is getting some but it is going way too slowly).
  110. Groovy FUD and Rails copy-cat[ Go to top ]

    I agree w/ KS.

    Once you use Goovy for a day, it's hard to go back to Java (so I don't, I use it anyplace one would use JEE frameworks).

    And I also agree that Grails is not impresive. gps (jsp) tags are cool, but that is separate component.

    It be cool if Java 7 was Groovy(yes, in Groovy you can use old the old Java), or had all the Groovy features. About time to wake up the 10 year old language (anotations are gooing to prove to be a bad idea imo)

    .V
  111. Groovy FUD and Rails copy-cat[ Go to top ]

    I agree w/ KS.Once you use Goovy for a day, it's hard to go back to Java (so I don't, I use it anyplace one would use JEE frameworks).And I also agree that Grails is not impresive. gps (jsp) tags are cool, but that is separate component.It be cool if Java 7 was Groovy(yes, in Groovy you can use old the old Java), or had all the Groovy features. About time to wake up the 10 year old language (anotations are gooing to prove to be a bad idea imo).V

    Vic whatever you're smoking, SEND ME SOME!!!
  112. Groovy FUD and Rails copy-cat[ Go to top ]

    whatever you're smoking, SEND ME SOME!!!

    One definition of a trol is no information, only inflamation.
    Would this be an example of a trol?

    (It seems that the buble is back, as masses that would not normaly be in the profesion are somehow in.)

    Sorry that you think that Ruby is best, but Groovy gives you java bytecode, and a good alternative.

    .V
  113. Groovy FUD and Rails copy-cat[ Go to top ]

    One definition of a trol is no information, only inflamation. Would this be an example of a trol?(It seems that the buble is back, as masses that would not normaly be in the profesion are somehow in.)Sorry that you think that Ruby is best, but Groovy gives you java bytecode, and a good alternative..V

    Very informative and at all inflamatory - calling someone a troll.
    Also, in the trademark Vic style, you seem to lack the ability to really understand other people's posts and jump to irrational conclusions (I never said Ruby is BEST, just BETTER than Groovy). The groovy/bytecode remark is also strikingly superfluous. You seem to think that I have somehow missed that... Bizzare.
    Regarding the "masses" that don't belong in the profession... I'm sure you also meant to direct that at me. It's too embarrassing to wave my brainbench certifications and other public information that might make you want to take that pathetic insult back.
  114. Groovy FUD and Rails copy-cat[ Go to top ]

    One definition of a troll is no information, only inflamation.

    Radu, I underlined that I agree w/ KS, and you slam me w/ one line on drugs, no technical argument or what part you disagree, I challange you to read *YOUR* 1st post to me and tell me what fact is your argument about.

    Groovy makes java bytecode, it can use all of the many jars, it's great at collections, w/ tomcat/resin - it reloads auto, etc.
    Which of the things upsets you or something else?

    .V
    ps: Or are you upset that I point out that code was refactored for various reasons in the previous posts?
  115. Groovy FUD and Rails copy-cat[ Go to top ]

    One definition of a troll is no information, only inflamation.
    Radu, I underlined that I agree w/ KS, and you slam me w/ one line on drugs, no technical argument or what part you disagree, I challange you to read *YOUR* 1st post to me and tell me what fact is your argument about.Groovy makes java bytecode, it can use all of the many jars, it's great at collections, w/ tomcat/resin - it reloads auto, etc. Which of the things upsets you or something else?.Vps: Or are you upset that I point out that code was refactored for various reasons in the previous posts?

    Vic, nothing in what you ever say upsets me, except lack of good humour on your part, calling me a troll and suggesting that I'm not fit to comment on the subject at hand, nor being in the industry.
    In case you didn't get it, the "one line on drugs" as you refer to it is a popular joke, not a very good one I might add, but it always seem to bring a smile on people's faces. The joke was directed to your wishful thinking about Java 7 being Groovy. Also as I'm sure you know "groovy" is one of the most popular words in the 70's slang. This is also reflected in the Groovy logo that employs a visual design style reminiscent of the same era. The pot joke was therefore tied in on a number of things, for one the (in my opinion) exaggerated idea that Java 7 would be mainly Groovy and the Groovy/groovy/70's/pot connection.
    Peace out man!
  116. Groovy FUD and Rails copy-cat[ Go to top ]

    In case you didn't get it, the "one line on drugs" as you refer to it is a popular joke, not a very good one I might add ... The joke was directed to your wishful thinking about Java 7 being Groovy.

    I can't read your mind about what you are talking about, and I take my drugs serious ;-)

    Why not be ambitious about Java 7?!
     As people in this thread wish for a nice improvments. Java 7 has to do something to keep up w/ C# v3 syntax.
    When granpa-Gosling says Java will never be dynamic it wories me.
    (Java was meant for devices, but... it does not run on PSP, PS2, XBox, Palm, MS WinPhone, PS3, etc. Hard to find a Java capable device. But they do run C)
    So I say be agresive w/ Java 7, study and use Groovy for a full day.
    I personaly use only Groovy anyplace people want Java (unless by some miracle Java 7 picks up the pace that will stay).
    This is simple since Groovy can extend and implement any java code or framework, unlike alternatives like Ruby. There are so many usefull Java jars (don't trow up the baby w/ the bathwater)

    And Resin (posibly the largerst makert share JEE server) already supports Groovy out of the box (and PHP anyplace you would use a JSP).

    .V
  117. Groovy FUD and Rails copy-cat[ Go to top ]

    Java 7 has to do something to keep up w/ C# v3 syntax.

    Just out of curiousity - why does it have to do this? I think the idea of continually extending a language with new syntax is a bad idea (especially at the speed Microsoft are doing things with C# and VB.NET). Far better would be to make the JVM itself more suitable for dynamic languages, and then add features via new APIs which can then be used by the increasing variety of languages which would run more efficiently on the JVM.
  118. IDE[ Go to top ]

    I like the way of development of Grails.
      A big plus of Java over any other language is the very good IDEs avaliable, like Eclipse.
      We must use this. We should not use notepad to edit our code.
      A implementation of Grails as a set of plugins to a IDE would make a very nice product. The same kind of development process, but with menu options to make them. With a good code editor, debugger and so on. Or at least some integration with a IDE, to make possible run grails targets.
      I think the Grails team should evaluate if this can be done.
  119. IDE[ Go to top ]

    Hi Danilo,

    Yes this is on the roadmap and in fact there is work underway at the moment on the Groovy Eclipse plug-in to get Groovy classes debuggable (this is already possible with JSWat an NetBeans). After this is done we will then have 2 options on which to build a Grails plug-in (Eclipse and NetBeans) and can look at building on the work that has been done to create a set of Grails specific extensions.

    The interesting thing to note about the Grails targets is that all they do is create files from templates there is no special configuration being done in the background by the targets themselves so you could just create the files as usual in an IDE using File/New. All the configuration happens at runtime.
  120. If you're thinking about trying Grails, I'd seriously recommend looking at Waffle first:

      http://waffle.sourceforge.net/

    I can't yet claim any first hand experience, but from my experience with how RoR enables the productivity increases that it does, I'd say that Waffle is the closest thing I seen yet and distilling those essential qualities in a Java framework.
  121. Oh Boy[ Go to top ]

    Just another example of our framework happy open source world where we are supposed to be excited about a v0.1 release. Please let us know after you've released v1.2 and have 50 major customers (fortune 1000 companies) using your product.

    Can we please stop with all these idiotic, quickly sharted frameworks? This one claims that it will "seamlessly" integrate into the JDK framework. Either that is a blatant lie, or it is no use to developers. They are still going to have to read through crappy documentation and ill-advised examples to try to get this thing to work.
  122. Oh boy it hurts[ Go to top ]

    Just another example of our framework happy open source world where we are supposed to be excited about a v0.1 release. Please let us know after you've released v1.2 and have 50 major customers (fortune 1000 companies) using your product.Can we please stop with all these idiotic, quickly sharted frameworks? This one claims that it will "seamlessly" integrate into the JDK framework. Either that is a blatant lie, or it is no use to developers. They are still going to have to read through crappy documentation and ill-advised examples to try to get this thing to work.

    Interesting point. Before I touch it however I just want say how sorry I am you're in so much pain, I wish it would be better for you.

    From the Grails wikipedia page:

    "Grails is build on top of and is part of the Java platform meaning it's very easy to integrate with Java libraries, frameworks and existing code bases. The most prominent feature Grails offers in this area is the transparent integration of classes that are mapped with the Hibernate ORM framework. This means existing applications that use Hibernate can use Grails without recompiling the code or reconfiguring the Hibernate classes while using the dynamic persistence methods discussed above. [4]

    One consequence of this is that scaffolding can be configured for Java classes mapped with Hibernate. Another consequence is that the capabilities of the Grails web framework are fully available for these classes and the applications that use them."
  123. Just another example of our framework happy open source world where we are supposed to be excited about a v0.1 release. Please let us know after you've released v1.2 and have 50 major customers (fortune 1000 companies) using your product.Can we please stop with all these idiotic, quickly sharted frameworks? This one claims that it will "seamlessly" integrate into the JDK framework. Either that is a blatant lie, or it is no use to developers. They are still going to have to read through crappy documentation and ill-advised examples to try to get this thing to work.

    I recently downloaded Grails and have started trying it out and have found the documentation and examples very good. Also, for a 0.1 release the quality is excellent.

    The framework seems well thought out, and is looking like it will be a very productive tool. Congrats on the release guys.

    Mike Stephen.
  124. I saw this coming[ Go to top ]

    This proves a theory that I have. When I heard all the buzz about RoR, I investigate about it , when I saw what RoR can do, I thought that it will never beat Java , the reason is that all the great things that RoR have, will be copied and improved (and added more new features ) by another framework in java in few time, RoR serve as an inspiration for the Java developers to make things easier, the same thing happened with C#.
    Grails will succeed over RoR because is based in great frameworks like Hibernate Spring, Groovy etc, I saw in the site that they will integrate templates engines like Velocity, so Grails is mainly an integration tool is a big difference from RoR where most of the parts are made by the same people and are new, they just doesn’t have all features that the old trusted frameworks have in java, for example you will never find all the features of Hibernate 3 in ActiveRecord. I never move to RoR because I lost all the great IDEs and apis that java have, it just to hard for the guys of Ruby make all the great things that are right now available in java, but for the Java community is easy to build a framework that do what RoR do, i am sure it will do it better, examples of this are Seam, Rife, Trails, Grails .
    Congratulations for the release to Grails guys.

    Note: English is not my native language so sorry if I wrote something wrong.
  125. "Grails will succeed over RoR because is based in great frameworks like Hibernate Spring, Groovy etc"

    While these are admittedly very good frameworks, the fact that Grails uses them is the reason it may *not* succeed over RoR. This is because using these frameworks makes it nearly impossible for Grails to implement the fundamental things that give RoR its productivity edge.

    That being said, if you *have* to stay in the Java camp, then you probably will be better off using something like Grails.
  126. "Grails will succeed over RoR because is based in great frameworks like Hibernate Spring, Groovy etc"While these are admittedly very good frameworks, the fact that Grails uses them is the reason it may *not* succeed over RoR. This is because using these frameworks makes it nearly impossible for Grails to implement the fundamental things that give RoR its productivity edge.That being said, if you *have* to stay in the Java camp, then you probably will be better off using something like Grails.

    Please ellaborate.
  127. The big productivity boosters in RoR come from things like "convention over configuration" (which eliminates the need for almost all configuration), instant turnaround (make a change, see it work), and other seemingly micro-features that actually add up big-time.

    Even if you never intend to use RoR, its worth spedning a couple days using it to implement something more complicated than hello world. Doing so will help open your eyes to what is possible, and you can bring that newfound experience back to your Java work.

    As I said in an earier comment, Waffle looks really promising for getting a lot of these productivity benefits in Java (but I can't say for sure because I haven;t used it yet):

      http://waffle.sourceforge.net/
  128. The big productivity boosters in RoR come from things like "convention over configuration"

    Some people believe RoR have invented everything even the wheel. Have you ever used JUnit? Do you need to configure which tests to run or the Swing runner is smart enough to look for testXXX methods? Look like "Convention over configuration" to me. It is true there were not enough default conventions in the past in the official specs and some frameworks like Struts but this idea has been around years before RoR was released and is very strong in products like Maven 2 or Struts Shale for instance. By the way, it is a main philosophy of JEE 5.
    (which eliminates the need for almost all configuration)

    Yeah sure! There has been too much config in the last years, so let's dump it all. It has totally no purpose, that why it was invented in the first place. Jumping from one extreme to the other is not better. This what is called "hype" and "buzzwords".

    Conventions are excellent as default values and are enough in a lot of cases. But when you just need more and you can't get it, it is very frustrating.
  129. RoR Hype[ Go to top ]

    By the way, am I the only one who doesn't see any productivity gain in RoR in the long run?

    I think it has some good ideas but overall I don't like it at all. Its approach remind me of Oracle Forms, it has been around for years in the client-server application space. Maybe it's because there was no of this type on the Web. Seriously, in my opinion, RoR is just something along the lines of Delphi, Visual Basic or Oracle Forms but for the Web.

    Anyway, maybe I am biased because where I work all the small applications which are supposed to be small and short-living end up being big and long-living. Consultants (like the RoR creator) probably don't care about such things but I do because I am the one stuck with the applications afterwar.
  130. RoR Hype[ Go to top ]

    By the way, am I the only one who doesn't see any productivity gain in RoR in the long run?

    No!
    I think it has some good ideas but overall I don't like it at all. Its approach remind me of Oracle Forms, it has been around for years in the client-server application space. Maybe it's because there was no of this type on the Web. Seriously, in my opinion, RoR is just something along the lines of Delphi, Visual Basic or Oracle Forms but for the Web. Anyway, maybe I am biased because where I work all the small applications which are supposed to be small and short-living end up being big and long-living. Consultants (like the RoR creator) probably don't care about such things but I do because I am the one stuck with the applications afterwar.

    I have the same opinion.
  131. The big productivity boosters in RoR come from things like "convention over configuration" (which eliminates the need for almost all configuration), instant turnaround (make a change, see it work), and other seemingly micro-features that actually add up big-time.

    I am really not convinced at all that they do. Most of my configuration is handled by tools, so where is the time saving in not having any? The instant turnaround only works for some situations, and once an application grows those situations, in my experience, get less common.
    Even if you never intend to use RoR, its worth spedning a couple days using it to implement something more complicated than hello world. Doing so will help open your eyes to what is possible, and you can bring that newfound experience back to your Java work.

    I believe that some of the RoR users need to see what is possible in Java development today, and bring that experience back to their RoR work - things like two-way development of data model and schema, portable query languages with transparent generation of high-performance SQL, persistence to non-relational stores.
  132. I don’t understand , Why you say using those frameworks will make for Grails team harder to implement the fundamentals things that RoR has?, for me if I have to make a framework like Ruby on Rails it will be great to have those frameworks, because it will let me focus on really productive functionality like generating CRUD code or MVC logic, and will not have to worry if I’m implementing ORM correctly for example, besides they are fully tested, if I implement my own ORM I will have to deal with the bugs of the implementation, using those framework make easier the migration process of applications that use the same frameworks like hibernate, and of course they are well documented with is great for the new Grails users and for old java users the fact that Grails uses spring or hibernate it make easier to use Grails because they already now part of it
  133. I agree with you Gabriel. I worded the title the way I did merely because it sounded like you were dismissing RoR widely documented increases in in productivity. My only point is that I don't believe that Grails will be able to achieve the same level of productivity increases that RoR has achieved.

    Grails looks promising, and I have every expectation that you will be better off using it than not. Still, I think its possible to do better in the Java web app space, and I *want* to see that happen, as well.
  134. Yes maybe/maybe not I would challenge this statement, but your first post was misleading as it implied that Grails does not use the coding by convention approach which it does.

    It does user Spring and Hibernate, but there is no XML configuration to write or annotations for that matter, configuration is done automatically at runtime based on the convention in the classes. For Hibernate the Grails team wrote a specific binder that binds Grails ORM classes to the Hibernate runtime meta model. Spring configuration is done at runtime.

    IF however you want the advanced features that Spring and Hibernate offer, they are there for you. You can map your "Java" classes in Hibernate if you want or have a legacy system to deal with, and you can use Spring to inject Java services into controllers and other Grails artifacts. This is why I believe Grails has greater potential to scale (in terms of application complexity) because you can do the small apps, but when they start to grow you can incorporate static typing and java classes to have a blend of approaches.

    It is the blend that is key as in my opinion the static vs dynamic debate is a red herring. Its about choosing the best tool for the job, and anyone who dismissed the benefit of static typing and the power of IDEs and refactoring tools clearly have never built a truely large application that they have to maintain or are simply in denial ;-)
  135. I agree with you Gabriel. I worded the title the way I did merely because it sounded like you were dismissing RoR widely documented increases in in productivity. My only point is that I don't believe that Grails will be able to achieve the same level of productivity increases that RoR has achieved.Grails looks promising, and I have every expectation that you will be better off using it than not. Still, I think its possible to do better in the Java web app space, and I *want* to see that happen, as well.

    Thanks for making this point. We would be very happy to hear your ideas on how to make Grails better. We also invite those interested to contribute to Grails. We're currently working to set up a plugin structure for 0.2 to make it easy to extend and improve Grails.

    Steven
  136. Hey, is this the April Fools joke you promised?
  137. Gromail is developed by Java guru Mike Nixon. All you need is to create email with some annotations and email sever will create Java code for you.

  138. RoR is like a square turd that makes your anus bleed. You sit there on the chamber pot trying to evacuate your bowl when suddenly you realize that it is not happening. Then you realize that you've been consuming too much junk food and not enough vegetables and fiber (writing in a inferior environment like Ruby). Oh you swear you will never do it again if you could just evacuate your bowl (release software developed in Ruby). You push and push, but the framework fights you all the way. Finally with one final push... oh the pain.



    RoR is like Visual FoxPro circa 1994. Why must we do this time travel? Why work in an environment without code completion, refactoring support, debugging, etc. Why must people go through this pain again?



    Webapps in Perl, Python, PhP, Model 1 JSP, VBScript, are basically the same old crap. Why is RoR so special? It is the biggest joke ever seen. It is joketastic. If you have done DBase III you have already done RoR. Do they really expect us to take this crap? Just say no to RoR.



    Of course you have the true believers. They will tell that RoR works well. If it does not work for you, then you are doing it wrong because you are not a true believer.


    I've spoken with many folks who hoped RoR would live up to their promises. It did not. There are no magic bullets. You don't here these stories. As long as you are writing mickeymouse applications then RoR is the framework is for you.



    Anything you can do in RoR, you can do in Java, and perhaps better and more stable. There is no shortage of RoR competitors in Java.



    What is RoR secret weapon? It is a joke. They have a method that gets called when no other method gets called to resolve a property that only really exists in the database. Their ADO framework is based on this magic bullet. So suddenly you have objects that don't really have APIs. Forget about code completion. If you deviate from the RoR core, you get no help, just crappy error messages (if you are lucky). Create a method that has a method called exectute that passes a string called method name, and you have RoR secret weapon. Oh you say, this is just a string. Yeah so is any object's method that allows an arbitrary string become a method. What a load of crap!



    RoR is people's righeous indignation to technologies like Struts, WebWork, and EJB (1,1.1,2.1,2.2 and 3). It is the desire not to spend your life configuring XML files. The Java community has moved on. We learned our lessons. We've purged the false profits. However, RoR is broken beyond belief. Choosing RoR is a mistake.



    Listen Groovy developers. No IDE tools no adoption.
  139. It feels like a troll[ Go to top ]

    it reads trollish, it must be a troll.
    No seriously some stuff is broken in rails, some not, but you cannot deny that Rails had a huge impact, suddenly and finally everyone realizes that we have to cope with complexities in the average webapp which is way too much to handle and also have a good development time. Suddenly frameworks which really try to make things easier instead of trying to shift the pole from java to xml arrive
    (Seam is one of those, Grails another one, Rumba also)
    Even for that we have to be thankful.
    As for code completion issues, this is an issue in dynamic languages, ruby is not the only language having this problem, but it is solvable.
  140. Does not seem like a Troll to me[ Go to top ]

    it reads trollish, it must be a troll.No seriously some stuff is broken in rails, some not, but you cannot deny that Rails had a huge impact, suddenly and finally everyone realizes that we have to cope with complexities in the average webapp which is way too much to handle and also have a good development time. Suddenly frameworks which really try to make things easier instead of trying to shift the pole from java to xml arrive(Seam is one of those, Grails another one, Rumba also)Even for that we have to be thankful.As for code completion issues, this is an issue in dynamic languages, ruby is not the only language having this problem, but it is solvable.

    It the strictness definition of Troll... It does not seem like a Troll to me. I think he (I guess he), brings up some valid points.

    I like the ideas behind RoR, but not RoR for many of the reason he espoused minus the references to bowl movements.