Tim Bray: Java is less scalable than PHP

Home

News: Tim Bray: Java is less scalable than PHP

  1. Tim Bray: Java is less scalable than PHP (165 messages)

    The thinkphp.de blog posted "Keynote of Tim Bray: Some Interesting Comparison between PHP, Rails, and Java", with the following:
    Tim Bray (Director of Web Technologies at Sun Microsystems - I.L.), who - among many other things - co-edited the XML 1.0 and XML namespace definitions, was invited to the International PHP Conference to give a keynote about "How to combine PHP technology with Java based on Enterprise Systems". I had the pleasure to talk with him and I like his spirit. During his keynote, he presented some very interesting comparison between the popular development "frameworks" PHP, Ruby on Rails (RoR, Rails) and Java.
    That page also contains links to the presentation slides on Tim's site. According to him, enterprise systems built on Java are less scalable than PHP-based systems and less maintainable than Ruby-on-Rails-based ones. Also Java-based development is much slower than both PHP and RoR. The only outlined benefit of Java platform is the reach of the development toolkit. Unfortunately, neither slides nor post contained references on how such metrics were measured. It's surprising that Java falls behind - on the slides - in scalability and maintainability to PHP (for scalability) and Rails (in maintainability). It'd be great to see more data on this.

    Threaded Messages (165)

  2. Begin flamewar![ Go to top ]

    Ah, I can foresee this is the beginning of yet another flamewar, based on the utterly arbitrary scriblings of a random attention-seeker..
  3. Re: Begin flamewar![ Go to top ]

    How do you figure that the Director of Web Technologies at Sun Microsystems is a random attention-seeker on this topic?
  4. Metrics with PHP, Ruby and Java[ Go to top ]

    Smart, mature, motivated people with good communication skills working with language X are 1000% more likely to succeed regardless of the language.
  5. How many time before Sun Microsystems - a.k.a the father of Java - declare "Java is no more appropriate for SOA" in other terms.. "Java is Dead, and it's time to introduce the future of programing language : ...xyz" After all these efforts and no $$$$ ... might be the good time ! ideas...?? share your thougts... Stephan
  6. The dangers of arbitrary-ness[ Go to top ]

    If we assume that the charts in the post are percentages and the graphs only use 100%, 75% and 50% (based on my cock-eyed view) then the average scores for the languages are: PHP: 56.25% RoR: 68.75% Java 68.75% So although Java would appear to lose out in some categories to PHP and RoR overall it compares pretty well when a wholistic view is taken. Of course the main bug-bear of the post (as pointed out) is that without any metrics to support the bar-charts they become only somebody's opinion. An opinion from a well respected individual but an opinion all the same. And as we all know, to err is human.
  7. Pretty shallow analysis by Tim. Very disappointing. What about: 1) Security. Tell compliance that it's not important. 2) Operations support. Not too many op guys want to fire up an IDE or browse through code to get runtime metrics. 3) Integration. Outside of WS-* and Rest SOA styles, there are other significant integration challenges that neither PHP or Ruby can tackle. 4) Scalability. Didn't buy his scalability arguments. Like the poster said, it would be nice to see some quantitative metrics to support this claim. It is disturbing that another engineer in the Sun family is downing Java. With the rumours of Open Sourcing, (ie "we're done, you guys deal with it"), the JRuby investments and presentations by internal thought leaders like this, maybe Java(the language, not the VM) is on it's last breath. I hope not.
  8. Pretty shallow analysis by Tim. Very disappointing.

    What about:

    1) Security. Tell compliance that it's not important.

    2) Operations support. Not too many op guys want to fire up an IDE or browse through code to get runtime metrics.

    3) Integration. Outside of WS-* and Rest SOA styles, there are other significant integration challenges that neither PHP or Ruby can tackle.

    4) Scalability. Didn't buy his scalability arguments. Like the poster said, it would be nice to see some quantitative metrics to support this claim.

    It is disturbing that another engineer in the Sun family is downing Java. With the rumours of Open Sourcing, (ie "we're done, you guys deal with it"), the JRuby investments and presentations by internal thought leaders like this, maybe Java(the language, not the VM) is on it's last breath. I hope not.
    Hi, I agree, we could do with a lot more context. What type of web app does Tim have in mind? What size team? What develop period? How much integration? What methodology? etc. Like always TSS has gone for the sensational headline. I would have liked to have been at the presentation, to hear what Tim had to say. If you go through the presentation, there is a lot more than a language comparision. IMO the most important comparison in the presentation is between REST and SOA. Choosing REST over SOA would have a significant impact on all the indicators mentioned above IMO. Personally, coming from being a J2EE champion back in 1997, my opinion now is that Java, J2EE and the Application Server container approach has been over hyped and over sold. Having used Ruby and RoR, I would not select Java for the average CRUD web application by choice. And my figures for productivity improvements would make these out of context charts look conservative. I would only consider Java for the most complex of EAI tasks, and even then, only because the required integration libraries are likely to be available just for Java. A sensible language comparison would be useful, along with what I believe to be an equally important issue, a sensible comparison of WS-* versus REST. BTW, It is funny that the people who imediately jump to Java's defense have never tried any of the alternatives, like PHP or RoR. We all need to keep an open mind. Paul.
  9. BTW, It is funny that the people who imediately jump to Java's defense have never tried any of the alternatives, like PHP or RoR.....
    because they don't want to learn it
  10. Ruby IDE[ Go to top ]

    There's not even a good IDE for ruby.
    Radrails is looking good. It is an Eclipse RPC application. Steve Punte Test Lens
  11. is PHP an alternative?[ Go to top ]

    i know PHP and it's quite easy to use but it's unusable for very large mission critical enterprise applications. so it's no alternative for me.
  12. Having used Ruby and RoR, I would not select Java for the average CRUD web application by choice.
    To which Java stack(s) (including toolsets) are you comparing RoR? Java is a language, set of standard libraries, and a virtual machine. Kind of like Ruby. RoR is a framework.
  13. Having used Ruby and RoR, I would not select Java for the average CRUD web application by choice.


    To which Java stack(s) (including toolsets) are you comparing RoR? Java is a language, set of standard libraries, and a virtual machine. Kind of like Ruby. RoR is a framework.
    Hi Erik, Yes, I know. Any comparison at this level is going to be pretty imprecise. I've used Struts, Webwork and a couple home grown Web frameworks in Java. I've used Pico Container and Spring, I've also used EJB's including Entity beans with Weblogic Application Server and Websphere and I've used JDBC and Hibernate. And of course various permitations of all of the above. As for tools, I've used everything form vi and x-emacs with JDE to Eclipse. For the "standard" web app (what ever that is, and obviously standard will very from one person's experience to the next), I've found that RoR is considerably more productive then any combination of the above. This is just one qualitative data point. BTW, I have a lot of respect for Tim Bray, and I'm sure that the narrative that went with the slides provided a lot more context. Like I said, it would be interesting to hear what Tim had to say first hand. Paul.
  14. For the "standard" web app (what ever that is, and obviously standard will very from one person's experience to the next), I've found that RoR is considerably more productive then any combination of the above.
    Well, if there is no singe definition of a "standard" web app, then no such claim about productivity is possible (one can't make a claim about something one can't define). Let me give an example of Java productivity. I have been working on a substantial web application, but needed to do some refactoring as a result of changes in the data model. Locating all the uses of classes, methods was trivial in my IDE. Subsequent refactoring was easy too. In a very short time the new data model was coded, and with a few lines of configuration change the updated application was ready for use on any of a range of different databases. In a recent blog entry (http://www.tbray.org/ongoing/When/200x/2006/09/29/Dynamic-IDE) Tim Bray has been discussing how highly dynamic languages like Ruby might try and gain similar refactoring abilities. The fact is, they don't yet. Until they do, they will be less productive if you have to manage large codebases. So, in this respect, Java is certainly more productive and scalable than PHP, or Ruby.
    I have a lot of respect for Tim Bray, and I'm sure that the narrative that went with the slides provided a lot more context.
    He is certainly someone who deserves respect, however I was rather underwhelmed by some recent comments he made about JRuby and Groovy, which seemed, at least to me, that he was not up-to-date with some things. (Why certain people at Sun seem to have a 'blind spot' regarding Groovy and frameworks that approach the productivity of Rails, like Grails, is a puzzle to me).
  15. For the "standard" web app (what ever that is, and obviously standard will very from one person's experience to the next), I've found that RoR is considerably more productive then any combination of the above.


    Well, if there is no singe definition of a "standard" web app, then no such claim about productivity is possible (one can't make a claim about something one can't define).
    Not true. I said that my perception is just a single qualitative data point. People use qualitative data all the time as the basis for decision making. Ask politicians and opinion polsters, they'll tell you all about it. Paul.
  16. For the "standard" web app (what ever that is, and obviously standard will very from one person's experience to the next), I've found that RoR is considerably more productive then any combination of the above.


    Well, if there is no singe definition of a "standard" web app, then no such claim about productivity is possible (one can't make a claim about something one can't define).


    Not true. I said that my perception is just a single qualitative data point. People use qualitative data all the time as the basis for decision making. Ask politicians and opinion polsters, they'll tell you all about it.

    Paul.
    I see what you are saying, but I hope that when we are talking about productivity, we are talking about something more than just opinion and politics. I don't think we would be debating this so fiercely if productivity was purely a qualitative matter - poor choices can be expensive.
  17. For the "standard" web app (what ever that is, and obviously standard will very from one person's experience to the next), I've found that RoR is considerably more productive then any combination of the above.


    Well, if there is no singe definition of a "standard" web app, then no such claim about productivity is possible (one can't make a claim about something one can't define).


    Not true. I said that my perception is just a single qualitative data point. People use qualitative data all the time as the basis for decision making. Ask politicians and opinion polsters, they'll tell you all about it.

    Paul.


    I see what you are saying, but I hope that when we are talking about productivity, we are talking about something more than just opinion and politics. I don't think we would be debating this so fiercely if productivity was purely a qualitative matter - poor choices can be expensive.
    You missed my point. I've tried both, this is my experience report. It is just one data point - take it or leave it. Paul.
  18. Personally, coming from being a J2EE champion back in 1997, my opinion now is that Java, J2EE and the Application Server container approach has been over hyped and over sold.

    Having used Ruby and RoR, I would not select Java for the average CRUD web application by choice. And my figures for productivity improvements would make these out of context charts look conservative. I would only consider Java for the most complex of EAI tasks, and even then, only because the required integration libraries are likely to be available just for Java.
    J2EE is dead. The heavyweight app server container is dead. The state of the art in java is better represented by tools like hibernate, spring for dependency injection, webwork/struts 2 or spring MVC for the webapp. EE java has adopting these principle wholesale. If you are comparing RoR to java based on J2EE, you're comparison is 3 years out of date (so go back to what RoR was 3 years ago! for an apples to apples comparison). I've tried RoR orm. It has some nice features. So does hibernate. All in all, I prefer hibernate3 with DAO generation. It doesn't riddle me with assumptions. With proper use of hibernate-tools, I do not think the productivity gain vs RoR is significant. I don't write DAO's any more, and I actually prefer hibernate's query by example capabilities over rails use of late binding methods. With ruby, you are kidding yourself if you think it's suite spot includes many EAI tasks. Ruby has no XA capabilities, poor threading, poor security, pathetic messaging capabilities and it's SOAP stack is not very scalable or robust. There's no WS-RM, for example, nor many of the WS-* standards. Ruby is extremely slow (and likely to remain so), so if you need to scale anything up to high data throughput you going to have some explaining to do. Ruby is a great tool for quickly solving problems in the simplest 1/3 of the standard corproate IT problem space. It' s probably the best in that space right now. It's not as far ahead as people tout it to be and the gap is shrinking, not growing.

    BTW, It is funny that the people who imediately jump to Java's defense have never tried any of the alternatives, like PHP or RoR. We all need to keep an open mind.
    That cuts both ways. 80% of people never look around at other tools besides what they are comforable with. Good programmers do. I recommend that every java programmer learn RoR and write an app with it. Then grab somebody elses app and try to add a feature. Then think about how you would use it at work. There are several good ideas in rails. There are also many explicit assumpions ("rails is opinionated software"). There are many enterprise features that are missing from rails. One big problem with rails is that there is no language spec. If Matz goes loco (like Larry Wall did with perl6/parrot) then ruby will stagnate. Open standards matter. They are more important than open source (which by the way java will by by christmas -- most likely GPL).
  19. J2EE is dead. The heavyweight app server container is dead. The state of the art in java is better represented by tools like hibernate, spring for dependency injection, webwork/struts 2 or spring MVC for the webapp.
    I think you mean EJB when you say J2EE. Considering that what you outline very likely will be using JSP and servlets. Maybe we could even say EJB pre-V3 since V3 entity beans is said to be very similar to Hibernate.
  20. It is disturbing that another engineer in the Sun family is downing Java.
    Be glad that Sun, as an organization, is enlightened enough to allow and encourage individual employees to voice their opinions. I don't see this kind of openness from IBM (believe me I've tried) or Microsoft (unless a secret internal memo is leaked). There are lots of companies out there whose employees doggedly recite the company line in the face of all evidence to the contrary. I'll choose to applaud Sun for *not* being one of them. And, I hope Tim continues to post despite having his opinion twisted into flame bait.
  21. Hmmm...[ Go to top ]

    PHP probably is more scalable - I'd agree with that. On a 1-10 scale I'd say java scales as a 7.5 and PHP as a 9 and ruby as a 4. PHP's resource consumption is quite low, and hosting providers have tuned the hell out of it for over many years in large traffic environments. PHP's problem is that it is horribly unmaintainable. Like hell do I want to even look at your PHP code! It also lacks enterprise features. It's one thing to write gallery or a forum, quite another to write a banking app or the like. I dispute RoR being more maintainable than java. There's not even a good IDE for ruby. The ruby syntax can have a lot of perl-isms can make it difficult to read (it's way better than perl, but it's still influenced by it). It's more maintainable than PHP, but it has a long way to go to catch java. My call for maintainability: java 8, ruby 6, php 2.5. It's not clear to me that ruby is as well suited to mass use of 3rd party libraries as java is. It's harder to use code you aren't source level familiar with in ruby, because dynamic typing, mixins, duck typing, and late method bind all mean you have to think a little more to use somebody else's code. I'm not saying it's impossible just ever so slightly more complicated. Java gives me "the priviledge of ignorance" for 3rd party code a lot more in terms of the mechanics of calling an API. I don't know how a language espousing the "princple of least surprise" can allow the bahavior capabilities of my objects and classes to depends on its runtime history. I don't want to have to care about such things to use code I didn't write. The valid methods should not depend on runtime state! I don't want my code to be another form of data. Been there, do that with lisp. No thanks -- it's not maintainable. I think Rails lets you develop simple webapps very quickly by making many assumptions about what your are trying to do. Rails is "opinionated software", by design. In particular, rails depends heavily on the fact that it is the only writer of data to the database. It's scalability is highly unproven, and not likely to be in the ballpark of java or PHP for many years. I think it's a lot more likely that java frameworks will incorporate the high productivity features of rails before rails can incorporate the enterprise-grade features of java, or the scalability features of PHP and Java. In fact, it's a common misconception that rails had "code for convention" before java. Maven1 was doing this years ago. Rails improved on it, true, by Maven2 actually is pretty polished. Where rails innovated was the use of a domain specific language combined with code by convention. The trade to a dynamic syntax is NOT revolutionary: python has not been stealing converts from java. To whatever extent this is valuable though, groovy will (someday) add it to the jvm in a much more seamless way than JRuby ever can. In summary, rumors of java's imminent demise are greatly exagerated and underestimate the resourcefulness of the java community, which is extremely large, talented, and well funded.
  22. Re: Hmmm...[ Go to top ]

    PHP probably is more scalable - I'd agree with that. On a 1-10 scale I'd say java scales as a 7.5 and PHP as a 9 and ruby as a 4. PHP's resource consumption is quite low, and hosting providers have tuned the hell out of it for over many years in large traffic environments. PHP's problem is that it is horribly unmaintainable.
    Well, that leads us to rethink the comparison. What apps are being compared? When we say less scalable, what does that mean? A simple dynamic script consumes less processing power than a servlet? Tim's been loosing it lately, I actually never found him very interesting. Basically I think we can't due real scalability comparisons without having two large enterprise applications that due the same thing written in Java and PHP. I wonder how many PHP apps banks are writing these days. Ilya Like hell do I want to even look at your PHP code! It also lacks enterprise features. It's one thing to write gallery or a forum, quite another to write a banking app or the like.

    I dispute RoR being more maintainable than java. There's not even a good IDE for ruby. The ruby syntax can have a lot of perl-isms can make it difficult to read (it's way better than perl, but it's still influenced by it). It's more maintainable than PHP, but it has a long way to go to catch java. My call for maintainability: java 8, ruby 6, php 2.5.

    It's not clear to me that ruby is as well suited to mass use of 3rd party libraries as java is. It's harder to use code you aren't source level familiar with in ruby, because dynamic typing, mixins, duck typing, and late method bind all mean you have to think a little more to use somebody else's code. I'm not saying it's impossible just ever so slightly more complicated.

    Java gives me "the priviledge of ignorance" for 3rd party code a lot more in terms of the mechanics of calling an API. I don't know how a language espousing the "princple of least surprise" can allow the bahavior capabilities of my objects and classes to depends on its runtime history. I don't want to have to care about such things to use code I didn't write. The valid methods should not depend on runtime state! I don't want my code to be another form of data. Been there, do that with lisp. No thanks -- it's not maintainable.

    I think Rails lets you develop simple webapps very quickly by making many assumptions about what your are trying to do. Rails is "opinionated software", by design. In particular, rails depends heavily on the fact that it is the only writer of data to the database. It's scalability is highly unproven, and not likely to be in the ballpark of java or PHP for many years.

    I think it's a lot more likely that java frameworks will incorporate the high productivity features of rails before rails can incorporate the enterprise-grade features of java, or the scalability features of PHP and Java.

    In fact, it's a common misconception that rails had "code for convention" before java. Maven1 was doing this years ago. Rails improved on it, true, by Maven2 actually is pretty polished. Where rails innovated was the use of a domain specific language combined with code by convention. The trade to a dynamic syntax is NOT revolutionary: python has not been stealing converts from java. To whatever extent this is valuable though, groovy will (someday) add it to the jvm in a much more seamless way than JRuby ever can.

    In summary, rumors of java's imminent demise are greatly exagerated and underestimate the resourcefulness of the java community, which is extremely large, talented, and well funded.
  23. Re: Hmmm...[ Go to top ]

    PHP probably is more scalable - I'd agree with that. On a 1-10 scale I'd say java scales as a 7.5 and PHP as a 9 and ruby as a 4. PHP's resource consumption is quite low, and hosting providers have tuned the hell out of it for over many years in large traffic environments.
    Actually you are not talking about scalability here. Low ressource usage and scalability are not the same. Actually it is usually impossible to do both.
  24. Re: Hmmm...[ Go to top ]

    PHP probably is more scalable - I'd agree with that. On a 1-10 scale I'd say java scales as a 7.5 and PHP as a 9 and ruby as a 4. PHP's resource consumption is quite low, and hosting providers have tuned the hell out of it for over many years in large traffic environments.


    Actually you are not talking about scalability here.

    Low ressource usage and scalability are not the same.

    Actually it is usually impossible to do both.
    Actually, I used the wrong wording. In absolute terms, PHP is actually pretty darn slow, but when you are scaling you don't care as you are measureing relative speed: double the hardware and expect double the performance. The perception of load due to the language when you are trying to scale is a reaction of the nonlinearity in scaling. So when I say PHP's resource consumption is low, I mean the loss from linear scaling do to language overhead is low.
  25. Re: Hmmm...[ Go to top ]

    So when I say PHP's resource consumption is low, I mean the loss from linear scaling do to language overhead is low.
    Doing what ? Shared nothing like what Tim Bray are talking about ?
  26. Php Vs Java Vs RoR[ Go to top ]

    Well, i agree that Php and RoR have an edge over Java based websites when it comes to smaller websites. But still when it comes to bigger webapplications i guess still Java is way ahead. Specially with Portal technology provides Java with an edge over these languages. Vikramark http://portlets-jsr168.blogspot.com/2006/11/is-portal-going-to-keep-java-float.html
  27. Re: Php Vs Java Vs RoR[ Go to top ]

    Well, i agree that Php and RoR have an edge over Java based websites when it comes to smaller websites. But still when it comes to bigger webapplications i guess still Java is way ahead.
    I find it difficult to see any technical reason why PHP can not support a site with extremely many vistors doing simple stuff. Indeed you can find big sites using PHP on the net. The real difference is what they do. Google/Yahoo type sites may have more hits than Amazon/Ebay type sites, but the last category has some much more demanding requirements for the backend.
  28. Re: Php Vs Java Vs RoR[ Go to top ]

    Well, i agree that Php and RoR have an edge over Java based websites when it comes to smaller websites. But still when it comes to bigger webapplications i guess still Java is way ahead.


    I find it difficult to see any technical reason why
    PHP can not support a site with extremely many vistors
    doing simple stuff.

    Indeed you can find big sites using PHP on the net.

    The real difference is what they do. Google/Yahoo type
    sites may have more hits than Amazon/Ebay type sites, but
    the last category has some much more demanding requirements
    for the backend.
    Bigger sites and more traffic is not necessarily linear with scalability requirements. Static web pages are the most scalable in that case. It's all about the application domain and services, complexity of the business process, etc... Ilya
  29. Re: Php Vs Java Vs RoR[ Go to top ]

    Bigger sites and more traffic is not necessarily linear with scalability requirements. Static web pages are the most scalable in that case.

    It's all about the application domain and services, complexity of the business process, etc...

    Ilya
    That was what I was trying to explain.
  30. Well, he was giving a presentation to a PHP conference, what did you expect? Still, I find his results a bit disappointing, because overall, I enjoy reading his blog and I usually share a lot of his opinions. Let's start with the Scaling aspect. There are a few big Web sites that use PHP out there, but they are still nowhere near high-traffic Web sites that Java powers. For these, you need a decent amount of clustering and load-balancing technologies, of which PHP offers none. Having said that, let's keep in mind that Tim is speaking in terms of Web applications only, which stacks the deck in favor of PHP somewhat. Still, web-server based scaling has limits, and when you hit these limits with PHP, you're stuck, while Java will still be able to provide you with more avenues to explore in order to scale your application to the next level. The Maintainability aspect is also very disingenuous. RoR more maintainable? For whom? I claim: only very good developers. Again, no question that RoR is more elegant, more modern, more sophisticated and, in many ways, generations ahead of what PHP can do. Still, I claim that for 95% of Web developers out there, maintaining a RoR application will be harder than patching a few PHP files. Which is one of the reasons why I still stand behind my claim that Ruby on Rails will never become mainstream. The "Development Speed" and "Development Tools" graphs look reasonable to me, although they should be considered more qualitative than quantitative. -- Cedric TestNG
  31. Which is one of the reasons why I still stand behind my claim that Ruby on Rails will never become mainstream.
    Excellent blog. Good point about Lisp and Smalltalk people. I'm finally forcing myself to actually learn Lisp, and I have to say I can start feeling those impulses.
  32. Well, he was giving a presentation to a PHP conference, what did you expect?

    Still, I find his results a bit disappointing, because overall, I enjoy reading his blog and I usually share a lot of his opinions.

    Let's start with the Scaling aspect. There are a few big Web sites that use PHP out there, but they are still nowhere near high-traffic Web sites that Java powers. For these, you need a decent amount of clustering and load-balancing technologies, of which PHP offers none.

    Having said that, let's keep in mind that Tim is speaking in terms of Web applications only, which stacks the deck in favor of PHP somewhat. Still, web-server based scaling has limits, and when you hit these limits with PHP, you're stuck, while Java will still be able to provide you with more avenues to explore in order to scale your application to the next level.

    The Maintainability aspect is also very disingenuous. RoR more maintainable? For whom? I claim: only very good developers. Again, no question that RoR is more elegant, more modern, more sophisticated and, in many ways, generations ahead of what PHP can do. Still, I claim that for 95% of Web developers out there, maintaining a RoR application will be harder than patching a few PHP files. Which is one of the reasons why I still stand behind my claim that Ruby on Rails will never become mainstream.

    The "Development Speed" and "Development Tools" graphs look reasonable to me, although they should be considered more qualitative than quantitative.

    --
    Cedric
    TestNG
    Cedric, I read your blog entry. And I must admit it left me fuming. How on earth can we call ourselves a profession when we openly concede that yes Smalltalk and Lisp and even Ruby are great, but are too hard for the average Java joe to comprehend? No wonder vendors have been leading us all by the nose for the last 30 years+. One lesson I've learnt in life is that you get what you settle for. Treat people like monkeys and you'll get monkeys. The simple truth is that programming is an intellectual exercise. It always has been and it always will be. It is not like digging a whole in the ground. The days of the 20-30 man dev team, where most of the team can just about spell Java is over. It has been shown time and time again, that a few programmers with the right intellect and skills will always out perform an army of morons. I would understand if getting people to a decent level of competence was a big deal, but it isn't. Most of the theory behind good software engineering is well known and well documented, and in my experience it is easier (and cheaper) to show people how to build systems right - then to leave them building paper castles into the sky that will collapse the moment there is a stiff breeze. So please stop selling the development community short. The majority are more intelligent then you think. IMO this the developers will never get it attitude is propagated by vendors, who want to keep us dumb and subservient so that they can sell us over hyped and over complex products. Promising to solve all our problems, because naturally we are all too dumb to solve our problems ourselves! Speak for yourself - The majority of developers and customers are tired of playing that game, and are taking their destinies into their own hands. All the developers I know, are more than capable of comprehending Lisp, Smalltalk, Ruby or anything else you want to throw at them - once they've been shown! Paul.
  33. FYI, Tim posted more detail on his blog. -- Cedric
  34. Hi Paul,
    I read your blog entry. And I must admit it left me fuming.
    That makes me sad... It's just a blog post, you know :-)
    How on earth can we call ourselves a profession when we openly concede that yes Smalltalk and Lisp and even Ruby are great, but are too hard for the average Java joe to comprehend?
    I'm not sure what the problem is with this view. Like in any other industry, there is some kind of bell-curve distribution in complexity in the Java world. These last 30+ years have taught us that most programmers feel reasonably comfortable with languages that follow the syntax pioneered by C and Basic. This is a simple observation, and the success of C++, Java, C# and Visual Basic should be enough to make this obvious to everyone. Anyway, I'm not sure there is much point in a debate between our respective perceptions of the average level of programmers out there. I'm just observing that a lot of people are turned off by the Smalltalk and Ruby syntaxes, and even for those who feel comfortable with Ruby, the sophistication of Ruby on Rails can be quite intimidating and, that's my personal claim, an obstacle to its widespread adoption. The simple reality is that the number of Visual Basic and PHP programmers dwarfs by at least an order of magnitude the number of Java and C++ programmers... -- Cedric
  35. Hi Paul,


    I read your blog entry. And I must admit it left me fuming.

    That makes me sad... It's just a blog post, you know :-)


    How on earth can we call ourselves a profession when we openly concede that yes Smalltalk and Lisp and even Ruby are great, but are too hard for the average Java joe to comprehend?

    I'm not sure what the problem is with this view. Like in any other industry, there is some kind of bell-curve distribution in complexity in the Java world. These last 30+ years have taught us that most programmers feel reasonably comfortable with languages that follow the syntax pioneered by C and Basic. This is a simple observation, and the success of C++, Java, C# and Visual Basic should be enough to make this obvious to everyone.

    Anyway, I'm not sure there is much point in a debate between our respective perceptions of the average level of programmers out there. I'm just observing that a lot of people are turned off by the Smalltalk and Ruby syntaxes, and even for those who feel comfortable with Ruby, the sophistication of Ruby on Rails can be quite intimidating and, that's my personal claim, an obstacle to its widespread adoption.

    The simple reality is that the number of Visual Basic and PHP programmers dwarfs by at least an order of magnitude the number of Java and C++ programmers...

    --
    Cedric
    Hi Cedric, The guts of your argument is that this is how things are today, so this is how they will necessarily be for an eternity. This argument simply doens't make sense. Also all the people that say that Lisp or Smalltalk are just too weird or too difficult to understand, don't have a problem with them themselves, it is just those other developers who just can't get it :^). I am an Agile coach, and we program in pairs. So I see junior developers struggling with concepts and ideas at first hand. After showing them by example they quickly catch on. Often we hit a problem which I would describe as a language smell, often the discussion would wonder into how we could perhaps better deal with this situation using an alternative language. Almost everytime I've done this I've seen people have an -aha moment. When I was a juniorr programmer aha moments where few and far between, because you were left in a corner by your own and just expected to know stuff. A bell curve is fine, but it is the standard deviation that counts. In our industry there is a massive difference between the best and the rest. Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that. You may be happy with the status quoe, but over 70% project failure is nothing to be proud of in my eyes. We as a community can all do a lot better, and the first step in improving is raising expectations. Paul.
  36. .... In our industry there is a massive difference between the best and the rest. Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.
    I bet the best trial attorneys in the US are at least 10 times better than the rest. Those guys that got OJ off aren't available to everyone. :)
  37. .... In our industry there is a massive difference between the best and the rest. Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.


    I bet the best trial attorneys in the US are at least 10 times better than the rest. Those guys that got OJ off aren't available to everyone. :)
    True, Yes, but they get paid 10 times as much too :^). How often does this happen in Software? Paul.
  38. .... In our industry there is a massive difference between the best and the rest. Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.


    I bet the best trial attorneys in the US are at least 10 times better than the rest. Those guys that got OJ off aren't available to everyone. :)

    True,

    Yes, but they get paid 10 times as much too :^).

    How often does this happen in Software?

    Paul.
    If anyone knows such a place, I have a resume for you...
  39. A bell curve is fine, but it is the standard deviation that counts. In our industry there is a massive difference between the best and the rest. Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.
    I know of no knowledge worker prefession where statistics like that don't exist. The only difference is software development (and other forms of engineering, I think) don't have salary skews where those with the 10x productivity boost don't enjoy 20x or more the salary boost. For example, here in the States the average software engineer makes more than the average lawyer. However, it's not hard to find a lawyer who actually makes money practicing law and brings in 7 figures anually, while it's pretty hard to find a software engineer (who makes his money writing software) who does the same.
  40. Also all the people that say that Lisp or Smalltalk are just too weird or too difficult to understand, don't have a problem with them themselves, it is just those other developers who just can't get it :^).
    Well, I have to disagree. I have been programming LISP on and off (albeit very occasionally) for years, and I find it pretty weird, and find other developers LISP code hard to follow.
  41. The guts of your argument is that this is how things are today, so this is how they will necessarily be for an eternity.
    You may be happy with the status quoe, but over 70% project failure is nothing to be proud of in my eyes.
    I'm a very curious to find out how you came to these two conclusions based on reading my blog entry. I never said things will be like this forever, just that programming languages gain adoption in small increments (C, then C++, then Java/C#, Basic then Visual Basic, then VB6), and Ruby and Smalltalk are too much of a leap for the programming world as it is today.
    A bell curve is fine, but it is the standard deviation that counts.
    Really? You realize that it can go in either directions, right?
    Apparently studies have shown that the best developers are over 10 times more productive than the average.
    I keep seeing this factoid thrown here and there, and I still have no idea what it means, if it's true, or if it's a good thing or a bad thing. And I fail to see its relevance to our current discussion, but as I said in my previous post, I really don't think there is much point in having a debate about two very personal views that we have on our industry, which are, by definition, absolutely subjective and therefore, impossible to prove or disprove. -- Cedric

  42. The guts of your argument is that this is how things are today, so this is how they will necessarily be for an eternity.


    You may be happy with the status quoe, but over 70% project failure is nothing to be proud of in my eyes.

    I'm a very curious to find out how you came to these two conclusions based on reading my blog entry.

    I never said things will be like this forever, just that programming languages gain adoption in small increments (C, then C++, then Java/C#, Basic then Visual Basic, then VB6), and Ruby and Smalltalk are too much of a leap for the programming world as it is today.


    A bell curve is fine, but it is the standard deviation that counts.

    Really? You realize that it can go in either directions, right?


    Apparently studies have shown that the best developers are over 10 times more productive than the average.

    I keep seeing this factoid thrown here and there, and I still have no idea what it means, if it's true, or if it's a good thing or a bad thing. And I fail to see its relevance to our current discussion, but as I said in my previous post, I really don't think there is much point in having a debate about two very personal views that we have on our industry, which are, by definition, absolutely subjective and therefore, impossible to prove or disprove.

    --
    Cedric
    Hi Cedric, It has been a while since I've done stats, but I know that if there is a large variance in the quality of any product or service charged at a similar price and nominally meant to be the same, then that points to an issue with quality control. You may not see a point in debating, but I do. Resigning ourselves to poor quality by using the failings of those other developers as an excuse isn't away forward IMO. As an industry we haven't got alot to crow about, and the complacency you display in your blog is one of the reasons why our industry is currently under threat from off shore competition. Do you remember what happened to the American motor car industry of the 1970's? Paul.
  43. When I was a juniorr programmer aha moments where few and far between, because you were left in a corner by your own and just expected to know stuff.
    You seem to imply that if we don't do Pair Programing, we're "left in a corner" by ourself without the option of consulting more senior staff. Seems like an exaggeration to me. Typical of some agile coaches I know.
    Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.
    Another extreme comment. That order of magnitude of difference in quality can be found in many professions: lawyers, boxers, etc... And don't forget Project Management, Upper Management, and ...Agile coaches.
    You may be happy with the status quoe, but over 70% project failure is nothing to be proud of in my eyes.
    Project failures are caused at least as much by screw-ups in management than the lack of quality of developers, if not more. And I fail to see how using a different programing language will help in that regard.
  44. Hi Tony, So you've adopted the TSS tone.. OK here goes..
    When I was a juniorr programmer aha moments where few and far between, because you were left in a corner by your own and just expected to know stuff.


    You seem to imply that if we don't do Pair Programing, we're "left in a corner" by ourself without the option of consulting more senior staff. Seems like an exaggeration to me. Typical of some agile coaches I know.

    No, I'm not implying anything. Just sharing my experience and frustrations as a junior programmer. I'll leave the wild generalisations to you.
    Apparently studies have shown that the best developers are over 10 times more productive than the average. I know of no other profession that would tolerate a statistic like that.


    Another extreme comment. That order of magnitude of difference in quality can be found in many professions: lawyers, boxers, etc... And don't forget Project Management, Upper Management, and ...Agile coaches.
    The diference with lawyers etc, is that they are not sold as the same thing. A top notch lawyer will charge tens times as much too. If you read my later post you will see that the point I'm making is about quality control and standards. If the quality of service can change by an order of magnitued,for what is nominally meant to be the same thing, then as a customer, I haven't a clue what I'm getting for my money.
    You may be happy with the status quoe, but over 70% project failure is nothing to be proud of in my eyes.


    Project failures are caused at least as much by screw-ups in management than the lack of quality of developers, if not more.

    And I fail to see how using a different programing language will help in that regard.
    We agree here 100%. Unlike others on this thread, I do not see language choice as THE determining factor when it comes to project success. If you follow my posts you will see that I'm arguing for choice. To me it is plainly obvious that some languages/frameworks/tools etc may be better suited to a given problem then others. I can't uderstand why some Java people get so rattled when anyone suggests the blatantly obvious - on size does not fit all. Paul.
  45. No, I'm not implying anything. Just sharing my experience and frustrations as a junior programmer. I'll leave the wild generalisations to you.
    The way you wrote the comment could lend itself to a different interpretation that the one you're giving. Anyway, thanks for clearing that up. As for my own comment, I fail to see how the expression "Typical of SOME agile coaches I KNOW" could be interpreted as "wild generalization".

    The diference with lawyers etc, is that they are not sold as the same thing. A top notch lawyer will charge tens times as much too. If you read my later post you will see that the point I'm making is about quality control and standards. If the quality of service can change by an order of magnitued,for what is nominally meant to be the same thing, then as a customer, I haven't a clue what I'm getting for my money.
    OK...How about my other examples? How about upper management? I see your point about quality control, but the statement you made is not exclusively a characteristic of programmers by far.

    We agree here 100%. Unlike others on this thread, I do not see language choice as THE determining factor when it comes to project success. If you follow my posts you will see that I'm arguing for choice.

    To me it is plainly obvious that some languages/frameworks/tools etc may be better suited to a given problem then others. I can't uderstand why some Java people get so rattled when anyone suggests the blatantly obvious - on size does not fit all.

    Paul.
    We agree here 100%.
  46. <blockquoteWe agree here 100%. Unlike others on this thread, I do not see language choice as THE determining factor when it comes to project success.</blockquote> Nothing like setting up a nice fat straw man to argue against! No-one on this thread has said that language choice is THE determining factor when it comes to project success. My view is that the determining factor is the quality and skills of developers. But for developers who don't have the highest level of skills, language choice is a significant factor in project success. For all developers it is at least some factor.
  47. Ruby Syntax[ Go to top ]

    These last 30+ years have taught us that most programmers feel reasonably comfortable with languages that follow the syntax pioneered by C and Basic.
    I'm just observing that a lot of people are turned off by the Smalltalk and Ruby syntaxes....
    Actually Ruby syntax is in the same ballpark as C or Basic. Prefix, not postfix notation, block structure, etc. Lisp and Smalltalk however are very different. Arguably one reason Ruby has caught on among programmers who didn't take to Smalltalk and Lisp is the syntax. Here's a for loop in Java: // C / Java / C#: for (int i=0; i < 10; ++i) { print("i is " + i); } </pre> The Ruby version doesn't look that different: <pre> # Ruby: for i in (0..10) do print("i is " + i) end But the lisp version is very different: ;; Lisp: (let ((i 0)) (print (concat "i is" i)) (setq i (+ i 1))) (That might not be quite right; my Lisp is rusty.) Of course when you get into meta-programming and DSL's Ruby can get very magical. But that's not really a syntax issue. Steve
  48. Re: Ruby Syntax[ Go to top ]

    ;; Lisp:(let ((i 0)) (print (concat "i is" i)) (setq i (+ i 1)))
    (dotimes (i 10) (format t "i is ~d~%" i)) Of course there's half a dozen other reasonable ways to do it using standard Lisp constructs, and many like to invent their own using macros (since dotimes is really just a macro).
  49. Re: Ruby Syntax[ Go to top ]

    These last 30+ years have taught us that most programmers feel reasonably comfortable with languages that follow the syntax pioneered by C and Basic.


    I'm just observing that a lot of people are turned off by the Smalltalk and Ruby syntaxes....


    Actually Ruby syntax is in the same ballpark as C or Basic. Prefix, not postfix notation, block structure, etc. Lisp and Smalltalk however are very different. Arguably one reason Ruby has caught on among programmers who didn't take to Smalltalk and Lisp is the syntax.

    Here's a for loop in Java:


    // C / Java / C#:
    for (int i=0; i print("i is " + i);
    }


    The Ruby version doesn't look that different:


    # Ruby:
    for i in (0..10) do
    print("i is " + i)
    end


    But the lisp version is very different:


    ;; Lisp:
    (let ((i 0))
    (print (concat "i is" i))
    (setq i (+ i 1)))


    (That might not be quite right; my Lisp is rusty.)

    Of course when you get into meta-programming and DSL's Ruby can get very magical. But that's not really a syntax issue.

    Steve
    Good point. I believe that it just comes down to familiarity. BTW sometimes inappropriate syntax can hide the underlying concepts in a language. IMO one of the reasons why Object technology is so poorly understood by many is because Algol like languages (C, C++ etc) lack uniformity. For example they do not uniformily apply message sends to objects as a way of controlling program flow. For me, I only really understood OO once I started programming in Smalltalk. Paul.
  50. Re: Ruby Syntax[ Go to top ]

    IMO one of the reasons why Object technology is so poorly understood by many is because Algol like languages (C, C++ etc) lack uniformity. For example they do not uniformily apply message sends to objects as a way of controlling program flow.

    For me, I only really understood OO once I started programming in Smalltalk.

    Paul.
    I am not sure I entirely agree with your first point, but I wholeheartedly back the idea of understanding OO via Smalltalk; I can't imagine how I would have realised the full power and richness of OOP if I had not learned it via Smalltalk.
  51. Re: Ruby Syntax[ Go to top ]

    The Ruby version doesn't look that different:
    # Ruby:
    for i in (0..10) do
    print("i is " + i)
    end
    Well, I'd rather write it that way: (1..10).each { |i| puts "i is #{i}" } which is definitely more "exotic" to a C programmer (as I was...) Erik
  52. Re: Ruby Syntax[ Go to top ]


    (1..10).each { |i| puts "i is #{i}" }
    Of course I meant
    (0..10).each { |i| puts "i is #{i}" }
    :-) Erik
  53. Re: Ruby Syntax[ Go to top ]


    (1..10).each { |i| puts "i is #{i}" }

    Of course I meant

    (0..10).each { |i| puts "i is #{i}" }

    :-)

    Erik
    Far too long and explicit. Use the full power of Ruby. Redefine 'each'....
  54. Re: Ruby Syntax[ Go to top ]

    Far too long and explicit. Use the full power of Ruby. Redefine 'each'....
    Sorry, I don't get the irony - not understanding what you aim at. This is as explicit to me (though I'm a beginner in Ruby - but experienced in many other languages) as its equivalents in C, C++ or Java (for example).
  55. Re: Ruby Syntax[ Go to top ]

    Far too long and explicit. Use the full power of Ruby. Redefine 'each'....

    Sorry, I don't get the irony - not understanding what you aim at. This is as explicit to me (though I'm a beginner in Ruby - but experienced in many other languages) as its equivalents in C, C++ or Java (for example).
    I think Steve is being sarcastic. The point is someone could have redefined "each" to mean anything, making the idiomatic solution completely wrong.
  56. Re: Ruby Syntax[ Go to top ]

    Far too long and explicit. Use the full power of Ruby. Redefine 'each'....

    Sorry, I don't get the irony - not understanding what you aim at. This is as explicit to me (though I'm a beginner in Ruby - but experienced in many other languages) as its equivalents in C, C++ or Java (for example).
    The point was, why write (0..10).each { |i| puts "i is #{i}" } every time? Simply redefine the 'each' method of Range: class Range def each i = first while i < last puts "i is #{i}" i += 1 end end end Now all you need do is.... (0..10).each even more concise! But you have over-written a method in a core class. The results are likely to be disastrous. The point is, any section of Ruby code anywhere, written by anyone, can do this. Or, they can overwrite any method in your code. This sort of thing has been seen before. It used to happen frequently in Smalltalk (although Smalltalk is less fragile, as such method name conflicts can usually be detected at the point of compilation; Ruby has no compilation). I saw some of the messy ways developers tried to deal with this. One way was to include a company or author name or initials in the method. You would end up loading String methods like 'szFormatAsDecimal:' or 'acmeSplitOnCommas'. This proved too much for serious commercial developers, and namespace strategies were developed. Ruby is an amazing language - elegant and powerful, but if it is to ever be a serious language for substantial projects, this is one of the matters that will have to be addressed.
  57. Re: Ruby Syntax[ Go to top ]

    Got it. I was actually "afraid" you meant
    Redefine 'each'...
    exactly the way you turn out to mean it :-).
    Ruby is an amazing language - elegant and powerful, but if it is to ever be a serious language for substantial projects, this is one of the matters that will have to be addressed.
    This is also my feeling. I've seen so many silly programs written in "strict" languages that I'd rather give up software development than have to cope with the madness that will inevitably spread if Ruby (in its current form) is being widely used...
  58. Re: Ruby Syntax[ Go to top ]

    Ruby is an amazing language - elegant and powerful, but if it is to ever be a serious language for substantial projects, this is one of the matters that will have to be addressed.
    Hi Steve, For some teams this may be true. For other teams it is totally false. No one on my team would overload standard methods. In the same way that a C++ programmer would not override an operator like != and provide it with new semantics - you just don't do it! It depends on the team. This is why I keep on mentioning choice. I can't see why you have a difficulty with this concept. People that know what they are doing should be able to choose to use expressive languages if they want to. Why dumb down everyone? Teams that make the right choice for them will succeed and those that don't will fail. I don't understand why you are trying to enforce some lowest common denominator upon everyone. Indeed is Java the 'safest' language? If safety was the most important issue then perhaps we should all be using a strict Functional language like OCAML? There are a number of issues a team needs to consider when choosing a language for a given task, and I don't believe you can legislate for everyone and every circumstance in the way you insist on doing. If Ruby doesn't work for you don't use it - but don't try and enforce your choices on everyone else. Paul.
  59. Re: Ruby Syntax[ Go to top ]

    It depends on the team. This is why I keep on mentioning choice. I can't see why you have a difficulty with this concept. People that know what they are doing should be able to choose to use expressive languages if they want to. Why dumb down everyone?
    I realise I do have difficulty with choice. It is a psychological problem. It is a sad story. I was traumatised years ago when I saw that someone who allowed to choose had chosen to use DOS assembler to write part of a CRM system, after I was called in to help fix problems with it (no, I am not making this up). You are right. It depends on the team. All we ever need to do is pick high-quality teams for every project! Great idea - problem solved!
    If Ruby doesn't work for you don't use it - but don't try and enforce your choices on everyone else.
    Sorry, but that is my cunning plan. I realise it is going to be a real challenge. There is just me, and everyone else means millions of developers. I'll make a start with those I work with. One step at a time..
  60. Re: Ruby Syntax[ Go to top ]

    But you have over-written a method in a core class. The results are likely to be disastrous. The point is, any section of Ruby code anywhere, written by anyone, can do this. Or, they can overwrite any method in your code.

    This sort of thing has been seen before. It used to happen frequently in Smalltalk (although Smalltalk is less fragile, as such method name conflicts can usually be detected at the point of compilation; Ruby has no compilation). .
    Hi Steve, So what is there to stop people overriding 'clone' or 'equals' or 'hashCode' in Java giving them new inappropriate semantics? Or implementing/overriding Comparable with inappropriate semantics? Bang goes your use of collections and comparators. BTW, this happening frequently with Smalltalk? Where? Have you evidence? I have used Smalltalk since 1993 and I have seen no evidence of what you describe as a wide spread practice. Sure there are different dialects, but that is a different issue entirely. I just can't understand you. Rather than all this FUD, why not just tell people not to do certain things? goto and labels and setjump, longjump is still part of C today but all C programmers know that they should not be used (until they should :^)). I just think you are creating a false argument. People have been using Ruby since 1993, I've been using it since 2005 and I have not come across a single instance of what you describe. Or read anywhere someone complaining about this common practice. It is not a problem, because people just don't do it. Paul.
  61. Re: Ruby Syntax[ Go to top ]

    It is not a problem, because people just don't do it.
    Though I agree that Steve's point of view (at least in the way he expresses it here) seems exagerated we must also have a thought about what can happen if 'people ever do it' (either by inadvertance or malignantly): what will it cost to find the cause of the problem, what can break in our system, does it open the possibility for security breaches etc. Put another way: if everyone knows what he is doing, then probably every language more or less does it - but we all know that we don't always know what we're doing :-), and maybe the language (how "dangerous" the features it offers are) then matters... Just a thought... Erik
  62. Re: Ruby Syntax[ Go to top ]

    Though I agree that Steve's point of view (at least in the way he expresses it here) seems exagerated we must also have a thought about what can happen if 'people ever do it' (either by inadvertance or malignantly): what will it cost to find the cause of the problem, what can break in our system, does it open the possibility for security breaches etc.
    Given the infinite permutations that any non-trivial program can be expressed as, Java isn't going to save you either. Some people seem to want the language designers to impose the strait jacket, while I'd rather have the team guidelines impose it. There's many valid reasons for the "safe choice", but it comes at a cost, and should be weighed as such by the myriad of environmental factors that a team has.
  63. Re: Ruby Syntax[ Go to top ]

    Given the infinite permutations that any non-trivial program can be expressed as, Java isn't going to save you either. Some people seem to want the language designers to impose the strait jacket, while I'd rather have the team guidelines impose it. There's many valid reasons for the "safe choice", but it comes at a cost, and should be weighed as such by the myriad of environmental factors that a team has.
    I basically agree - and did not expect Java to save me ;-). I just tend to think that we could be confronted with very nasty problems if we don't think about the "dangers" of a powerful dynamic language - especially when it comes to designing frameworks where you cannot rely on team guidelines - because the team is open. But as I mentioned: I'm just beginning to learn Ruby, I'll then have a look on RoR - maybe I'll be convinced that there is not real reason to be afraid of it in a few months... Erik
  64. Re: Ruby Syntax[ Go to top ]

    Given the infinite permutations that any non-trivial program can be expressed as, Java isn't going to save you either. Some people seem to want the language designers to impose the strait jacket, while I'd rather have the team guidelines impose it. There's many valid reasons for the "safe choice", but it comes at a cost, and should be weighed as such by the myriad of environmental factors that a team has.

    I basically agree - and did not expect Java to save me ;-). I just tend to think that we could be confronted with very nasty problems if we don't think about the "dangers" of a powerful dynamic language - especially when it comes to designing frameworks where you cannot rely on team guidelines - because the team is open.

    But as I mentioned: I'm just beginning to learn Ruby, I'll then have a look on RoR - maybe I'll be convinced that there is not real reason to be afraid of it in a few months...

    Erik
    Hi Steve, It is a valid concern, and I believe you are doing the right thing - learning Ruby and trying RoR for yourself. In the end only thing that really counts is real world experience, and everything else is just FUD. Try out a few of the RoR forums and express your concerns there. I'm sure that others with real world experience of will allay your fears too. I haven't come across any horror stories. Paul.
  65. Re: Ruby Syntax[ Go to top ]

    Given the infinite permutations that any non-trivial program can be expressed as, Java isn't going to save you either. Some people seem to want the language designers to impose the strait jacket, while I'd rather have the team guidelines impose it. There's many valid reasons for the "safe choice", but it comes at a cost, and should be weighed as such by the myriad of environmental factors that a team has.

    I basically agree - and did not expect Java to save me ;-). I just tend to think that we could be confronted with very nasty problems if we don't think about the "dangers" of a powerful dynamic language - especially when it comes to designing frameworks where you cannot rely on team guidelines - because the team is open.

    But as I mentioned: I'm just beginning to learn Ruby, I'll then have a look on RoR - maybe I'll be convinced that there is not real reason to be afraid of it in a few months...

    Erik


    Hi Steve,

    It is a valid concern, and I believe you are doing the right thing - learning Ruby and trying RoR for yourself.

    In the end only thing that really counts is real world experience, and everything else is just FUD. Try out a few of the RoR forums and express your concerns there. I'm sure that others with real world experience of will allay your fears too.

    I haven't come across any horror stories.

    Paul.
    Did I say Steve? .. Sorry I meant to say Erik :^) P.
  66. Re: Ruby Syntax[ Go to top ]

    In the end only thing that really counts is real world experience, and everything else is just FUD.
    Let's say you were reviewing junior programmer's code, and noticed that one of his unit tests wasn't testing a certain class of reasonable inputs. So you add a few new tests. Bam! The code is failing them. You go find the programmer to talk about fixing the failing method. The programmer says he's aware of the problem. When he first wrote the code, he had a unit test case much like yours. He took it out when his method was failing, and he realized that making it pass would require a far more complex algorithm. He then asserts that the method has been used in its present form in production for months under heavy loads and has yet to cause a problem, and that he believes the application will never pass it a "bad" value. Experience says it works because the edge cases never actually occur. Do you rewrite the method or remove the tests?
  67. Re: Ruby Syntax[ Go to top ]

    The programmer says he's aware of the problem. When he first wrote the code, he had a unit test case much like yours. He took it out when his method was failing ....

    Do you rewrite the method or remove the tests?
    Three logical choices: 1) 90%: You accept it because that is the path of least resistance, and you continue to collect your pay-check and pad your resume until that company folds or you find a better job to hop to with your newly padded resume. 2) 9%: You fix it (which includes building the unit and integration tests for it), because that is the right thing to do. Unfortunately, a small side-effect occurs, and you are blamed for a production outage, so you have to work long nights and every weekend trying to put Humpty-Dumpty back together. In the end, you end up reporting to the junior programmer that wrote the crap in the first place, since he has managed to pad his resume and move into project management. 3) 1%: You quit and go to work for yourself so you don't have to deal with stuff like that. ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Cache
  68. Re: Ruby Syntax[ Go to top ]

    The programmer says he's aware of the problem. When he first wrote the code, he had a unit test case much like yours. He took it out when his method was failing ....

    Do you rewrite the method or remove the tests?


    Three logical choices:

    1) 90%: You accept it because that is the path of least resistance, and you continue to collect your pay-check and pad your resume until that company folds or you find a better job to hop to with your newly padded resume.

    2) 9%: You fix it (which includes building the unit and integration tests for it), because that is the right thing to do. Unfortunately, a small side-effect occurs, and you are blamed for a production outage, so you have to work long nights and every weekend trying to put Humpty-Dumpty back together. In the end, you end up reporting to the junior programmer that wrote the crap in the first place, since he has managed to pad his resume and move into project management.

    3) 1%: You quit and go to work for yourself so you don't have to deal with stuff like that. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Cache
    Hi Cameron, I like your option two. But things aren't that bad, once you've found the problem, then it becomes a "known bug" and once you've fixed it , it becomes a "known fix" ready for your regression test suite and your next release (you are regression testing and releasing regularly right? :^)). BTW the junior programmer could do with a little re-orientation. Peer pressure tends to suffice! Erik, I think you've missed the plot. My point was that in the face of FUD, the true test is to try it yourself, or better still talk to people that have tried it themselves. People have been using Ruby for a wide range of applications since 1993 - and to date no one as reported the sky falling in. Paul.
  69. Re: Ruby Syntax[ Go to top ]

    Though I agree that Steve's point of view (at least in the way he expresses it here) seems exagerated...
    I accept that it may well be exaggerated, but I would like to explain why.... all through my IT career a significant part of my role wherever I have worked has been to deal with bugs in legacy software and rescue failing projects. This means I probably have seen a higher proportion of the worst side of things than typical developers. So, if I go on excessively about how things can go wrong, and how coders can fail, you now know why :)
  70. Re: Ruby Syntax[ Go to top ]

    So what is there to stop people overriding 'clone' or 'equals' or 'hashCode' in Java giving them new inappropriate semantics? Or implementing/overriding Comparable with inappropriate semantics? Bang goes your use of collections and comparators.
    Exactly! You finally understand! It is all in the last sentence. Bang goes YOUR use of collections and comparators for the classes in which you have overriden those. It only goes wrong for YOUR classes. You aren't changing the semantics for all code anywhere in the application that use 'clone', or 'equals' or 'hashCode'.
    BTW, this happening frequently with Smalltalk? Where? Have you evidence? I have used Smalltalk since 1993 and I have seen no evidence of what you describe as a wide spread practice.
    I have been using Smalltalk since 1986. Method and class name clashes were indeed common, and were a problem: "Namespaces are essential to avoid name clashes. Once one has a convenient component technology one starts to see clashes. Once we had made VisualWorks 3.0 a system based on parcels we started to see clashes such as both VisualWave and SmallWalker defining an HTTPClient, etc. From the proposal to add namespaces to VisualWorks Smalltalk. Here is a recommendation from the authors of Dolphin Smalltalk about how to avoid name clashes: http://www.object-arts.com/docs/index.html?classname.htm "This means that the namespace for class names is limited and it is sometimes necessary to be careful how one names a particular class or group of classes in order to avoid clashes. In some situations it may be advantageous to add a prefix to your class names to avoid potential classes." Here is a description in GNU Smalltalk of the issue of method name clashes, which proposes exactly the solution that I saw developers adopt with Digitalk packages in the 80s: So, GNU Smalltalk namespaces cannot yet solve 100% of the problem of clashes between extensions to a class--for that you'll still have to rely on prefixes to method names
    I just can't understand you. Rather than all this FUD, why not just tell people not to do certain things?
    Well, as I have show above, it is certainly not FUD. However... all we need to do to maintain developer quality is to just tell people not to do certain things? That always works :)
    I just think you are creating a false argument. People have been using Ruby since 1993, I've been using it since 2005 and I have not come across a single instance of what you describe.
    You have now: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/191389 "But we're getting away from the issue aren't we? The issue seems to be: should execution behaviour change with the order of require statements in a program? Is it sufficient to have Ruby warn us that a method is being redefined?" You may wish to note the name of the author of the package being discussed. He was not so experienced then, but I would find it hard to believe that the typical Ruby developer would be better.
  71. Re: Ruby Syntax[ Go to top ]

    So what is there to stop people overriding 'clone' or 'equals' or 'hashCode' in Java giving them new inappropriate semantics? Or implementing/overriding Comparable with inappropriate semantics? Bang goes your use of collections and comparators.


    Exactly! You finally understand! It is all in the last sentence. Bang goes YOUR use of collections and comparators for the classes in which you have overriden those.

    It only goes wrong for YOUR classes. You aren't changing the semantics for all code anywhere in the application that use 'clone', or 'equals' or 'hashCode'.

    BTW, this happening frequently with Smalltalk? Where? Have you evidence? I have used Smalltalk since 1993 and I have seen no evidence of what you describe as a wide spread practice.


    I have been using Smalltalk since 1986. Method and class name clashes were indeed common, and were a problem:

    "Namespaces are essential to avoid name clashes. Once one has a convenient component technology one starts to see clashes. Once we had made VisualWorks 3.0 a system based on parcels we started to see clashes such as both VisualWave and SmallWalker defining an HTTPClient, etc.

    From the proposal to add namespaces to VisualWorks Smalltalk.

    Here is a recommendation from the authors of Dolphin Smalltalk about how to avoid name clashes:

    http://www.object-arts.com/docs/index.html?classname.htm
    "This means that the namespace for class names is limited and it is sometimes necessary to be careful how one names a particular class or group of classes in order to avoid clashes. In some situations it may be advantageous to add a prefix to your class names to avoid potential classes."

    Here is a description in GNU Smalltalk of the issue of method name clashes, which proposes exactly the solution that I saw developers adopt with Digitalk packages in the 80s:

    So, GNU Smalltalk namespaces cannot yet solve 100% of the problem of clashes between extensions to a class--for that you'll still have to rely on prefixes to method names

    I just can't understand you. Rather than all this FUD, why not just tell people not to do certain things?


    Well, as I have show above, it is certainly not FUD.

    However... all we need to do to maintain developer quality is to just tell people not to do certain things? That always works :)

    I just think you are creating a false argument. People have been using Ruby since 1993, I've been using it since 2005 and I have not come across a single instance of what you describe.


    You have now:
    http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/191389

    "But we're getting away from the issue aren't we?
    The issue seems to be: should execution behaviour change with the order of require statements in a program? Is it sufficient to have Ruby warn us that a method is being redefined?"

    You may wish to note the name of the author of the package being discussed. He was not so experienced then, but I would find it hard to believe that the typical Ruby developer would be better.
    Hi Steve, Namespaces have nothing to do with overriding standard methods. Adding new classes/methods of your own that may clash with classes added by someone else is a different problem. Extending the system is not the same as overriding what is already there. So please the evidence. Paul.
  72. Re: Ruby Syntax[ Go to top ]

    Namespaces have nothing to do with overriding standard methods.
    No, you are right. Other approaches are needed to deal with that problem. (Remember, we are not talking about 'overriding' as in subclasses - we are talking about 'overwriting' in the standard (or other) classes). I admit that I was mis-remembering the labelling of methods into packages with putting them into namespaces. You still get the screw-ups, but at least you know which package has caused them!
    Adding new classes/methods of your own that may clash with classes added by someone else is a different problem.
    No, it is exactly the same problem. Things clash and can be overwritten whether they are your classes or methods, or standard classes or methods. In a namespace-free Smalltalk image and in Ruby there is no distinction between standard classes and user-added classes.
    Extending the system is not the same as overriding what is already there.
    We aren't talking about overriding. We are talking about replacing. If you re-define the Range.each method in Ruby, or put your own code into the String.printString method in Smalltalk then that will change the behaviour of that method globally.
    So please the evidence.

    Paul.
    I have given the evidence. I have shown that name clashes were a real problem in Smalltalk that had to be (only partially) addressed by the introduction of namespaces. I have given you proof that I was not making this up by quotes from discussions of this issue from three different Smalltalk distributions. I have given you a real example of how method replacement during execution of a Ruby program by a leading Ruby developer led to bugs, and a discussion amongst keen Ruby supporters about Ruby's weaknesses in this area. Let me quote more from that thread (you can find this by following the thread back): "My premise is that Ruby is not ready for enterprise use because the inability to predict the behavior of programs. If one cannot predict the behavior of programs, one cannot test the programs. If one cannot test the programs, one cannot deploy the programs into environments that have significant regulation (e.g., financial services, health care, insurance, etc.) I gave as an instance of this issue, Instiki. So... let's drill down. - Instiki was written by someone who was not an 'idiot chef' but a skilled Ruby programmer. - Instiki was written using Rails... the "way" to write web apps in Ruby. - Instiki is not a complex app (the application itself is If a non-complex Ruby app written by a skilled Ruby developer using standard Ruby tools breaks, how can a large company trust that a very complex Ruby program that has passed QA won't fall into the same issue." (My emphasis) This was said by David Pollak - someone who is well known in Ruby circles, not some defensive Java developer.
  73. Re: Ruby Syntax[ Go to top ]

    Namespaces have nothing to do with overriding standard methods.


    No, you are right. Other approaches are needed to deal with that problem. (Remember, we are not talking about 'overriding' as in subclasses - we are talking about 'overwriting' in the standard (or other) classes). I admit that I was mis-remembering the labelling of methods into packages with putting them into namespaces. You still get the screw-ups, but at least you know which package has caused them!

    Adding new classes/methods of your own that may clash with classes added by someone else is a different problem.


    No, it is exactly the same problem. Things clash and can be overwritten whether they are your classes or methods, or standard classes or methods. In a namespace-free Smalltalk image and in Ruby there is no distinction between standard classes and user-added classes.

    Extending the system is not the same as overriding what is already there.


    We aren't talking about overriding. We are talking about replacing. If you re-define the Range.each method in Ruby, or put your own code into the String.printString method in Smalltalk then that will change the behaviour of that method globally.

    So please the evidence.

    Paul.


    I have given the evidence. I have shown that name clashes were a real problem in Smalltalk that had to be (only partially) addressed by the introduction of namespaces. I have given you proof that I was not making this up by quotes from discussions of this issue from three different Smalltalk distributions. I have given you a real example of how method replacement during execution of a Ruby program by a leading Ruby developer led to bugs, and a discussion amongst keen Ruby supporters about Ruby's weaknesses in this area.

    Let me quote more from that thread (you can find this by following the thread back):

    "My premise is that Ruby is not ready for enterprise use because the inability to predict the behavior of programs. If one cannot predict the behavior of programs, one cannot test the programs. If one cannot test the programs, one cannot deploy the programs into environments that have significant regulation (e.g., financial services, health care, insurance, etc.)

    I gave as an instance of this issue, Instiki. So... let's drill down.

    - Instiki was written by someone who was not an 'idiot chef' but a skilled Ruby programmer.
    - Instiki was written using Rails... the "way" to write web apps in Ruby.
    - Instiki is not a complex app (the application itself is - Yet Instiki has somehow fallen into this issue of unpredictability because of the order of class loading.
    - If a non-complex Ruby app written by a skilled Ruby developer using standard Ruby tools breaks, how can a large company trust that a very complex Ruby program that has passed QA won't fall into the same issue."

    (My emphasis)

    This was said by David Pollak - someone who is well known in Ruby circles, not some defensive Java developer.
    Hi Steve, Namespaces and overriding a standard method like 'each' using open classes are too different issues. The first can be solved by convention, the secound you just down't do it! As for 'predictablity' of programs. No imperative program can be proven to be free of side effects and hence by definition is unpredictable. The only way I know to be sure of program behaviour is to program in a strict functional style, avoding loops and using techniques like tail recursion etc. A fully featured functional language like CAML as I mentioned before comes to mind. Even then to prove correctness, you need to be a dab hand at predicate calculus (I'm doing all this of a dim and distant memory, so please correct me anyone if I'm wrong). So the normal burden of proof for imperative languages, is that if it can be demonstrated to work then it's fine to ship. Of course if someones life depends on it then CAML may be the way to go. Or how about a system with redundancy with majority voting like they use in Aircraft? I think you are misguided with this line of argument Steve. All programs have bugs, and the only thing we can do to avoid them is test. This is the case for any imperative language. Paul.
  74. Re: Ruby Syntax[ Go to top ]

    Namespaces and overriding a standard method like 'each' using open classes are too different issues. The first can be solved by convention, the secound you just down't do it!
    Paul - on the overriding the standard methods: I agree that you shouldn't do it and that every sane programmer won't do it. But: what if it happens? How do we recognize it? Contrived (but maybe no that much) example: I expand a standard class with a very useful method called whatever. Then comes Ruby version x+1 that now defines whatever for that very class, but with a slighly different semantic than my version of whatever (but the same signature). How will I recognize that this has happened (except by reading carefully the release notes which I definitely should do)? And what kind of effect can this have? Remember: I'm a Ruby beginner, so the answer to my "puzzle" may be obvious to the expert, no yet to me... Erik
  75. Re: Ruby Syntax[ Go to top ]

    I think this is relevant to this discussion: http://www.rcrchive.net/rcr/show/207 It's a proposal to add a command line argument to Ruby that will automatically freeze all builtin classes on startup, so people can modify them. I particularly like this comment on the proposal:
    I am opposed because this is not Java and Ruby's command-line arguments (and C code) should not be cluttered up by things to make it into Java. This would also destroy libraries like mathn.
  76. Re: Ruby Syntax[ Go to top ]

    I think this is relevant to this discussion:

    http://www.rcrchive.net/rcr/show/207

    It's a proposal to add a command line argument to Ruby that will automatically freeze all builtin classes on startup, so people can modify them.

    I particularly like this comment on the proposal:

    I am opposed because this is not Java and Ruby's command-line arguments (and C code) should not be cluttered up by things to make it into Java. This would also destroy libraries like mathn.
    I personally "prefer" the end of the same comment :
    They can also choose to use another language, as Ruby is likely not for them.
    Does it mean as much as "Real men need this feature - others should use Java" ;-) ? Erik
  77. Re: Ruby Syntax[ Go to top ]

    Namespaces and overriding a standard method like 'each' using open classes are too different issues. The first can be solved by convention, the secound Tyou just down't do it!

    Paul - on the overriding the standard methods: I agree that you shouldn't do it and that every sane programmer won't do it. But: what if it happens? How do we recognize it?

    Contrived (but maybe no that much) example: I expand a standard class with a very useful method called whatever. Then comes Ruby version x+1 that now defines whatever for that very class, but with a slighly different semantic than my version of whatever (but the same signature). How will I recognize that this has happened (except by reading carefully the release notes which I definitely should do)? And what kind of effect can this have?

    Remember: I'm a Ruby beginner, so the answer to my "puzzle" may be obvious to the expert, no yet to me...

    Erik
    Hi Erik, As far as recknonising that this as occured, after referring to the pickaxe book, I don't think their is a mechanism within the language. I'm not an expert, but my first though is to rely on how I detect sutble bugs when upgrading any library/framework. I rely on my regression test suite, also I would have some testers give it a good going over. There is a good discussion on this very same point here: http://www.artima.com/forums/flat.jsp?forum=270&thread=173574 Take a look at the other's Erik's post about freezing classes also. There is a definately a cultural difference here. Dynamic programmers tend to take a different attitude to 'code safety'. Their mindset is to 'test everything that can possibly break'. They do not see the compiler-as-thought-police, or 'limits' introduced by the language designer as offering any practical benefit. It is just a point of view. My own view is that anything that gets in the way of me expressing what I want to do tends to make the code more convoluted and verbose and hence difficult to maintain. After payng this price, I still find that I'm not confident that my code is correct untill I "test everything that can possibly break". I think it comes down to judgement and experience. But I agree such power can be abused. If unsure play it safe and do things the Java way :^), I do. Paul.
  78. Re: Ruby Syntax[ Go to top ]

    http://www.artima.com/forums/flat.jsp?forum=270&thread=173574
    Good discussion indeed - thanks for the link. Erik
  79. Re: Ruby Syntax[ Go to top ]

    I rely on my regression test suite
    Their mindset is to 'test everything that can possibly break'.
    You can keep mentioning testing all you want, but it is not credible when, for the third time, a senior and very experienced Ruby developer says different. This may be a minority view in the Ruby community; in fact I am sure it is, but it is a valid point of view, especially from someone so experienced and respected. I fail to see why you persist in ignoring this. I would have expected better; perhaps some direct challenge to it, or some evidence to show that the issues he is raising can be dealt with.
    I don't think their is a mechanism within the language
    But, no, it seems you don't have an answer; or do you? As I am getting nowhere, I'll leave it to others. Enjoy the debate :)
  80. Re: Ruby Syntax[ Go to top ]

    I rely on my regression test suite


    Their mindset is to 'test everything that can possibly break'.


    You can keep mentioning testing all you want, but it is not credible when, for the third time, a senior and very experienced Ruby developer says different.

    This may be a minority view in the Ruby community; in fact I am sure it is, but it is a valid point of view, especially from someone so experienced and respected.

    I fail to see why you persist in ignoring this. I would have expected better; perhaps some direct challenge to it, or some evidence to show that the issues he is raising can be dealt with.

    I don't think their is a mechanism within the language


    But, no, it seems you don't have an answer; or do you?

    As I am getting nowhere, I'll leave it to others. Enjoy the debate :)
    Hi Steve, You forgot this quote:
    I think it comes down to judgement and experience. But I agree such power can be abused. If unsure play it safe and do things the Java way :^), I do.
    I get your point. I just don't believe it it the best option for everyone, all the time. So we are back to that old chestnut of choice which I know you struggle with. I choose to use a highly productive environment, and utilise the time saved to produce extensive automated regression tests. This is my preferred choice for rapid delivery of robust, solid, production ready web applications. There are alternative choices, and everyone gets to choose for themselves. Paul.
  81. Re: Ruby Syntax[ Go to top ]

    There are alternative choices, and everyone gets to choose for themselves.

    Paul.
    Everyone gets to choose for themselves. So we end up with more 'using assembler for CRM'-type choices that I have had to deal with. Great. And IT continues to suffer from the failure rates of the past, because so many refuse to learn from past; because, after all, what matters is choice for the developers; let them learn through mistakes - project failures and resulting business failures and financial loss are secondary. A depressing situation.... Ah well, really must get on with other things.
  82. Re: Ruby Syntax[ Go to top ]

    Namespaces and overriding a standard method like 'each' using open classes are too different issues. The first can be solved by convention, the secound you just down't do it!
    The good old 'just tell them not to' again :) Good luck with that approach... I have tried it often, but I am afraid it failed quite a bit.
    I think you are misguided with this line of argument Steve. All programs have bugs, and the only thing we can do to avoid them is test. This is the case for any imperative language.

    Paul.
    There have always been languages which have been less prone to certain bugs than others. The issues with pointers and lack of bounds checking in C is a classic one. As developers moved to safer practices in C++ and as Java became more dominant a class of bugs was significantly reduced making developers in general more productive; saving the IT industry significant time and money. We aren't after perfection - just safer ways of working. The 'all languages have faults' argument just doesn't work. It is a classic mistaken way of arguing called the 'Association Fallacy' (a particular breed of red herring!). Extrapolate this to other areas of life - just because you can have accidents at any speed, does that make speed limits as a whole worthless? Of course not. Anyway, in the article I quoted, a well-respected Ruby developer said:
    If one cannot predict the behavior of programs, one cannot test the programs.
    I obviously agree with you at least in the respect that testing is a vital part of dealing with bugs. Why is why it is best to stick with languages where decent testing is more feasible. The mere fact that a someone senior in the 'Ruby community' has posted serious concerns about this makes me concerned; maybe you
  83. ...and even for those who feel comfortable with Ruby, the sophistication of Ruby on Rails can be quite intimidating and, that's my personal claim, an obstacle to its widespread adoption.
    Interesting viewpoint. I've heard the opposite criticism, that Rails is very inviting at first because it hides all the complexity and it's easy to get up and running, but that there's too much magic going on and thus is hard to debug when there's a problem. Like VB without the safety coating as another poster said. I don't agree with this criticism, but it is a common one. I have seen developers who don't know Ruby and try to use Rails have this problem though. For me, Spring + Hibernate + Java + JSF/Shale/WebWork + JSP + JSTL + EL is very intimidating!
  84. ...and even for those who feel comfortable with Ruby, the sophistication of Ruby on Rails can be quite intimidating and, that's my personal claim, an obstacle to its widespread adoption.


    Interesting viewpoint. I've heard the opposite criticism, that Rails is very inviting at first because it hides all the complexity and it's easy to get up and running, but that there's too much magic going on and thus is hard to debug when there's a problem. Like VB without the safety coating as another poster said. I don't agree with this criticism, but it is a common one. I have seen developers who don't know Ruby and try to use Rails have this problem though.

    For me, Spring + Hibernate + Java + JSF/Shale/WebWork + JSP + JSTL + EL is very intimidating!
    +1 Like I said before, the most forceful oppostion come from people with no real experience of alternatives. Paul.
  85. Paul, I know this wasn't directed at me, but I feel compelled to respond.
    I read your blog entry. And I must admit it left me fuming. How on earth can we call ourselves a profession when we openly concede that yes Smalltalk and Lisp and even Ruby are great, but are too hard for the average Java joe to comprehend?
    I think "hard" is the wrong word. How is this for you: The average developer is unwilling to comprehend Smalltalk, Lisp, and even Ruby. If I remember right, Smalltalk was designed so that a child should be able to program it. Ruby may become mainstream, but if it does it will be like Visual Basic. Most people who use it will have no clue about the magic going on under the hood. The biggest different will be there will be no protective covering over the magic...which will probably burn people. I'll say I've been trying to learn Lisp for almost a decade now, and I've just finally done it (well, to the point I can actually program in it). It's not that Lisp is hard or doesn't make sense or anything like that. It's that its syntax is offensive to someone who's first "real" language was Pascal (I'm disqualifying Basic and Logo), followed by C, C++, Java, and Ada. It took me six months to finally latch on to Python - mostly because most tutorials started out in an interactive prompt and because of the syntax - and without it I probably would have never tolerated Lisp. Someday I'll get around to Ruby, but last time I tried it drove me nuts. Why? It's not Python, so none of my Python skills apply, and pretending it's Java defeats the purpose of using Ruby. If you're going successfully use a language, you have to understand it's paradigm(s), and that takes patience.
    It has been shown time and time again, that a few programmers with the right intellect and skills will always out perform an army of morons.
    Don't forget attitude.
    All the developers I know, are more than capable of comprehending Lisp, Smalltalk, Ruby or anything else you want to throw at them - once they've been shown!
    Define "comprehend." I had to actively apply metaclasses and descriptors in Python before I could see the point of using the language. I don't think the majority of the developers with whom I've worked will ever grasp such matters. If you read what many write about Python metaprogramming, you'd say they don't have to. Metaprogramming is black magic for wizards. But I find the idea of people using and abusing things of which they have no comprehension very frightening. So, in my opinion, if you don't understand metaprogramming, you don't understand Python well enough to effectively and safely use it.
  86. Ruby may become mainstream, but if it does it will be like Visual Basic. Most people who use it will have no clue about the magic going on under the hood. The biggest different will be there will be no protective covering over the magic...which will probably burn people.
    Precisely.
    Metaprogramming is black magic for wizards. But I find the idea of people using and abusing things of which they have no comprehension very frightening. So, in my opinion, if you don't understand metaprogramming, you don't understand Python well enough to effectively and safely use it.
    I would go even further - I find the idea of even competent developers using such 'tricks' frightening. Just look at the reputation Perl has obtained for 'write once' code, because so many developers thought speed of coding, brevity and cleverness were more important than clarity and long-term maintenance. I can see a great potential for the same situation happening with other dynamic languages as so many blogs and articles gleefully proclaim the benefits of metaprogramming.
  87. Paul,

    I know this wasn't directed at me, but I feel compelled to respond.

    I read your blog entry. And I must admit it left me fuming. How on earth can we call ourselves a profession when we openly concede that yes Smalltalk and Lisp and even Ruby are great, but are too hard for the average Java joe to comprehend?


    I think "hard" is the wrong word. How is this for you:

    The average developer is unwilling to comprehend Smalltalk, Lisp, and even Ruby.

    If I remember right, Smalltalk was designed so that a child should be able to program it.

    Ruby may become mainstream, but if it does it will be like Visual Basic. Most people who use it will have no clue about the magic going on under the hood. The biggest different will be there will be no protective covering over the magic...which will probably burn people.

    I'll say I've been trying to learn Lisp for almost a decade now, and I've just finally done it (well, to the point I can actually program in it). It's not that Lisp is hard or doesn't make sense or anything like that. It's that its syntax is offensive to someone who's first "real" language was Pascal (I'm disqualifying Basic and Logo), followed by C, C++, Java, and Ada. It took me six months to finally latch on to Python - mostly because most tutorials started out in an interactive prompt and because of the syntax - and without it I probably would have never tolerated Lisp. Someday I'll get around to Ruby, but last time I tried it drove me nuts. Why? It's not Python, so none of my Python skills apply, and pretending it's Java defeats the purpose of using Ruby. If you're going successfully use a language, you have to understand it's paradigm(s), and that takes patience.

    It has been shown time and time again, that a few programmers with the right intellect and skills will always out perform an army of morons.


    Don't forget attitude.

    All the developers I know, are more than capable of comprehending Lisp, Smalltalk, Ruby or anything else you want to throw at them - once they've been shown!


    Define "comprehend." I had to actively apply metaclasses and descriptors in Python before I could see the point of using the language. I don't think the majority of the developers with whom I've worked will ever grasp such matters. If you read what many write about Python metaprogramming, you'd say they don't have to. Metaprogramming is black magic for wizards. But I find the idea of people using and abusing things of which they have no comprehension very frightening. So, in my opinion, if you don't understand metaprogramming, you don't understand Python well enough to effectively and safely use it.
    Hi Erik, I agree with most of what you say here. The things is that a lot more people would be willing and able to comprehend something like Smalltalk, if there was an abundance of jobs out there paying the best rates. The issue in software, as always been one of commercial interests meets computer science, and the two make for an heady mix. As for the difficulty in comprehending metaprogramming. In Smalltalk once you get the idea that a class is an object so must also have a class of it's own which is its meta-class, then the rest is plain sailing. Perhaps in Smalltalk this is easier to grasp because all the objects are there tangible and alive in the image and can be inspected at anytime. So you can inspect class and instance objects and see how they relate. In Python and Ruby it is perhaps more difficult, since these languages have a clear edit then run mode, where in smalltalk there is no distinction, everything is running all the time. Anyway my point is that metaprogramming is not that dificult and idea, it is just perspective again IMO, and how you come to it. Paul.
  88. As for the difficulty in comprehending metaprogramming. In Smalltalk once you get the idea that a class is an object so must also have a class of it's own which is its meta-class, then the rest is plain sailing. Perhaps in Smalltalk this is easier to grasp because all the objects are there tangible and alive in the image and can be inspected at anytime. So you can inspect class and instance objects and see how they relate.

    In Python and Ruby it is perhaps more difficult, since these languages have a clear edit then run mode, where in smalltalk there is no distinction, everything is running all the time.

    Anyway my point is that metaprogramming is not that dificult and idea, it is just perspective again IMO, and how you come to it.

    Paul.
    The ability to deal with classes (and meta-classes) as objects and understand their existence is, by itself, not metaprogramming, and does not raise the sort of issues that, as I read things, some of us are describing. Metaprogramming is the ability for programs to write or manipulate themselves or other programs. It is another layer of abstraction, and does not require OOP. The problem arises when there is layer upon layer of code changing or generating new code, to the point where following what goes on can be difficult. A language like Ruby has a considerable range of metaprogramming features. For example (to use a non-OOP description) functions can be added, removed or replaced at any point in any path through code. It is not so much that inexperienced developers don't realise that it is possible to do these things. It is that they may be naive about the consequences, or simply not care, and so use clever tricks leading to code that is meaningless or misleading to the casual reader, and even worse, can sabotage other code because of the ability to redefine on-the-fly methods in 'base' classes. Things are actually the other way around than you describe; languages like Python and Ruby are both more powerful and more dangerous than Smalltalk because there is so little distinction between editing code and running it. Part of the metaprogramming capability means that new source code can be constructed as the program runs. This is a real issue in these languages that can be of importance even to good developers. There are issues of unpredictability and stability of code which can be very hard to test. There are examples of this happening with Ruby projects involving some of the best Ruby developers.
  89. As for the difficulty in comprehending metaprogramming. In Smalltalk once you get the idea that a class is an object so must also have a class of it's own which is its meta-class, then the rest is plain sailing. Perhaps in Smalltalk this is easier to grasp because all the objects are there tangible and alive in the image and can be inspected at anytime. So you can inspect class and instance objects and see how they relate.

    In Python and Ruby it is perhaps more difficult, since these languages have a clear edit then run mode, where in smalltalk there is no distinction, everything is running all the time.

    Anyway my point is that metaprogramming is not that dificult and idea, it is just perspective again IMO, and how you come to it.

    Paul.


    The ability to deal with classes (and meta-classes) as objects and understand their existence is, by itself, not metaprogramming, and does not raise the sort of issues that, as I read things, some of us are describing.

    Metaprogramming is the ability for programs to write or manipulate themselves or other programs. It is another layer of abstraction, and does not require OOP.

    The problem arises when there is layer upon layer of code changing or generating new code, to the point where following what goes on can be difficult. A language like Ruby has a considerable range of metaprogramming features. For example (to use a non-OOP description) functions can be added, removed or replaced at any point in any path through code.

    It is not so much that inexperienced developers don't realise that it is possible to do these things. It is that they may be naive about the consequences, or simply not care, and so use clever tricks leading to code that is meaningless or misleading to the casual reader, and even worse, can sabotage other code because of the ability to redefine on-the-fly methods in 'base' classes.

    Things are actually the other way around than you describe; languages like Python and Ruby are both more powerful and more dangerous than Smalltalk because there is so little distinction between editing code and running it. Part of the metaprogramming capability means that new source code can be constructed as the program runs.

    This is a real issue in these languages that can be of importance even to good developers. There are issues of unpredictability and stability of code which can be very hard to test. There are examples of this happening with Ruby projects involving some of the best Ruby developers.
    Hi Steve, What I was talking about was comprehending metaprogramming. Being able to inspect instance, class and meta-class objects in Smalltalk did aid comprehension for me. For example I never understood what static methods in C++ were all about, until I saw class methods defined in the Metaclass in Smalltalk. Use and/or abuse of Metagprogramming is something else. Yes it can be abused - but then again so can many things. Like always the most important ingredient is the programmer, and if you don't trust yourself then don't use it. Use something else, like Java :^) BTW, Have you read the blog entry by Tim Bray? It is well reasoned and balanced IMO. I think the real issue here is that people should have the choice to use whatever language they feel is well suited to them and their problem. The difficulty we face is that the skills market is heavilly skewed towards languages like Java and C# which are essentially the same (similiar). I think there is value in alternative ideas, the problem isn't comprehension by developers IMO. The problem is that developers need to see a ready market for these languages before investing time and energy learning new skills. Hopefully, balanced, emotion free assesments like the one in Tims blog will urge people to look at alternatives and help create the necessary critical mass to allow a number of viable alternatives to flourish. Saying that I find Ruby good for somethings, doesn't deminish the value of Java for others. Paul.
  90. Use and/or abuse of Metagprogramming is something else. Yes it can be abused - but then again so can many things. Like always the most important ingredient is the programmer, and if you don't trust yourself then don't use it. Use something else, like Java :^)
    I still don't think you are getting the point. Metaprogramming isn't 'just another thing that can be abused'. It takes the possibility of such abuse to whole new levels, to the point where such abuse can be hard to detect let alone fix. You may be happy about that freedom being available to developers of all standards. It deeply concerns me.
    I think the real issue here is that people should have the choice to use whatever language they feel is well suited to them and their problem.
    But, yet again, this does not address the issue of competence. Developers have been having that choice for a very long time now, and we have seen the consequences.
  91. Hi Steve,

    What I was talking about was comprehending metaprogramming. Being able to inspect instance, class and meta-class objects in Smalltalk did aid comprehension for me. For example I never understood what static methods in C++ were all about, until I saw class methods defined in the Metaclass in Smalltalk.
    Static methods have nothing to do with metaprogramming. The use of Meta referring to classes is nothing to do with the use of Meta in 'metaprogramming'. You are confusing two entirely different concepts. Understanding one is not relevant to understanding the other.
    Use and/or abuse of Metagprogramming is something else. Yes it can be abused - but then again so can many things. Like always the most important ingredient is the programmer, and if you don't trust yourself then don't use it. Use something else, like Java :^)
    Let me explain again what I said in a previous post. The metaprogramming capabilities of languages like Ruby have resulted in actual examples of fragile code even when that code has been produced by experienced Ruby developers. Even highly competent people who have trusted themselves to understand the language have had problems. If even the finest 'ingredients' (programmers) can result in something unpalatable, doesn't that suggest a flaw in your viewpoint? If they have occasional problems producing robust code with Ruby, what hope the rest of us?
  92. Hi Steve,

    What I was talking about was comprehending metaprogramming. Being able to inspect instance, class and meta-class objects in Smalltalk did aid comprehension for me. For example I never understood what static methods in C++ were all about, until I saw class methods defined in the Metaclass in Smalltalk.


    Static methods have nothing to do with metaprogramming. The use of Meta referring to classes is nothing to do with the use of Meta in 'metaprogramming'. You are confusing two entirely different concepts. Understanding one is not relevant to understanding the other.

    Use and/or abuse of Metagprogramming is something else. Yes it can be abused - but then again so can many things. Like always the most important ingredient is the programmer, and if you don't trust yourself then don't use it. Use something else, like Java :^)


    Let me explain again what I said in a previous post. The metaprogramming capabilities of languages like Ruby have resulted in actual examples of fragile code even when that code has been produced by experienced Ruby developers. Even highly competent people who have trusted themselves to understand the language have had problems. If even the finest 'ingredients' (programmers) can result in something unpalatable, doesn't that suggest a flaw in your viewpoint? If they have occasional problems producing robust code with Ruby, what hope the rest of us?
    Hi Steve, The definition from wikipedia:
    Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at compile time during runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually.
    To do this dynamic languages manipulate (change) class and metaclass objects as a way of changing the behaviour of the running program. Java does the same thing to a lesser degree, but without classes and metaclasses as true objects, you have to rely upon the reflection API and the dynamic proxy API. As for the safety of using reflection in Java or in say Ruby, and changing code on the fly using say CGLIB in Java then yes it is dangerous, and I wouldn't want to do it myself. So does that mean we should all stop using Java? Personally, I avoid the use of reflection in Java, and leave it to the framework and library builders. I take the same phylosophy to Ruby and it's use of reflection to create DSLs. I leave it to the framework (Rails). Paul.
  93. To do this dynamic languages manipulate (change) class and metaclass objects as a way of changing the behaviour of the running program.
    No, sorry, you have this wrong. Some dynamic languages do it this way, others don't. If you look at that wikipedia article, the first example of metaprogramming uses bash, which is, by no stretch the imagination an OOP language. There is a possibly confusing term used in metaprogramming - the language which is being manipulated is called the 'object language'. However, that does not mean in any way that it need be an object-oriented language. An understanding of classes and metaclasses in an OOP language has little relevance to the issue of metaprogramming.
    Java does the same thing to a lesser degree, but without classes and metaclasses as true objects, you have to rely upon the reflection API and the dynamic proxy API.
    Again, that is not metaprogramming. That is examining data structures, not writing or modifying code.
    As for the safety of using reflection in Java or in say Ruby, and changing code on the fly using say CGLIB in Java then yes it is dangerous, and I wouldn't want to do it myself.

    So does that mean we should all stop using Java?
    This is a very weak argument. There is all the difference between tweaking things using byte enhancement and having metaprogramming as a core 'cool' feature of the language, which developers are encouraged to use. No-one chooses Java because of its rich metaprogramming capabilities, but that is one reason why Ruby is selected.
    Personally, I avoid the use of reflection in Java, and leave it to the framework and library builders. I take the same phylosophy to Ruby and it's use of reflection to create DSLs. I leave it to the framework (Rails).

    Paul.
    What matters is not how wise you are, but how wise typical developers are. I see no evidence that your wisdom and restraint are widespread - quite the contrary. Metaprogramming is not an obscure part of Ruby - again, it is a major feature of the language that developers are encouraged to use.
  94. re: metaprogramming/ruby[ Go to top ]

    In regard to meta-programming abuse: I've seen exactly what you're talking about. But not just in Ruby...I've seen it in Java, C++, Delphi. Really freaking smart people can create these overly complex frameworks (whether it's a Java class framework or a Ruby meta-language framework) that no one else can understand. I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end. Just like you don't code 100 levels of inheritance for a class hierarchy, or write all kinds of byte code manipulation - you don't write complex meta-programming based frameworks that only one person can comprehend. You apply them where they make sense (like generating XML, build scripts, simulation scripts, aspect type uses). phil
  95. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.
    How?
  96. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.


    How?
    Same way you don't let your uber-programmers write their own web framework instead of using an standard one... good management keeps an eye out and says no.
  97. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.


    How?


    Same way you don't let your uber-programmers write their own web framework instead of using an standard one... good management keeps an eye out and says no.
    But again we are back to issues of quality; this time of project management. I have seen plenty of examples where management was either not up to judging what programmers were doing, or simply trusted them to get the job done. I have seen, and had to fix, too many projects where developers did go off the deep end, resulting in code filled with clever tricks that led to cryptic code that was a support nightmare. Which is why I personally prefer to use, and recommend to others when I get the chance, development languages that aren't as flexible as, say, Ruby or Perl. I have found it too easy to 'go off the deep end' myself - what I thought at the time was clever coding appeared in hindsight (often a long time later) to be cryptic and hard to support.
  98. Re: re: metaprogramming/ruby[ Go to top ]

    I have seen plenty of examples where management was either not up to judging what programmers were doing, or simply trusted them to get the job done.
    I have seen, and had to fix, too many projects where developers did go off the deep end, resulting in code filled with clever tricks that led to cryptic code that was a support nightmare.
    Which is why I personally prefer to use, and recommend to others when I get the chance, development languages that aren't as flexible as, say, Ruby or Perl.
    I have found it too easy to 'go off the deep end' myself - what I thought at the time was clever coding appeared in hindsight
    I..I...I...I..I.. doesn't translate to the experiences of other teams. Steve, what's so hard about answering the question of what languages are robust and what aren't? You want to recommend that people use "robust" languages. So what are they?
  99. Re: re: metaprogramming/ruby[ Go to top ]

    I..I...I...I..I.. doesn't translate to the experiences of other teams.
    It translates to mine. And I have worked at plenty of places to know it isn't isolated to a few.
  100. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.


    How?
    Give them a zillion interlocking frameworks and overlapping standards to sort through just to print ascii over a socket. That'll keep those clever bastards too busy to cause trouble getting stuff done.
  101. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.


    How?


    Give them a zillion interlocking frameworks and overlapping standards to sort through just to print ascii over a socket. That'll keep those clever bastards too busy to cause trouble getting stuff done.
    Well, I don't know about you, but although I have come across code where a developer suddenly decides to use meta-programming for a clever trick, I have never (yet) come across a website where a Java developer suddenly decides to switch to another web framework entirely to do something clever on a page or two. (Although would not suprise me if this has happened). 'Yet another web framework' is certainly a 'feature' of Java, but whatever framework is chosen, it does not raise the same issues as Ruby metaprogramming.
  102. Re: re: metaprogramming/ruby[ Go to top ]

    I don't think the answer is to limit the flexibility of the language. The answer is to be smart and pragmatic about using the language features. Don't let really freaking smart people go off the deep end.


    How?


    Give them a zillion interlocking frameworks and overlapping standards to sort through just to print ascii over a socket. That'll keep those clever bastards too busy to cause trouble getting stuff done.


    Well, I don't know about you, but although I have come across code where a developer suddenly decides to use meta-programming for a clever trick, I have never (yet) come across a website where a Java developer suddenly decides to switch to another web framework entirely to do something clever on a page or two. (Although would not suprise me if this has happened). 'Yet another web framework' is certainly a 'feature' of Java, but whatever framework is chosen, it does not raise the same issues as Ruby metaprogramming.
    Hi Steve, In your zeal to defend Java, you have totally misquoted again. The fact is that with Java you do need to use a number of interlocking frameworks, e.g. JSF, Spring, JDO (your fravorites). With Ruby you use just one - Rails. The other point you choose to ignore is that most of the time we are just pulling strings through a socket, interpreting them as data and writing to a database. How complicated does that need to be? There are significant problems with Java web applications of over complexity, poor OO design etc. Which is why people are looking at simpler, better structured, more productive alternatives. When dealing with strings, bang goes type safety. HTML is not compiled, just interpreted. The web is late-bound and true OO concepts allow you to say things just the once (DRY). As for the extensive use of XML configuration in Java Frameworks like Spring - it all looks like an over complex attempt at late-binding to me. So continue to blame the messengers - Tim, myself, and others are all stupid. Keep on your blinkers if you want to, but some of use would much rather focus on results. Paul.
  103. Re: re: metaprogramming/ruby[ Go to top ]

    In your zeal to defend Java, you have totally misquoted again.
    No. The post referered (I assumed) to generating HTML. There was no mention at all of persistence. If you do want a single framework in Java that does all this, you need look no further than Seam or RIFE. So, it is clearly not a 'fact' that you have to work with multiple frameworks in Java. Me, I like choice. I like the ability to plug in different solutions at different points of an application. However, if you don't want to, there are other ways in Java. You can't claim to support choice in one area, then attack Java because it gives you choice. And I really don't have the time to respond to rest of your post, except to say that I think you need to calm down and realise that I was not calling anyone stupid - I have respect for Tim Bray. This is not a good reaction to a polite attempt to disagree politely with one of his conclusions. I am sorry, but you are just going to have to accept that someone with considerable experience and expertise disagrees with you. I am trying to do this amicably; I have no doubt about your expertise, but I believe your huge enthusiasm for your approaches leads to repeated accusations of closed minds, blinkers, misquoting, and misreading, and it also leads to polarised views of moderate comments. That is not a healthy way to debate. If there is further discussion here, enjoy it. I am sure we will be 'crossing swords' on some other thread at some time in the future...
  104. Re: re: metaprogramming/ruby[ Go to top ]

    In your zeal to defend Java, you have totally misquoted again.


    No. The post referered (I assumed) to generating HTML. There was no mention at all of persistence. If you do want a single framework in Java that does all this, you need look no further than Seam or RIFE. So, it is clearly not a 'fact' that you have to work with multiple frameworks in Java.

    Me, I like choice. I like the ability to plug in different solutions at different points of an application. However, if you don't want to, there are other ways in Java. You can't claim to support choice in one area, then attack Java because it gives you choice.

    And I really don't have the time to respond to rest of your post, except to say that I think you need to calm down and realise that I was not calling anyone stupid - I have respect for Tim Bray. This is not a good reaction to a polite attempt to disagree politely with one of his conclusions.

    I am sorry, but you are just going to have to accept that someone with considerable experience and expertise disagrees with you. I am trying to do this amicably; I have no doubt about your expertise, but I believe your huge enthusiasm for your approaches leads to repeated accusations of closed minds, blinkers, misquoting, and misreading, and it also leads to polarised views of moderate comments. That is not a healthy way to debate.

    If there is further discussion here, enjoy it. I am sure we will be 'crossing swords' on some other thread at some time in the future...
    Hi Steve, I know all your moves now. Firstly you should try reading more carefully before posting. No reference was made to HTML. Secoundly, go ahead and try and turn the tables - we've all read what you've had to say. Your attempts to spread FUD, disguised as reasoned and rational argument has been shown for what it is - FUD. The irony is that people where spreading this same kind of FUD about Java not so long ago :^) How times have changed! As someone else has wisely pointed out, we all need to stop and think. There is nothing to fear, except fear itself. Paul.
  105. Re: re: metaprogramming/ruby[ Go to top ]

    no reference was made to HTML.
    Well, this thread is about web frameworks. It includes mention of PHP, which is primarily for writing HTML, and has no standard framework (like Rails) for simplifying database access. It made sense to me to discuss the common factor.
    Your attempts to spread FUD, disguised as reasoned and rational argument has been shown for what it is - FUD.
    I am sorry you feel this way - I enjoy vigorous debate; if nothing else is it a great way to challenge your own ideas. If anything, this thread has given me even more confidence in some of my cautious views about Ruby and similar languages. I had a only general feeling of caution about Ruby's open classes, but I have now concrete examples of how these can cause problems, and doubts from a well-known Ruby developer about the ability of testing (the panacea of dynamic language supporters) to deal with this. I have also discovered I was wrong about some things; for example, I believed that Smalltalk namespace solutions included methods, but they only handle classes. (But even that has been useful - it gave me an excuse to look again at the rather wonderful Smalltalk/X - which has a far better GUI for general use than Squeak, in my view). This thread has re-inforced my views. Others have proved me wrong. That, surely, is the point - to learn things.
  106. Re: re: metaprogramming/ruby[ Go to top ]

    no reference was made to HTML.


    Well, this thread is about web frameworks. It includes mention of PHP, which is primarily for writing HTML, and has no standard framework (like Rails) for simplifying database access. It made sense to me to discuss the common factor.

    Your attempts to spread FUD, disguised as reasoned and rational argument has been shown for what it is - FUD.


    I am sorry you feel this way - I enjoy vigorous debate; if nothing else is it a great way to challenge your own ideas.

    If anything, this thread has given me even more confidence in some of my cautious views about Ruby and similar languages. I had a only general feeling of caution about Ruby's open classes, but I have now concrete examples of how these can cause problems, and doubts from a well-known Ruby developer about the ability of testing (the panacea of dynamic language supporters) to deal with this. I have also discovered I was wrong about some things; for example, I believed that Smalltalk namespace solutions included methods, but they only handle classes. (But even that has been useful - it gave me an excuse to look again at the rather wonderful Smalltalk/X - which has a far better GUI for general use than Squeak, in my view). This thread has re-inforced my views. Others have proved me wrong. That, surely, is the point - to learn things.
    Hi Steve, Well said, and to think I was about to give up on you :^) Debate and apposing ideas are good, but common ground is good too. The truth is that there is much in common amongst us, but often the debate is painted in black and white. I tend to find that the most enlightening insights are often found in the grey. Looking forward to a more grey debate next time round. Cheers, Paul.
  107. Paul,
    As for the safety of using reflection in Java or in say Ruby, and changing code on the fly using say CGLIB in Java then yes it is dangerous, and I wouldn't want to do it myself.
    I could be run, but I believe most (all?) frameworks perform bytecode instrumentation at class load time. Once a class is loaded, it stays the way it is. This isn't too far removed from C++ template metaprogramming, where code generation is done at compile time. Both are very different from changing code while the application is running.
  108. I could be run, but I believe most (all?) frameworks perform bytecode instrumentation at class load time. Once a class is loaded, it stays the way it is. This isn't too far removed from C++ template metaprogramming, where code generation is done at compile time. Both are very different from changing code while the application is running.
    Well, 'class load time' is still run time, so you won't catch certain kinds of errors until after you've deployed. In stark contrast to C++ template metaprogramming. Thus the need for testing. But anyway that's pretty close to what happens most of the time in Rails as well. For example the first time your model class is loaded the association methods get added. After that it stays the same (except in development where hot deploy of changes is handy). So I think we're talking about a distinction without a difference. If I understand correctly other posters are arguing that Ruby's meta programming capabilities can be misused. Since Java doesn't have those capabilities that's better because mediocre developers can't misuse them. Yet the same or similar capabilities are available for misuse with cglib. The fact that most frameworks and developers don't misuse them suggests that a better approach is not to remove useful features, but to provide best practices as to when and how to use them. Which of course would apply to Ruby's meta-programming capabilities or Java's byte code manipulation libraries. Unless you want to argue that Java's byte code libraries are too tricky for the average developer to use at all so only the clever developers use them. That'd be an ironic position: Ruby is bad for average developers because it's too easy! I don't want to wade into the semantic debate as to what is or is not 'meta programming', so I'll just call it magic. To many developers, Hibernate, Spring DI, and AOP are magic. I've heard exactly the same argument against their introduction -- too much magic going on behind the scenes, too hard to figure out what happened when something goes wrong. They have a point, and certainly there are apps where ORM or DI frameworks would be overkill or not appropriate. However in the long run you're fighting city hall. It doesn't matter if your talking about assembly versus C or whatever. Productivity and higher abstraction always wins out. Some teams will learn the hard way how not to use a new approach, but in the long run the more productive approach with the higher level of abstraction, combined with best practices on how to use it, will win out. The fact is Java programmers are doing 'magic' or using frameworks with magic every day: Spring AOP, cglib byte manipulation, Hibernate SQL generation and cglib enabled lazy loading, annnotations, EL in JSP's, etc. To keep things 'simple' Java the language doesn't support all that stuff so it gets added through the back door with external libraries. The magic is happening anyway, and it's too hard for the average developer to keep up with the plethora of magic technologies used in one app. That's why Rails is better for the average developer: yes there's magic, but it's mostly all Ruby magic all the way through. I'd much rather step through the Ruby code in ActiveRecord try to figure out what the heck cglib is doing. Give me a developer that new nothing but Cobol say, and I could turn them into a competent Ruby on Rails developer much quicker than it would take to train them in Java, Spring, Hibernate, HQL, EL, JSP, JSTL, xml.... Java is for the clever devopers; Rails is better for average developers like me. Steve
  109. The fact is Java programmers are doing 'magic' or using frameworks with magic every day: Spring AOP, cglib byte manipulation, Hibernate SQL generation and cglib enabled lazy loading, annnotations, EL in JSP's, etc. To keep things 'simple' Java the language doesn't support all that stuff so it gets added through the back door with external libraries. The magic is happening anyway, and it's too hard for the average developer to keep up with the plethora of magic technologies used in one app. That's why Rails is better for the average developer: yes there's magic, but it's mostly all Ruby magic all the way through.
    But that is irrelevant. There is CGLIB magic in Java. There is Ruby magic in Rails. It would be fine if the 'magic' were left for the frameworks. But that is not what is happening. No matter how you want to pitch it, Java does not actively encourage such 'magic' as a standard way to develop. You won't find many articles or books on general application development using CGLIB or equivalents. The difference is that with Ruby, metaprogramming 'magic' IS encouraged as a standard approach for development.
    Unless you want to argue that Java's byte code libraries are too tricky for the average developer to use at all so only the clever developers use them. That'd be an ironic position: Ruby is bad for average developers because it's too easy!
    I don't understand why that is ironic. The point of view I am trying to put forward is that languages can be potentially bad if certain dangerous capabilities are too accessible, at least without the language having precautions against the consequences. My view is that this is the case with metaprogramming in Ruby; it is too easy to do dangerous things - a language that is to be used for substantial applications and to produce maintainable code should have barriers against this. This is not ironic - it is a well established principle. For example, it C it was too easy for developers to gain access to 'raw memory' and possibly overwrite data and code (allowing what may be considered to be a very coarse form of accidental metaprogramming!)
    Some teams will learn the hard way how not to use a new approach, but in the long run the more productive approach with the higher level of abstraction, combined with best practices on how to use it, will win out.
    I believe that there is considerable evidence to show that this is wrong, or at least extremely over-optimistic. I have personally dealt with so many examples of how best practices have definitely not won out, even after developers have had years of experience with a language.
  110. The difference is that with Ruby, metaprogramming 'magic' IS encouraged as a standard approach for development.
    Stop confusing RoR with Ruby. Who is encouraging metaprogramming as a standard approach to development? Most rational people would encourage the cleanest, most-straightforward, and maintainable way - which probably wouldn't involve metaprogramming magic for most applications. And once again, according to Steve Zara, what languages are "robust" and what languages aren't? I need a clarification of your handwaving.
  111. Let me explain again what I said in a previous post. The metaprogramming capabilities of languages like Ruby have resulted in actual examples of fragile code even when that code has been produced by experienced Ruby developers. Even highly competent people who have trusted themselves to understand the language have had problems. If even the finest 'ingredients' (programmers) can result in something unpalatable, doesn't that suggest a flaw in your viewpoint? If they have occasional problems producing robust code with Ruby, what hope the rest of us?
    And the non-metaprogamming capabilities of languages like Java have resulted in actual examples of "fragile" code even when that code has been produced by experinced Java developers. Or more generally, even smart people do dumb things sometimes.
  112. And the non-metaprogamming capabilities of languages like Java have resulted in actual examples of "fragile" code even when that code has been produced by experinced Java developers. Or more generally, even smart people do dumb things sometimes.
    Indeed. Because even smart people do dumb things sometimes, it makes sense to try and encourage the wider use of languages that are robust to help reduce the consequences.
  113. And the non-metaprogamming capabilities of languages like Java have resulted in actual examples of "fragile" code even when that code has been produced by experinced Java developers. Or more generally, even smart people do dumb things sometimes.


    Indeed. Because even smart people do dumb things sometimes, it makes sense to try and encourage the wider use of languages that are robust to help reduce the consequences.
    So according to Steve Zara, what languages are "robust" and what languages aren't?
  114. Anyway my point is that metaprogramming is not that dificult and idea, it is just perspective again IMO, and how you come to it.
    You very well could be right. I don't know. All I know is that moving from normal Java or C++ programming to metaprogramming in a dynamic language is a rather mind-bending experience. I don't know if it's the concepts or the transition from the static mindset that is difficult. I'm fairly certain that most developers will not make the leap unless they see significant $$$ on the other side, and the $$$ are drying up where their at. People still make good money writing COBOL. I hear it's actually improving, because there are so few COBOL programmers these days. I'm also fairly certain that a developer without a strong background in static languages is just as stunted as one without a strong background in dynamic ones. So maybe this is an educational problem, but a large portion of developers aren't Computer Scientists or Computer Engineers. They just picked up programming - so how to you influence their education? Ok...I've gone pretty far off topic...you get the point.
  115. Anyway my point is that metaprogramming is not that dificult and idea, it is just perspective again IMO, and how you come to it.


    You very well could be right. I don't know. All I know is that moving from normal Java or C++ programming to metaprogramming in a dynamic language is a rather mind-bending experience.

    I don't know if it's the concepts or the transition from the static mindset that is difficult.
    I believe the difficulty is to do with the modal nature of static programming. We tend to think of our code as dead text on the page (edit mode). It doesn't come alive until we run the program (run mode), where an aplication containing objects, containing, methods etc suddenly bursts into life. The original research into Object Technology didn't see things this way. Smalltalk is modeless. You edit the program whilsts it is running, so no edit/run mode. Infact the whole developent environment is your application and you have to strip stuff out before you ship. It is a different perspective. Languages like Python and Ruby marry this perpspective to the file based edit/run modal programming approach we are all use to. Try Smalltalk and Metaprogramming may not seem such a big deal.
    I'm fairly certain that most developers will not make the leap unless they see significant $$$ on the other side, and the $$$ are drying up where their at.
    People will do what ever is good for their careers, and that usually means following the latest buzz. This is why the pragmatic programmers are marketing Ruby as strong as they have been. There is little new in Ruby, even open classes is possible in Smalltalk, you can add a method to any class in your Smalltalk image, voila open classes. So there is not that much new.
    I'm also fairly certain that a developer without a strong background in static languages is just as stunted as one without a strong background in dynamic ones.
    Actually I've come to the opinion the static programming is a subset of dynamic programming. If you look at the way Strongtalk deals with types, it is actually better at it then C++/Java/C#. Types are orthogonal to objects, but the way they are dealt with in conventional static OO languages introduces coupling between the two concepts that lead to language smells IMO.
    So maybe this is an educational problem, but a large portion of developers aren't Computer Scientists or Computer Engineers. They just picked up programming - so how to you influence their education?
    Smalltalk was designed with children in mind. Squeak is being taught to children in schools around the world today. To a fresh mind, Objects as real tangible things isn't a weird concept, it is actually very familiar. You just need to go back to basics, drop the hybrid blinkers and think pure objects, and it all suddenly makes sense. Paul.
  116. IMO this the developers will never get it attitude is propagated by vendors, who want to keep us dumb and subservient so that they can sell us over hyped and over complex products. Promising to solve all our problems, because naturally we are all too dumb to solve our problems ourselves!

    Speak for yourself - The majority of developers and customers are tired of playing that game, and are taking their destinies into their own hands. All the developers I know, are more than capable of comprehending Lisp, Smalltalk, Ruby or anything else you want to throw at them - once they've been shown!

    Paul.
    I honestly wish I could say the same, but I can't. I have been dealing with other people's code as part of various jobs for 20 years. I have seen code of great quality and elegance, well documented and robust. But, I have seen an equal quantity of code that is extremely poor. The 'developers won't get it' is not propagated by vendors (why should it be? - they have nothing to gain by it - they could make as much from selling great tools for Smalltalk, LISP or Ruby - in fact many do!). It is the sad result of bitter experience dealing with the consequences of poor quality developers. All the developers you know may be capable, but all I can say is I can't say that of all the developers I have known over the years.
  117. IMO this the developers will never get it attitude is propagated by vendors, who want to keep us dumb and subservient so that they can sell us over hyped and over complex products. Promising to solve all our problems, because naturally we are all too dumb to solve our problems ourselves!

    Speak for yourself - The majority of developers and customers are tired of playing that game, and are taking their destinies into their own hands. All the developers I know, are more than capable of comprehending Lisp, Smalltalk, Ruby or anything else you want to throw at them - once they've been shown!

    Paul.


    I honestly wish I could say the same, but I can't. I have been dealing with other people's code as part of various jobs for 20 years. I have seen code of great quality and elegance, well documented and robust. But, I have seen an equal quantity of code that is extremely poor.

    The 'developers won't get it' is not propagated by vendors (why should it be? - they have nothing to gain by it - they could make as much from selling great tools for Smalltalk, LISP or Ruby - in fact many do!). It is the sad result of bitter experience dealing with the consequences of poor quality developers.

    All the developers you know may be capable, but all I can say is I can't say that of all the developers I have known over the years.
    Hi Steve, I think you are making my point. If the first time sone else gets to review another persons code is when they've got to maintain it, then we must be doing something wrong. How will the poor programmers you speak of ever get any feedback? My point wasn't thatb there aren't a load of poor programmers out there, my point was that we need to get better and improving skills across the board. In my experience it doesn't take much. Peer review is a big help. I find that using pair programming and pairing senior staff with junior ones and rotating the pairs on a regular basis works well. Well also break out and discuss design issues as a group should one pair find that they've become stuck. So what I'm talking about is spreading the knowledge. It can be done, I've worked in teams that have done it. Paul.
  118. Hi Steve,

    I think you are making my point. If the first time sone else gets to review another persons code is when they've got to maintain it, then we must be doing something wrong.

    How will the poor programmers you speak of ever get any feedback?
    Unfortunately, I have often seen poor programmers getting feedback from other poor programmers. The quality of pair programming (or other feedback techniques) depends on the quality of the people.
    My point wasn't thatb there aren't a load of poor programmers out there, my point was that we need to get better and improving skills across the board.
    Well, yes... but until then.... we have to deal with the current situation, not an idea future one where all programmers are watched by skilled mentors.
  119. Hi Steve,

    I think you are making my point. If the first time sone else gets to review another persons code is when they've got to maintain it, then we must be doing something wrong.

    How will the poor programmers you speak of ever get any feedback?


    Unfortunately, I have often seen poor programmers getting feedback from other poor programmers. The quality of pair programming (or other feedback techniques) depends on the quality of the people.

    My point wasn't thatb there aren't a load of poor programmers out there, my point was that we need to get better and improving skills across the board.


    Well, yes... but until then.... we have to deal with the current situation, not an idea future one where all programmers are watched by skilled mentors.
    Hi Steve, Maybe I'm not making myself clear. This is no future scenario. Many people do this today. Spread the knowledge amongst the team, that way you are stronger than your weakest link. I like think that we are as as strong as our strongest link on any given area of expertise. People did this long before Agile became fashionable. Back in the day it was called a code review. Paul.
  120. Maybe I'm not making myself clear. This is no future scenario. Many people do this today. Spread the knowledge amongst the team, that way you are stronger than your weakest link. I like think that we are as as strong as our strongest link on any given area of expertise.

    People did this long before Agile became fashionable. Back in the day it was called a code review.

    Paul.
    I know. But my point is that many people don't do this today, or the review is not undertaken by reviewers of sufficient quality or training to understand that the code they are reviewing is distinctly sub-standard. Sometimes the strongest link isn't that strong. Teams, like individuals, vary in quality. We have to deal with that situation.
  121. Maybe I'm not making myself clear. This is no future scenario. Many people do this today. Spread the knowledge amongst the team, that way you are stronger than your weakest link. I like think that we are as as strong as our strongest link on any given area of expertise.

    People did this long before Agile became fashionable. Back in the day it was called a code review.

    Paul.


    I know. But my point is that many people don't do this today, or the review is not undertaken by reviewers of sufficient quality or training to understand that the code they are reviewing is distinctly sub-standard. Sometimes the strongest link isn't that strong. Teams, like individuals, vary in quality.

    We have to deal with that situation.
    Hi Steve, I actually agree. Some teams are better suited to a language like Ruby than others. That's why choice is a good thing, and one size doesn't fit all. PaUL.


  122. I know. But my point is that many people don't do this today, or the review is not undertaken by reviewers of sufficient quality or training to understand that the code they are reviewing is distinctly sub-standard. Sometimes the strongest link isn't that strong. Teams, like individuals, vary in quality.

    We have to deal with that situation.


    Hi Steve,

    I actually agree. Some teams are better suited to a language like Ruby than others. That's why choice is a good thing, and one size doesn't fit all.

    PaUL.
    But this is missing the point. Who decides what a team is suited to, or what technologies they can best handle? It takes a good team to understand the issues. And for a very powerful language like Ruby, with its openness, dynamic nature and metaprogramming capabilities, there are many issues to be considered.


  123. I know. But my point is that many people don't do this today, or the review is not undertaken by reviewers of sufficient quality or training to understand that the code they are reviewing is distinctly sub-standard. Sometimes the strongest link isn't that strong. Teams, like individuals, vary in quality.

    We have to deal with that situation.


    Hi Steve,

    I actually agree. Some teams are better suited to a language like Ruby than others. That's why choice is a good thing, and one size doesn't fit all.

    PaUL.


    But this is missing the point. Who decides what a team is suited to, or what technologies they can best handle? It takes a good team to understand the issues. And for a very powerful language like Ruby, with its openness, dynamic nature and metaprogramming capabilities, there are many issues to be considered.
    The team gets to choose for themselves. Some will succeed, some fail. But we don't need the thought police. Paul.
  124. My point wasn't thatb there aren't a load of poor programmers out there, my point was that we need to get better and improving skills across the board.
    And I think the debate is, at it's core, about what actually constitutes improving skills, or possibly what the skills are that need to be improved. I'm in what I'll call the "white box" camp. I think a programmer should understand how his tools work and should understand the underlying principles of computer science and mathematics. Simply being competent at wielding them is not enough. The purpose of abstractions is to enable the programmer to focus on the problem at hand, not to hide the details or eliminate the need for understanding. I love open source libraries and frameworks because I can see the code, and regularly look at it. Others fall into the "black box" camp. They believe you don't need to know how or why something works - just that it does and how to use it. That's what abstraction is for.
  125. Let's start with the Scaling aspect. There are a few big Web sites that use PHP out there, but they are still nowhere near high-traffic Web sites that Java powers. For these, you need a decent amount of clustering and load-balancing technologies, of which PHP offers none.
    I think the PHP sites out there are actually bigger than the J2EE sites. When we just count page hit or visitors. J2EE is king when we consider web sites with a huge backend doings transactions with multiple databases and/or backend systems. But for the ligth web app, where you have a couple of pages grabbing some stuff out of the database and displaying, then everybody can make the application scalable. PHP inclusive. J2EE can be used as well, but 95% of J2EE is not needed for the job. Making J2EE not a particular obvious choice.
  126. it doesn't scale...[ Go to top ]

    ...crap, java doesn't scale!?... oops. Someone better tell eBay and Amazon quickly that their apps wont scale for large enterprise sites, they may not be reading this. :)
  127. I think the actual link that should have been used is his blog entry: http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks In it he says:
    For Web apps, I've given PHP the edge, because I think building scalable PHP is a little easier. By default, PHP gives you a "shared-nothing" (or at least "shared very little") architecture, which means you’re going to scale out pretty well until your database hits the wall. Java is a much richer system and assumes you're smart enough to know whether a shared-nothing architecture is appropriate or not. The effect is, you have to be smarter to get the same kind of scaling out of Java.
    It's not quite the same as the inflamitory statement "Java is less scalable than PHP".
  128. I think the actual link that should have been used is his blog entry:

    http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks

    In it he says:

    For Web apps, I've given PHP the edge, because I think building scalable PHP is a little easier. By default, PHP gives you a "shared-nothing" (or at least "shared very little") architecture, which means you’re going to scale out pretty well until your database hits the wall. Java is a much richer system and assumes you're smart enough to know whether a shared-nothing architecture is appropriate or not. The effect is, you have to be smarter to get the same kind of scaling out of Java.


    It's not quite the same as the inflamitory statement "Java is less scalable than PHP".
    TSS posting out-of-context flamebait quotes? Never... There must be some confusion. Although he should have posted the explanation blog before this "news" appeared on TSS.
  129. You can write JSP pages by "PHP manner". See for example what Coldbeans in doing. So what is the point?
  130. I think the actual link that should have been used is his blog entry:

    http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks

    In it he says:

    For Web apps, I've given PHP the edge, because I think building scalable PHP is a little easier. By default, PHP gives you a "shared-nothing" (or at least "shared very little") architecture, which means you’re going to scale out pretty well until your database hits the wall. Java is a much richer system and assumes you're smart enough to know whether a shared-nothing architecture is appropriate or not. The effect is, you have to be smarter to get the same kind of scaling out of Java.


    It's not quite the same as the inflamitory statement "Java is less scalable than PHP".
    I would call it rather pointless. How does one make a shared-nothing solution not scalable ? If the requirements for a web app say shared-nothing, then anything should be scalable. PHP. J2EE. Whatever.
  131. RE: it doesn't scale...[ Go to top ]

    Someone better tell Amazon quickly that their apps wont scale for large enterprise sites, they may not be reading this. :)
    I think that the Amazon folks may have other things on their minds: http://www.masonhq.com/?AmazonDotCom
  132. Re: RE: it doesn't scale...[ Go to top ]

    Someone better tell Amazon quickly that their apps wont scale for large enterprise sites, they may not be reading this. :)
    I think that the Amazon folks may have other things on their minds: [..] masonhq [..]
    It has been a couple months since I was at Amazon, but way back then they were still using lots and lots of Java. Peace, Cameron Purdy Tangosol Coherence: Clustered Caching for Java
  133. What I really said[ Go to top ]

    Erik Engbrecht, commenting here, got it right: I should have posted the blog piece before the slides leaked out on the Internet. It is a bit irritating that Igor and TSS went with this flame-bait rather than rushing online with their interpretation of one picture, out of context. Once again, what I really said is here: http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks
  134. Re: What I really said[ Go to top ]

    Erik Engbrecht, commenting here, got it right: I should have posted the blog piece before the slides leaked out on the Internet. It is a bit irritating that Igor and TSS went with this flame-bait rather than rushing online with their interpretation of one picture, out of context.

    Once again, what I really said is here: http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks
    Well, when I saw that post at thinkphp, I tried to find more information over the internet including your site. Having found nothing I made this post. My goal was to attract community attention to this topic and hopefully get more information about what did you actually meant. I apologise for upsetting you. My post wasn't intended to be a flame-bait. The fact that it appreared at the newsfeed here means that TSS editors neither think it is. TSS is very Java-biased community and I believe no flamewar on such subject is possible here. People just express their surprise and disappointment on uncernanity of the context of results your provided.
  135. Discussions, just as usual[ Go to top ]

    To the author... You're right, PHP scales better than Java in a non-reliable application (write to some reliable layer for instance, like a transactional database). You just chain some webservers - not caring about tasks and lifecycles beside request/response. RoR works similiar to this behavior, but is database-centric only and you can do some lifecycle (threading), too. Java provides both and more, too. Of course, Java is type safe and you need to write more code. And that's why Java has a better IDE support. Scalability in Java is on how you define scalability. Do you want to have a scalable web application not counting on a 99,9% QoS with failover, just buy a strong app server machine and some web servers using mod_jk. But if you have an application, which is just more than a web application, where C++ is not productive / cost-effective enough (hey, and some Java VM-Implementations are providing realtime) you'll love Java (or .NET ;). Cost efficiency in technology is dispensable in sectors, where your income depends on the technologies reliability! And that's what Java (and .net) is living from. Each language has its right of being. But all depends on the problem which needs to be solved and which language is the most suitable to get these things done! Zend did their first steps in supporting Java (Beans), which is a wonderful approach in my eyes. And I will use RoR, when I have the time of developing my new personal website ;).
  136. silly me[ Go to top ]

    And to think I dumped php after 4 years because I was experiencing very poor scalability. To be fair though, my php contact form does scales reasonably.
  137. Re: silly me[ Go to top ]

    <?php str_replace('scales', 'scale', $post)?>
  138. I guess this is why java.net can host PHP applications, but they can't host any Java code :) Cheers, Dion
  139. My take on Tim Bray and monkeys[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :) Alas, I do. Heard him speak once at a Java conference... All I remember is - a guy from Sun in a Australian-like hat speaking about how Java looses to dynamic languages like Python and Perl. He was very open about it and the only thing he "asked" the full cinema theater full of Java developers, was to have an open mind and consider. I remember at first it got me rather offended to listen to this, but then it did show some aspects that we can learn from... Anyway I figure he is one of the "troublemakers" that makes the Java pool from becoming a swamp. I am unlikely to try either Ruby or Python in the near future - I am doing quite well with Java, but for sure his message has a place under the Sun, pardon the pun :) As for "think about people as monkeys..." line of thought, it always reminds me of some message that came from Sun one day, something along the line "we have X thousands Java developers in the world and we wont to get another Y thousands, and the best group to target would be VB developers, hence we need to simplify the language"... So to achieve that, we got handed the Java 1.5 improvements, most of which are just plain ugly as far as language syntax goes, but it can be argued that they did improve the language. As long as such thinking is in place, and this is the way to get people into Java, most of developers will be "monkeys" and many of the projects will fail. Alas, programming is yet not taught as Art and what we get is more like "mass production of programmers". With this picture, any claims and language comparison can be made true - the playing field is often too shallow. Just my 2 cents
  140. Re: My take on Tim Bray and monkeys[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :)

    Alas, I do. Heard him speak once at a Java conference...
    Tim is someone of significance - I came across his name years ago as he was heavily involved in the design of XML.
    Alas, programming is yet not taught as Art and what we get is more like "mass production of programmers". With this picture, any claims and language comparison can be made true - the playing field is often too shallow.

    Just my 2 cents
    I am not sure we are getting 'mass production' of programmers - at least then we could be surer of consistent quality. Perhaps software design and engineering needs to be taught something like architecture rather than art - a combination of understanding of materials and good design. The main difference between software engineering and other engineering disciplines is the lack of requirement for qualifications. Not many people would use an architect to design their office unless that architect had formal training and was certified by a recognised institution. At one stage in the 80s, it seemed that a similar process could be established for developers in the UK via the British Computer Society, but it did not seem to catch on, for various reasons.
  141. Re: My take on Tim Bray and monkeys[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :)

    Alas, I do. Heard him speak once at a Java conference...


    Tim is someone of significance - I came across his name years ago as he was heavily involved in the design of XML.

    Alas, programming is yet not taught as Art and what we get is more like "mass production of programmers". With this picture, any claims and language comparison can be made true - the playing field is often too shallow.

    Just my 2 cents


    I am not sure we are getting 'mass production' of programmers - at least then we could be surer of consistent quality. Perhaps software design and engineering needs to be taught something like architecture rather than art - a combination of understanding of materials and good design. The main difference between software engineering and other engineering disciplines is the lack of requirement for qualifications. Not many people would use an architect to design their office unless that architect had formal training and was certified by a recognised institution. At one stage in the 80s, it seemed that a similar process could be established for developers in the UK via the British Computer Society, but it did not seem to catch on, for various reasons.
    The issue of traning for me seems very straight forward. People learn best by example. I see programming as essentially a pratical, pragmatic, intellectual exercise. So refering to it as an art is apt IMO. People tend to pick up such things by working closely with a master crafts person, learning through example by watching on. They also learn through being allowed to make mistakes and having those mistakes critiqued by their seniors. In my experience, team leads have been provding such mentoring for other programmers for years, one of the problems though was just because a person had a given skill on their CV, the managment expectation was that they knew it. So the fact that you didn't know had to be a big secret, especially once you had a few years experience. In recent years I've noticed that people have become more tolerant of the idea that there is a lot to know, and most of us don't know everything. So I see a learning culture and open and honesty as paramount. Also signifiant contact and cooperation amongst developers is needed. So everyone benefits from the strengths of the team. Software is more an art or craft then a science IMO, and we all need to be continuingly learning. Having said this the technical side of the job is well understood - the what to do. The when and why to do it, and the when not is a art though, but it can be taught. If we look to other art forms like journalism, or say fashion design and see how they manage and mentor and brng on talent I think we would find a much more appropriate model for ourselves. Paul.
  142. Re: My take on Tim Bray and monkeys[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :)

    Alas, I do. Heard him speak once at a Java conference...


    Tim is someone of significance - I came across his name years ago as he was heavily involved in the design of XML.

    Alas, programming is yet not taught as Art and what we get is more like "mass production of programmers". With this picture, any claims and language comparison can be made true - the playing field is often too shallow.

    Just my 2 cents


    I am not sure we are getting 'mass production' of programmers - at least then we could be surer of consistent quality. Perhaps software design and engineering needs to be taught something like architecture rather than art - a combination of understanding of materials and good design. The main difference between software engineering and other engineering disciplines is the lack of requirement for qualifications. Not many people would use an architect to design their office unless that architect had formal training and was certified by a recognised institution. At one stage in the 80s, it seemed that a similar process could be established for developers in the UK via the British Computer Society, but it did not seem to catch on, for various reasons.


    The issue of traning for me seems very straight forward. People learn best by example. I see programming as essentially a pratical, pragmatic, intellectual exercise. So refering to it as an art is apt IMO.
    The reason I mentioned architecture is for two reasons - firsly, I have experience of that area through family connections, but secondly because it does combine both art and science/engineering. I think there is a strong parallel.
    People tend to pick up such things by working closely with a master crafts person, learning through example by watching on. They also learn through being allowed to make mistakes and having those mistakes critiqued by their seniors.
    Yes - this is the way architecture works, but architectural teams usually have highly trained, qualified and certified leaders.
    In my experience, team leads have been provding such mentoring for other programmers for years, one of the problems though was just because a person had a given skill on their CV, the managment expectation was that they knew it.
    Addressing your last point first... I totally agree - this is a real problem. As for the first point; I come back to something I keep posting in response to comments here... yes, in an ideal world. The repeated mention of terms like 'mentor' or 'team lead' describes a size and level of organisation that is often absent. Let me try and put the point across by comparison with another profession. In the UK, much building work is done by very small teams - often as few as 2-3 people in a family firm; perhaps even individuals. They learn through experience, but most people have heard of examples of poor quality. Let's translate your approach to builders: "Head builders have been teaching others for years; all builders are capable of learning anything - all they need is for the highly-trained architect on each team to watch what they are doing. They should learn by experience - let all builders work with whatever tools and materials they choose to - sure some things will fall down, but that is part of the learning experience." I am not intending to mock at all here; simply to try and highlight what I disagree with.
    So I see a learning culture and open and honesty as paramount.
    Yes, but this is an ideal, and often not matched by reality.
    Software is more an art or craft then a science IMO, and we all need to be continuingly learning.
    Yes, but what do you do when developers simply won't learn? When they assume that their skillset is all they need, and refuse to believe that things have moved on?
    Having said this the technical side of the job is well understood - the what to do. The when and why to do it, and the when not is a art though, but it can be taught.
    Yes.
    If we look to other art forms like journalism, or say fashion design and see how they manage and mentor and brng on talent I think we would find a much more appropriate model for ourselves.

    Paul.
    The fashion design analogy is perhaps not the one I would have chosen, but is not that bad - you still need to have understanding of materials and 'architecture' :)
  143. Tim Bray is [in]famous[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :)
    Tim is someone of significance - I came across his name years ago as he was heavily involved in the design of XML.
    Yes. He is responsible for XML. Does that merit a medal of honor, or a firing squad? ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Clustered Cache
  144. Re: Tim Bray is [in]famous[ Go to top ]

    I'd love to say I don't know who Tim Bray is, so why should I bother? :)


    Tim is someone of significance - I came across his name years ago as he was heavily involved in the design of XML.


    Yes. He is responsible for XML.

    Does that merit a medal of honor, or a firing squad? ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Clustered Cache
    I did phrase things very carefully - 'significance' is ambiguous :)
  145. Hi All, Just a different take on the issue. I think all this stuff about comprehension and the weirdness of languages like Lisp, Smalltalk, Ruby etc is a red herring. The real issue is that if their was an abunance of jobs requiring people with these languages then developers would willingly learn them as away of progressing in their careers. As it stands today there is little incentive, which is a pity. The real issue in my opinion, is the poor comprehension by many programmers of fundamental ideas like Object Orientation. The reason for this IMO is that their only exposure to OT has been through hybrid languages. So why hybrid? Well the purpose was to leverage the incumbent technology base (both physical and intellectual) rather then to express the new idea (OT) in a high fidelity way. As a consequence IMO we have a large percentage of procedural hackers using hybrid procedural/OT languages and tools. We were warned about this at the beginning by the people at Xerox Parc who did the original research into OT, but these warning went unheeded. So where are we know? After ditching a number of anti-patterns (DTO's EJB's etc) we are beginning to seek cleaner object orientated, message based solutions (POJOs, DSLs etc). This IMO is leading us to languages with a clean, pure object orientated, high fidelity approach. The problem is though, that the hybrid view of objects is very different from the pure view and this can add confusion in itself. Anyone who has a clear view of what objects are all about realises that pure objects are infinately more simple then the static hybrid mess we have been dealing with for years. For example hybrid static languages have no concept of a message send which is an essential concept for pure objects. Instead these languages rely on a virtual function call which was an invention of C++, added to meet the needs of a static optimising compiler. So the problem now is how do you retrain a generation of programmers who have a skewed understanding of OT, based on hybrid procedural/OT languages like C++, Java and C#? Paul.
  146. Hi Paul
    The real issue in my opinion, is the poor comprehension by many programmers of fundamental ideas like Object Orientation. The reason for this IMO is that their only exposure to OT has been through hybrid languages. So why hybrid? Well the purpose was to leverage the incumbent technology base (both physical and intellectual) rather then to express the new idea (OT) in a high fidelity way.
    I guess by hybrid, you mean a language like C++, and by a pure OO language, you would mean something like Smalltalk. As you probably know, OO is not the only paradigm we have. In fact, I contend that OO means so many different things to different things that it's almost meaningless at this point, except to point out that Smalltalk is the canonical example of a pure OO language. As you know, OO is not the only paradigm we have. In fact, as concurency becomes a bigger concern, we're seeing the functional paradigm being considered more and more. We're already seeing it coming to fruition in at least one mainstream programming language - C# 3.0 "Why Functional Programming Matter". That paper expouses the virtues of pure functional programming, but most people don't see OO and FP as mutually exclusive. You mentioned Lisp, and as you probably know, the very powerful CLOS was largely built out of Lisp itself, but Lisp is hardly a pure OO language, and Lisp programmers can choose the appropriate tools - macros, CLOS, functional, for the domain they are writing to. Anyway, I gotta run, but here is an amusing discussion on OO and FP over at Lambda-the-ultimate.
  147. Anyway, I gotta run, but here is an amusing discussion on OO and FP over at Lambda-the-ultimate.
    Thanks for the great laugh. +1
  148. Hi Paul

    The real issue in my opinion, is the poor comprehension by many programmers of fundamental ideas like Object Orientation. The reason for this IMO is that their only exposure to OT has been through hybrid languages. So why hybrid? Well the purpose was to leverage the incumbent technology base (both physical and intellectual) rather then to express the new idea (OT) in a high fidelity way.


    I guess by hybrid, you mean a language like C++, and by a pure OO language, you would mean something like Smalltalk. As you probably know, OO is not the only paradigm we have. In fact, I contend that OO means so many different things to different things that it's almost meaningless at this point, except to point out that Smalltalk is the canonical example of a pure OO language.

    As you know, OO is not the only paradigm we have. In fact, as concurency becomes a bigger concern, we're seeing the functional paradigm being considered more and more. We're already seeing it coming to fruition in at least one mainstream programming language - C# 3.0 "Why Functional Programming Matter". That paper expouses the virtues of pure functional programming, but most people don't see OO and FP as mutually exclusive. You mentioned Lisp, and as you probably know, the very powerful CLOS was largely built out of Lisp itself, but Lisp is hardly a pure OO language, and Lisp programmers can choose the appropriate tools - macros, CLOS, functional, for the domain they are writing to.

    Anyway, I gotta run, but here is an amusing discussion on OO and FP over at Lambda-the-ultimate.
    Hi Frank, I agree. The problem I'm highlighting is that OT has been diluted, confused and banded around as amarketing term for so long that it has become meaningless. If you look at languages that build on the original cononical OT technology like Self, the essentials, (messaging and late binding) are still there, whilst the non-essentials (classes) have been romoved. Most Java programmers will think that the last sentence doesn't make sense, which is my point about poor comprehension. As for functional programming, it as always been part and parcel of pure OT through late binding. As for Lisp and CLOS, I see Lisp as the ultimate meta-language, hence the concepts in Smalltalk can be expressed within LISP as a DSL, which is essentially what CLOS is. This was not the case with C++, the concepts in Smalltalk were diluted and altered to suit the host language (C). For those programmers that understood this C++ was a fine tool, but the vast majority did/do not and hence the problem I'm describe. I would say that 90% of Java programmers I come across haven't a full grasp of OT and happily write procedural code unknowingly. Paul.
  149. Hi Paul
    I agree. The problem I'm highlighting is that OT has been diluted, confused and banded around as amarketing term for so long that it has become meaningless.
    I agree, but I believe it goes even beyond that, to where (back in the early 90s?), OO was supposed to be some silver bullet, and everybody was willing and eager to mold OO to fit whatever tools, languages, and methodologies they were trying to sell.
    I would say that 90% of Java programmers I come across haven't a full grasp of OT and happily write procedural code unknowingly.
    I've thought about that, and it might not totally be java programmers fault. As in most Smalltalks, classes serve a dual-role of namespace and object template. I contend that Java should have had top-level, package-level functions. I've always felt that the Nice Language is what Java should have been if the Nice developers would have had engineering resources. As far as Steve Zara is concerned, the term you're probably looking for is solipsist. He still refuses to say what is a robust language and what isn't. I guess he got caught off guard on someone picking that up.
  150. He still refuses to say what is a robust language and what isn't. I guess he got caught off guard on someone picking that up.
    Not at all. It is just that I know exactly what will happen. I will say 'Java' is robust (although I would also definitely put modern Smalltalks in that category), then you will talk about being able to do harm in any language, I will talk about how all that matters is relative safety, then it will go downhill from there. Sorry if this seemed impolite, but I believe we have such diametrically opposed opinions, that I can't see any point in debating, as we won't get anywhere.
  151. He still refuses to say what is a robust language and what isn't. I guess he got caught off guard on someone picking that up.


    Not at all.

    It is just that I know exactly what will happen. I will say 'Java' is robust (although I would also definitely put modern Smalltalks in that category), then you will talk about being able to do harm in any language, I will talk about how all that matters is relative safety, then it will go downhill from there.

    Sorry if this seemed impolite, but I believe we have such diametrically opposed opinions, that I can't see any point in debating, as we won't get anywhere.
    That's interesting that you put Smalltalk in the "robust" category, but I'm assuming you think that Ruby is not. The reason is because you can sure make a mess of Smalltalk images.
  152. Assembly for scalability![ Go to top ]

    With respect to the notion that “PHP scales better than Java” Mr. Bray uses the following argument: “PHP gives you a “shared-nothing” (or at least “shared very little”) architecture, which means you’re going to scale out pretty well” Maybe in theory the simpler and lighter a framework is, the better it should scale, but in practice thin-architectures provide for thin-results. That reminds me the grudges between high-level and low-level languages. Perhaps Mr. Bray believes that we shouldn’t use any components, or even libraries if we have to develop scalable architectures. Maybe we should even program everything in C or even better Assembly. Cool… Assembly for scalability! (FWIW I highly admire Mr. Bray’s work on other subjects)
  153. Less scalable than PHP? How come when you compile PHP into Java Bytecode, it is 6 time faster than normal? http://www.theserverside.com/news/thread.tss?thread_id=38144 I don't get it. Almost everything I've read through the years is exactly the opposite of what this guy claims. I would take this with a huge grain of salt... I do, however, find it stupid that so many of Sun's sites are written in PHP. Microsoft has no problem eating it's own dog food (i.e. their website), but Sun seems to. At any rate, I'd bet that properly written Java running on a good server is probably one of the *most* scalable platforms out there. Mike
  154. Less scalable than PHP?

    How come when you compile PHP into Java Bytecode, it is 6 time faster than normal?

    http://www.theserverside.com/news/thread.tss?thread_id=38144

    I don't get it.
    Because speed != scalability necessarily. Scalability is a superset.
    I do, however, find it stupid that so many of Sun's sites are written in PHP.
    PHP has it's place, as does RoR. If the sites require minimal business logic, extensibility, and are just CRUD collection of web pages, it's most likely a lot faster to do in PHP. And developers are cheaper:-)
    Microsoft has no problem eating it's own dog food (i.e. their website), but Sun seems to.

    At any rate, I'd bet that properly written Java running on a good server is probably one of the *most* scalable platforms out there.

    Mike
    Absolutely, that's why a complex enterprise app that needs to withhold the test of time, business process changes, extensibility, maintainability, etc... are perfect candidates for Java. I think one of the biggest java strengths is not necessarily it's speed, scalability, etc..., rather it's the popularity of the language and choices of frameworks that are availalble. These frameworks are tested and are in use by production applications, though making it easier to make the decision to go with java. Remember, same app you can write in java, you can write in Perl, Ruby, PHP, Python, etc..., the choice is made based on various factors that are critical to that application and management. Ilya
  155. I stated before, Tim is a veeery sharp guy and I enjoy reading every word he says. Of course I didn't believe when I saw his post about PHP scaling better than java, first because is apples and oranges, second because I was sure his words were interpreted out of context. Anyway, I started to read his blog and found the above quote in which he tries to explain the CONTEXT in which he said those "awful" words about java. From Tim's blog:
    Thus we are not considering general issues of compute performance, because in Web apps, you don’t do much computing. You get some values from the browser, you use them to pull some info out of a database, you report them to the user, maybe you update the database, and that’s about it.
    All I have to say to that we're in danger of considering web applications dumb html generated by a java/PHP backend that reads a database. That's the same as you'd say that "Swing's Hello World" is a complex desktop application. I know the're are out there web applications more complex than CRUD through a web interface, and I am sure there are some written in Java and some written in PHP. That's why I believe any Java - PHP - RoR scalability discussion will only generate flamewar because as in any benchmark and even for a scalability benchmark we simply lack significant numbers/criteria. For performance I'd credit PHP even that I never used it. For scalability, I'm a Java fan though, given that an application should perform more than listing items from a database (well, even there, we can discuss but I won't start :-)) ).
  156. I stated before, Tim is a veeery sharp guy and I enjoy reading every word he says.
    Really? I don't get the same feeling:-) From listening to some of his interviews and reading some of his stuff, I actually dislike most of his abstracted thoughts that are in times just opinions from observation without viable experience.
    Thus we are not considering general issues of compute performance, because in Web apps, you don’t do much computing. You get some values from the browser, you use them to pull some info out of a database, you report them to the user, maybe you update the database, and that’s about it.
    Exactly what I'm talking about. Tim, dude, please don't tie your experience of hacking together your weblog in Perl, to a scalable enterprise application with a web front end. Ilya
  157. Really? I don't get the same feeling:-) From listening to some of his interviews and reading some of his stuff, I actually dislike most of his abstracted thoughts that are in times just opinions from observation without viable experience.
    I am beginning to move towards this point of view, at least for some comments. One example is that he puts RoR above Java in terms of long-term maintenance because of the reduced code size, and claims "The maintenance cost of code is strongly related to its size". As someone who has been developing and supporting very long-term projects, I find little relationship. Ease of maintenance comes from structure and clarity. Code can be sometimes be more easily understood if it is more verbose and explicit. You can be very consise in languages like Perl and Prolog, but the results may be hard to follow. In fact, this viewpoint seems somewhat ironic given that Tim was so heavily involved with XML, in which clarity (and so an improved ability to maintain information) is at least partly due to its verbosity. Information coded in XML can be far larger that in other formats, but one of the advantages of XML is that it helps to ensure that the information remains maintainable. In fact, there is a view that for code that needs to be maintained long-term, additional text in the form of explicit type information can be a significant aid to maintenance. If just one of those 'intrinsic' comparisons is (well, at least in my view) so questionable, it throws doubt on the others.
  158. Hi, i think regardless of the language, it's up to the developer to use the right tool for the job. someone mentioned for small web apps, that using a runtime language is more suitable than something more heavy duty like java, is right on. And I also agree with the other poster that siad for heavy backends/transactions is better suited for Java. One language isn't going to be the silver hammer for every problem. I find myself doing java,perl and ruby development, and have to weigh things various factors (time, costs, maintainence) when I choose what lanaguage to use for a project.
  159. MORE scalable or LESS scalable ?[ Go to top ]

    Gentlemen, there is no such thing like "more scalable" or "less scalable". Your app/technology is either scalable or not. It is a non-functional attribute of your application that you can achieve by a good design. Scalability in few words means that your application is able to digest more load by simply adding more system resources to the HW it is running on. A fast performing application does not mean that it is automatically scalable. If you reach a limit of this app you cannot do anything to allow for more load. On ther other hand a scalable application will gain a second breadth by e.g. inserting an additional 4G of memory or a second processor. The support for scalability by Java, Ruby, PHP is rather correlated on how they support e.g. multithreading. In this case it is quite clear who is the winner.
  160. Re: MORE scalable or LESS scalable ?[ Go to top ]

    The support for scalability by Java, Ruby, PHP is rather correlated on how they support e.g. multithreading. In this case it is quite clear who is the winner.
    Well, first of all, its not that simple. Multithreading is one piece of the puzzle, but not the only, and not always the most important. Also, I dont think that it is "quite clear who is the winner", at all. Anyhow, call me crazy, but I will venture a guess that for 99% of business applications, the bottleneck is the database, and if the application scales or not will be determined in this tier. Fortunately, for database vendors, and the world economy at large, this is also the most expensive tier to scale. Tim Bray? Well, according to http://www.infoq.com/news/2006/11/tim-bray-intrinsics his opinion is actually that: "InfoQ: Why is PHP more scalable than Java? It isn't, but in the Web-app space, it's a little easier to scale (shared-nothing by default); Java requires you to think." Well, so lets think a bit. Or spend time on pointless flamewars.
  161. let's think then[ Go to top ]

    Call me crazy, but I think that for 99% of business applications, the bottleneck is the unskilled programmers not able to write scalable applications. Of course it is not only about multithreading. I wanted to point out that the concept of scalability rather disallows talking in terms of "more" or "less". The clear winner concerning multithreading is of course Java, especially with the freshly integrated concurrency package. So my standpoint summarized is: i don't care how much faster is a PHP web application. If I write the same functionality in Java and I make sure the application scales by adding a new processor, memory card or a new machine in the cluster i go with Java. HW is cheap. And the code aesthetics is an issue for me.
  162. Re: let's think then[ Go to top ]

    The clear winner concerning multithreading is of course Java, especially with the freshly integrated concurrency package.
    Compared to what? PHP? Most people probably deploy PHP applications using mod_php, and how relevant is the speed of threads in PHP then?
  163. MORE scalable or LESS scalable ?[ Go to top ]

    there is no such thing like "more scalable" or "less scalable". Your app/technology is either scalable or not. It is a non-functional attribute of your application that you can achieve by a good design. Scalability in few words means that your application is able to digest more load by simply adding more system resources to the HW it is running on.
    The relationshiph between additional resources and additional processing that can be done is called a Scaling Factor (SF): - An SF of 1.0 indicates linear scalability - An SF higher than 1.0 indicates super-linear scalability - An SF lower than 1.0 but higher than 0.0 indicates sub-linear scalability - An SF of 0.0 indicates a complete lack of scalability - An SF less than 0.0 indicates negative scale Well designed applications tend to scale sub-linearly. Some databases with heavy read loads, for example, can achieve an SF over 0.9 as CPUs are added and enough RAM is present; that is an example of "vertical scaling". Some web applications with heavily read-only content can scale near linearly as servers are added; that is an example of "horizontal scaling".
    The support for scalability by Java, Ruby, PHP is rather correlated on how they support e.g. multithreading. In this case it is quite clear who is the winner.
    It is more than just multi-threading, since for all large applications, one scales by adding servers. In this case, the ability to balance work across multiple servers and avoid bottlenecks within that distributed environment become very important. Right now, due to the maturity of solutions available for Java (such as our Coherence product), I do see that Java has a clear lead in this measure. However, that is changing rapidly, and Ruby and PHP and Python and .NET will all have reached full parity with Java within the next twelve to eighteen months. Peace, Cameron Purdy Tangosol Coherence: Replicated and Partitioned Caching for Java and .NET
  164. ...and Ruby and PHP and Python and .NET will all have reached full parity with Java within the next twelve to eighteen months.
    Should we be expecting a Tangosol product for the LAMP stack space soon? ;)
  165. enter the matrix[ Go to top ]

    Here is my 2c and it's simple as this. Java is the Matrix and Ruby is the real world, well not the real real world we're living in :). In the Matrix, there are rules and regulations that we must follow, hence we become good citizens. On the other hand, the Ruby's world is totally different. You can bend the rules as you like so you can become a very powerful individual (redefine the Class at runtime...). The point is, we human have impulses and we need laws & regulations so that we get along better (project maintainability). This is we live in the world we are now instead of a savage life without rules and regulations. That's why people still want to stay inside the Matrix. As for me, I am not ready to be unplugged yet, but RoR will definitely be in my toolbox! :) there is no spoon... is there?!
  166. I have developed a little PHP and I am relatively new to Java also. My experience so far is, that in general Java can be awesome and awkward depending on the library and framework stack used.

    So, IMHO such a generic result cannot exist.

    From my personal experience all dynamic languages are more error prone and sometimes I loose quite a long time finding such bugs. So I personally prefer static typed ones - but also regarding this, opinions are very different and again a generic conclusion is not applicable.