The many problems with this Go to top ] Posted by: Mike Brown

Posted on: February 17 2006 08:39 EST

in response to Tom Donoghue I have noticed that Java developers seem to have this impression that all other languages are dead and no one uses them. This is simply not true. "Dead like COBOL" I would waiger that there are more lines of active COBOL code in the world today than Java. Also, if COBOL is dead, then it had a good 4 decade run. I hope Java has the same.



Useless we can actuall look at what he did in Java and what was done in Ruby, we shouldn't conclude that he is correct. Just because he wrote some books, doesn't make him an expert. 4 months Java = 2 days Ruby? Reply to this Reply to original

COBOL IS NOT DEAD FOR SURE Go to top ] Posted by: Ilya Sterin

Posted on: February 18 2006 10:14 EST

in response to Adel Alrashidi "COBOL is dead" >>> where I work, there are more COBOL programmers then any other langauge!! so I don't think that COBOL is dead or will be dead in the next 10 years.Java is strong, and it is getting stronger and stronger in the server side. however, yes, we really need to work a lot in the client side.Adel

Yes, but I bet you don't have many or any new projects starting in COBOL. Or course COBOL will exist as long as there is still software written in it, for maintenance and additional feature reasons. Some companies can't justify rewriting an inhouse application, if the current one is efficient and meets their needs.



Ilya Yes, but I bet you don't have many or any new projects starting in COBOL. Or course COBOL will exist as long as there is still software written in it, for maintenance and additional feature reasons. Some companies can't justify rewriting an inhouse application, if the current one is efficient and meets their needs.Ilya Reply to this Reply to original

RoR vs Java Again??? Go to top ] Posted by: Rogerio Saulo

Posted on: February 17 2006 08:46 EST

in response to Tom Donoghue Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve.

Come on people, this is not a valid comparison, RoR does not compete with JEE, I like to see how they do an complex application with an DB with 100+ tables with ActiveRecord, you cannot base your application 100% on the DB design, it is a poor design, the DB and business rules need to be separated. RoR IMHO does not work for legacy DBs and RoRis JUST for smaller projects, TSS need to stop posting articles that make wrong comparisons... Come on people, this is not a valid comparison, RoR does not compete with JEE, I like to see how they do an complex application with an DB with 100+ tables with ActiveRecord, you cannot base your application 100% on the DB design, it is a poor design, the DB and business rules need to be separated. RoR IMHO does not work for legacy DBs and RoRis JUST for smaller projects, TSS need to stop posting articles that make wrong comparisons... Reply to this Reply to original

Open Source Go to top ] Posted by: Paul Beckford

Posted on: February 17 2006 09:32 EST

in response to Rogerio Saulo Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve. Come on people, this is not a valid comparison, RoR does not compete with JEE,..

I don't think this was the main thrust of Bruce's interview. I think the point he was making is how should we go about innovating.



He makes the point that the open source model is a lot better at doing this. I agree. I don't think this was the main thrust of Bruce's interview. I think the point he was making is how should we go about innovating.He makes the point that the open source model is a lot better at doing this. I agree. Reply to this Reply to original

RoR vs Java Again??? Go to top ] Posted by: Hans Prueller

Posted on: February 17 2006 10:56 EST

in response to Rogerio Saulo Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve. Come on people, this is not a valid comparison, RoR does not compete with JEE, I like to see how they do an complex application with an DB with 100+ tables with ActiveRecord, you cannot base your application 100% on the DB design, it is a poor design, the DB and business rules need to be separated. RoR IMHO does not work for legacy DBs and RoRis JUST for smaller projects, TSS need to stop posting articles that make wrong comparisons...

I just can say: +++ +++ +++ +++!!!



You definitely mentioned the right think. See also



http://hanzz.lbs-logics.at/index.php?option=com_content&task=view&id=64&Itemid=2



for my comments. I just can say: +++ +++ +++ +++!!!You definitely mentioned the right think. See alsofor my comments. Reply to this Reply to original

Dead like PL/1? Go to top ] Posted by: Ilya Sterin

Posted on: February 17 2006 09:10 EST

in response to Victor C. Fact:1.Upcoming JSE 6 does not include GroupLayout (Netbeans Matise layout)2.Upcoming JEE 5 does not include Portlets.End of story. Not even fair to mention what other features other tech stack DO include now relative. Clients and Developers are being chased away from where I see..V

What in the world are you talking about? This is why clients are being chased away? Because of GroupLayout and lack of JEE support for portlets? Ruby or other languages have that support? Even if the portlets are not going to be included in the JEE 5 support, I'm sure there will be great quality implementations out there you can use.



Ilya What in the world are you talking about? This is why clients are being chased away? Because of GroupLayout and lack of JEE support for portlets? Ruby or other languages have that support? Even if the portlets are not going to be included in the JEE 5 support, I'm sure there will be great quality implementations out there you can use.Ilya Reply to this Reply to original

Dead like PL/1? Go to top ] Posted by: Victor C.

Posted on: February 17 2006 12:45 EST

in response to Ilya Sterin

lack of JEE support for portlets? <snip> other languages have that support?

I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK!



How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.



JEE including or not including Portlets is important.



.V Ilaya,I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK!How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.JEE including or not including Portlets is important..V Reply to this Reply to original

Dead like PL/1? Go to top ] Posted by: Ilya Sterin

Posted on: February 17 2006 13:19 EST

in response to Victor C. Ilaya, lack of JEE support for portlets? <snip> other languages have that support? I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK! How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.JEE including or not including Portlets is important..V

But C# has other drawbacks, single vendor, one platform, etc... I never compare JEE to C#, I don't see why other do. Unless we're ready to switch to a single platform enterprise, and all but windows, it takes a last seat in my book. It's great for analytical client applications though, or maybe putting a lightweight front end to OLTP.



Ilya But C# has other drawbacks, single vendor, one platform, etc... I never compare JEE to C#, I don't see why other do. Unless we're ready to switch to a single platform enterprise, and all but windows, it takes a last seat in my book. It's great for analytical client applications though, or maybe putting a lightweight front end to OLTP.Ilya Reply to this Reply to original

Dead like PL/1? Go to top ] Posted by: damian frach

Posted on: February 17 2006 13:45 EST

in response to Victor C. Ilaya, lack of JEE support for portlets? <snip> other languages have that support? I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK! How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.JEE including or not including Portlets is important..V

I do not know, but any modern J2EE portal supports portlets. And some of them are also free. I do not see a problem.



