Discussions

News: Podcast: 10 Things Java Should Steal from Ruby

  1. Podcast: 10 Things Java Should Steal from Ruby (103 messages)

    In this presentation, given at TheServerSide Java Symposium Barcelona in June, Bruce Tate looks at how Java developers, framework designers, and language designers can learn from the capabilities of Ruby to improve Java. He specifically addresses language features, new framework idioms, domain specific languages and Web development frameworks. Download and listen to 10 Things Java Should Steal from Ruby (16.5 MB) The slides for this presentation can be downloaded here. Here are a few excerpts from various parts of the presentation: Bloat in the Java language
    "I believe that Java has been the most successful language of all time. I still believe that. Part of the reason that it got there is due to effective stewardship; the language has been managed beautifully by Sun and the Java community. I think it's really an amazing story when you think how far we've come in 10 years. But when you're successful, you're going to bloat -- you have more customers to satisfy, you have more political interests to satisfy. That's going to lead to additional things in the library and competing interests that tug and pull at Java in unnatural ways. No language is going to last forever. But with a more aggressive approach to the Java language we can be better off and extend the language..."
    Tooling
    "When I interviewed James Duncan Davidson, who was the creator of Tomcat and Ant and responsible for pushing those into the open source community, he said that 'the number one problem with Java right now is that reliance on tools is bullshit'. I think that's a great way of looking at things in that if we start from a cleaner, simpler foundation, then it's much easier to tool on top of that, and you're getting additional leverage by building on top of a cleaner foundation. And that's the approach that some of the other languages have taken...."
    Java on Rails?
    "I'm not saying that we should rebuild Ruby on Rails in Java. I think that would be a fundamental mistake. One of the reasons I think that Ruby on Rails is so powerful is that it leverages the strengths of the Ruby language. We need to do things like Geert (Bevin) does in the RIFE framework to leverage the unique strengths of the Java programming language to give us additional capability..."
    Java Web frameworks
    "I think that there's a reason that Tapestry won the Duke award at this year's JavaOne and part of it is because we're working with straight html; we're working with a straight, clean, templating strategy. Same thing for RIFE, same thing for Wicket. A lot of the Java frameworks have this idea right; wouldn't it be nice to have one standard one?"
    Object-relational mapping
    "I really miss Hibernate, JDO, JPA in Ruby...I think Ruby is really missing the boat and is steering away from enterprise projects that we can't attack because we're not embracing object relational mapping. The inverse is also true, Java is not investing in wrapping approaches. The way that I see it, if you don't need a map, you don't need to be doing object-relational mapping...."
    What do you think -- does Java have a lot to learn from the Ruby language in terms of simplicity? Conversely, is Ruby on Rails on track to become a mature platform for 'serious' enterprise application development, like Java is today?

    Threaded Messages (103)

  2. let the flame wars begin[ Go to top ]

    did someone forget to turn off the repeat button? peter
  3. OK If ruby is so good[ Go to top ]

    Just change languages! Sorry but there is a problem with java. The problem is that java is being used for things that where not designed or not wanted (just like games, sorry but you are a very high level application language, no pedal to the metal with java) In addition, for many things is good, for other things is bad, is not you job to find the best technology?
  4. Re: OK If ruby is so good[ Go to top ]

    Just change languages! Sorry but there is a problem with java. The problem is that java is being used for things that where not designed or not wanted (just like games, sorry but you are a very high level application language, no pedal to the metal with java)
    Groovy 1.0 should be right around the corner.
  5. PHP versus rest of the world ( Java, Ruby etc)[ Go to top ]

    Going by the number of PHP sites I think focus should be on easier scripting language like Groovy. PHP is so simple that anybody can learn it quickly and start developing websites right away. Go to craigslist.90% of teh projects are in PHP.Nobody is developing websites in Java anymore
  6. I think PHP are great for small website with simple/ straight-forward business logic, and there are lots of apps out there that are in the range. PHP is moving towards OO, but most are still using it as a scripting language without much thot to the OO design For enterprise/ heavy weight, i think only Java/J2EE can make the cut. most of us are already struggling to maintain Java/j2ee enterpriese, it will be a very long nightmare to maintain a PHP enterprise project
    Going by the number of PHP sites I think focus should be on easier scripting language like Groovy.
    PHP is so simple that anybody can learn it quickly and start developing websites right away.
    Go to craigslist.90% of teh projects are in PHP.Nobody is developing websites in Java anymore
  7. I think people figured out Java wasn't so hot for building web sites, and moved to PHP. Hopefully, they also figured out that PHP wasn't so hot for building web applications, and moved to Java.
  8. I think people figured out Java wasn't so hot for building web sites, and moved to PHP. Hopefully, they also figured out that PHP wasn't so hot for building web applications, and moved to Java.
    Funny. Maybe the real question is should we be building web applications at all? Did our entire industry take a wrong turn somewhere? Is all this confusion a symptom of a larger problem? ______________ George Coller DevilElephant
  9. I think people figured out Java wasn't so hot for building web sites, and moved to PHP. Hopefully, they also figured out that PHP wasn't so hot for building web applications, and moved to Java.


    Funny.

    Maybe the real question is should we be building web applications at all? Did our entire industry take a wrong turn somewhere? Is all this confusion a symptom of a larger problem?

    ______________
    George Coller
    DevilElephant
    +10
  10. Maybe the real question is should we be building web applications at all? Did our entire industry take a wrong turn somewhere? Is all this confusion a symptom of a larger problem?
    A big yes!. I am doing my part to do it right. :)
  11. Re: let the flame wars begin[ Go to top ]

    Hey peter, you were right about the flames. This time I brought a bag of marshmallows before I read through the postings. Mmmm smores. Hilarious how defensive people get over critiques of the Java platform. If you are getting this emotional over a set of tools you need to spend more time with your families. My 2 cents: Of course Java is getting bloated - that is a fact. Have you seen the size comparisons between the versions of J2SE? Logarithmic growth I believe. Of course Java is extremely verbose. It was based on the C family, which also is verbose. It is very apparent that Java creators were more concerned with practical features (JVM, libraries, etc) than with graceful language design. Java is a kind of ugly language but is still reasonably easy to read - mostly because of its limitations. Java 1.5 has helped a lot with foreach, autoboxing, and generics to make it feel a bit more scripty. My big gripe against generics is that I don't feel that they are all that helpful. I've written many lines of Java and never had a ClassCastException coming from pre-1.5 collections. I just wish autoboxing was smart enough to use non-typed collections and still not require a specific cast to a typed object. List list = new ArrayList(); ... // add a bunch of stuff to the list String myString = list.get(0); I don't really understand the name "generics" anyway. To me the feature should be called "specifics" since by adding strong typing to collections your are not in any way being more generic. From a prettiness standpoint this is just ugly code: List list = new ArrayList(); ... // add a bunch of stuff to the list String myString = list.get(0); ______________ George Coller DevilElephant
  12. Hilarious how defensive people get over critiques of the Java platform. If you are getting this emotional over a set of tools you need to spend more time with your families.
    We can use the same logic to the other side. "It's hilarious how offensive people get over critiques of the Java platform". I like critiques, they help to improve things. What I don't like is the lack of arguments. It works like this: - Someone says "it's 'A'"; - You ask "But why!?"; - The "someone" says "you are so stupid for not agreeing with me"; - Some other one says "it's hilarious how people get defensive..."; You see what I mean? See what the problem is? We should seek healthy and rational conversations, that's all it's needed. If you think in terms of reason instead of emotions you will see that 99% of Ruby proponents are a bunch of boring-one-sided-with-an-agenda-to-promote apologists, looking more like a sales person yelling at you than a professional. I don't care if it's Java or whatever. I only started using Java after many years the hype had ended, and not because someone told me so, but because I really thought Java was a good platform to develop with. I could do the same for any other technology, it's just a matter of reason.
  13. If you think in terms of reason instead of emotions you will see that 99% of Ruby proponents are a bunch of boring-one-sided-with-an-agenda-to-promote apologists, looking more like a sales person yelling at you than a professional.
    83.5% of all statistics are made up you know :-) I'm not sure if you are agreeing with me or slamming me. I'm the one who made the assertion that folks are being over-emotional on this topic. Your 99% crack only diminishes your argument and lumps you in with the rest of the peanut gallery today (though it was funny). Sort of like saying "Hey dummies, Quit calling names!" This is a Java board so it is totally appropriate for me to critique how silly the conversation gets when Ruby is mentioned. I was mainly agreeing with Peter Lin's prediction. Besides, it is Friday so why not laugh? To take a second to be more serious regarding your complaint of a lack of arguments from the Ruby crowd; Isn't Mr. Tate's podcast a list of valid thought-out arguments? Whether you agree with him or not, are you not getting the "reasons why" you state 99% of Rubiests never provide? Mr. Tate will feel flattered to be in that 1%. I'm sure we all agree that Java vs. Ruby leads to insipid conversations. See my own postings for proof. What can Java learn from Ruby is an intersting conversation. Wish someone would publish a podcast or something like that discussing it some time. ______________ George Coller DevilElephant
  14. 83.5% of all statistics are made up you know :-)
    Oh please, why is it so difficult to people to understand each other? We are writing the same language, aren't we? So, you are an intelligent person, and an intelligent person wouldn't consider that number literally but instead as a way of saying "the vast majority of Rubyist Java-bashers don't provide arguments". The number itself is irrelevant. If you think that's not true, that the majority of Rubyist do provide all the arguments anyone would ever need, just say it.
    To take a second to be more serious regarding your complaint of a lack of arguments from the Ruby crowd; Isn't Mr. Tate's podcast a list of valid thought-out arguments? Whether you agree with him or not, are you not getting the "reasons why" you state 99% of Rubiests never provide? Mr. Tate will feel flattered to be in that 1%.
    I don't think he does.
  15. 83.5% of all statistics are made up you know :-)


    Oh please, why is it so difficult to people to understand each other? We are writing the same language, aren't we?
    Well, maybe the problem is that you don't understand that I'm trying to keep it light. See that emoticon? That means don't take it seriously, you know humor?
  16. Re: let the flame wars begin[ Go to top ]

    83.5% of all statistics are made up you know :-)


    Oh please, why is it so difficult to people to understand each other? We are writing the same language, aren't we?

    Well, maybe the problem is that you don't understand that I'm trying to keep it light. See that emoticon? That means don't take it seriously, you know humor?
    Maybe it's the heat. It seems like a lot of people in this thread have been quick to take offense. Time for a cold beer. Java will still be there in the morning.
  17. LISP takes over the world[ Go to top ]

    Hi, my name is LISP - and all your base (Java, Ruby, C#, etc) are belong to us. G'day.
  18. I agree with some of the statements that he makes about improving the language - things like closures and continutations can be added, and should be added, at the language level without destroying backward compatibility. But when it comes to the frameworks I think differently. There are plenty of frameworks out there trying to really improve ease of development and simplicity in Java. Hell, I wrote one (and I think it's pretty damn good). The problem is that the Java *community* is full of people who think enterprise==complex==good. If the community isn't ready to radically simplify, no amount of changes in the framework landscape will help them. -Tim Fennell Stripes: Because web development should just be easier.
  19. Java Community is not THAT bad[ Go to top ]

    The problem is that the Java *community* is full of people who think enterprise==complex==good. If the community isn't ready to radically simplify, no amount of changes in the framework landscape will help them.
    I strongly disagree with this statement. I think that the Java community should be given the proper respect for being open and adaptive. Two prominent examples are Hibernate and Spring. Both of them are not based on standards, changed some basic concepts (for the better), and got adopted all over the board. Banks use Spring and Hibernate, and Banks are one of the more difficult environments to introduce new technologies ("nobody gets fired for buying IBM"). Naturally, there are people that fit your equation, but that is what happens when a language is popular (expect it to happen to Ruby as well if it gets widespread). Even the commotion and discussion that happens around Ruby within the Java community shows that Java developers listen. New web frameworks are spreading like wildfire, mainly as a response to Ruby on Rails, which shows that Java developers are trying to find a better/simpler/easier way. My view is that it is just a matter of time. We, the Java community, need to find our way to match the simplicity Ruby and Rails introduce. I would be worried if a standard solution (standards are important) would suddenly appear, without proper thinking or evaluation. I say let evolution take its course, and I am sure that certain features will find their way into the Java language, let it be directly within the Java language, or with the stability and widespread usage of JVM based scripting languages. It does not mean though, that people should not speak up, and speak loud. It gets thing moving. Shay Compass: Java Search Engine Framework
  20. Re: Java Community is not THAT bad[ Go to top ]

    Banks use Spring and Hibernate, and Banks are one of the more difficult environments to introduce new technologies ("nobody gets fired for buying IBM"). Naturally, there are people that fit your equation, but that is what happens when a language is popular (expect it to happen to Ruby as well if it gets widespread).
    I agree. There will be people using Ruby even when it is not the best tool for the job if Ruby becomes as wide spread as Java is today. Many in the Ruby Community are aware of this, and they do not want Ruby to become too popular, fot that very reason. The way I see it is that there are leaders and followers. In the early days most of the Java community were leaders. Today along the way IMO the leaders have become out numbered by followers, or maybe many of the original leaders have moved on to Ruby :^). My view of the future is one where concepts and ideas are more important than specific brands. In such a future programmers are comfortable being multi-lingual. Selecting the language that offers the right mix of concepts and features for the problem at hand. No mass herd, just choices, and programmers able and willing to exercise choice. Better still, inter-language operability would be nice. Paul.
  21. Re: Java Community is not THAT bad[ Go to top ]

    I strongly disagree with this statement. I think that the Java community should be given the proper respect for being open and adaptive. Two prominent examples are Hibernate and Spring.
    This largely illustrates my point if you ask me. I'm not saying that there aren't folk in the Java community that are innovative (that's altogether different). Nor that there aren't a small percentage (which would still be a lot of developers) who do focus on simplicity. But Hibernate as an example of a community committed to simplicity? You've got to be kidding? Hibernate is awesome, it can handle almost anything. But simple? No. I read an interview with Gavin somewhere where he describes that he started out to build something simple, and that hibernate ended up "unabashedly complex". The truth is it is complicated - and it's overkill for a lot of smaller/simpler applications where something like ActiveRecord is easier to pick up and get going. As for Spring, I know a lot of people like Spring. And Spring *is* simpler by far than the EJB spec it was initially a reaction to. But my personal opinion is that there's too much externalized configuration and that it promotes over de-coupling. But that's just my 2c and other will (vehemently) disagree. -Tim Fennell Stripes: Because web development should just be easier.
  22. +1
  23. Re: Java Community is not THAT bad[ Go to top ]

    But Hibernate as an example of a community committed to simplicity? You've got to be kidding? Hibernate is awesome, it can handle almost anything. But simple? No. I read an interview with Gavin somewhere where he describes that he started out to build something simple, and that hibernate ended up "unabashedly complex". The truth is it is complicated - and it's overkill for a lot of smaller/simpler applications where something like ActiveRecord is easier to pick up and get going.
    I think that you missed my point. I did not stated that Hibernate is simple (though it is simple for a fully pledged ORM framework). The point I was trying to make is that there was a problem in this area (Entity beans), it was acknowledged, and a simple tool came out of it. Now, Hibernate was created when Java was already popular, and got rave acceptance within the community, even though it was not based on standards, and probably considered dangerous to adopt for standards focused companies. Same thing happened with Spring, the fact that things needed to be simplified, and a framework emerged, again with great acceptance by the Java community (side stepping your view of Spring drawbacks, since it is not the point). The same thing will happen with what Ruby and Rails brings to the table, and we should be more confident of our Java community to be able to match it, as it has done before. Both the leaders and innovators to create it, and the masses to acknowledge and use it.
  24. I am a bit tired of hearing the "We need to make Java and/or J2EE simpler" mantra. If we want to make it easier for first semester computer science to learn the language then maybe. If we want to have hobbyist web developers create their cats homepage in JSP then maybe. But if we are talking professional software development, then I do really not see the point. I can not recall ever having seen a real world project where Java and/or J2EE learning curve was a real problem. It is always domain specific problems and the classic hard to solve technology independent enterprise architecture problems that gives problems. Smart tools and getting rid of various cryptic syntax may make Hello World programs easier. But they will not make bad programmers good programmers or in any other way effect real world projects.
  25. reality ain't always easy[ Go to top ]

    re: message#214818 from Arne Vajhøj
    I am a bit tired of hearing the "We need to make Java
    and/or J2EE simpler" mantra.

    If we want to make it easier for first semester computer
    science to learn the language then maybe....But if we are talking professional software development,
    then I do really not see the point....

    It is always domain specific problems and the classic
    hard to solve technology independent enterprise
    architecture problems that gives problems...
    Well said! 'Language Wars' is a waste of time. Ruby/Rails addresses a class of applications. Various Java API's and tools address other classes of applications. PHP, yet others. etc The tools should automate the mundane and mechanical aspects, but non-trivial problems require hard work to solve. Choose the best fit for the entire circumstances, business and technical, and get on with it!
  26. Yay enough of this increasingly idiotic simplicity mullahs. Yes, JAVA is too complex unfortunately, for Journalism majors trying to meke it out in IT and FUNCTIONAL gunk trying to slip by wearing an OO camouflage. If there is one thing that JAVA belts the shit out of these "Functional Ayatollahs" is SHIPPING IT. yea, right. How many attention grabbing products did these scripting wunderkids ship in the last 30 years that were supported by functional BS. Compare that with the gigantic IT landscape built with Java. And rightly so, Java is dead, only after you are long gone. Oh wait, before you mention some "maps" grabbing attention, it pays to KNOW what it is SUPPORTED by. SHOW ME THE RESULTS, Bruce Almighty.
  27. title of the podcast is bogus[ Go to top ]

    Bruce's talk is not "10 things java should steal from ruby" but more about expanding your thinking beyond the limitations of java.
  28. Ruby on rails with diamonds ...[ Go to top ]

    One of the reasons I think that Ruby on Rails is so powerful is that it leverages the strengths of the Ruby language
    Hey, has anybody realized that Ruby language is actually older than Java ? So why did Java blasted the world when Ruby staid in diapers untel RoR get out and Bruce Tate decided that he may have more money to make with this "new" beast? Xtreme programming, Agile Programming, AOP, AJAX, RoR... 6 months and them, net buzzword :)
  29. Scripting languages are for pussies[ Go to top ]

    This is one of the best blogs I've read that mirrors my feelings on scripting languages: http://discuss.joelonsoftware.com/default.asp?joel.3.309321.3 Bill
  30. Listen to the podcast[ Go to top ]

    Has anyone that responds negatively to this topis actually listened to the podcast? Bruce is extremely constructive here. Don't dismiss his message due to out-of-context titles and excerpts. Java is indeed not the "end all" of programming languages, and it's certainly not perfect. Be happy that Bruce stands up and gives a well researched summary of what we can learn from Ruby. It takes courage to publicly take the unjustified heat for this. You can bury your head in the sand and continue chanting that Java is wonderful while bashing anyone who has justified critisims, just don't come back crying in 5 years about how you became so uncompetitive with your technical toolset. At least Bruce is giving feedback about his findings and putting a lot of effort in finding the best way to explain the essence of what needs to be done in this area. I for one thank Bruce a lot for daring to speak up like this for the needs of "the long tail" in the Java community since I'm mostly part of it. Thanks to the well earned reputation from his writing, many people are at least now starting to open up to what needs to be done to move Java forward in other areas than the enterprise. Bruce, I hope you'll continue this effort and I admire that you stay on course even though it's easy to be dishearted by some of the negative voices out there!
  31. Re: Listen to the podcast[ Go to top ]

    No I haven't listened to the podcast, is that bad? I think however, I'm aware of the 'hidden agenda' for Bruce --- selling books: http://www.amazon.com/s/102-9196531-2260925?ie=UTF8&index=books&rank=-relevance%2C%2Bavailability%2C-daterank&field-author-exact=Bruce%20Tate Obviously he has every right to do so, but that doesn't mean we should listen to him. We have to stay focused an building actual applications, which is not that hard using Java/JEE.
  32. Re: Listen to the podcast[ Go to top ]

    No I haven't listened to the podcast, is that bad? I think however, I'm aware of the 'hidden agenda' for Bruce --- selling books:
    Resistance is futile, despite you "meddling kids" uncovering his evil plan. You will buy the books. You will program in Ruby.
    Obviously he has every right to do so, but that doesn't mean we should listen to him.
    Oh no, listening is mandatory for we. That's the only way the subliminal messages ("program ruby....program ruby.....program ruby") will work.
  33. Re: Listen to the podcast[ Go to top ]

    No I haven't listened to the podcast, is that bad? I think however, I'm aware of the 'hidden agenda' for Bruce --- selling books:
    Well I'm believing Bruce when he's saying that he's not really making money from his books if you look at the amount of time that it takes to write them. Have you ever written one? Unless you're an absolute best seller (not even just selling decently well), consulting pays a lot more. So, Bruce would have decided to undermine his well working Java consulting work just to sell a couple of thousand more copies of his books? I doubt that. Actually, I know for a fact that the out-of-context quotes on sites like this have hurt his business more than increase it. In the meantime he has decided to make the leap of faith and converted his consulting business into one that focuses more on Ruby (you'd know that if you'd have listened to the podcast or were at the conference). Even then though, he has not much to gain for his consulting besides reputation by clearly illustrating how Java can improve and learn from other languages. Come on man, is it that horrible for you to admit that Java is not flawless and can improve by picking up ideas that come from more dynamic languages? What's so bad about that? Be glad that people are on the watch-out for things like this and try to let our development platform evolve. They could just move on and not care. I'm happy that he takes the trouble to do so. Now besides all that, imagine he does get some financial reward for all his efforts, is that such a terrible thing? Speaking at conferences, posting on public forums, writing articles all takes a lot of time. You do get paid for your time, don't you? All the Bruce-bashers out there, maybe you should take the effort of having a drink with him or dinner and actually engage into a real conversation with him, you might be surprised at the man you discover. He's a very generous and respectful guy with his heart in the right place and a very high moral standard. I'm happy to know him in person and am thankful that he continues to stand up against all the crap and continues to speak his mind.
  34. Re: Listen to the podcast[ Go to top ]

    Geert: I'm sure your defence of Bruce has nothing to do with the positive quotes about RIFE in all this material ;) (Just kidding - please don't jump down my throat). In all honesty this is the first material from Bruce in a while that hasn't raised my hackles. The whole Beyond Java fiasco felt not good. I think Bruce has been integral (whether he intended it or not) in making the conversation about RoR/Ruby being the successor and "taking over" Java, instead of it being a conversation about simply the rise of Ruby and what it's good for (as is more the case with the Python community). But in this instance I agree with you. I think Bruce has done a good job describing what he thinks are the things that need to change in Java land to improve it's competitiveness. I don't agree on all his points - but this is a helpful contribution nonetheless. As I said above though, I think the Java community is going to have a hard time swallowing some of these changes. I think a lot (though clearly not all) of the Java guys who shoot for simplicity and productivity have left to the Ruby community. And so we're left with the 10% of the community who actually read TSS/blogs/articles, out of which some want to make things simpler. And 90% who are uninterested in the community aspect and just want to keep using their current skills in their current job. Maybe I'm being too harsh here - but this seems to me to be the #1 problem holding Java back in many of the areas Bruce talks about. -Tim Fennell Stripes: Because web development should just be easier
  35. Re: Listen to the podcast[ Go to top ]

    Geert: I'm sure your defence of Bruce has nothing to do with the positive quotes about RIFE in all this material ;)/
    Of course it hasn't, but it did get us both to talk about many things and to eventually meet in person. However, Bruce is speaking a lot of good about better known and more established Java solutions like Spring and Hibernate. So this hardly is a secret plot between friends to pat themselves on the back. Please don't reduce yourself to insinuations like that, Tim.
    In all honesty this is the first material from Bruce in a while that hasn't raised my hackles. The whole Beyond Java fiasco felt not good. I think Bruce has been integral (whether he intended it or not) in making the conversation about RoR/Ruby being the successor and "taking over" Java, instead of it being a conversation about simply the rise of Ruby and what it's good for (as is more the case with the Python community).
    Are you talking about things that Bruce has actually said himself, or about how others have taken quotes from him out of context and went spinning around with that? Like the "dead like Elvis" thing?
    Maybe I'm being too harsh here - but this seems to me to be the #1 problem holding Java back in many of the areas Bruce talks about.
    I think you're overstating it a lot. Some vocal Java users have gone, but I'm betting that 99.99999% is still there. Actually it seems that at last projects like yours and mine, like Grails and Trails, ... have at last received some credibility and room to prove themselves. Actually, I'm quite enthusiast about the possibilities that have been opening up lately, even Sun is starting to listen. This is partly thanks to Bruce's efforts. Yes, he did oversimplify things and yes, he has not always phrased his statements as carefully as possible, but then again most people don't listen if things are not simplified are maybe even shocking.
  36. Re: Listen to the podcast[ Go to top ]

    Sorry, forgot to preview the previous one, reposting for clarity...
    Geert: I'm sure your defence of Bruce has nothing to do with the positive quotes about RIFE in all this material ;)
    Of course it hasn't, but it did get us both to talk about many things and to eventually meet in person. However, Bruce is speaking a lot of good about better known and more established Java solutions like Spring and Hibernate. So this hardly is a secret plot between friends to pat themselves on the back. Please don't reduce yourself to insinuations like that, Tim.
    In all honesty this is the first material from Bruce in a while that hasn't raised my hackles. The whole Beyond Java fiasco felt not good. I think Bruce has been integral (whether he intended it or not) in making the conversation about RoR/Ruby being the successor and "taking over" Java, instead of it being a conversation about simply the rise of Ruby and what it's good for (as is more the case with the Python community).
    Are you talking about things that Bruce has actually said himself, or about how others have taken quotes from him out of context and went spinning around with that? Like the "dead like Elvis" thing?
    Maybe I'm being too harsh here - but this seems to me to be the #1 problem holding Java back in many of the areas Bruce talks about.
    I think you're overstating it a lot. Some vocal Java users have gone, but I'm betting that 99.99999% is still there. Actually it seems that at last projects like yours and mine, like Grails and Trails, ... have at last received some credibility and room to prove themselves. Actually, I'm quite enthusiast about the possibilities that have been opening up lately, even Sun is starting to listen. This is partly thanks to Bruce's efforts. Yes, he did oversimplify things and yes, he has not always phrased his statements as carefully as possible, but then again most people don't listen if things are not simplified are maybe even shocking.
  37. Re: Listen to the podcast[ Go to top ]

    Geert: I'm sure your defence of Bruce has nothing to do with the positive quotes about RIFE in all this material ;)

    Of course it hasn't [snip] So this hardly is a secret plot between friends to pat themselves on the back. Please don't reduce yourself to insinuations like that, Tim.
    Come on Geert, talk about mis-quoting? Did the red haze decend before I said I was just joking? I don't really believe you and Bruce are in cahoots - I thought you could take a little joke.
    Are you talking about things that Bruce has actually said himself, or about how others have taken quotes from him out of context and went spinning around with that? Like the "dead like Elvis" thing?
    I'm talking about things Bruce wrote. I'm interested enough in Ruby and what's going on to keep up to date and so I did read Beyond Java cover to cover. My reaction to it was that there were some good facts and ideas in the book but it was presented in a much more Java vs. Ruby way than was necessary to make the point. Ruby *is* a fun language. So is Python and a big bag of others. It doesn't mean it has to replace Java and always talking about it from that angle is unnecessarily sensationalist. I admit, I haven't had a chance to hear Bruce speak, and perhaps his previous material comes across better in person?
    I think you're overstating it a lot. Some vocal Java users have gone, but I'm betting that 99.99999% is still there. Actually it seems that at last projects like yours and mine, like Grails and Trails, ... have at last received some credibility and room to prove themselves.
    Maybe I'm overstating the who's left part, but my gut feeling is still that the bulk of the Java community has been exposed to so much pain over the years (EJB, early JSP, Struts 1.x, performance woes early in life, lack of some neater language features) that it has developed an enormous tolerance for pain. And it's just that tolerance that stops a lot of people standing up and asking "hey, couldn't this be easier?". Or worse, even when presented with simpler/easier solutions questioning their validity because they are not complex enough ;) -Tim Fennell Stripes: Because web development should just be easier
  38. Re: Listen to the podcast[ Go to top ]

    Come on Geert, talk about mis-quoting? Did the red haze decend before I said I was just joking? I don't really believe you and Bruce are in cahoots - I thought you could take a little joke.
    Sure I can, but with these subjects I'm extra careful. I also have already been burned in these Ruby-Java discussions.
    I admit, I haven't had a chance to hear Bruce speak, and perhaps his previous material comes across better in person?
    To me it has always been clear that Bruce talked about niche markets and specific use cases of web apps that babysit a database. I never saw it as a message that announced Ruby overthrowing Java and everything it's good at. However, for most non expert programmers, writing a simple database-driven web application is immensely easier to do in a dynamic language than in Java. Nowadays Bruce does state this up front when he's talking, so that little confusion can be made (unless people don't actually listen to the recorded material of course).
    And it's just that tolerance that stops a lot of people standing up and asking "hey, couldn't this be easier?". Or worse, even when presented with simpler/easier solutions questioning their validity because they are not complex enough ;)
    I'm with you there, however it's not that bad yet. In many shops people don't actually care all that much, they just use what they're told to use. It will take a long time for the real crowd to even look up and really investigate what all the fuss is (was) about. 100% re-training and completely throwing away existing IP is more than what most people can affort, even for smaller shops. We have time to steer our platform in direction that takes better care of simplification.
  39. Re: Listen to the podcast[ Go to top ]

    Come on Geert, talk about mis-quoting? Did the red haze decend before I said I was just joking? I don't really believe you and Bruce are in cahoots - I thought you could take a little joke.
    Sorry Tim, I didn't get the joke either.
    Are you talking about things that Bruce has actually said himself, or about how others have taken quotes from him out of context and went spinning around with that? Like the "dead like Elvis" thing?
    Even the "dead like Elvis" thing was a quote taken out of context. It was suppose to be a joke but people didn't get it either.
    I admit, I haven't had a chance to hear Bruce speak, and perhaps his previous material comes across better in person?
    You should, he can certianly hold his own amoung the best, entertaining, lots of energy, great ideas and most importantly, he leaves you thinking. Kirk
  40. Re: Listen to the podcast[ Go to top ]

    I think a lot (though clearly not all) of the Java guys who shoot for simplicity and productivity have left to the Ruby community.
    You mean to say the Ruby on Rails community? Let's just remove all RORs and Active records from Ruby just for a thought experiment, and then ask youself again, if you are willing to jump to the Ruby bandwagon for simplicity and productivity. My guess is that almost 100% would say no, and they did, up until RoR came around. SO where's the real value? Is that same value available to Java? It's pretty clear that a language does not define the value alone. To me, after a certain treshold, things never are about the programming language, so I am very cautious to make any wholesale switches. I waited for years before starting to use Java.
  41. Re: Listen to the podcast[ Go to top ]

    Hi, I was hoping to keep out of this one but...
    My guess is that almost 100% would say no, and they did, up until RoR came around.
    Your guess based on what? Have you used Ruby? or any dynamic language for that matter?
    SO where's the real value?
    Well were shall I start: 1. Uniform abstractions (everything is an object, no primitives). 2. Full polymorphism through message sending 3. Full closures 4. Continuations 5. Immediacy of development 6. Classes as first class objects 7. Meta-programming 8. Functional programming 9. 80% of the expressiveness of Lisp style macros 10. Higher order functions 11. Internal DSL's 12. Editing code whilst it's still running. 13. Object Memory 14. Object specific classes 15. Mixins 16. ... Shall I go on? Ignorance is bliss. Paul.
  42. Re: Listen to the podcast[ Go to top ]

    1. Uniform abstractions (everything is an object, no primitives).
    2. Full polymorphism through message sending
    3. Full closures
    4. Continuations
    5. Immediacy of development
    6. Classes as first class objects
    7. Meta-programming
    8. Functional programming
    9. 80% of the expressiveness of Lisp style macros
    10. Higher order functions
    11. Internal DSL's
    12. Editing code whilst it's still running.
    13. Object Memory
    14. Object specific classes
    15. Mixins
    16. ...

    Shall I go on?

    Ignorance is bliss.

    Paul.
    Well, it does sound like a great list. We should probably add 20 more cool features and more syntax elements to the language while we are at it. It makes it so much better.
  43. Re: Listen to the podcast[ Go to top ]

    1. Uniform abstractions (everything is an object, no primitives).
    2. Full polymorphism through message sending
    3. Full closures
    4. Continuations
    5. Immediacy of development
    6. Classes as first class objects
    7. Meta-programming
    8. Functional programming
    9. 80% of the expressiveness of Lisp style macros
    10. Higher order functions
    11. Internal DSL's
    12. Editing code whilst it's still running.
    13. Object Memory
    14. Object specific classes
    15. Mixins
    16. ...

    Shall I go on?

    Ignorance is bliss.

    Paul.


    Well, it does sound like a great list. We should probably add 20 more cool features and more syntax elements to the language while we are at it. It makes it so much better.
    We need to be honest about exactly what Java is. Java was a pragmatic solution at the time, mixing some of the ideas of Smalltalk (byte code VM, automatic memory management), with the efficiency and syntax of C++. Sun saw a gap and filled it. At the very same time they already had a language that could do everything Ruby can today and a lot more, it's called Self. They chose not to market Self because they knew that microprocessors at that time couldn't deal with it and C/C++ programmers would not take to it (it looked a lot like Smalltalk). Since 1995 moores law has given us a 25 times improvement in performance. All the Ruby guys have done, is gone back to the high level languages of the past and implemented the features (from Lisp, Smalltalk primarily) using an Algol like (C like ) syntax. My point is that we shouldn't care whether the language is called Lisp, Smalltalk, Java, Ruby or whatever. What we should care about is the concepts and features that we feel will meet our needs (speed of development, runtime performance or whatever). I posted an article that demonstrates that in many ways the dominate OO languages of today are rather primitive compared to what is possible. TSS didn't publish though. Silly me, I thought that programming was an intellectual exercise, yet the TSS seems more interested in a fashion show. Paul.
  44. Re: Listen to the podcast[ Go to top ]

    Hi,

    I was hoping to keep out of this one but...
    No, I believe your post is perfect to illustrate a logic flaw in the mind of Ruby zealots.
    Well were shall I start:

    1. Uniform abstractions (everything is an object, no primitives).
    2. Full polymorphism through message sending
    3. Full closures
    4. Continuations
    5. Immediacy of development
    6. Classes as first class objects
    7. Meta-programming
    8. Functional programming
    9. 80% of the expressiveness of Lisp style macros
    10. Higher order functions
    11. Internal DSL's
    12. Editing code whilst it's still running.
    13. Object Memory
    14. Object specific classes
    15. Mixins
    16. ...

    Shall I go on?

    Ignorance is bliss.

    Paul.
    The flaws: - No weight on good sides and bad sides. You just assume "more is better", and Ruby has no "bad things", it's all "good things"; - Non sensical list of features. As if the only thing used as a measure for choosing one technology over the other is the "list of language features". While we are at it, why don't we do the same thing for the other hundreds of languages? Have you ever considered the tools you will need? What about the frameworks? What about the libraries? It's ridiculous to think "Ruby is simple, we need no stikin' IDEs", any big enough project will be complex. If you haven't found any in Rubyland is because nobody is building them. We have diversity in Javaland, you may not like learning new frameworks, but at least we have a choice. And the standard class library from Java is unbeatable, plus the lots of opensource makes it very attractive and productive for development. People always underestimate the value of a good class library. In my opinion, that's the reason that differentiates Java from the rest. And Ruby is OLDER than Java, shouldn't it have more of everything I have just cited? - No sense of purpose or applicability. If you cited the feature plus something like "that enables me to add .... to my business. Impossible using Java" I would give some credit to it; - Dubious "good things", i.e, "Uniform abstractions". WTF!? - Anecdotal evidence, sort of wishful thinking, like in "Immediacy of development"; - Internal DSLs? Oh, Unix had some DSLs, that must be why it super easy for common people to use it and every desktop on the planet has a version of Unix running.... oh no, wait... The list continues, should I go on? What I would like to hear is some reasonable description of the technology, what it enables developers to do that wouldn't be possible in Java in practical terms, just saying "oh, it's functional programming", WTF! Yes, I guess only because of that I should throw all my Java code away, quit my job, and dedicate my life to spread the "good news" among men, "Ruby is coming to save you!".
  45. Re: Listen to the podcast[ Go to top ]

    Hi,

    I was hoping to keep out of this one but...


    No, I believe your post is perfect to illustrate a logic flaw in the mind of Ruby zealots.

    Well were shall I start:

    1. Uniform abstractions (everything is an object, no primitives).
    2. Full polymorphism through message sending
    3. Full closures
    4. Continuations
    5. Immediacy of development
    6. Classes as first class objects
    7. Meta-programming
    8. Functional programming
    9. 80% of the expressiveness of Lisp style macros
    10. Higher order functions
    11. Internal DSL's
    12. Editing code whilst it's still running.
    13. Object Memory
    14. Object specific classes
    15. Mixins
    16. ...

    Shall I go on?

    Ignorance is bliss.

    Paul.


    The flaws:

    - No weight on good sides and bad sides. You just assume "more is better", and Ruby has no "bad things", it's all "good things";

    - Non sensical list of features. As if the only thing used as a measure for choosing one technology over the other is the "list of language features". While we are at it, why don't we do the same thing for the other hundreds of languages? Have you ever considered the tools you will need? What about the frameworks? What about the libraries?

    It's ridiculous to think "Ruby is simple, we need no stikin' IDEs", any big enough project will be complex. If you haven't found any in Rubyland is because nobody is building them.

    We have diversity in Javaland, you may not like learning new frameworks, but at least we have a choice. And the standard class library from Java is unbeatable, plus the lots of opensource makes it very attractive and productive for development.

    People always underestimate the value of a good class library. In my opinion, that's the reason that differentiates Java from the rest.

    And Ruby is OLDER than Java, shouldn't it have more of everything I have just cited?

    - No sense of purpose or applicability. If you cited the feature plus something like "that enables me to add .... to my business. Impossible using Java" I would give some credit to it;

    - Dubious "good things", i.e, "Uniform abstractions". WTF!?

    - Anecdotal evidence, sort of wishful thinking, like in "Immediacy of development";

    - Internal DSLs? Oh, Unix had some DSLs, that must be why it super easy for common people to use it and every desktop on the planet has a version of Unix running.... oh no, wait...

    The list continues, should I go on?

    What I would like to hear is some reasonable description of the technology, what it enables developers to do that wouldn't be possible in Java in practical terms, just saying "oh, it's functional programming", WTF!

    Yes, I guess only because of that I should throw all my Java code away, quit my job, and dedicate my life to spread the "good news" among men, "Ruby is coming to save you!".
    You choose to display even more of your ignorance. 40 years of computer research has shown why the things on my list are valuable. If you want to build your future on the foundation of a universal assember language (C), initially designed for efficient system program not as an high level application programming language, then thats up to you. Like I said, ignorance is bliss, and I'm not going to relieve you of it :^). Paul.
  46. Re: Listen to the podcast[ Go to top ]

    You choose to display even more of your ignorance. 40 years of computer research has shown why the things on my list are valuable.

    If you want to build your future on the foundation of a universal assember language (C), initially designed for efficient system program not as an high level application programming language, then thats up to you.

    Like I said, ignorance is bliss, and I'm not going to relieve you of it :^).

    Paul.
    Who are you talking to? You can't even figure that several different people are sending you messages! Please read the entire message and capture the meaning of what is being said. Your reaction is just the evidence of the low level (both of manners and intellectual) of this discussion and of the proponents of it. You CAN'T back any of your arguments with practical data, real life data, only with some ficticious and vague "40 years of research", that, of course, you don't specify what, when or how. You don't because you can't do so, and if you tried you would just expose your ignorance. The most amazing thing, that against all the points I cited! What reasearch states "IDEs are bad" or "class library is bad"!? Haha I believe this works against your goal. People won't see Ruby as "good alternative" only because of geeky-blackmail: "Either you agree with me or I call you stupid in the internet forum, where all other geeks like us will see it". Please grow up and try to add something useful to this conversation. Calling other people names only because they don't agree with you only expose the fact that you aren't mature enough to participate in things of adults.
  47. Re: Listen to the podcast[ Go to top ]

    You choose to display even more of your ignorance. 40 years of computer research has shown why the things on my list are valuable.

    If you want to build your future on the foundation of a universal assember language (C), initially designed for efficient system program not as an high level application programming language, then thats up to you.

    Like I said, ignorance is bliss, and I'm not going to relieve you of it :^).

    Paul.


    Who are you talking to? You can't even figure that several different people are sending you messages! Please read the entire message and capture the meaning of what is being said.

    Your reaction is just the evidence of the low level (both of manners and intellectual) of this discussion and of the proponents of it. You CAN'T back any of your arguments with practical data, real life data, only with some ficticious and vague "40 years of research", that, of course, you don't specify what, when or how. You don't because you can't do so, and if you tried you would just expose your ignorance.

    The most amazing thing, that against all the points I cited! What reasearch states "IDEs are bad" or "class library is bad"!? Haha

    I believe this works against your goal. People won't see Ruby as "good alternative" only because of geeky-blackmail: "Either you agree with me or I call you stupid in the internet forum, where all other geeks like us will see it".

    Please grow up and try to add something useful to this conversation. Calling other people names only because they don't agree with you only expose the fact that you aren't mature enough to participate in things of adults.
    Ignorance is not name calling. Ignorance is a state. From your response you are clearly ignorant of the language features I've listed. This particular thread of conversation is labelled "Listen to the podcast". I suggest you do that before responding further. Once you've relieved yourself of your ignorance then perhaps we can have a constructive conversation about the pros and cons and the type of applications to which Java and Ruby are best suited respectively and language features that could/should be copied. Sorry for confusing you with a different poster. I apologise for this. The original poster to which I responded claimed that the only difference between Java and Ruby is RoR. If he had taken the time to relieve himself of his ignorance too then he would know that it is impossible to implement RoR as implemented in Ruby in Java. This is because RoR relies upon several of the laguage features that I have cited on my list. Paul.
  48. Re: Listen to the podcast[ Go to top ]

    Sorry for confusing you with a different poster. I apologise for this. The original poster to which I responded claimed that the only difference between Java and Ruby is RoR. If he had taken the time to relieve himself of his ignorance too then he would know that it is impossible to implement RoR as implemented in Ruby in Java. This is because RoR relies upon several of the laguage features that I have cited on my list.

    Paul.
    Interestingly, I said nothing of the sort. I more or less said that Ruby needed RoR to make it interesting. Ruby had been sleeping more or less 10 years before then...at least it never really catched my imagination before RoR. Regardless of all these great features it had remained a very marginal language. Why is that??? I have used dynamic languages and scripting for over 16 years on a daily basis. I am for example running an app that has to be fully modifiable during runtime. You can introduce new classes, extend classes, automatically version classes, use closures, intercept, and basically modify all the aspects of the running application without restarting or reloading anything. It carries many of the features of Ruby (maybe as not elegantly) and it does its job. Java could not do it, but Ruby could not either. There is a lot of implied propaganda in the Ruby community about replacing Java, Java's dead, and so on. I would just say that regardless of the features it has, it could not solve my problem. Java can, and right now I don't see it changing in the close future.
  49. Re: Listen to the podcast[ Go to top ]

    Hi Tero,
    There is a lot of implied propaganda in the Ruby community about replacing Java, Java's dead, and so on. I would just say that regardless of the features it has, it could not solve my problem. Java can, and right now I don't see it changing in the close future.
    If you follow my posts, you will see that I'm not into propoganda either. We should be able to choose the right tool for the job. On this we definately agree. What I'm against is the herd mentality. With any luck Ruby will avoid the herd which I don't think has helped Java over the years. Hopefully more programmers will begin to appreciate languages for what they are: tools. Having just the one tool in your tool box is not a good idea. Paul.
  50. Re: Listen to the podcast[ Go to top ]

    Once you've relieved yourself of your ignorance...
    Ah, get a clue. What I said has nothing to do with the podcast or Bruce's presentation or his books, it was related to your flawed message, pointing to the lack of real world applicability and tradeoff considerations. A broader picture of present and future is needed for any serious choice, including career choice and company strategy choice. No intelligent person bases his future in a simplistic list of features. If you are older than 15 years old you should know that! It's hopeless to expect reason from such zealots. I give up!
  51. Re: Listen to the podcast[ Go to top ]

    Hey Paul, I thought I'd just make some counter-points.
    1. Uniform abstractions (everything is an object, no primitives).
    So stop using primitives in your Java code. When an API needs a primitive, Java 5 will just unbox it for you.
    2. Full polymorphism through message sending
    Ruby doesn't support multiple inheritance. What I think you're refering to here is extremely-late binding (no compile-time interface conformance checking, as opposed to fashionably late binding (virtual functions)). This is an advantage in some areas and a disadvantage in others.
    3. Full closures 4. Continuations
    You can achieve the same effect using object-oriented methods. It will be more verbose, but it will also be more flexible, because you won't be locked into the language's implementation.
    5. Immediacy of development
    Is this because of Java and compiling, or is it because app servers take too long to restart? I'd also argue that the added feedback you get from a compiler (and IDE) is significantly more immediate than having to run the code.
    6. Classes as first class objects
    Java classes are first-class final objects.
    7. Meta-programming
    AOP, runtime bytecode manipulation, annotations, reflection, dynamic proxies, generics, etc...
    8. Functional programming
    How exactly does Ruby do this better than Java?
    9. 80% of the expressiveness of Lisp style macros
    IMHO macro-style metaprogramming isn't a good thing. Neither is code generation.
    10. Higher order functions
    Java has functors, and you can define them inline. They're called anonymous inner classes, and a lot of people don't think using them is such a good idea.
    11. Internal DSL's
    Java could do this if it had operator overloading. Any OO language with operator overloading can do internal DSLs. Some could argue that even without operator overloading good OO equates to an internal DSL.
    12. Editing code whilst it's still running.
    I personally have doubts about the value of editting code while it is running. It seems a little too non-deterministic to me. But...being able to interact with code from an interpreter prompt IS valuable. Of course you can use Jython or (I think) Groovy or JRuby for that.
    13. Object Memory
    That is a really neat feature in Ruby, but it seems like one of those features that people will misuse. I'm not sure it really has value.
    14. Object specific classes
    Please clarify.
    15. Mixins
    Java syntax for mixins is just more verbose and less dynamic. ---------------- All in all I'd say Java creates a higher impedance to expressing thoughts than Ruby, because it makes you think a lot. Your thoughts have to be more conrete to be expressed in Java, and sometimes that is hard. The thing is, your thoughts have to be a heck of a lot more complete than Java requires in order to get a working, maintainable systems. There is no question is my mind that languages like Ruby and Python reduce the time it takes to go from an idea to something that "kind of works," or "works within a limited context." However, I don't think it shortens the amount of time it takes to turn an idea into a production ready system. Keep in mind that my standards for a production ready system are high, and are rarely met by systems that arguably deliver real business value. I agree that there's a lot that Java (and C# and C++) can learn from dynamic languages in terms of compile-time metaprogramming, and I think features like static typing are valuable and will lead to more powerful metaprogramming. I disagree with that argument for better-late-than-never binding in dynamic languages. I know you didn't make it here, but I can feel it's emanations drifting across the Atlantic. I've made a lot of mistakes in Python (haven't used Ruby much) that a compiler would have caught, and spent a lot of time tracking them down. The compiler is your friend.
  52. Re: Listen to the podcast[ Go to top ]

    Hi Erik, Intelligent and thoughtful as always. Thanks for stating the counter position. I'll try and answer your questions, then explain why I'm big on late-binding:
    8. Functional programming
    How exactly does Ruby do this better than Java?
    In it's most basic form, functional programming is passing functions as arguments. So creating a function as a parameter is equivalent to a Lamda expression in Lisp and a block in Smalltalk and Ruby. Ruby has a neat syntax when you only pass a single function to a method which looks very similar to functional programming in Lisp. As for Java well there is always the anonymous inner class, but the less said about that the better :^).
    I disagree with that argument for better-late-than-never binding in dynamic languages.
    Message sending and the decoupling (late-binding) it allows, with automatic memory management (garbage collection) along with meta-capbailities gives a completely different feel to objects. Using a late-bound language in a static context means very little I agree, but the vision for objects that the original researchers had at Xerox-Parc was not static and has been largely mis-understood. So what we generally think of as object orientation today is a degenerative form of their original ideas, which were watered down to meet the processing capabilities of microprocessors and personal computers in the mid 1980's. So we have thrown away a lot of good stuff, much of which IMO the Ruby crowd are rediscovering today. To see why I believe that the future is late-bound take a look at this demo of Self. A late bound OO system built by Sun Microsystems in the mid 90's: http://video.google.com/videoplay?docid=5776880551404953752 Think about the Self principle of liveliness and how that applies to an internet centric world today. The Croquet system which is also late-bound has incorporated this idea too. There are a whole set of videos by the original researchers into object orientation going back to Doug Engelbart the guy who created the first GUI in th 1950's I think. Here is the link: http://www.esug.org/resourcesdocsmedia/onlinesmalltalkvideos/ I've been watching them on my lunch break. A real interesting one is Dan Ingalls describing Object Orientation back in the eighties. If you listen carefully you will see that his concept is very different to how we see objects today. Paul.
  53. Re: Listen to the podcast[ Go to top ]

    Thanks for the post. The Self video was interesting. Between that and the Lisp book I'm slowly plowing through you really learn everything old is new again. I was able to see a live demo of Croquet at a BarCamp conference recently. That stuff is fun too. http://barcamp.org/ I know I made this comment earlier on this post but maybe the question is are we building the right kinds of applications for the web. My guess is that soon the concept of building page-based web apps will seem as cheesy as punch card programming. ______________ George Coller DevilElephant
  54. Re: Listen to the podcast[ Go to top ]

    Thanks for the post. The Self video was interesting. Between that and the Lisp book I'm slowly plowing through you really learn everything old is new again.

    I was able to see a live demo of Croquet at a BarCamp conference recently. That stuff is fun too.
    http://barcamp.org/

    I know I made this comment earlier on this post but maybe the question is are we building the right kinds of applications for the web. My guess is that soon the concept of building page-based web apps will seem as cheesy as punch card programming.

    ______________
    George Coller
    DevilElephant
    +1000
  55. Re: Listen to the podcast[ Go to top ]

    Paul -
    As for Java well there is always the anonymous inner class, but the less said about that the better :^).
    They're really not _that_ bad. The root of the problem is the heaviness of the class format itself in terms of (a) packaging (since each is packaged individually and thus is self-sufficient from a referential point of view) and (b) identity (since all classes have unique global identity from a loading perspective). The second is -- at present -- a requirement due to the design of the JVM, but the first could easily be addressed, e.g. by at least embedding inner and anon classes inside the classfile for the containing class. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  56. Re: Listen to the podcast[ Go to top ]

    Hi Paul. This is an interesting thread, with less than the usual heat in the debate. As I have practical development experience with languages you mention, I hope you don't mind me commenting.
    Using a late-bound language in a static context means very little I agree, but the vision for objects that the original researchers had at Xerox-Parc was not static and has been largely mis-understood. So what we generally think of as object orientation today is a degenerative form of their original ideas, which were watered down to meet the processing capabilities of microprocessors and personal computers in the mid 1980's.
    I don't think this was the case, as full implementations of Smalltalk were available on PCs in the mid 1980s (even on pure DOS machines). I used various implementations of Smalltalk in the 80s and early 80s. The performance was not great, but they weren't usually cut down in any significant way. In fact, the Digitalk Smalltalk implementations could fit a rich development environment and class library into just a few MB of memory!
    I've been watching them on my lunch break. A real interesting one is Dan Ingalls describing Object Orientation back in the eighties. If you listen carefully you will see that his concept is very different to how we see objects today
    Well, yes, but object orientation always has been a fuzzy term, with different (but equally valid) points of view about what it means. There have been parallel developments of the idea - when I started to use Smalltalk, I was surprised to learn of the Simula-style of OOP (on which C++ and Java are largely based), and I realised my view of that style of OOP as generally inferior to Smalltalk's was mistaken. Both approaches have their merits. I agree that the more message-based OOP style of Smalltalk is incredibly powerful, and I believe I read somewhere that there are technical reasons why it may be (at least theoretically) be faster than statically typed languages with the appropriate forms of runtime optimisation. One thing that the Self video you provided a link to illustrates something that is missing from much current dynamic language development is good visual tools - vital for good Smalltalk development (for example) is the ability to interact with, and modify live objects in a graphical manner. Hopefully the Ruby people will re-discover the benefits of this approach as well. And, I have to thank you for posting it - it brought back memories of the excitement I felt when I first discovered Smalltalk some time ago.
  57. Re: Listen to the podcast[ Go to top ]

    Hi Steve, The cut down Smalltalk that I am referring to is C++. C++ went back to Simula (Algol + OO pre-processor). Getting rid of message sends, byte codes and automatic memory management meant that you could have a sort of OO but without the performance overhead of the things I mention above. Also static typing meant that you could use an optimising compiler. C++ compilers like C compiliers before them, hard code everything and optimise the hell out of the code (two passes). The upside is that you get machine code as optimal as hand written assembler. Very important with 512K of memory and an 8088 processor! The real deal IMO is not Smalltalk versus Java or C++, but high level languages that required big iron computers in the mid 80's versus low level languages that could run on the new low power microprocessors. C was intended for system programming and device drivers. In modern systems today C/C++ is still used for that same purpose. So both the Java and Smalltalk VMs are still written in C/C++, so are all the leading Operating Systems. Java has come from a similar heritage, and Forth upon which it was based was a language for downloading code to device drivers. The original development of Oak was for toasters and the like. So the question is whether moores law means that we can now give up our pre-occupation with highly performat low level languages and explore some of the other ideas that have been around for over 40 years. IMO the reason why the debate can become heated, is because a lot of programmers have grown up with these languages. IMO a lot of the difficulties we have faced in recent years are to do with complexity, and to address this we need to start thinking at a higher level of abstraction, getting away from the hardware. If you look through the videos you will see that people realised that this view would enivatbly be the future of computing a long time ago. So objects are the new high level abstraction. Think of them as small computers, each dedicated to it's own purpose and each responding to it's own message queue. Another good analogy is cells in the human body, each encapsulated and seperate with it's own DNA and it's own role to play. We just do not have this today! Projects like Croquet are looking to put that right. Paul.
  58. Re: Listen to the podcast[ Go to top ]

    Hi Paul - I am going to disagree with you somewhat at the start, but then I think you raise some interesting points...
    Hi Steve,

    The cut down Smalltalk that I am referring to is C++. C++ went back to Simula (Algol + OO pre-processor).
    Yes, but that is why I would say that C++ is not really a cut-down Smalltalk - because its ancestry is Simula (which came before Smalltalk).
    Getting rid of message sends, byte codes and automatic memory management meant that you could have a sort of OO but without the performance overhead of the things I mention above.
    I am not sure. As I understand it Simula, C++ etc are definitely first-class OOP languages, at least according to well-recognised definitions. True, they don't have the rich and powerful dynamic features of Smalltalk, but they are, nevertheless, OOP. I don't know if there are useful additional terms that one could use to describe the combination of dynamic + OOP + message passing? Perhaps you are really talking about some combination of OOP + the Actor model? As wikipedia says "OOP is subject to much contention as to its precise definition and its principal ideas".
    but high level languages that required big iron computers in the mid 80's versus low level languages that could run on the new low power microprocessors.
    Again, as user of such languages in the mid 80s, I disagree. Smalltalk, LISP, Prolog etc. worked fine on personal computers - I used them on such machines - I would not call a 286-based PC big iron! Smalltalk has been used in embedded low-power systems, and there was even work to produce a chip that would run Smalltalk byte codes. I don't think the 'big iron/microprocessor' idea is helpful in distinguishing these languages.
    C was intended for system programming and device drivers. In modern systems today C/C++ is still used for that same purpose.
    If only they had stayed in that role....
    So the question is whether moores law means that we can now give up our pre-occupation with highly performat low level languages and explore some of the other ideas that have been around for over 40 years.
    This is indeed a very interesting question! My experience (having used both Smalltalk and C++ since the mid 80s) is that things really haven't changed that much. As Moore's law increases processor power, the demands of users grows to match. Just to give a personal example - I occasionally work in the area of mathematical modelling. In the 80s I wrote software to model molecular systems with hundreds of particles. A year or so ago, I heard reports of models of millions of particles. But would developers switch to an easier way of development system but get an order of magnitude less power? There are plenty of examples of increasing demand in less esoteric fields. On the other hand, processing power is now so cheap... I think that the opportunity to explore the richness and features of dynamic OOP languages has always been there, but the long legacy of Algol-type languages and the conservative nature of IT has held people back. Fortunately, it seems that Ruby may be a catalyst for a change here. My reason for caution is that at some point applications often need performance that is beyond what dynamic OOP languages can deliver. Perhaps what is needed is an easy way to allow mixed language development so power can be easily provided where necessary. Perhaps the long-term future of the JVM will be as a platform to provide such mixed development and deployment.
    IMO the reason why the debate can become heated, is because a lot of programmers have grown up with these languages.
    Yes, and there is occasionally a reluctance to learn, especially when new paradigms are involved. I remember the effort it took before I finally 'got' OOP....
    IMO a lot of the difficulties we have faced in recent years are to do with complexity, and to address this we need to start thinking at a higher level of abstraction, getting away from the hardware.

    If you look through the videos you will see that people realised that this view would enivatbly be the future of computing a long time ago. So objects are the new high level abstraction. Think of them as small computers, each dedicated to it's own purpose and each responding to it's own message queue. Another good analogy is cells in the human body, each encapsulated and seperate with it's own DNA and it's own role to play.

    We just do not have this today! Projects like Croquet are looking to put that right.

    Paul.
    As I have said before, I am skeptical about croquet as such - the Smalltalk/Squeak crowd have been a source of good ideas for some time, but these ideas only tend to get adopted in a very watered-down form and then only many years later. Perhaps this time they will succeed. However, this brings to mind a missed opportunity for Smalltalk in the late 80s. A Digitalk implementation ran on OS/2 (and, incidentally, had great portability with the Windows and DOS versions). A certain Mr Gates saw a demonstration of this and claimed: "This is the right way to develop applications for OS/2 PM. OS/2 PM is a tremendously rich environment, which makes it inherently complex. Smalltalk/V PM removes that complexity and lets you concentrate on writing great programs." (However, he followed this by: "Smalltalk/V PM is the kind of tool that will make OS/2 the successor to MS/DOS"!). And then, a few years later, after having seen the richness and full OOP of Smalltalk, he came up with.... Visual Basic, which was not portable and lacked inheritance. Perhaps the main developer community will always be stuck with lesser tools and approaches. Perhaps the main role of languages like Smalltalk, and systems like Squeak, is to demonstrate what might be possible, rather than what is actually going to be used. I hope not.
  59. Re: Listen to the podcast[ Go to top ]

    Hi Steve, Thanks forthe post and you provide some interesting points.
    I am not sure. As I understand it Simula, C++ etc are definitely first-class OOP languages, at least according to well-recognised definitions. True, they don't have the rich and powerful dynamic features of Smalltalk, but they are, nevertheless, OOP. I don't know if there are useful additional terms that one could use to describe the combination of dynamic + OOP + message passing?
    I don't want to become pendantic about terminology, but I hate the fact that the people who did the hard research and work seldom get the credit. There was no Object Orientation before Alan Kay and his team (Dan Ingalls, Adele Goldberg etc) coined the term back at Xerox-Parc in the 1970's
    I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - Alan Kay, OOPSLA '97
    The quote I make above is take from the following speach (video). So you can see the context for yourself http://video.google.com/videoplay?docid=-2950949730059754521 Now Alan Kay may have a reptuation as a grumpy old fart. But you would probably be grumpy too if you saw your whole lifes work misrepresented.
    Perhaps the main developer community will always be stuck with lesser tools and approaches. Perhaps the main role of languages like Smalltalk, and systems like Squeak, is to demonstrate what might be possible, rather than what is actually going to be used. I hope not.
    There is nothing stopping any of us building the systems we feel are needed ourselves. This is exactly what the Squeak and the Ruby communities (and the Spring, Hibernate etc) are doing.
    "The best way to predict the future is to invent it" - Alan Kay
    Paul.
  60. Re: Listen to the podcast[ Go to top ]

    I don't want to become pendantic about terminology, but I hate the fact that the people who did the hard research and work seldom get the credit. There was no Object Orientation before Alan Kay and his team (Dan Ingalls, Adele Goldberg etc) coined the term back at Xerox-Parc in the 1970's
    Hey, I am the pedantic one anyway :) I am not sure one can really say that there was no object orientation before Kay and co-workers coined the term. After all, Simula had all the features generally recognised as OOP: Classes, Objects, Methods, Inheritance, Encapsulation, Polymorphism and so on. As is often the case, technologies can be labelled some time after they have been invented. (An example is the term 'structured programming'. This only came into widespread use in the 70s, but no-one would deny that earlier languages like Algol 60 weren't structured). But anyway, I don't think that 'object oriented' is a sufficiently broad term to describe the full richness of languages like Smalltalk. It does not include the dynamic nature of how these languages use objects - such the ability to create new classes on the fly, and to mutate objects while an application is running (for example, the Smalltalk #become: message, or the even more powerful features of Ruby). Perhaps we need a new term - something that has not become so vague in meaning?
    Alan Kay may have a reptuation as a grumpy old fart. But you would probably be grumpy too if you saw your whole lifes work misrepresented.
    That so often happens with people who have visionary ideas.
    There is nothing stopping any of us building the systems we feel are needed ourselves. This is exactly what the Squeak and the Ruby communities (and the Spring, Hibernate etc) are doing.
    I think there are some things that inhibit this - many of us don't have the resources to spend time building such systems, and then teaching others to use our non-standard systems - how many of us would have the time to invent and write a system like Hibernate? Maybe with higher levels of abstraction, this is less of an issue? But anyway, I am grateful for your links to videos. They have reminded me what I have been missing for some time since I largely abandoned Smalltalk - a real sense of fun while developing.
  61. Re: Listen to the podcast[ Go to top ]

    Hi Steve, About the terminology. If ParcPlace Systems (or Rank Xerox) had trade-marked or the term "It's Object Orientated (tm)" or patented OO, in the Same way Apple patented the "waste basket icon" or Microsoft trade-marked "Windows (tm)" or Intels "Intel inside (tm)" etc. then we wouldn't be having this conversation. And Xerox may have been the Apple or Microsoft of today. The term was ripped off by others, pure and simple. You make an interesting point about VB6 programmers earlier. Well when Microsoft moved to .NET, the natural hoem for all those stranded VB6 programmers was Dolphin Smalltalk so they could have had Smalltalk in the end if they wanted to. My guess is that most of them went to Java or C# tio stay close to the herd. My view is that software systems are like politics and politicians and we end up with the systems we deserve :^). Paul.
  62. Re: Listen to the podcast[ Go to top ]

    Hi Steve,

    About the terminology. If ParcPlace Systems (or Rank Xerox) had trade-marked or the term "It's Object Orientated (tm)" or patented OO, in the Same way Apple patented the "waste basket icon" or Microsoft trade-marked "Windows (tm)" or Intels "Intel inside (tm)" etc. then we wouldn't be having this conversation. And Xerox may have been the Apple or Microsoft of today.

    The term was ripped off by others, pure and simple.
    Things are never simple :), and I feel you are being a bit harsh, after all, many had put considerable work into at least the foundations of OOP before Smalltalk was devised, even though they did not all use that term, in fact, there was no term to be ripped off, because even Alan Kay was vague about what it meant - he came up with different definitions at different times: in his initial work he even left out inheritance. Re-reading Kay's work, I can see where your views come from!
    You make an interesting point about VB6 programmers earlier. Well when Microsoft moved to .NET, the natural hoem for all those stranded VB6 programmers was Dolphin Smalltalk so they could have had Smalltalk in the end if they wanted to. My guess is that most of them went to Java or C# tio stay close to the herd.

    My view is that software systems are like politics and politicians and we end up with the systems we deserve :^).

    Paul.
    There was far more for Windows development than just Dolphin - Smalltalk/MT was also available - a really high-performance multi-threaded implementation, which I am surprised has not had more publicity.
  63. Re: Listen to the podcast[ Go to top ]

    You make an interesting point about VB6 programmers earlier. Well when Microsoft moved to .NET, the natural hoem for all those stranded VB6 programmers was Dolphin Smalltalk so they could have had Smalltalk in the end if they wanted to. My guess is that most of them went to Java or C# tio stay close to the herd.
    My experience is that they mostly have gone to VB.Net. If they went anywhere.
  64. Historic References[ Go to top ]

    Paul, Thanks for the links. Watching some of those videos was very informative. I think OO has quite clearly split for its original intent - or at least what we commonly call today. I don't think that's necessarily bad, or good, it just is. Anyway, on to binding. I've got two questions: 1. When is the appropriate time to bind interface? 2. When is the appropriate time to bind implementation? My proposed selections are: a. Compile time b. Build/link time c. Runtime Initialization d. Runtime e. Never Static OO languages require you to bind interface at compile time, and implementation at runtime. Of course, they allow you to bind implementation at compile time as well, and this frequently occurs. They also make binding to interface very tedious, by requiring that it be explicit. Dynamic OO languages never bind to interface. Call it "duck typing," "simulation" or whatever, but what's important is that they understand the messages that they are sent - not that they declared that they implemented a given interface. My opinion is that static OO languages have it right in theory, but they're implementation of it is awful. Especially Java. Its compiler is down right lazy. The reason I feel this why is I have a near religious belief in "fail-fast" code. Compile time is the best time to fail, because I never get the delusion that my code works. In the end, I think programming is about effectively communicating with the computer. Communicating with the computer via a dynamic language is kind of like communicating with your spouse. Much of what you communicate can remain unsaid, because you're spouse infers it based on context and experience. The problem is, sometimes the inference process goes horribly wrong, and you don't realize it until it's too late. On the flip side, communicating with the computer via a static language is kind of like communicating with your lawyer. It expects you to be very explicit on every point, and will just stop as soon as your are vague. This really impedes progress, but it also avoids many future problems. Neither modes of communication require you to particularly make sense, which is a problem. Anyway, I think Bruce is right. However, I think it's important to keep the good while shedding the bad. How can we improve programmer productivity? How can we increase safety of code?
  65. Re: Historic References[ Go to top ]

    Hi Erik Adele's Goldbergs response to this question would be "bind at the latest possible moment". She has been looking into this for over 30 years so who am I to argue. I agree with you that the issue comes down to implementation. The Self Group optimised out all the late binding down to machine code at the latest possible moment (creating machine code caches). If they got a miss on their cache then they had to undue the optimsations and go back to a more interpretative approach. Over time the system would be trained and the machine code cache would be hit most of the time. This is how the Java Hotspot VM works which incidently was a spin off from the Self project. There is another issue that you raise, which is how does it feel to program in a late-bound system. I could turn that question on it's head and say how does it feel to live in a late-bound world? StrongTalk was an attempt to bring types to Smalltalk. I have never used it, but the researchers aborted their attempts because even though it made the code more readable, they ended up creating rigid and inflexible systems (types) which is something they wanted to avoid. Dolphin Smalltalk uses Interfaces (protocols)as markers on classes, but they are just there to help the programmer and are not enforced at runtime. The Self video talks about modalessness. The edit/run cycle is modal, and not the way the real world works (Have you seen the matrix movie? :^)). About getting feedback at the earliest possible moment. David Ungar at the end of the video talks about moving away from editing then running static code to "banging on objects that then bang back", instant feedback. This style of programming is bottom up (just like REPL in Lisp). Incidently it is the same style of programming recommended by many Agile advocates (Kent Beck for example), which is not surprising since many of the Agile ideas stem from experiences with Smalltalk. Paul.
  66. Re: Historic References[ Go to top ]

    Paul,
    Adele's Goldbergs response to this question would be "bind at the latest possible moment". She has been looking into this for over 30 years so who am I to argue.
    You are precisely one to argue, as is Steve, myself, and anyone else working in the field of software development.
    I agree with you that the issue comes down to implementation. The Self Group optimised out all the late binding down to machine code at the latest possible moment (creating machine code caches). If they got a miss on their cache then they had to undue the optimsations and go back to a more interpretative approach. Over time the system would be trained and the machine code cache would be hit most of the time. This is how the Java Hotspot VM works which incidently was a spin off from the Self project.
    I have no doubt that brilliant engineers can optimize dynamic languages to perform as well or better than static ones. Which is why I never raised the performance issue.
    The Self video talks about modalessness. The edit/run cycle is modal, and not the way the real world works (Have you seen the matrix movie? :^)). About getting feedback at the earliest possible moment. David Ungar at the end of the video talks about moving away from editing then running static code to "banging on objects that then bang back", instant feedback.
    The immediacy of feedback is entirely dependent on the code on which feedback is required and the method by which feedback is obtained. If I'm writing a data mining algorithm in Python (which I've done), run it, and 3 hours into processing it throws an exception because it tries to call a method that is not defined on an object, that is not very immediate feedback (which has happened to me). Netbeans or Eclipse would have underlined the error as I typed it. That is immediate feedback. Your counter argument could be that in a dynamic language you can change the code and then start back up where you left off. However, in order to do that, the system must have been left in a consistent state from which execution can resume. If the stack just unwound and all the state was eaten by the garbage collector you're out of luck. Even if you do have a consistent state from which to resume, you have no guarantee that your new code would not have failed on the first part of the input stream that the old code passed. Now, there are plenty of situations where dynamic languages can be much more immediate. My point is the immediacy is highly dependent on the situation, and in many cases static languages provide much more immediate feedback.
  67. Re: Historic References[ Go to top ]

    Hi Erik, I am not arguing the case one way or the other, I'm merely expressing the ideas of others who have done a lot of research in this area. When you build a bike, You don't through all the bits together (edit) and then get on and try to ride it (run) only to find out that the gears have been put on back to front. What you do is get a single bolt (object) and place on a single nut (object) and see if it fits right (feedback). When that works you add another thing, then another bottom up testing all the while. The final test is riding the whole bike, but the bike has been alive all the time at various stages of construction with various bits working. This is what David Ungar is talking about, modalessness. In Self terms you would drag an object off some pallete and send messages to it and see what it does (what it answers back). You would then creat an object to talk to that object you've just explored, building up the system bottom up, much like a child in a play pen playing with lego blocks. In not advocating, I'm merely explaining :^) Paul.
  68. Re: Historic References[ Go to top ]

    StrongTalk was an attempt to bring types to Smalltalk. I have never used it, but the researchers aborted their attempts because even though it made the code more readable, they ended up creating rigid and inflexible systems (types) which is something they wanted to avoid.
    That is an incomplete version of the history of StrongTalk, at least according to my knowledge of the subject. The first version of the type system (presented at OOPSLA 93) was indeed problematic, because it was grafted on the existing ParcPlace libraries. However, considerable progress was made after that. Far from being rigid and inflexible, "the type-feedback technology was actually nicely suited for a good, production-quality compiler" (to quote from Dave Griswold, one of those involved in StrongTalk). Far from aborting their attempts, they went on to produce a high-performance Smalltalk system which could run either typed or untyped code as desired. In fact, the results of their work is now available for free, here.
  69. Re: Historic References[ Go to top ]

    StrongTalk was an attempt to bring types to Smalltalk. I have never used it, but the researchers aborted their attempts because even though it made the code more readable, they ended up creating rigid and inflexible systems (types) which is something they wanted to avoid.


    That is an incomplete version of the history of StrongTalk, at least according to my knowledge of the subject. The first version of the type system (presented at OOPSLA 93) was indeed problematic, because it was grafted on the existing ParcPlace libraries. However, considerable progress was made after that. Far from being rigid and inflexible, "the type-feedback technology was actually nicely suited for a good, production-quality compiler" (to quote from Dave Griswold, one of those involved in StrongTalk). Far from aborting their attempts, they went on to produce a high-performance Smalltalk system which could run either typed or untyped code as desired. In fact, the results of their work is now available for free, here.
    Thanks Steve. Perhaps this is the middle ground Erik is looking for. Paul.
  70. Re: Historic References[ Go to top ]

    StrongTalk was an attempt to bring types to Smalltalk. I have never used it, but the researchers aborted their attempts because even though it made the code more readable, they ended up creating rigid and inflexible systems (types) which is something they wanted to avoid.


    That is an incomplete version of the history of StrongTalk, at least according to my knowledge of the subject. The first version of the type system (presented at OOPSLA 93) was indeed problematic, because it was grafted on the existing ParcPlace libraries. However, considerable progress was made after that. Far from being rigid and inflexible, "the type-feedback technology was actually nicely suited for a good, production-quality compiler" (to quote from Dave Griswold, one of those involved in StrongTalk). Far from aborting their attempts, they went on to produce a high-performance Smalltalk system which could run either typed or untyped code as desired. In fact, the results of their work is now available for free, here.


    Thanks Steve. Perhaps this is the middle ground Erik is looking for.

    Paul.
    Perhaps - this is why I posted the reference. The StrongTalk project was, for some time, sadly somewhat crushed by Sun's overwhelming emphasis on Java. You are certainly right that Sun had a major technology that it could have released instead of Java, but I would suggest that it was StrongTalk rather than Self (if that was what you were suggesting) - perhaps Self was too 'way out'? I know that many people, including me, were eagerly awaiting a truly high-performance portable Smalltalk. StrongTalk could have been such a language. Perhaps with an optional type system it could have even attracted C and C++ developers? Perhaps such optional typing is a way forward. It is present in BeanShell and Groovy, and it looks like some form of it may be present in Ruby 2.0.
  71. Java has stolen too much already...[ Go to top ]

    Hi Steve, I've been playing with Strongtalk and boy it's depressing. Aside from the type system, the dynamic compiler is real fast. I've never seen anything like it. Also the code browser looks pretty much like a standard editor. I mean you can see all of a class at once. BTW: The reason why this stuff was never launched is that they got bought up by Sun. So Sun has been sitting on this stuff and Self for over ten years!!! I always saw Sun as one of the better vendors out there, but this is proof if ever we needed it that commerce and science in software just doesn't mix. I mean they could have released this stuff as a specialised high end tool. Charged a whopping price for it even, but no, they didn't want to confuse the "Java Everywhere" message. The last honest commercial language IMO was C++ with true multi-vendor support. I was taken in by Java, just like everyone else, but this is evidence if ever we needed it that single company commercial languages aren't a good idea. Its all about $$$$. As for the type system, well they've done the right thing. Types are added as annotations which are basically ignored by the VM. You can run a type checker anytime you choose and it will check your types for you. They even allow for mutiple types so: aMethod: anArgument ^ means that the argument to this method can be one of two types, X or Y. Now that's what I call proper polymorphism. BTW the ^ bit says that the method returns an Integer. They use mixins so you get proper multiple inheritance and they use Interfaces (Protocols) pretty much in the way described in the blue book and implemented in Dolphin Smalltalk as far as I can see. They provide a little tutorial that shows you what you need to know to get going. In about 60 secounds I had put a forward button on their HTML Viewer. Smalltalk rocks! My first impression is that the type system probably doesn't provide much more benefit than say Code Critic in VisualWorks, but I'm not a real Smalltalker and I haven't used it enough to say. But where I think the type system would have come in useful is like you say, helping all those C/C++ programmers to give Smalltalk a try. The whole way Strongtalk is structured is to make it more accessable to non-smalltalkers. They have even stopped using the Image to save state. The type system could serve as hand-holding for those who needed it, but you can write standard Smalltalk and it will accept that too. You may say it's harsh, but after seeing this I truly believe that Sun has held us back by over 10 years (this stuff was written in 1996). The main stream has got a long way to go to catch up with where these guys were over 10 years ago. With the IDE, Type System and PIC (Polymorphic Inline Cache), Ruby doesn't even come close. Maybe we'll see something like this in about 10 years when the Squeak guys have had a chance to catch up (Squeak was only started in 1996/7). The world is a cruel place :^( Paul.
  72. Hi Steve,



    I've been playing with Strongtalk and boy it's depressing. Aside from the type system, the dynamic compiler is real fast. I've never seen anything like it. Also the code browser looks pretty much like a standard editor. I mean you can see all of a class at once.

    BTW: The reason why this stuff was never launched is that they got bought up by Sun. So Sun has been sitting on this stuff and Self for over ten years!!!

    I always saw Sun as one of the better vendors out there, but this is proof if ever we needed it that commerce and science in software just doesn't mix. I mean they could have released this stuff as a specialised high end tool. Charged a whopping price for it even, but no, they didn't want to confuse the "Java Everywhere" message.

    The last honest commercial language IMO was C++ with true multi-vendor support. I was taken in by Java, just like everyone else, but this is evidence if ever we needed it that single company commercial languages aren't a good idea. Its all about $$$$.

    As for the type system, well they've done the right thing. Types are added as annotations which are basically ignored by the VM. You can run a type checker anytime you choose and it will check your types for you. They even allow for mutiple types so:

    aMethod: anArgument ^

    means that the argument to this method can be one of two types, X or Y. Now that's what I call proper polymorphism. BTW the ^ bit says that the method returns an Integer. They use mixins so you get proper multiple inheritance and they use Interfaces (Protocols) pretty much in the way described in the blue book and implemented in Dolphin Smalltalk as far as I can see.

    They provide a little tutorial that shows you what you need to know to get going. In about 60 secounds I had put a forward button on their HTML Viewer. Smalltalk rocks!

    My first impression is that the type system probably doesn't provide much more benefit than say Code Critic in VisualWorks, but I'm not a real Smalltalker and I haven't used it enough to say. But where I think the type system would have come in useful is like you say, helping all those C/C++ programmers to give Smalltalk a try.

    The whole way Strongtalk is structured is to make it more accessable to non-smalltalkers. They have even stopped using the Image to save state. The type system could serve as hand-holding for those who needed it, but you can write standard Smalltalk and it will accept that too.

    You may say it's harsh, but after seeing this I truly believe that Sun has held us back by over 10 years (this stuff was written in 1996). The main stream has got a long way to go to catch up with where these guys were over 10 years ago. With the IDE, Type System and PIC (Polymorphic Inline Cache), Ruby doesn't even come close.

    Maybe we'll see something like this in about 10 years when the Squeak guys have had a chance to catch up (Squeak was only started in 1996/7).

    The world is a cruel place :^(

    Paul.
    Yet again, I think you are being very harsh - I am a pragmatist. Would a Smalltalk dialect have become mainstream? Personally, I doubt it. Java succeeded because it had a gentle learning curve for C and C++ users. Far from holding us back, Sun has moved things on - for the first time a safe, garbage collected language has become not only mainstream, but dominant. In my view that is one of the most significant developments in IT for a very long time, after the disaster that mainstream use of C++ turned out to be. I believe Java is proof that science and commerce do mix, as the science behind StrongTalk and Self allowed the JVM to run code at high speed - giving unparalled portability for mainstream development, rather than just in some obscure academic environment. We get the development languages we deserve! The opportunity for mass take-up of Smalltalk was clearly there in the late 80s. It was largely rejected. Sun realised that and came up with a compromise that worked. I would say that we have been holding ourselves back, and Sun was simply recognising this situation..... So, I think you are blaming the wrong people - blame developers in general for their conservatism and resistance to innovation. It is our fault! And, of course it was at least partly about dollars - Sun is not a charity. However, they released Java - even on platforms that they weren't selling - for free. As you say, we still haven't caught up, in many respects Ruby is a poor cousin of Smalltalk, even as it was 15,20,25 years ago. I want my refactoring browsers!
  73. Hi Steve,
    We get the development languages we deserve! The opportunity for mass take-up of Smalltalk was clearly there in the late 80s. It was largely rejected. Sun realised that and came up with a compromise that worked. I would say that we have been holding ourselves back, and Sun was simply recognising this situation..... So, I think you are blaming the wrong people - blame developers in general for their conservatism and resistance to innovation. It is our fault!
    It's nice to be in total agreement for a change. It is our fault! Will we ever learn? Paul.
  74. Re: Java has stolen too much already...[ Go to top ]

    Hi Steve,

    We get the development languages we deserve! The opportunity for mass take-up of Smalltalk was clearly there in the late 80s. It was largely rejected. Sun realised that and came up with a compromise that worked. I would say that we have been holding ourselves back, and Sun was simply recognising this situation.....

    So, I think you are blaming the wrong people - blame developers in general for their conservatism and resistance to innovation. It is our fault!




    It's nice to be in total agreement for a change. It is our fault! Will we ever learn?

    Paul.
    Nope. Most developers have alot of trouble learning. Unfortunately. Most are barely functional at best. Sadly.
  75. Re: Java has stolen too much already...[ Go to top ]

    Nope. Most developers have alot of trouble learning. Unfortunately. Most are barely functional at best. Sadly.
    Hi all, In the Strongtalk tutorial there is a simple bench mark. I tried running it. Smalltalk (ms) 761 729 27 28 30 28 27 27 27 29 Best Time = 27 Java (ms) 282 516 750 985 1204 1422 1625 1829 2032 2250 Best Time = 282 The interesting this is that the later Java runs actually took longer! Strongtalk stayed at 27ms for all subsequent runs (the advantage of having an image). Smalltalk code: simpleTest: n "Test benchmark: [ Test simpleTest: 10000000 ]" | a | a := Array new: 1. n timesRepeat: [ a at: 1 put: 3.] Java Code: void simpleTest(int n) { Integer[] a = new Integer[1]; for(int i = 0; i < n; i++) { a[0] = new Integer(3); } } n = 10000000 Not sure how much Sun paid them for their adaptive compiler technology, but it doesn't seem to be working that well in the JVM :^). Since the JVM looked like it needed some help, I decided to try primitives and forget objects: Java (primitives): void simpleTest(int n) { int[] a = new int[1]; for(int i = 0; i < n; i++) { a[0] = 3; //new Integer(3); } } And the results: 47 63 94 157 172 203 219 250 266 297 Best Time = 47 Try it yourselves! Paul.
  76. Try it yourselves!

    Paul.
    I have. My results are different. I not only ran the same benchmark, I put it in a loop so I could make it run for longer. (when I tried to increase the run time by making n large, the entire StrongTalk system crashed at a certain point). Number of repeats, best time for StrongTalk, worst time for StrongTalk,avg time for Java (1.5.0_06) 1,49,481,31 10,487,4750,313 100,4971,50593,3146 The average time for Java is substantially below the best times for StrongTalk, and often an order of magnitude below the worst times.. The reason it only works well in Java with primitives is because most Smalltalk implementations automatically use primitives for integers below a certain size. So, it looks like the compiler technology is working just fine in the JVM.
  77. Try it yourselves!

    Paul.


    I have. My results are different.

    I not only ran the same benchmark, I put it in a loop so I could make it run for longer. (when I tried to increase the run time by making n large, the entire StrongTalk system crashed at a certain point).

    Number of repeats, best time for StrongTalk, worst time for StrongTalk,avg time for Java (1.5.0_06)

    1,49,481,31
    10,487,4750,313
    100,4971,50593,3146

    The average time for Java is substantially below the best times for StrongTalk, and often an order of magnitude below the worst times..

    The reason it only works well in Java with primitives is because most Smalltalk implementations automatically use primitives for integers below a certain size.

    So, it looks like the compiler technology is working just fine in the JVM.
    Hi Steve, Are you running the benchmark in the Strongtalk tutorial? The loop is repeated 10 million times. This is then repeated 10 times with the best time highlighted. BTW I know about the trick in Smalltalk that uses the actual byte as an integer untill it gets two big ofcourse then it becomes an object. The point is though this is completely transparent and part of the implementation. So all integers are infact objects as far as the programmer is concerned. Do the Java numbers get larger on successive runs for you too? If you could present your data in the same format as the strongtalk tutorial then I can see the trend over time. If this is the case, then considering that Smalltalk has message sends, no type information and the Strongtalk VM is pre-alpha and over 10 years old the comparable times is pretty impressive. Also if you want real integer objects in Java (small or otherwise) then Smalltalk is an order of magnitued faster (at least it was for me). It could all be pilot error on my part, but it was fun :^). Paul.
  78. Are you running the benchmark in the Strongtalk tutorial?

    The loop is repeated 10 million times. This is then repeated 10 times with the best time highlighted.
    Yes, that is the one.
    BTW I know about the trick in Smalltalk that uses the actual byte as an integer untill it gets two big ofcourse then it becomes an object. The point is though this is completely transparent and part of the implementation. So all integers are infact objects as far as the programmer is concerned.
    Indeed, and this is an excellent feature of Smalltalk.
    Do the Java numbers get larger on successive runs for you too?
    No.
    If you could present your data in the same format as the strongtalk tutorial then I can see the trend over time.
    Sure. Running the thing again: For one pass: 31 47 32 31 31 31 32 31 31 31 10 passes: 687 328 328 329 328 312 328 328 313 328 100 passes; 3593 3844 3422 3406 3297 3266 3344 3484 3375 3437
    If this is the case, then considering that Smalltalk has message sends, no type information and the Strongtalk VM is pre-alpha and over 10 years old the comparable times is pretty impressive.
    Well, sort of. The point is that the StrongTalk VM is optimising out all that sort of thing.
    Also if you want real integer objects in Java (small or otherwise) then Smalltalk is an order of magnitued faster (at least it was for me).
    That does not surprise me! I have seen benchmarks from years back that showed that Smalltalk is very fast at object creation.
    It could all be pilot error on my part, but it was fun :^).

    Paul.
    Yes - this is all very illuminating. It shows that even apparently slower languages can be fast in some respects. For example, you get very fast object manipulation in Smalltalk, but as soon as you try and do math....
  79. StrongTalk[ Go to top ]

    Looks like it might be what I'm looking for. Hopefully I'll have some time tonight to check it out. Too bad it's not "production ready."
  80. Hi Erik,
    I've got two questions: 1. When is the appropriate time to bind interface? 2. When is the appropriate time to bind implementation?
    In my last response to this I kind of side stepped the question and referred you to Adele Goldberg. The reason why is because IMO the answer is complex. I'll try and explain my view without writing war and peace :^) Polymorphism means "many forms", I think it's Greek. So the idea of message sends in message based OO is that the receiver can possibly take many forms and the actual form is unknown to the sender who doesn't care. Types are sets of objects that share a common form, so {1, 2, 3} is a set of Integers whilst { A, B, C } is a set of Characters. So a type is a fixed form. Polymorphism is good because it allows for a system to change in ways not initially envisaged by the original designers. Static type systems are good because they aid the static comprehension of the system by both programmers and compilers alike. Static typing and Polymorphism are opposites IMO. So when should you use one versus the other? Well some things are deterministic in nature and naturally fixed. So writing to a bitmapped display is a well-known and fixed problem, so is performing the mathematics for 3D rendering. Such things IMO are ideal candidates for a statically typed approach. They are unlikely to change and the compiler can use the type system to optimise the code. So we end up with fixed "shape" objects that we can depend upon. As for type safety, well predicate calculus shows that you cannot prove the correctness of an imperative program statically. But I must admit declaring all those types and having the compiler check them for me does give me a warm and fuzzy :^). Other things by their very nature are more malleable. The Internet is a good example. The objects you are likely to find out on the internet will come in many forms, yet you will want to talk to all of them. Also the forms of these objects are likely to change over time. Any attempt to fix the expected form of objects in this environment is likely to lead to fragile systems that break often. So for this you may choose to use a meta-protocol to discover the form of the receiver so that you know to send the appropriate messages at runtime. The last point I want to make is a bit more philosophical. Static type systems are inherent in the way we generally think about programming in a procedural sense. Objects can be viewed as a radical departure, a new paradigm. So in this new space it is a good idea to explore how we can program in new ways. Dynamic typing and Polymorphism are complementary IMO. Static types just do not fit polymorphic objects for the reasons I've mentioned above. So my long-winded answer is I don't know. I have spoken to people who have written large production quality systems in Smalltalk for big financial institutions, and they say that the lack of static typing was never a problem. I have done some programming in Smalltalk and Ruby myself and whilst it presents different challenges, I do not find it intrinsically more difficult then a static approach. I would say that we have probably tried to use static approaches where a more dynamic approach would have fit better (component models like EJB's come to mind). My general view is dynamic languages are under utilised and are applicable in many more instances then they are currently applied. Mixing the two approaches is possible. Croquet uses OpenGL written in C++ for it's 3D rendering. On top of this they build their TObject 3D visual objects in Squeak. Paul.
  81. Great post, Paul. I'd like to chime in here. First, I'm starting to learn that dynamic languages with late binding offer a whole new level of metaprogramming. Techniques like open classes demand late binding, but allow the critical tricks that form the very foundation of Rails and Ruby DSLs. As the metaprogramming problems we're solving with frameworks in Java--Spring, AOP, Hibernate, EJB--a language like Smalltalk, Ruby, or even Lisp--should become much more important. I think Ruby will one day have object-relational mappers that will kill anything that we have in the Java space. There have already been two credible attemptes that are ready to take off, and iBATIS already has a Ruby port. Second, as automated testing comes into play, the dangers recede, and that also reduces the benefits of static typing. And it's not just testing. Since the change/try model for dynamic languages is so strong, I tend to develop in much smaller chunks. I get the benefits of continuous integration to the extreme. Java developers underestimate this benefit, I think. I certainly did. So over time, our development practices are marginalizing static typing. And one final point. You can get most of the metaprogramming benefits and the benefits of static typing in functional languages. I'm coming to the conclusion that I like static typing (especially type-inferred static typing) in functional languages, but dynamic typing and message passing in object oriented languages.
  82. First, I'm starting to learn that dynamic languages with late binding offer a whole new level of metaprogramming.
    I think that means you're only scratching the surface of metaprogramming. I wrote an ORM in Python a couple years ago that relied extensively on metaprogramming that in some ways was more sophisticated than ActiveRecord. It required substantially less written code (only when you needed behavior) and supported inheritance (note: a ton of metadata regarding relationships was in the database beyond normal schema information). Static type information could have been added in relatively easily by inserting Java-generic style information in the abstract base classes and then having the metaclass fill it in with concrete base classes. As it was, I put automatically generated runtime type checks in as a form of validation. If you think of classes as factories for objects, and metaclasses as factories for classes, then it makes perfect sense for a metaclass to be able to generate a class from metadata code, XML, an RDBMS, or a combination thereof. A metaclass can also, like a compiler, validate that the information it is using to generate the class is correct, and do this in ways much more sophisticated than a standard language compiler. In a dynamic language like Python this is all done at runtime, but there is no reason why it could not be done at build time. I think your causal links between late-binding and the benefits of dynamic languages are deeply flawed.
  83. Hi Erik,
    In a dynamic language like Python this is all done at runtime, but there is no reason why it could not be done at build time.
    How do you exercise your instance factories (Classes) and Class factories (MetaClasses) at build time? Please explain. Paul.
  84. Hi Erik,

    In a dynamic language like Python this is all done at runtime, but there is no reason why it could not be done at build time.


    How do you exercise your instance factories (Classes) and Class factories (MetaClasses) at build time?

    Please explain.

    Paul.
    Make running unit tests against them part of your build process.
  85. Hi Erik,

    In a dynamic language like Python this is all done at runtime, but there is no reason why it could not be done at build time.


    How do you exercise your instance factories (Classes) and Class factories (MetaClasses) at build time?

    Please explain.

    Paul.


    Make running unit tests against them part of your build process.
    So why not just run unit tests against your objects at build time? This is what Bruce is saying, when running tests all of the time the benefits of static typing is much reduced. Paul.
  86. This is what Bruce is saying, when running tests all of the time the benefits of static typing is much reduced.
    That's where Bruce and I disagree. In my experience once my programs in Python exceed a few hundred lines - as in before they even exit the trivial category in terms of length - I start inserting explicit runtime type checks allover my code because I know somewhere I passed the wrong type into a method or assigned it to an instance variable, but I don't know where. I know, it's a very un-Pythonic practice. Guido would shoot me. But I learned OO in C++, and I learned that "the compiler is your friend, it will check your types, give it meaningful type information." Along those lines, maybe I like static typing so much because I learned from the start to use it to help validate the correctness of my programs. Consequently, I am less productive when that tool is taken away from me. Look at the Boost C++ libraries. There's extensive metaprogramming in there, and it's almost all driven by type information, and all of it is compile-time. My issue is that someone looks at the traits of existing dynamic languages, then looks at some of the benefits of existing dynamic languages, and then concludes that all of the traits must be present in a language to yield all of the benefits. I see a lack of rigorous analysis. I think there are HUGE gains to be made by examining the strengths and weaknesses of existing programming languages. These discussions are a start...but they seem to degrade into ideological debates too quickly. Hmmm...is there a Wiki anywhere for, let's say, documenting requirements for an "ideal" programming language or suite of languages? These forums are interesting, but the threads slowly vanish into obscurity and it seems like no one completely flushes out their ideas. We need a more permanent base.
  87. Hmmm...is there a Wiki anywhere for, let's say, documenting requirements for an "ideal" programming language or suite of languages? These forums are interesting, but the threads slowly vanish into obscurity and it seems like no one completely flushes out their ideas. We need a more permanent base.
    An excellent idea.
  88. Hi Erik,
    This is what Bruce is saying, when running tests all of the time the benefits of static typing is much reduced.


    That's where Bruce and I disagree. In my experience once my programs in Python exceed a few hundred lines - as in before they even exit the trivial category in terms of length - I start inserting explicit runtime type checks allover my code because I know ...
    With all due respect this is where you are going wrong. The moment you say I know is the moment you lock yourself into one mode of thinking. One of the Agile ideas is to learn through doing. So how about leaving out those type tests (which the Python runtime does for you anyway) and replacinging them with TDD unit tests and seeing what happens? This is why I said I don't know because I haven't written enough programmes using a dynamic language, using all the best idioms and techniques to say I know anything. People who have say that static types just aren't needed if you know what you're doing! My experiences make me tend to agree. Like I said before:
    As for type safety, well predicate calculus shows that you cannot prove the correctness of an imperative program statically. But I must admit declaring all those types and having the compiler check them for me does give me a warm and fuzzy :^).
    And I get an even bigger warm and fuzzy feeling when I see that green bar when running JUnit (Java), SUnit (Smalltalk) or Test::Unit (Ruby). I have confidence that my code works : no null pointers, no class cast exceptions, or a string of other runtime exceptions that can equally occur is a statically typed language. The only way to prove that my code works is to run it. This is just mathematical fact. Static typing isn't an ends in it self. You cannot prove that code works through static analysis.
    Hmmm...is there a Wiki anywhere for, let's say, documenting requirements for an "ideal" programming language or suite of languages? These forums are interesting, but the threads slowly vanish into obscurity and it seems like no one completely flushes out their ideas. We need a more permanent base.
    I've noticed that you have a tendency to want to define everything and know everything. My view is that life just isn't like that. No black and white just grey. A language may be good for some purposes and not so good for others. IMO there is no ideal language and there will never be. What there are are choices. As professionals we need to be able to choose the right tool for the job. Paul.
  89. First, I'm starting to learn that dynamic languages with late binding offer a whole new level of metaprogramming.


    I think that means you're only scratching the surface of metaprogramming.

    I wrote an ORM in Python a couple years ago that relied extensively on metaprogramming that in some ways was more sophisticated than ActiveRecord. It required substantially less written code (only when you needed behavior) and supported inheritance (note: a ton of metadata regarding relationships was in the database beyond normal schema information).

    Static type information could have been added in relatively easily by inserting Java-generic style information in the abstract base classes and then having the metaclass fill it in with concrete base classes. As it was, I put automatically generated runtime type checks in as a form of validation.

    If you think of classes as factories for objects, and metaclasses as factories for classes, then it makes perfect sense for a metaclass to be able to generate a class from metadata code, XML, an RDBMS, or a combination thereof. A metaclass can also, like a compiler, validate that the information it is using to generate the class is correct, and do this in ways much more sophisticated than a standard language compiler.

    In a dynamic language like Python this is all done at runtime, but there is no reason why it could not be done at build time.

    I think your causal links between late-binding and the benefits of dynamic languages are deeply flawed.
    If I'm only scratching the surface of metaprogramming, Java is still in the stone ages. So far, most of Java's approaches to solve the metaprogramming problem fundamenally shift to a delayed binding model. And they do it with much more infrastructure, complexity and effort. That's the problem. How much lifting do you have to do to solve the most common, important problems?

    Don't just look at ActiveRecord. Look at domain specific languages in Rails that graft units onto existing classes. (6.days.ago, or 10.metric_tons). Look at Rake, and compare it to Ant, which delays binding by introducing XML. Look at unit testing in Ruby, which uses method injection on a case-by-case basis instead of mandating a DI container (most of which delay binding through XML) and a whole new level of complexity. Look at instant interceptors through open classes, or overriding missing_method, which both allow the introduction of crosscutting concerns, and a whole new family of message passing.

    Hey, I'm not saying that metaprogramming in Java is impossible. I'm just saying that it's much easier in dynamic languages, and a whole new family of tools, and a new stack of groundbreaking frameworks is proving that to be true.

    Thanks for your excellent framework, and these contributions. I'm enjoying this thread.

  90. If I'm only scratching the surface of metaprogramming, Java is still in the stone ages.
    No doubt.
    So far, most of Java's approaches to solve the metaprogramming problem fundamenally shift to a delayed binding model. And they do it with much more infrastructure, complexity and effort. That's the problem.
    Fully agree. But it doesn't have to be this way.
    Hey, I'm not saying that metaprogramming in Java is impossible. I'm just saying that it's much easier in dynamic languages, and a whole new family of tools, and a new stack of groundbreaking frameworks is proving that to be true.
    You're of course correct, at least in my opinion. My point is that we don't want to throw the baby out with the bath water.
  91. Hi Bruce, This was what did it for me too...
    Second, as automated testing comes into play, the dangers recede, and that also reduces the benefits of static typing. And it's not just testing. Since the change/try model for dynamic languages is so strong, I tend to develop in much smaller chunks. I get the benefits of continuous integration to the extreme. Java developers underestimate this benefit, I think. I certainly did. So over time, our development practices are marginalizing static typing.
    +1 Paul.
  92. The last point I want to make is a bit more philosophical. Static type systems are inherent in the way we generally think about programming in a procedural sense. Objects can be viewed as a radical departure, a new paradigm. So in this new space it is a good idea to explore how we can program in new ways. Dynamic typing and Polymorphism are complementary IMO. Static types just do not fit polymorphic objects for the reasons I've mentioned above.
    Hi Paul. Your posts have been interesting, as they have helped clarify my ideas on these matters, but I do find the above paragraph problematic. Polymorphism has been successfully integrated with static typing in a range of languages; all it defines is a form of contract - classes will be either guaranteed to be of, or subclasses of, a class, or to implement an interface, or a sub-interface. One can argue about lack of dynamic flexibility, but I don't see how it can be argued that this isn't polymorphic, after all developers do get major benefits from this approach. Also, the static/dynamic typing issue is surely unconnected with procedural/OOP development - there is a long history of largely procedural languages that have allowed the freedom of dynamic typing, all the way from APL to Visual Basic, TCL, PERL, PHP and so on, and, as stated before, perhaps the earliest OOP language, Simula, was statically typed. What is my point - why am I being critical of these statements? It is because I think that software development has always progressed by compromises and pragmatic, hybrid, approaches. C++ and Java have been wildly successful because they introduced statically-typed OOP and this was accessible to the majority of developers. I think it is healthy to praise the range of approaches, and my opinion is that to set up opposites such as dynamic/oop vs static/procedural would seem to me to denigrate these compromises - I find it too extreme a point of view to be useful. This is why I find some of Alan Kay's statements problematic. For example, why does it matter if C++ isn't what he had in mind when he came up with the term OOP? For a long time, it was the way that most developers where introduced to OOP in at least some form, and the way that OOP ideas became mainstream. That was a big step forward for software development, and not a sign that his ideas had been largely ignored - quite the contrary. More dynamic approaches to development are undoubtedly going to become more important, but I would expect in yet more compromise/hybrid languages, perhaps similar in approach to StrongTalk - allowing optional types could be one way forward. To claim (for example) that static types don't fit polymorphism would appear to be denying the validity of such approaches - it is too Alan Kay-like an attitude for me (of course, you may well consider that praise!). But anyway, thanks for the debate.
  93. Hi Steve,
    What is my point - why am I being critical of these statements? It is because I think that software development has always progressed by compromises and pragmatic, hybrid, approaches
    Well these hybrid approaches had me confused for years. Comming from a real-time embedded systems background I knew what a message queue was. Yet what was going on in C++ wasn't messages. I was looking for objects as indpendent processes each responding to their own message queue. After all that is what messages and ecapsulation meant to me. In the end I gave up on messages and just thought of OO as another form of data abstraction; and classes as types and sub-types and polymorphism as different sub-types. This is why I taught myself Smalltalk, because I wasn't getting OO with C++. I would never have understood a language like Self based on my experiences with C++. In the end it turns out that I was right in the first place. Message based OO is about encapsulation and messaging, but C++ just wasn't doing message based OO. No one told me that. I had to work it out for myself, and I am sure that it may comes as a surprise to many reading this thread that have been doing so-called OO programming for years. Paul.
  94. Hi Steve,

    What is my point - why am I being critical of these statements? It is because I think that software development has always progressed by compromises and pragmatic, hybrid, approaches


    Well these hybrid approaches had me confused for years. Comming from a real-time embedded systems background I knew what a message queue was. Yet what was going on in C++ wasn't messages. I was looking for objects as indpendent processes each responding to their own message queue. After all that is what messages and ecapsulation meant to me.

    In the end I gave up on messages and just thought of OO as another form of data abstraction; and classes as types and sub-types and polymorphism as different sub-types. This is why I taught myself Smalltalk, because I wasn't getting OO with C++. I would never have understood a language like Self based on my experiences with C++.

    In the end it turns out that I was right in the first place. Message based OO is about encapsulation and messaging, but C++ just wasn't doing message based OO. No one told me that. I had to work it out for myself, and I am sure that it may comes as a surprise to many reading this thread that have been doing so-called OO programming for years.

    Paul.
    Just to illustrate how terms can get used in confusing ways, many articles do actually consider method calls in C++ (and Java) to be messaging - function or method invocation is viewed as passing a local message to an object to change state. Even I consider this to be taking the use of such terms too far! I am not saying that the hybrid language approach is ideal - just that it seems to be the way things happen, and it does seem to work - it is an evolutionary rather than revolutionary aproach, but you are right about the disadvantages. It is commonplace to still find OOP considered as merely secondary to procedural code - nothing more than a form of library management. My view is that this is often a result of poor teaching, with OOP mentioned long after other features. Smalltalk is indeed a great language for learning about OOP. One of the things I really like about Smalltalk is its lack of syntax - everything is messages, and adding new control structures and keywords involves nothing more than defining new methods. Even Ruby is a compromise in this respect.
  95. Re: Listen to the podcast[ Go to top ]


    Well were shall I start:

    1. Uniform abstractions (everything is an object, no primitives).
    Mixins
    16. ...

    Shall I go on?
    Yes, lots of cool features, but the point still stands. Every language has it's cool features: Scheme, Perl, Python, Smalltalk, Objective-C, Java - what sets Ruby apart is Rails. That is the killer app for Ruby. It did for Ruby what Visicalc did for Apple, what the IBM PC did for DOS: put it on the map. And if you don't think so, well, ignorance is bliss, then...
  96. Re: Listen to the podcast[ Go to top ]

    Yeah, it's pretty amazing with all the folks that have never written a book in their life stating that Bruce has another agenda. To sell his books. Most IT authors either write books to get their name out as an expert in the field and/or for the love of writing. Unless you're in the top 5 computer books of all time, you can't make a living out of it. I'd say over 80% of computer book authors never get a penny after their initial advance. These are computer books guys, not a NYT bestseller. Ilya
  97. Re: Listen to the podcast[ Go to top ]

    No I haven't listened to the podcast, is that bad? I think however, I'm aware of the 'hidden agenda' for Bruce --- selling books:
    And we all know how rich one can get selling tech books. Kind regards, Kirk
  98. Re: Listen to the podcast[ Go to top ]

    No I haven't listened to the podcast, is that bad? I think however, I'm aware of the 'hidden agenda' for Bruce --- selling books:


    And we all know how rich one can get selling tech books.

    Kind regards,
    Kirk
    Money from book sales is entirely secondary. I suspect there is a strong correlation between book sales and consultancy contracts (and perhaps paid speaking engagements?). So, there is an agenda there. Still, it doesn't mean his message is off, or not worth listening to.
  99. Rise of Ruby !!![ Go to top ]

    I personally feel whatever Bruce said is correct. I am a java developer and I agree what Ruby on Rails is all about "Convention over Configuration". It admires me a lot. Now RoR is in the beginning phase as Java was sometime ago. I am sure it is gonna make a huge impact. We should actually encourage such new technologies rather than finding fault in them. As a programmer we are not restricted to any technologies. If RoR is gonna make things easy for us then why not adopt it or try it or atleast not to comment badly on it. Java community should definetly inherit those features. Instead of Java 2 Standard Edition (which is not standardized), we need something like Java 2 Simple Edition.
  100. Re: Rise of Ruby !!![ Go to top ]

    I personally feel whatever Bruce said is correct. I am a java developer and I agree what Ruby on Rails is all about "Convention over Configuration". It admires me a lot.
    Now RoR is in the beginning phase as Java was sometime ago. I am sure it is gonna make a huge impact. We should actually encourage such new technologies rather than finding fault in them. As a programmer we are not restricted to any technologies. If RoR is gonna make things easy for us then why not adopt it or try it or atleast not to comment badly on it. Java community should definetly inherit those features.
    I fully agree with this. I think we, as a Java community, should not close our eyes on new technologies. For example look at C# which embraces closures and in it's version 3 will support more constructs inspired by functional languages. I don't say ALL things are great about Ruby, but there are some interesting things like meta-programming (which would be a great help to develop DSL's), closures, etc. It's always the same story, when there's a post about Ruby or Bruce Tate or whatever, there's an immediate negative response from the Java-community. I think we should take a look at Ruby and see which things would be nice to have supported by the Java language. What's wrong with taking a look at what 'the others' are doing and learning from that? And that's what Bruce Tate is doing.
  101. Re: Rise of Ruby !!![ Go to top ]

    I personally feel whatever Bruce said is correct. I am a java developer and I agree what Ruby on Rails is all about "Convention over Configuration". It admires me a lot.
    Now RoR is in the beginning phase as Java was sometime ago. I am sure it is gonna make a huge impact. We should actually encourage such new technologies rather than finding fault in them. As a programmer we are not restricted to any technologies. If RoR is gonna make things easy for us then why not adopt it or try it or atleast not to comment badly on it. Java community should definetly inherit those features.


    I fully agree with this. I think we, as a Java community, should not close our eyes on new technologies. For example look at C# which embraces closures and in it's version 3 will support more constructs inspired by functional languages. I don't say ALL things are great about Ruby, but there are some interesting things like meta-programming (which would be a great help to develop DSL's), closures, etc. It's always the same story, when there's a post about Ruby or Bruce Tate or whatever, there's an immediate negative response from the Java-community. I think we should take a look at Ruby and see which things would be nice to have supported by the Java language. What's wrong with taking a look at what 'the others' are doing and learning from that? And that's what Bruce Tate is doing.
    +1
  102. You wascals! Postin' Bruce Tate and his Ruby rantings on TSS is like droppin' a mouse in a barrel full of cats!
  103. The truth in all this BULL[ Go to top ]

    Bruce has got too used to making money from other people's thoughts. Good Luck! THIEF. er.rr... CHIEF
  104. Great discussion. Sorry I wasn't there for most of it. To those of you who liked the podcast, thanks for the kind words. For those of you who didn't, thanks for the lively debate. Paul, we've never met, but I'd love to have a beer some time. Drop me a note at bruce.tate at nospam.j2life.com. I'd love to tap your brain on a new article series that I'm writing.