Also you can bundle your specific Swing layout manager with your app if you want. I do not see it as an overkill ... I do not know, but any modern J2EE portal supports portlets. And some of them are also free. I do not see a problem.Also you can bundle your specific Swing layout manager with your app if you want. I do not see it as an overkill ... Reply to this Reply to original

Ruby is great, but... Go to top ] Posted by: Ilya Sterin

Posted on: February 17 2006 09:07 EST

in response to Tom Donoghue Before I actualy looked into Ruby (I haven't really worked with RoR much, other than read a few article and tried a simple sample app), I didn't give it any credit. Well, that has changed, Ruby is truly a beautiful language, but...



Ruby does not and I doubt ever will, have the commercial support and standards committee like Java. These are the most important factors for enterprise technologies. If you're an independent consultant and are writting an app for a small/midsize client (who doesn't have a clue), they'll let you write it in anything to save the bucks. In that scenerio, if you love Ruby (RoR), it might be a good choice.



In most enterprise application cases, there is more to writting an app than the beauty of the language.



The other day, I was trying to make a case to make a client of mine use RoR, so that I can learn it and they can save some development time associated costs (so I've been hearing:-). I was done in about 2 minutes, after I couldn't come up with a viable enterprise quality/grade deployment platform for RoR. Even in the RoR book, they describe multiple deployment scenerios, lighttpd with FastCGI, apache with mod_ruby or fastCGI where the only two recommended for production. The first is said to be unstable sometimes (these words are directly from the book), and the second is no longer actively supported/developed. So how comfortable would a company feel in deploying their app in an unstable and/or unsupported environment. So until Ruby has a viable platform, commercial and/or open source, which has a lot of traction, money behind it, etc..., it's a huge risk for any corporation to take on.



For some reason, Ruby folks are not jumping on building a quality server platform, as say mod_perl/Apache, and even Python enjoys. I mean, what good is RoR without anywhere to deploy it?



Ilya Reply to this Reply to original

Ruby is great, but... Go to top ] Posted by: Radu-Adrian Popescu

Posted on: February 23 2006 02:40 EST

in response to Ilya Sterin [...]lighttpd with FastCGI, apache with mod_ruby or fastCGI where the only two recommended for production. The first is said to be unstable sometimes (these words are directly from the book), and the second is no longer actively supported/developed.

Where does it say that FastCGI support is no longer actively supported/developed? It seemed to me that this was by far and large the best deployment option. Any links? Cheers. Where does it say that FastCGI support is no longer actively supported/developed? It seemed to me that this was by far and large the best deployment option. Any links? Cheers. Reply to this Reply to original

Yes, but.. Go to top ] Posted by: David Peters

Posted on: February 17 2006 09:12 EST

in response to Tom Donoghue If I have to learn another language, wont I find myself getting confused when I switch back and forth between languages?



Wont I need another set of tools and scripts for compiling/deploying?



Wont I lose the ability to re-use my favorite libraries - i.e; DOM4J, Spring, Log4j, Hibernate, JUnit, etc..?



For a language that is not yet mainstream, wont it be harder to "google" for answers to your technical questions, and find documentation and a community?



Definately, we need to evolve and develop new languages as time goes by. But there has to be something BIG to get me to leave my comfort zone and community. From C++ to Java, it was the OS independence. I dont see it yet, with ROR. Reply to this Reply to original

Yes, but.. Go to top ] Posted by: Stefan Arentz

Posted on: February 17 2006 09:36 EST

in response to David Peters If I have to learn another language, wont I find myself getting confused when I switch back and forth between languages?Wont I need another set of tools and scripts for compiling/deploying?Wont I lose the ability to re-use my favorite libraries - i.e; DOM4J, Spring, Log4j, Hibernate, JUnit, etc..?For a language that is not yet mainstream, wont it be harder to "google" for answers to your technical questions, and find documentation and a community?Definately, we need to evolve and develop new languages as time goes by. But there has to be something BIG to get me to leave my comfort zone and community. From C++ to Java, it was the OS independence. I dont see it yet, with ROR.

I miss a lot of things when I work in RoR. Simple example, I needed an app to generate secure PayPal buttons. In Java this is about 40 lines of code that uses the JCE APIs. In Ruby there is nothing similar so you are simply not able to do this. End of story. I ended up with writing a simple web service in Java to do the crypto work so that the Ruby app can still have this functionality. Works ok, but it is not ideal.



Many other things. I really miss JMS in the Ruby world. I miss the well defined APIs of the standard Java runtime. I miss the quality documentation. The many more resources available in books and online. I miss simple things like an IoC container, a choice of web servers, Jakarta Commons. I miss things like JMX to monitor my app, etc.



I've asked people on for example Ruby newsgroups and in chatrooms about the above things and I usually get the same reaction as from the Python people: "you don't think in a Ruby way". Personally I think these people simply don't know any better. Java is a very rich platform with many choices and available tools. Ruby and other scripting languages are much more limited.



Sure, the language is really nice and has many features that make it so much less verbose and more powerful than something like Java. But a language is just one side of it. I need frameworks to get my job done. Most advocates don't understand that.



Sorry for the rant. I'm actually a happy user of both, you just need to know when to use the right tool for the right job :-)



S. I miss a lot of things when I work in RoR. Simple example, I needed an app to generate secure PayPal buttons. In Java this is about 40 lines of code that uses the JCE APIs. In Ruby there is nothing similar so you are simply not able to do this. End of story. I ended up with writing a simple web service in Java to do the crypto work so that the Ruby app can still have this functionality. Works ok, but it is not ideal.Many other things. I really miss JMS in the Ruby world. I miss the well defined APIs of the standard Java runtime. I miss the quality documentation. The many more resources available in books and online. I miss simple things like an IoC container, a choice of web servers, Jakarta Commons. I miss things like JMX to monitor my app, etc.I've asked people on for example Ruby newsgroups and in chatrooms about the above things and I usually get the same reaction as from the Python people: "you don't think in a Ruby way". Personally I think these people simply don't know any better. Java is a very rich platform with many choices and available tools. Ruby and other scripting languages are much more limited.Sure, the language is really nice and has many features that make it so much less verbose and more powerful than something like Java. But a language is just one side of it. I need frameworks to get my job done. Most advocates don't understand that.Sorry for the rant. I'm actually a happy user of both, you just need to know when to use the right tool for the right job :-)S. Reply to this Reply to original

Java is no longer compelling Go to top ] Posted by: U G

Posted on: February 26 2006 06:55 EST

in response to Stefan Arentz Java has run its course. SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.



Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.



We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.



Because we are *above* RAD. But if Java is good for heavy it should be good for light. But then you would have to compete with .NET or Rails and it cant...so the whole standards copout and "whaaa I need a J2ee container coput get played".



Whats the copout going to be when Spring kills J2ee containers? Reply to this Reply to original

Java is no longer compelling Go to top ] Posted by: Steve Zara

Posted on: February 26 2006 15:27 EST

in response to U G Java has run its course.

I love posts like these. They normally turn up on Slashdot, and go something like 'Intel is doomed', or 'Windows is on the way out', and, of course, 'Java is finished'.

SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.

Strange, then, that many of the reference implementations of JSRs are open source, and not implemented by vendors at all! An example I am particularly interested in is JPOX, will will be the RI of JDO 2.0. Strange form of vendor lock-in. Another interesting example is Oracle donating JSF components to Apache MyFaces - a sort of 'anti' lock-in!

Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.

So what is RAD? Fast development - perhaps with a visual tool, with integrated debugging? Well, for client-side development there is NetBeans 5.0 with its awesome GUI tool. For server-side development there is Studio Creator, with its ability to produce data-linked web applications in a matter of minutes. That sure looks like at least two RAD solutions to me!

Because we are *above* RAD.

Well, I am not a fan of Studio Creator myself, but that is just me.

But if Java is good for heavy it should be good for light.

Like J2ME? Hmm....

But then you would have to compete with .NET or Rails and it cant...

Sure .... look at all those thousands of .NET apps on Linux, Solaris, HPUX... And those thousands of Rails jobs advertised out there.....

so the whole standards copout and "whaaa I need a J2ee container coput get played".Whats the copout going to be when Spring kills J2ee containers?

Er - perhaps things like JDO and JPA, which don't need J2EE containers? Standards with open source implementations? I love posts like these. They normally turn up on Slashdot, and go something like 'Intel is doomed', or 'Windows is on the way out', and, of course, 'Java is finished'.Strange, then, that many of the reference implementations of JSRs are open source, and not implemented by vendors at all! An example I am particularly interested in is JPOX, will will be the RI of JDO 2.0. Strange form of vendor lock-in. Another interesting example is Oracle donating JSF components to Apache MyFaces - a sort of 'anti' lock-in!So what is RAD? Fast development - perhaps with a visual tool, with integrated debugging? Well, for client-side development there is NetBeans 5.0 with its awesome GUI tool. For server-side development there is Studio Creator, with its ability to produce data-linked web applications in a matter of. That sure looks like at least two RAD solutions to me!Well, I am not a fan of Studio Creator myself, but that is just me.Like J2ME? Hmm....Sure .... look at all thoseof .NET apps on Linux, Solaris, HPUX... And thoseof Rails jobs advertised out there.....Er - perhaps things like JDO and JPA, which don't need J2EE containers? Standards with open source implementations? Reply to this Reply to original

Java is no longer compelling Go to top ] Posted by: David McCoy

Posted on: February 26 2006 21:08 EST

in response to U G Java has run its course. SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.Because we are *above* RAD. But if Java is good for heavy it should be good for light. But then you would have to compete with .NET or Rails and it cant...so the whole standards copout and "whaaa I need a J2ee container coput get played".Whats the copout going to be when Spring kills J2ee containers?

Speak for yourself. Just because *YOU* are overengineering and *YOU* are getting your ass kicked doesn't mean that Java is compelling.



Have you consider that YOUR stuff is overengineered and your ass is being kicked because you suck? Speak for yourself. Just because *YOU* are overengineering and *YOU* are getting your ass kicked doesn't mean that Java is compelling.Have you consider that YOUR stuff is overengineered and your ass is being kicked because you suck? Reply to this Reply to original

Java: Dead Like COBOL, Not Like Elvis? Go to top ] Posted by: William Childers

Posted on: February 17 2006 09:22 EST

in response to Tom Donoghue Is Tate living in a cocoon. He says in the article "Well, look at it from a historical context. The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases. The thinking was, and still is: ‘If you can solve that web-database problem very quickly, most of the time you will be important." Well, I've been doing Java and and JEE for a number of years in the enterprise space and "slapping a web UI" has rarely if ever been the focus for our use of Java. In Java's early days it wasn't even the web. People in corporations kept trying to write fat clients with Java. They thought they had a better more portable VB. Attempts to use it on the web beyond applets came later. The people who did think that Java was primarily for solving UI problems where the weenies and kids - the same types who think the world's important problems could/should be solved by spinning widgets in VB.



As years have gone by and JEE has matured, we are increasingly using it to replace the backend systems and not just integrate with them. Tate says that in the article, but his tone implies that he thinks that sort of work is somehow less important. Well Bruce, its the sort of computing that runs the world. The UI's are just the icing. Amazon's one-click web interface wouldn't be very important if they couldn't obtain the product, ship it to you and collect the money. That's not done by a web UI.



So for everyone like Bruce who thinks its all about the UI - please go chase after the next big UI toy and leave the real work to the adults.



All that being said, I agree with a number of Tate's points and there is a lot to criticize about the JCP and the role of vendors in gunking up the platform and the ridiculous proliferation of "frameworks" and "standards". However, all this activity is actually proof that Java is not dead "like COBOL". The COBOL world has not experience that much diversity and change in decades, if ever. Reply to this Reply to original

UI is what the users/clients see :-) Go to top ] Posted by: Gennadiy Civil

Posted on: April 10 2007 14:31 EDT

in response to William Childers Yes the back end processing is important. IMPORTANT. However - one has to understand the importantce of the UI, if you think that UI is somehow secondary this is exactly the arrogance that gets an IT group in trouble with the clients. Tate is simply stating that existing J2EE set is not suitable for creating nice looking and functional UIs quckly as it should be in this day and age. I agree. Many, may times I would have to write some JavaScript in web application spending hours and sometimes days that I would not even think about if I was using Microsoft platform... I would dare to reverse your example - if Amazon did not have a nice UI there may not have been all this need to write a robust back end to process all these orders. How about 1-Click orders on Amazon? This is one of their most prised posessions , if I am not mistaken there was a legal proceedings at some point with someone else for the right do to a 1-Click orders. Reply to this Reply to original

Bruce does anything to sell his books Go to top ] Posted by: Stefan Arentz

Posted on: February 17 2006 09:25 EST

in response to Tom Donoghue I don't buy this story for several reasons.



You cannot tell me that an experienced team of two Java programmers spend 4 months working on an application, getting the job not done and then doing a rewrite in less than a week.



Either the numbers don't add up, Bruce is not telling the whole story or the experience of those developers was not so brilliant after all.



Sure, RoR is great, and I can also crank out a complex data model in minimal time. But really, with Hibernate 3.1 I can do it in the same time. In RoR I edit SQL code and create mostly empty model classes and with Hibernate I just write model classes with some annotations added.



Maybe Bruce spend 4 months building this app in a classic J2EE/1.3 environment; Struts, Entity Beans, etc. Well, we all already knew that it is pretty difficult to be agile with that combination.



So, invitation to Bruce: why not give us fill disclosure about what went really wrong in the original project?



S. Reply to this Reply to original

Java: Dead Like COBOL, Not Like Elvis? Go to top ] Posted by: Bruce Tate

Posted on: February 17 2006 09:41 EST

in response to Tom Donoghue Boy, the TSS knows how to pick out a quote...don't they? Maybe I should provide a little context. So when someone reads Beyond Java, the question inevitably comes up like this:



"So Java is dead, right?"



And I need to respond without reciting a dissertation including all of the ideas in the book. And I think this quote captures the idea: old languages will someday be pushed to the back burner and new ideas will be expressed in something else, and the community will move on to something else. But old successful languages don't die. And the economy around them doesn't disappear.



Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.



But I hardly think one sensationalized quote captures the spirit of the whole interview, the book, or my opinions, and I think that pushing out such a quote as a headline is a cheap trick to generate traffic. Certainly no conversation of substance will come out of it. Reply to this Reply to original

Java: Dead Like COBOL, Not Like Elvis? Go to top ] Posted by: Darryl Smith

Posted on: February 17 2006 10:30 EST

in response to Bruce Tate Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.

What shape is ruby in? Its birthday will be in 13th birthday will be in 7 days



http://www.ruby-lang.org/en/20030224.html What shape is ruby in? Its birthday will be in 13th birthday will be in 7 days Reply to this Reply to original

Java: Dead Like COBOL, Not Like Elvis? Go to top ] Posted by: Darryl Smith

Posted on: February 17 2006 10:32 EST

in response to Darryl Smith Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.

What shape is ruby in? Its birthday 13th birthday will be in 7 days



http://www.ruby-lang.org/en/20030224.html



preview preview preview What shape is ruby in? Its birthday 13th birthday will be in 7 days Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: lecharny emmanuel

Posted on: February 18 2006 05:36 EST

in response to Bruce Tate Your assertion that 'Java is in danger' based on its age is just strange, to say the less.



The facts :

FORTRAN : 1954

LISP : 1958

COBOL : 1959

C : 1971

ADA : 1979

C++ : 1983

Perl : 1987

Python : 1991

Ruby : 1993 <--- !!!

PHP : 1995

JAVA : 1995 <---

C# : 2000



Ok. Ruby is two years older than Java. If Java is dying, are you just necrophil to play with Ruby?



Let's face the facts... It took more than 10 years to build a framework (RoR) out of Ruby, while the first usable MVC framework for Java came out around 2000, 6 years before RoR. I found it pretty reactive for a dying body ... Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Arcadius Ahouansou

Posted on: February 18 2006 13:22 EST

in response to lecharny emmanuel Your assertion that 'Java is in danger' based on its age is just strange, to say the less. The facts :FORTRAN : 1954LISP : 1958COBOL : 1959C : 1971ADA : 1979C++ : 1983Perl : 1987Python : 1991Ruby : 1993 <--- !!!PHP : 1995JAVA : 1995 <---C# : 2000Ok. Ruby is two years older than Java. If Java is dying, are you just necrophil to play with Ruby?...

Good points.



I had a look at some RoR tutorials at onlamp.com.

And I must admit that RoR looks very impressing.

So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.



But Java and .Net would remain for real enterprise developers.



Arcadius. Good points.I had a look at some RoR tutorials at onlamp.com.And I must admit that RoR looks very impressing.So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.But Java and .Net would remain for real enterprise developers.Arcadius. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Ilya Sterin

Posted on: February 18 2006 14:45 EST

in response to Arcadius Ahouansou So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.But Java and .Net would remain for real enterprise developers.Arcadius.



Your first comments, I agree with. Majority of developers to move to Ruby will come from these environments.



I don't understand what you mean by Java and .Net would be for "Real" enterprise developers. What's the definition of a real? Using a language (rather platform) that provides most of enterprise service implementations for you? Some might argue that it actualy creates an abstraction layer that makes the developers clueless as to the underlying implementation and though not as intelligent. I disagree with that, but also disagree with the fact that entperprise software has to be created in Java and/or .NET. I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next. Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl). There are thousands more, that I'm not as familiar with.



Enterprise developers, are just that, enterprise developers, classified by knowledge of the problem domain, technologies, implementation, possibly low level implementation, OO methodologies, patterns, etc..., but in no way is someone who knows J2EE and/or .NET be classified as an enterprise developer. That's like calling someone who drives a BMW a race car driver.



Ilya Your first comments, I agree with. Majority of developers to move to Ruby will come from these environments.I don't understand what you mean by Java and .Net would be for "Real" enterprise developers. What's the definition of a real? Using a language (rather platform) that provides most of enterprise service implementations for you? Some might argue that it actualy creates an abstraction layer that makes the developers clueless as to the underlying implementation and though not as intelligent. I disagree with that, but also disagree with the fact that entperprise software has to be created in Java and/or .NET. I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next. Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl). There are thousands more, that I'm not as familiar with.Enterprise developers, are just that, enterprise developers, classified by knowledge of the problem domain, technologies, implementation, possibly low level implementation, OO methodologies, patterns, etc..., but in no way is someone who knows J2EE and/or .NET be classified as an enterprise developer. That's like calling someone who drives a BMW a race car driver.Ilya Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Arcadius Ahouansou

Posted on: February 18 2006 15:45 EST

in response to Ilya Sterin So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.But Java and .Net would remain for real enterprise developers.Arcadius. Your first comments, I agree with. Majority of developers to move to Ruby will come from these environments.I don't understand what you mean by Java and .Net would be for "Real" enterprise developers. What's the definition of a real?

By "real enterprise developers", I meant those who work on big projects for large companies in the financial, healthcare, automotive, telecom, etc industry.

Why don't you ask Google about their heavy use of Python for underlying services? ...

About google...

Google uses Java internally.

If you followed the news, you'd have learnt that, some of the core Java engineers moved from SUN to Google (no need to cite names here). Moereover, there have been an article at sun.com about Google migration from Java 1.4 to 5.0.



Arcadius. By "real enterprise developers", I meant those who work on big projects for large companies in the financial, healthcare, automotive, telecom, etc industry.About google...Google uses Java internally.If you followed the news, you'd have learnt that, some of the core Java engineers moved from SUN to Google (no need to cite names here). Moereover, there have been an article at sun.com about Google migration from Java 1.4 to 5.0.Arcadius. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Ilya Sterin

Posted on: February 18 2006 17:25 EST

in response to Arcadius Ahouansou About google...Google uses Java internally.If you followed the news, you'd have learnt that, some of the core Java engineers moved from SUN to Google (no need to cite names here). Moereover, there have been an article at sun.com about Google migration from Java 1.4 to 5.0.Arcadius.

Oh, I'm sure they do, actually Google is hiring Java, C/C++, Perl, Python, etc... developers. So I'm not discounting their heavy Java use. They leverage each technology for it's best features and not argue over what should be the true "one and only" standard within the enterprise. With various technologies, like CORBA and/or SOAP, you can leverage verious services within the enterprise, without sacrificing agility. I think languages will become less and less predominant, as they have been, and we'll see the usage of many languages and technologies within each company, interoperating with each other, in cross platform/language neutral way.



Again, noone can argue the popularity and usage of other technologies I mentioned, Perl, Python, etc... in large enterprise-level applications. Each has it's own strength and weakness.



Ilya Sterin Oh, I'm sure they do, actually Google is hiring Java, C/C++, Perl, Python, etc... developers. So I'm not discounting their heavy Java use. They leverage each technology for it's best features and not argue over what should be the true "one and only" standard within the enterprise. With various technologies, like CORBA and/or SOAP, you can leverage verious services within the enterprise, without sacrificing agility. I think languages will become less and less predominant, as they have been, and we'll see the usage of many languages and technologies within each company, interoperating with each other, in cross platform/language neutral way.Again, noone can argue the popularity and usage of other technologies I mentioned, Perl, Python, etc... in large enterprise-level applications. Each has it's own strength and weakness.Ilya Sterin Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Cameron Purdy

Posted on: February 18 2006 21:49 EST

in response to Ilya Sterin I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next.

I'm not sure what "enterprise grade" is, but I do know that most software that purports to be "enterprise software" is not "enterprise software".

Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl).

FWIW, all three of those companies do most of their heavy lifting (in apps built in the past five years anyhow) using Java.



Peace,



Cameron Purdy

: Clustered Shared Memory for Java I'm not sure what "enterprise grade" is, but I do know that most software that purports to be "enterprise software" is not "enterprise software".FWIW, all three of those companies do most of their heavy lifting (in apps built in the past five years anyhow) using Java.Peace,Cameron Purdy Tangosol Coherence : Clustered Shared Memory for Java Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Ilya Sterin

Posted on: February 19 2006 19:37 EST

in response to Cameron Purdy I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next. I'm not sure what "enterprise grade" is, but I do know that most software that purports to be "enterprise software" is not "enterprise software".

Well, the definition to enterprise software is very subjective any ways, I was more relating to software that is robust, scalable, extensible, interoperable, etc... Basically most properties that one would consider as "Enterprise Software". There are many of those written in variety of technologies. Yes, Java might enable some of these with it's frameworks/libraries vs. having to write one yourself, but it still doesn't mean that the same (or even better) can't be accomplished in any other general purpose language.



I use Java 90% of the time, I wouldn't use anything else write now at client sites for most of the OLTP systems, but I'm always looking at and learning alternatives. And I will definitely employ RoR if I find a low risk project with a good fit.

Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl). FWIW, all three of those companies do most of their heavy lifting (in apps built in the past five years anyhow) using Java.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Well, I don't know about most, I know (as I mentioned in their post), that they use variety of technologies. And I wouldn't be surprised if they used Java heavily, it would be a great choice on their behalf, but... I know Amazon backend web services are all done in Perl, as well as BT is using Perl for very heavy data intensive tasks, etc..., as well as their Call Management Information system. Again, all I'm trying to say is that there is more than Java out there. I love Java, I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.



Ilya Well, the definition to enterprise software is very subjective any ways, I was more relating to software that is robust, scalable, extensible, interoperable, etc... Basically most properties that one would consider as "Enterprise Software". There are many of those written in variety of technologies. Yes, Java might enable some of these with it's frameworks/libraries vs. having to write one yourself, but it still doesn't mean that the same (or even better) can't be accomplished in any other general purpose language.I use Java 90% of the time, I wouldn't use anything else write now at client sites for most of the OLTP systems, but I'm always looking at and learning alternatives. And I will definitely employ RoR if I find a low risk project with a good fit.Well, I don't know about most, I know (as I mentioned in their post), that they use variety of technologies. And I wouldn't be surprised if they used Java heavily, it would be a great choice on their behalf, but... I know Amazon backend web services are all done in Perl, as well as BT is using Perl for very heavy data intensive tasks, etc..., as well as their Call Management Information system. Again, all I'm trying to say is that there is more than Java out there. I love Java, I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Steve Zara

Posted on: February 20 2006 05:43 EST

in response to Ilya Sterin I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya

Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby?



Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts.



My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java. Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby?Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts.My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Bruce Tate

Posted on: February 20 2006 06:09 EST

in response to Steve Zara I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby? Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts. My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java.

I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages. I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Karl Peterbauer

Posted on: February 20 2006 06:57 EST

in response to Bruce Tate I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.

I think this post is a pretty good indication why Bruce Tate's arguments have come to a dead end: RoR is not designed as lightweight tier sitting on top of some SOA-type architecture. RoR is simply "slapping a web UI around relational databases". I think this post is a pretty good indication why Bruce Tate's arguments have come to a dead end: RoR is not designed as lightweight tier sitting on top of some SOA-type architecture. RoR is simply "slapping a web UI around relational databases". Reply to this Reply to original

Simple is better or complex ? Go to top ] Posted by: Victor C.

Posted on: February 20 2006 09:36 EST

in response to Karl Peterbauer ... "slapping a web UI around relational databases".

Which is more sophisticated? Simple, or Complex.

What say the unwashed masses?



Scales? Maintain? Time to market? Looks better (ex: negative space)?





.V

ps: It be simpler if vendors included Portlets in JEE, otherwise, I have to budget for i... iPlanet (glassfish) or Tomcat and I have to integrate and explain why we are not using MasterPages and WebParts... that are integrated. Otherwise call it an EJB server. There has to be something for non EJB apps. Which is more sophisticated? Simple, or Complex.What say the unwashed masses?Scales? Maintain? Time to market? Looks better (ex: negative space)?.Vps: It be simpler if vendors included Portlets in JEE, otherwise, I have to budget for i... iPlanet (glassfish) or Tomcat and I have to integrate and explain why we are not using MasterPages and WebParts... that are integrated. Otherwise call it an EJB server. There has to be something for non EJB apps. Reply to this Reply to original

Ruby on Rails on top of Component instead of DB Go to top ] Posted by: Paul Beckford

Posted on: February 20 2006 14:01 EST

in response to Karl Brodowsky Even though RoR is designed to be running on top of a database, I do see a perspective of running on top of components communicated to using something like XML-RPC, Corba, Soap or whatever (SOA). In a way the database is nothing else than this, but we don't see it like that, because databases are such an integral part of most applications. I agree. In reality very few "enterprise" components have been produced. When EJB's and J2EE was first launched we were promised distributed enterprise wide components, there was even talk of a market in EJB components. But mostly due to the difficulties in distribution most applications are merely presentation on top of a database. I agree using "SOA" as component glue will merely result in presentation on top of SOAP. Which something like Rails could tackle readily.



IMO Sun lost all ambition when they decided to follow Microsoft down the "SOA" path, whatever happened to JINI?



Conservatism, and trying to out market Microsoft, has lead to what can only be described as technological stagnation.



What surprises me is how everyone is getting so upset because someone dared to mention what many of use have been quitely thinking for a long time.



Paul. I agree. In reality very few "enterprise" components have been produced. When EJB's and J2EE was first launched we were promised distributed enterprise wide components, there was even talk of a market in EJB components. But mostly due to the difficulties in distribution most applications are merely presentation on top of a database. I agree using "SOA" as component glue will merely result in presentation on top of SOAP. Which something like Rails could tackle readily.IMO Sun lost all ambition when they decided to follow Microsoft down the "SOA" path, whatever happened to JINI?Conservatism, and trying to out market Microsoft, has lead to what can only be described as technological stagnation.What surprises me is how everyone is getting so upset because someone dared to mention what many of use have been quitely thinking for a long time.Paul. Reply to this Reply to original

Simple is better or complex ? Go to top ] Posted by: Ilya Sterin

Posted on: February 21 2006 03:44 EST

in response to Victor C. ... "slapping a web UI around relational databases". Which is more sophisticated? Simple, or Complex.What say the unwashed masses?Scales? Maintain? Time to market? Looks better (ex: negative space)?.Vps: It be simpler if vendors included Portlets in JEE, otherwise, I have to budget for i... iPlanet (glassfish) or Tomcat and I have to integrate and explain why we are not using MasterPages and WebParts... that are integrated. Otherwise call it an EJB server. There has to be something for non EJB apps.

What? I'm not trying to be rude, but what are you talking about?



Ilya What? I'm not trying to be rude, but what are you talking about?Ilya Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Steve Zara

Posted on: February 20 2006 07:28 EST

in response to Bruce Tate I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby? Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts. My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java. I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.

Firstly, you are missing the point of what I posted. We were talking about 'the global IT backbone'. By that term I was assuming we meant more than the niche that is web applications or client-side software.



Secondly, simplu disagree. I have, over decades, seen so many projects fail because the latest RAD approaches collapse when there is some 'heavy lifting' required, which in my experience inevitably happens when a project grows above a certain size - when what starts as some lightweight interface over a database or other services grows into something more substantial. I also find it is hard to predict which projects will grow in this fashion.



So, my view is that it is right to use a language that has the performance so that it can be used at all scales of development. I have seen too many projects crash and burn because they didn't. Firstly, you are missing the point of what I posted. We were talking about 'the global IT backbone'. By that term I was assuming we meant more than the niche that is web applications or client-side software.Secondly, simplu disagree. I have, over, seen so many projects fail because the latest RAD approaches collapse when there is some 'heavy lifting' required, which in my experience inevitably happens when a project grows above a certain size - when what starts as some lightweight interface over a database or other services grows into something more substantial. I also find it is hard to predict which projects will grow in this fashion.So, my view is that it is right to use a language that has the performance so that it can be used at all scales of development. I have seen too many projects crash and burn because they didn't. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Paul Beckford

Posted on: February 20 2006 08:57 EST

in response to Steve Zara So, my view is that it is right to use a language that has the performance so that it can be used at all scales of development. I have seen too many projects crash and burn because they didn't.

I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility. Martin Fowler has discussed this in his writings on DSL's and language work benches. Croquet, which I’ve mentioned before is also taking this approach.



In a sense it is an extension of what we are already doing. I would guess that most Java VMs are written in C. So why not use a dynamic domain specific business language to script together Java components? In Croquet they are experimenting with end user scripting using a language called TVML, scripting together Smalltalk objects (components). The Smalltalk objects make use of an underlying C/C++ OpenGL library for rendering. As I said before one cap doesn't necessarily need to fit all.



Paul. I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility. Martin Fowler has discussed this in his writings on DSL's and language work benches. Croquet, which I’ve mentioned before is also taking this approach.In a sense it is an extension of what we are already doing. I would guess that most Java VMs are written in C. So why not use a dynamic domain specific business language to script together Java components? In Croquet they are experimenting with end user scripting using a language called TVML, scripting together Smalltalk objects (components). The Smalltalk objects make use of an underlying C/C++ OpenGL library for rendering. As I said before one cap doesn't necessarily need to fit all.Paul. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Steve Zara

Posted on: February 20 2006 09:30 EST

in response to Paul Beckford I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility.

I know this may sound like an extreme position, but I think it can make sense (well, perhaps not device drivers, but certainly high-performance things like databases). If a language is efficient enough to write such things, you have a guarantee that it will cope with whatever you throw at it. You know that it will run well multi-threaded. You know that it can efficiently handle memory.

So why not use a dynamic domain specific business language to script together Java components?

Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages. I know this may sound like an extreme position, but I think it can make sense (well, perhaps not device drivers, but certainly high-performance things like databases). If a language is efficient enough to write such things, you have a guarantee that it will cope with whatever you throw at it. You know that it will run well multi-threaded. You know that it can efficiently handle memory.Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Paul Beckford

Posted on: February 20 2006 10:22 EST

in response to Steve Zara So why not use a dynamic domain specific business language to script together Java components? Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages.

This is what I meant when I said nothing is certain. I agree that this use to be the case, but times are changing. For example the language workbench implementations Martin Fowler talks about that allow you to seamlessly move the dividing line.



In some situations the dividing line is clearer. Spring makes use of this and provides the ability to "script" together components using XML. So people using a three tier architecture can link together the tiers of their application in XML. Now looking forward we will want to link together enterprise wide components (actually we were promised this with EJB1.0...) rather than just components within a single app. What type of language will we need then? For sure it will need to be dynamic.



Paul. This is what I meant when I said nothing is certain. I agree that this use to be the case, but times are changing. For example the language workbench implementations Martin Fowler talks about that allow you to seamlessly move the dividing line.In some situations the dividing line is clearer. Spring makes use of this and provides the ability to "script" together components using XML. So people using a three tier architecture can link together the tiers of their application in XML. Now looking forward we will want to link together enterprise wide components (actually we were promised this with EJB1.0...) rather than just components within a single app. What type of language will we need then? For sure it will need to be dynamic.Paul. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: David McCoy

Posted on: February 20 2006 11:31 EST

in response to Paul Beckford So why not use a dynamic domain specific business language to script together Java components? Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages. This is what I meant when I said nothing is certain. I agree that this use to be the case, but times are changing. For example the language workbench implementations Martin Fowler talks about that allow you to seamlessly move the dividing line.In some situations the dividing line is clearer. Spring makes use of this and provides the ability to "script" together components using XML. So people using a three tier architecture can link together the tiers of their application in XML. Now looking forward we will want to link together enterprise wide components (actually we were promised this with EJB1.0...) rather than just components within a single app. What type of language will we need then? For sure it will need to be dynamic.Paul.

I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise. I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Paul Beckford

Posted on: February 20 2006 12:04 EST

in response to David McCoy I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise. So why do they call it a bean factory? And why all that AOP style interceptor semantics? XML doesn't look like a scripting language granted, but that is exactly what it is being used for.



Incidently EJB descriptors are used for a similar purpose. In dynamic languages none of this "IoC" is needed. Loose coupling and runtime binding come for free.



Paul. So why do they call it afactory? And why all that AOP style interceptor semantics? XML doesn't look like a scripting language granted, but that is exactly what it is being used for.Incidently EJB descriptors are used for a similar purpose. In dynamic languages none of this "IoC" is needed. Loose coupling and runtime binding come for free.Paul. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: David McCoy

Posted on: February 20 2006 14:12 EST

in response to Paul Beckford I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise. So why do they call it a bean factory? And why all that AOP style interceptor semantics? XML doesn't look like a scripting language granted, but that is exactly what it is being used for.Incidently EJB descriptors are used for a similar purpose. In dynamic languages none of this "IoC" is needed. Loose coupling and runtime binding come for free.Paul.

They don't call it scripting. AOP definitely has nothing to do with scripting.



No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails. They don't call it scripting. AOP definitely has nothing to do with scripting.No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails. Reply to this Reply to original

Ruby will be dead before Java... Go to top ] Posted by: Frank Bank

Posted on: February 20 2006 14:40 EST

in response to Paul Beckford No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.No they don't call it scripting... No offence but it doesn't seem that you are capable of opening your mind and thinking for yourself :^)

The wife and I were watching Ellen DeGeneres standup on TV earlier this morning and she was talking about "just kidding".



"I hope you didn't pay for that haircut....just kidding"



"I don't think you know the meaning of just kidding or we'd both be laughing"



"No offense, but..." The wife and I were watching Ellen DeGeneres standup on TV earlier this morning and she was talking about "just kidding"."I hope you didn't pay for that haircut....just kidding""I don't think you know the meaning of just kidding or we'd both be laughing""No offense, but..." Reply to this Reply to original

I'm out Go to top ] Posted by: Paul Beckford

Posted on: February 20 2006 15:09 EST

in response to Paul Beckford Hi All,



I've partcipated in all three "beyond Java" discussions on TSS. And they've all gone the same way. Now in response to the last "blind ignorant" comment - I could of dug up papers on IoC such as the PicoContainer work at ThoughtWorks and evidence of the link between scripting languages and IoC, but why bother? Why educate the wilfully ignorant?



I think the main issues here are not technical, but have to do with people and their comfort zones.



So in conclusion here is what I've learnt:



1. If you want to use a dynamic language for Agile development anytime soon, forget the JVM or the CLR - use a native dynamic language along with a native VM.



2. Sun gave up on the idea of technical excellence long ago, and are busy trying to beat Microsoft at it's own game.



3. The Java community are admiring their own navels and aren't interested in ideas from outside the Java world.



4. Because of 3. the "next big thing" will not come from Java



5. The "next big thing" will not come from the business sector either, due to their conservatism and the entrenchment of Java/J2EE and .NET (which are pretty much the same thing).



6. Look to other sectors like Academia for true innovation - just like the creation of the Internet and the World Wide Web in the past. In this regard Croquet looks promising. Eventually the business sector will catch up... they always do.



Peace and Out



Paul. Reply to this Reply to original

I'm out Go to top ] Posted by: David McCoy

Posted on: February 20 2006 22:14 EST

in response to Paul Beckford Here are some examples of what's been done by us in Spring

I've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.



In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.



By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.



Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.



The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.



Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.



So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.



Foolishness.



I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use. Reply to this Reply to original

I'm out Go to top ] Posted by: Paul Beckford

Posted on: February 21 2006 00:43 EST

in response to David McCoy Here are some examples of what's been done by us in SpringI've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.Foolishness.I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use. I said I wasn't going to do this but a Single google search and what do I find: NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,

Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.

Straight on the PcoContainer website's front page:



http://www.picocontainer.org/



This is what I mean by closed minds. A massive rant on "what I am doing with Spring. And he hasn't even taken the time to look at the next most popuplar IoC framework in Java - never mind looking at other languages - never mnd realise that IoC containers are just not needed in dynamic languages etc...



This is my point. Blind allegiance to what some one else as correctly described as a proprietary technology (Java).



Last person I heard ranting like this was a Microsoft VB geek. The truth is that Sun and Microsoft are looking pretty similar these days.



Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.



Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.



Paul. I said I wasn't going to do this but a Single google search and what do I find:Straight on the PcoContainer website's front page:This is what I mean by. A massive rant on "whatam doing with Spring. And he hasn't even taken the time to look at the next most popuplar IoC framework in Java - never mind looking at other languages - never mnd realise that IoC containers are just not needed in dynamic languages etc...This is my point. Blind allegiance to what some one else as correctly described as a proprietary technology (Java).Last person I heard ranting like this was a Microsoft VB geek. The truth is that Sun and Microsoft are looking pretty similar these days.Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.Paul. Reply to this Reply to original

I'm out Go to top ] Posted by: Bruce Tate

Posted on: February 21 2006 03:09 EST

in response to Paul Beckford Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave.



So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche. Reply to this Reply to original

I'm out Go to top ] Posted by: Jason Carreira

Posted on: February 21 2006 10:32 EST

in response to Bruce Tate Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.

Bruce,



This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases.



Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably. Bruce,This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases.Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably. Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Andreas Andreakis

Posted on: February 21 2006 10:58 EST

in response to Jason Carreira Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche. Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.



I understand full loyality to Java from the following people:

1) You work for SUN

2) You get paid from SUN to defend Java´s pride

3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.

4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.



If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)



cheers,

Andreas



Like said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted. I understand full loyality to Java from the following people:1) You work for SUN2) You get paid from SUN to defend Java´s pride3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)cheers,AndreasLike said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted. Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Jason Carreira

Posted on: February 21 2006 12:25 EST

in response to Andreas Andreakis Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably. I understand full loyality to Java from the following people:1) You work for SUN2) You get paid from SUN to defend Java´s pride3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)cheers,AndreasLike said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted.

Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy? Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy? Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: David McCoy

Posted on: February 21 2006 12:35 EST

in response to Jason Carreira Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably. I understand full loyality to Java from the following people:1) You work for SUN2) You get paid from SUN to defend Java´s pride3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)cheers,AndreasLike said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted. Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?

Apparently, if you don't agree that ROR is the next, best, cutting, edge thing, you are tacitly a fan-boy.



However, if you agree with Bruce, then you are admitted to the cutting edge club. ;-) Apparently, if you don't agree that ROR is the next, best, cutting, edge thing, you are tacitly a fan-boy.However, if you agree with Bruce, then you are admitted to the cutting edge club. ;-) Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Andreas Andreakis

Posted on: February 21 2006 12:38 EST

in response to Jason Carreira

Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps?

I agree that my response, which you quoted was a little bit nasty, sorry for that :)



Read my forther responses on that, there I clearify what I mean.

Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?

I´ll be nasty again, because if you dont consider alternativ approaches you are a "fan-boy". Don´t get me wrong, I really like working with Java - in the correct usecases.



In many cases java is not #1 choise. Guess which language is mostly used for dynamic Pages out there.

Tip 1) it is not Java

Tip 2) it starts with "P" and ends with "P"



cheers,

Andreas My response was based on this sentence of yours:I agree that my response, which you quoted was a little bit nasty, sorry for that :)Read my forther responses on that, there I clearify what I mean.I´ll be nasty again, because if you dont consider alternativ approaches you are a "fan-boy". Don´t get me wrong, I really like working with Java - in the correct usecases.In many cases java is not #1 choise. Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Steve Zara

Posted on: February 21 2006 12:46 EST

in response to Andreas Andreakis Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas I forgot to mention, that it is #1, because it is really simple to use.

Not in my experience; not for substantial projects. After occasionally struggling with obscure PHP code (with no tools for compile-time checking or refactoring), and trying to deal with conflicts between different versions of Apache and PHP, 'easy' is not a term I would use.



It is #1 partly because it is easy to get started with, and easy for novices to use, and very easy for companies to host. Not in my experience; not for substantial projects. After occasionally struggling with obscure PHP code (with no tools for compile-time checking or refactoring), and trying to deal with conflicts between different versions of Apache and PHP, 'easy' is not a term I would use.It is #1 partly because it is easy to get started with, and easy for novices to use, and very easy for companies to host. Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Andreas Andreakis

Posted on: February 21 2006 13:05 EST

in response to Steve Zara Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas I forgot to mention, that it is #1, because it is really simple to use. Not in my experience; not for substantial projects. After occasionally struggling with obscure PHP code (with no tools for compile-time checking or refactoring), and trying to deal with conflicts between different versions of Apache and PHP, 'easy' is not a term I would use.It is #1 partly because it is easy to get started with, and easy for novices to use, and very easy for companies to host.

Whether it is part of your experience or not PHP is #1 in dynamic webabbs.



This this actually not a matter of experience or personal opinion. This is a matter of fact.



cheers,

Andreas Whether it is part of your experience or not PHP is #1 in dynamic webabbs.This this actually not a matter of experience or personal opinion. This is a matter of fact.cheers,Andreas Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Jason Carreira

Posted on: February 21 2006 12:44 EST

in response to Andreas Andreakis My response was based on this sentence of yours: Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? I agree that my response, which you quoted was a little bit nasty, sorry for that :)Read my forther responses on that, there I clearify what I mean. Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy? I´ll be nasty again, because if you dont consider alternativ approaches you are a "fan-boy". Don´t get me wrong, I really like working with Java - in the correct usecases. In many cases java is not #1 choise. Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas

And how maintainable are those sites? If I need to add integration with other organizations via asynchronous messaging, how do I do it?



There is definitely a disconnect here if you're going to invoke PHP. Sorry, I don't build bulletin boards or blogs, although the best product I've ever seen in that space (Confluence from Atlassian) is written in Java (and even uses WebWork :-) ). And how maintainable are those sites? If I need to add integration with other organizations via asynchronous messaging, how do I do it?There is definitely a disconnect here if you're going to invoke PHP. Sorry, I don't build bulletin boards or blogs, although the best product I've ever seen in that space (Confluence from Atlassian) is written in Java (and even uses WebWork :-) ). Reply to this Reply to original

Don´t blame - learn !!! Go to top ] Posted by: Andreas Andreakis

Posted on: February 21 2006 13:02 EST

in response to Jason Carreira And how maintainable are those sites? If I need to add integration with other organizations via asynchronous messaging, how do I do it?There is definitely a disconnect here if you're going to invoke PHP. Sorry, I don't build bulletin boards or blogs, although the best product I've ever seen in that space (Confluence from Atlassian) is written in Java (and even uses WebWork :-) ).

Just to get to uptodate: PHP is #4 @ Sourceforge about 13.000 projects. Java has 18.000.



There are also messaging projects available, but I cant tell you more on that. Also if you think they dont meet your needs go for Java, PHP is your friend in specific cases not your enemie.



Also there a dozens of complex PHP app´s out there. You can have a look yourself. Just to get to uptodate: PHP is #4 @ Sourceforge about 13.000 projects. Java has 18.000.There are also messaging projects available, but I cant tell you more on that. Also if you think they dont meet your needs go for Java, PHP is your friend in specific cases not your enemie.Also there a dozens of complex PHP app´s out there. You can have a look yourself. Reply to this Reply to original

Business A-B-C Go to top ] Posted by: Andreas Andreakis

Posted on: February 21 2006 11:24 EST

in response to Jason Carreira Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche. Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.



Business is driven by requirements, not by illusions.



You will hardly find customers, who are ready to pay money for the case their webapp "would" have visitors like Amazon / ebay. If that is about to happen, you will be reconsulted to upgrade the system - be happy. If someones is about to buy a car, you will never be able to sell him a space shuttle, for the case he would like to fly to the Moon. Remeber: go for simplicity, the simplest solution is the b