Discussions

News: Sun Hires the JRuby-guys

  1. Sun Hires the JRuby-guys (156 messages)

    Tim Bray has posted a blog on Sun’s surprising move to hire the JRuby guys Charles Nutter and Thomas Enebo. According to Tim the move to hire came very quickly. In the entry, Tim gives praise to Bob Brewing and Rich Green for making this decision. The round of back slapping is followed up by a Q&A section where Tim answers questions posed by Jacki DeCoster. Synopses of the answers is that both Charles and Thomas will be tasked to working full time to make sure that Ruby runs on the JVM. They will also have a mandate to think about tools as this is a current drawback to moving to Ruby. Has Sun breathed a little life in the Ruby community by hiring Charles Nutter and Thomas Enebo? The party line as stated by Tim is that Sun is interested in anything that developers are interested in.
    Dynamically-typed languages like Ruby are only beginning to be accepted in the software mainstream, and many of the best practices and tools remain to be invented.
    While Sun may have given Ruby the nod as the second official language to be supported on the JVM, it doesn't mean the end to Groovey, Beanshell or jython according to Charles. This view is support by Tim as he states that Sun is actively looking at PHP, Perl, Python, VisualBasic and Rails. With all of this choice in the works it looks as though the focus on the JVM is well placed. Message was edited by: kirk@javaperformancetuning.com

    Threaded Messages (156)

  2. Second official language?[ Go to top ]

    While Sun may have given Ruby the nod as the second official language to be supported on the JVM
    I don't see any evidence of this in the blog entry. I more get the impression that it's half marketing/responding to hype (that's not necessarily a bad thing, a company the size of Sun assigning two skilled guys to work on something that's getting so much attention is probably a very good move and more cost effective than what some companies would do) and half attempt to learn. IMHO the learning half is probably what's more important to Sun R&D while the hype half is what get the reqs approved. Personally I wish they would have hired someone to work on Jython, because I'm not too fond of Ruby (yet, it took me a while to love Python).
  3. Re: Sun Hires the JRuby-guys[ Go to top ]

    I think this is exciting news. Things will get interesting (and good for Ruby developers) if and when the JRuby guys get performance via compilation to byte codes, and also if good tools for JRuby appear in future. This should increase pressure on C-Ruby developers to provide similar improvements. Competition between implementations is good for developers.
  4. Re: Sun Hires the JRuby-guys[ Go to top ]

    I think this is exciting news. Things will get interesting (and good for Ruby developers) if and when the JRuby guys get performance via compilation to byte codes, and also if good tools for JRuby appear in future. This should increase pressure on C-Ruby developers to provide similar improvements. Competition between implementations is good for developers.
    Hi Steve, This is great news. The main advantage is true choice on the JVM platform. Sun has never really marketed the Java platform as a seperate entity from the Java language. So Java everywhere meant the language and the platform. This move can only give developers more choice over the language they choose. I do have some concerns: 1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform? 2. Tim Bray at Sun is a Ruby advocate, and there seems to be many at Sun with a genuine interests in dynamic languages, but I can't help thinking that this move has more to do with recent anouncements by Microsoft that they will be providing a lot more dynamic language support on the CLR. So this could just be another example of Sun playing catch-up with Microsoft. 3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java. So like Groovy and JPython, the adoption of JRuby may remain low, with people sticking to Java only solutions like Seam. Time will tell whether JRuby becomes a serious production language, but even if it remains in the "scripting" realm then the pseudo endorsement by Sun can only lead to more Java programmers giving it a go. Which IMO can only be a good thing. If the only tool you have in your tool box is an hammer, then every problem you come across will look like a nail! Paul.
  5. Re: Sun Hires the JRuby-guys[ Go to top ]

    1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform?
    On a somewhat related note, Sun open sourced the StrongTalk VM yesterday. http://www.strongtalk.org
  6. Re: Sun Hires the JRuby-guys[ Go to top ]

    1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform?


    On a somewhat related note, Sun open sourced the StrongTalk VM yesterday. http://www.strongtalk.org
    Wow! This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book. Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too. IMO, moving forward the platform will become more important then the language, so why lock yourself in to an inferior platform? Strongtalk with its polymorphic inline cache seems a lot more future proof then the JVM to me, ofcourse you would loose backward compatibility and access to a broad set of bytecode libraries. For some this may be a trade off worth taking (in contrast to moving from Java to native Ruby say). Lets see how long it takes for a Strongtalk based open source project to take off. Sun are definately on a roll! Paul.
  7. Re: Sun Hires the JRuby-guys[ Go to top ]

    Lets see how long it takes for a Strongtalk based open source project to take off.
    Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
  8. Re: Sun Hires the JRuby-guys[ Go to top ]

    Lets see how long it takes for a Strongtalk based open source project to take off.


    Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
    Well, I wasn't holding my breath to see the VM source code open sourced. I didn't expect Sun to take Ruby support on the JVM seriously either. Fortunately there are a lot of knowledgeable people out there bot inside and outside large companies like Sun, that feel that it is time for change. If they are right then anyone who chooses to graft say Ruby onto Strongtalk and port the C++ VM code to several platforms (a relatively trivial task) could end up being the next JBoss. I'm not holding my breath. I think I'll just wait and see :^) Paul
  9. Re: Sun Hires the JRuby-guys[ Go to top ]

    Lets see how long it takes for a Strongtalk based open source project to take off.


    Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
    Besides, a quick look at the website shows that the project still lacks many basic stuff, like automatic GC, multithreading, etc., and is not recommended for production yet. It still has a long way before catching up with JVM in many aspects, although it may be more advanced in some specific areas.
  10. Re: Sun Hires the JRuby-guys[ Go to top ]

    Wow! This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book. Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too.
    You gotta wonder where we things would be right now if Sun had gone down the Self/Strongtalk VM route. Well, technically Sun did incorporate some Self VM ideas into the JVM. But it would have been interesting to have had a Strongtalk environment, along with a Algol-like language.
  11. Re: Sun Hires the JRuby-guys[ Go to top ]

    Wow!

    This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book.

    Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too.


    You gotta wonder where we things would be right now if Sun had gone down the Self/Strongtalk VM route. Well, technically Sun did incorporate some Self VM ideas into the JVM. But it would have been interesting to have had a Strongtalk environment, along with a Algol-like language.
    +1 Agreed. Our industry is obsessed with short-termism. We tend to opt for short term gain, leading to long term pain. We then to re-invent ourselves every ten years or so. If we where to stop and take a long term view we could save ourselves so much wasted time and effort IMO. My view is that eventually we will work our way back to the future. Back to the 80's or should I say Smalltalk-80 :^). Paul.
  12. Re: Sun Hires the JRuby-guys[ Go to top ]

    3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java.
    Have Ruby developers interest in exploring Java? Or are they just ex. Java developers? Either way, it does not seem more open or adventurous. Java developers are quite far from being conservative IMHO. They might be in the middle somewhere, but hardly conservative. There is a group far more conservative and larger than the body of Java developers, if you ask me.
  13. Re: Sun Hires the JRuby-guys[ Go to top ]

    3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java.


    Have Ruby developers interest in exploring Java? Or are they just ex. Java developers? Either way, it does not seem more open or adventurous.

    Java developers are quite far from being conservative IMHO. They might be in the middle somewhere, but hardly conservative. There is a group far more conservative and larger than the body of Java developers, if you ask me.
    This is just pure opinion of course, and neither of us have any data to back any claim. I was a strong Java advocate back in 1996 where it seemed obvious to me Java's advantages over C++. At that time most C++ programmers where ridiculing Java as a toy in pretty much the same way many Java programmers ridicule Ruby today. Also Java 1.0 was pretty limited. No event model (that turned up in Java 1.1), and hence no decent windowing toolkit. If wasn't fit for much more than simple applets. Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management. Over time Java got better, and faster, and much of the C++ crowd where won over. It took two years where I where to finally convince them to pilot Java. I just see history repeating itself. There are different types of personalities. Some people are constantly looking for ways to improve and push forward, others are happy with the status quo as long as they can find steady and reliable employment. As the Java bandwagon took off the "herd mentality" became firmly entrenched IMO. The focus became (premature) standardisation rather then innovation and technical excellence. With the right set of Java acronyms on your CV you knew that you where guaranteed to find work. Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion. Paul.
  14. Re: Sun Hires the JRuby-guys[ Go to top ]

    Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion.

    Paul.
    I disagree with you 100%. I believe the best developers have a natural instinct of being skeptical about miracles, and they just jump to a new solution when they feel it's mature enough for their purposes. They know there are trade-offs, and often when you gain something, like a feature, you lose something else, like simplicity, performance, etc. I think that this move was the best Sun could do. And both Microsoft and now Sun are pulling the carpet from below the so called "dynamic languages". Once you get a good implementation (JRuby, Jython, IronPython, etc) with a good speed, that can easily be integrated with existing code, what's the point of using the original Ruby or the original Python? Ruby, Python, etc are dead, so dead they don't even realize it yet. I see in the next 10 years the competition will be between platforms, the Java platform and its language forks against .Net and its language forks.
  15. Re: Sun Hires the JRuby-guys[ Go to top ]

    Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion.

    Paul.


    I disagree with you 100%. I believe the best developers have a natural instinct of being skeptical about miracles, and they just jump to a new solution when they feel it's mature enough for their purposes.

    They know there are trade-offs, and often when you gain something, like a feature, you lose something else, like simplicity, performance, etc.

    I think that this move was the best Sun could do. And both Microsoft and now Sun are pulling the carpet from below the so called "dynamic languages". Once you get a good implementation (JRuby, Jython, IronPython, etc) with a good speed, that can easily be integrated with existing code, what's the point of using the original Ruby or the original Python?

    Ruby, Python, etc are dead, so dead they don't even realize it yet. I see in the next 10 years the competition will be between platforms, the Java platform and its language forks against .Net and its language forks.
    Sounds like you are reading things into my words, that I'm just not saying! And what is all this stuff about death? I'm making a simple point. To exercise choice firstly you need to be informed. To become informed requires effort. Some just can't be bothered and find it easier to flow with the herd (whilst slinging mud at everyone else). Hopefully an healthy ecosystem of languages supported on a common platform or on mutiple platforms will reduce the size of the herd, providing less of a place for developers to hide. That way developers will have more of an incentive to actively choose what is the best tool for them, rather then just using the same as everyone else. It looks like I've hit a nerve, and IMO the tone of your response just makes my point :^). Paul.
  16. Re: Sun Hires the JRuby-guys[ Go to top ]

    I'm making a simple point. To exercise choice firstly you need to be informed. To become informed requires effort. Some just can't be bothered and find it easier to flow with the herd (whilst slinging mud at everyone else).

    Hopefully an healthy ecosystem of languages supported on a common platform or on mutiple platforms will reduce the size of the herd, providing less of a place for developers to hide.

    That way developers will have more of an incentive to actively choose what is the best tool for them, rather then just using the same as everyone else.

    It looks like I've hit a nerve, and IMO the tone of your response just makes my point :^).

    Paul.
    I think you didn't understand anything of what I said at all. You mentioned the similarities between C++ -> Java time, to a supposed "Java -> Ruby" happening now. First I disagree with that because what is driving the changes in Java land is .Net (as usual), not Ruby. And I just said early adopters cannot be accounted as an "examples to follow". Java has come a long way to become a viable option and that is due to the work of many companies, not due to a few "enlightened" individuals. The best developers have their reasons, and the reasons depend on the requirements, and the requirements go way beyond than just the code, for using this or that platform. Second, I just illustrated what will happen to the "dynamic languages". Just use the logic. This is a death blow to their original implementations, and these forks will soon have more users than they ever had. Once they get more users, they will be free to add any "extensions" for improving it either for the JVM or for .Net. I think this move is a sign of what is coming, it will help: - To keep the Java ecosystem alive and competitive with .Net; - To either kill or make it an isolated gueto of the original implementations (Ruby, Python, etc) by draining mindshare to a JVM language; - The future to be platform vs. platform, not languages. Record this day in your memory and 10 years from now tell me if I was right or not.
  17. Black Hole's and "innovation"[ Go to top ]

    Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management.
    Ok, here's another theory. There's this "Black Hole" theory Gosling was talking about recently: http://blogs.sun.com/jag/entry/the_black_hole_theory_of Goes something like this: "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". (quoted above) I have another theory. There are some fairly cool programming languages. They do some very cool things. But people have a hard time grasping them. For example, most people only see parentheses when they see LISP, they can't get past the syntax. And Smalltalk is just weird.. and way too touchy feely (see Squeak for example). So people tend to take the safe road. C++ was ok because it was just enhanced C. Java was ok, because we needed the sandbox (originally), the portability and it was a lot like C++ in syntax. Yet Java allowed us to reach a much larger potential than C++ did. It helped us see some of the cool features of Smalltalk and Self that we'd previously dismissed as weird. Now comes Ruby.. an language that is almost a replica of Smalltalk (minus the environment, minus the same level of cleanliness, minus the baby look, etc..). Ruby allows us to see the advantages of that older language.. so interest builds up and we get all excited about this "innovation". 20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
  18. Re: Black Hole's and "innovation"[ Go to top ]

    20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed. My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions. Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java. There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
  19. Re: Black Hole's and "innovation"[ Go to top ]

    My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago,
    Becomes an issue for what implementation of what language? The commercial implementations of Common Lisp don't have performance issues. Dylan was/is fast. Strongtalk has a very fast VM. Ruby's implementation is irrelevant to everybody else.
    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
    The advantages of static typing were never lost to be re-discovered. Most language research is done in the ML/Haskell family.
  20. Re: Black Hole's and "innovation"[ Go to top ]

    My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago,


    Becomes an issue for what implementation of what language? The commercial implementations of Common Lisp don't have performance issues. Dylan was/is fast. Strongtalk has a very fast VM. Ruby's implementation is irrelevant to everybody else.

    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.


    The advantages of static typing were never lost to be re-discovered. Most language research is done in the ML/Haskell family.
    Hi Frank, Exactly. The demise of Smalltalk had nothing to do with static typing. Try commercial mis-management like the infamous suicide note from ParcPlace Systems: http://www.listserv.dfn.de/cgi-bin/wa?A2=ind9703&L=info-cls&D=0&T=0&P=36059&F=P (A link to the original internal e-mail is out there somewhere) And the fact that a single Smalltalk developer license would set you back around £3000 at the time (I think, some massive amount anyway), compared to Java which was free and marketed like crazy, and you can see why the writing was on the wall. Smalltalks big percieved advantage over C++ was memory management. Java had "borrowed" that along with byte code and the use of a VM, and was free. So Java was seen by many as a "good enough" Smalltalk. Like I mentioned earlier - we suffer from short-termism. So here we are again 10 years later picking through the bones of Smalltalk/Lisp for what we can "borrow" next! Paul.
  21. Re: Black Hole's and "innovation"[ Go to top ]

    20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).


    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.

    My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.

    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.

    There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
    Hi Steve, I've seen you make this argument again and again, but I'm sorry it just isn't supported by the facts. I've spoken to several true Smalltalk developers over they years, who have written thousands of lines of production Smalltalk code mostly in critical environments like banking (the City of London), and none of them agree with what you say. Infact try making this assertion on a Smalltalk forum and I'm sure that you'd be linched (metaphorically :^)). All the ex-Smalltalkers I know are drepressed that they have to program in Java to make a living and would return to Smalltalk at the drop of an hat if they knew they could find secure work. This is the thing about herds, not everyone in the herd actually chooses to be there, many just get swept along! Anecdotel I know, but we had a ex-Smalltalker on my last team (who incidently wrote the simplest and cleanest code I've seen for years) who was generally dis-interested and didn't particpate much in technical team decisions. One day I came in with a copy of the Purple book (the Smalltalk bible), and he came up to me a different man, all energised and enthusiatic - "Oh great, with Smalltalk we'll knock this out in days". I had to explain that I was just doing stuff in my spare time and we weren't using Smalltalk, the change is his body language was enormous. For a person who likes to see claims backed by facts, how about comming up with some facts of your own? Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"? Most of the best programmers out there (Kent Beck, Ward Cunningham, Ron Jeffries, Ralph Johnson, Gilad Bracha (Sun), Dave Griswold (Sun), etc), just to name a few come from a Smalltalk background and if you read their blogs you will see that they would all go back to Smalltalk in an instance if they got the chance. BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^). Take a look yourselves: http://tech.groups.yahoo.com/group/strongtalk/messages Smalltalk is a muched loved language. Paul.
  22. Re: Black Hole's and "innovation"[ Go to top ]

    20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).


    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.

    My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.

    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.

    There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.

    Hi Steve,

    I've seen you make this argument again and again, but I'm sorry it just isn't supported by the facts. I've spoken to several true Smalltalk developers over they years, who have written thousands of lines of production Smalltalk code mostly in critical environments like banking (the City of London), and none of them agree with what you say.

    Infact try making this assertion on a Smalltalk forum and I'm sure that you'd be linched (metaphorically :^)).

    All the ex-Smalltalkers I know are drepressed that they have to program in Java to make a living and would return to Smalltalk at the drop of an hat if they knew they could find secure work. This is the thing about herds, not everyone in the herd actually chooses to be there, many just get swept along!

    Anecdotel I know, but we had a ex-Smalltalker on my last team (who incidently wrote the simplest and cleanest code I've seen for years) who was generally dis-interested and didn't particpate much in technical team decisions. One day I came in with a copy of the Purple book (the Smalltalk bible), and he came up to me a different man, all energised and enthusiatic - "Oh great, with Smalltalk we'll knock this out in days". I had to explain that I was just doing stuff in my spare time and we weren't using Smalltalk, the change is his body language was enormous.

    For a person who likes to see claims backed by facts, how about comming up with some facts of your own? Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?

    Most of the best programmers out there (Kent Beck, Ward Cunningham, Ron Jeffries, Ralph Johnson, Gilad Bracha (Sun), Dave Griswold (Sun), etc), just to name a few come from a Smalltalk background and if you read their blogs you will see that they would all go back to Smalltalk in an instance if they got the chance.

    BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^).

    Take a look yourselves:

    http://tech.groups.yahoo.com/group/strongtalk/messages

    Smalltalk is a muched loved language.

    Paul.
    Sorry, but it is clearly supported by fact. If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed, and as for the namespace issue, you need look no further than any commercial Smalltalk to see how these matters are having to be dealt with. As an experienced Digitalk Smalltalk user in the 80s, I had to deal with exactly this kind of namespace clash when installing libraries and extensions. Sorry Paul, but just because many well-known high-profile developers and some you have spoken too like the language, and can be productive with it, does not mean that these issues don't exist. You can't hand-wave away well-established issues simply because certain people are productive with Smalltalk in certain applications. This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally. This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't? I like Smalltalk a lot too, but I realise its limitations.
  23. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, No I think you are the one doing all the hand-waving. Frank made the point about Smaltalk and performance which I agree with. At one time performance was a problem for Smalltalk, but you disagreed:
    I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well.
    A bit of flip-flopping going on here I think. With regards to name spaces, yes I agree too that this was an oversight in Smalltalk-80 and I don't care much for the later commercial solutions either. If you had made this specific point, I would have responded to it in kind but you didn't. Your points were:
    The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
    And
    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
    Now I don’t know what the size of a project has got to do with performance. Either the language is performant or it’s not, which is it? And I don’t see what namespaces has to do with open classes, the two issues are orthogonal. Also throwing in static typing as a solution for all ills at the end doesn’t strengthen your argument either. Several people responded, (Frank, Amin and myself) highlighting your folly yet you continue to respond in the same vein. Now I know that you have decided for your organisation that Java should be the standard, fine. Justifying your decision with mis-information and black-propaganda after the fact doesn't help. I challenge your to find a single blog entry from an experienced Smalltalk programmer who agrees in anyway with your assessment. There are people on this forum who have never tried a number of the languages we are discussing so we have a responsibility to be honest and truthful. So again:
    Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
    A bad workman blames his tools. I agree that with power comes responsibility and languages like Lisp and Smalltalk provide the developer with a great deal of power. I think the correct term is that these languages are highly "expressive" meaning a lot of functionality for very little code. I want a language with inherent power, so do many framework and library authors. This power does not have to be used by every day application developers as clearly demonstrated in Rails (and Spring and Hibernate and JBoss etc) and policing it’s use is a cultural issue in my view not a technical one (although there are technical solutions in the pipeline, see Martin Fowlers discussion on Language Workbenches). You don’t hear people saying that dynamic proxies or the reflection API should be removed from Java because it is too dangerous for the average programmer. The truth is that the average Java programmer seldom if ever uses these features. If you are a framework programmer though writing JBoss, or involved with Spring or Hibernate then these features are priceless and the real truth is that you could do with a lot more. Even <a href="" "http:="" blogs.sun.com="" ag="" ntry="" he_black_hole_theory_of"="" rel="nofollow">Gosling admits that his attempt to "police" developer power in Java with inner classes has lead to somewhat of a kludge. If even he can concede, I can't see why you can't. lLisp and Smalltalk just provide a lot more meta-capabilities “designed in” from conception through dynamic typing and late-binding. The names I mentioned are not my mates, the list includes the names of people that got your beloved JVM running half decent. People like Gilad Bracha who have views that are considerably different from yours. So please make your specific points and I will respond to them as such. Otherwise cut out the noise. Regards, Paul.
  24. Re: Black Hole's and "innovation"[ Go to top ]

    A bit of flip-flopping going on here I think.
    No. This was in response to a claim that people were 'not ready' for the features of Smalltalk and LISP 20 years ago, and that improvements in hardware have changed this. The relatively widespread use of Digitalk Smalltalk (not that small a group!) 15-20 years ago is evidence against this claim.
    Now I don’t know what the size of a project has got to do with performance. Either the language is performant or it’s not, which is it?
    As described below in a quote from Dave Griswold, there are many issues that only arise in larger applications. As an application grows, new functionality can be added, and it is likely that at some point, such functionality can require high performance. Specific cases I have come across with Smalltalk were XML parsing and image processing.
    And I don’t see what namespaces has to do with open classes, the two issues are orthogonal.
    No, they aren't. The issue is about how extensions to the language can conflict. In Smalltalk this can happen when new methods are loaded from one package that conflict with those from another. The situation with open classes is worse, as the same conflicts can happen at run time. Smalltalk has attempted to resolve such matters with namespaces.
    Also throwing in static typing as a solution for all ills at the end doesn’t strengthen your argument either.
    I never said it was a solution to all ills, just that it can help.
    Several people responded, (Frank, Amin and myself) highlighting your folly yet you continue to respond in the same vein.
    Facts aren't a matter of votes on a thread.
    Now I know that you have decided for your organisation that Java should be the standard, fine. Justifying your decision with mis-information and black-propaganda after the fact doesn't help.
    As I have said before I use a range of languages. I use Java, Groovy, Ruby, Python - whatever suits.
    I challenge your to find a single blog entry from an experienced Smalltalk programmer who agrees in anyway with your assessment.
    First of all, I am an experienced Smalltalk programmer. I have been using the language for 20 years, and I am still supporting software written in the language. However, if you don't trust my experience, how about this from Dave Griswold: http://strongtalk.org/history.html "On the East Coast, I (Dave Griswold) was frustrated with the fact that there were still a lot of obstacles to using Smalltalk in most kinds of production applications. ParcPlace and Digitalk had made a lot of progress, especially with Deutsch/Schiffman dynamic translation technology, which sped up Smalltalk by a factor of 1.6 or so at the time. But it was still way too slow for any kind of compute intensive application (which I was doing), and I felt there were several other obstacles to widespread use as well. One of the biggest among these in my mind was the lack of any kind of type system, which although it makes the language extremely flexible, also means that organizing and understanding large-scale software systems is a lot harder. " There were indeed obstacles to widepread use of the language. This is exactly my view.
    There are people on this forum who have never tried a number of the languages we are discussing so we have a responsibility to be honest and truthful.
    Absolutely.
    Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
    It is a global experience, of course. If it were not, then why would StrongTalk have been developed?
    A bad workman blames his tools.
    Far worse is a workman who does not recognise the limitations of a tool.
    So please make your specific points and I will respond to them as such. Otherwise cut out the noise.

    Regards,

    Paul.
    Please try and respond politely, and to the points I make. You may wish to post specific information about Smalltalk performance, for example. Calling someone's honest contribution 'noise' is not helpful.
  25. Re: Black Hole's and "innovation"[ Go to top ]

    Hey Paul,
    Frank made the point about Smaltalk and performance which I agree with. At one time performance was a problem for Smalltalk, but you disagreed:
    I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well.
    A bit of flip-flopping going on here I think. With regards to name spaces, yes I agree too that this was an oversight in Smalltalk-80 and I don't care much for the later commercial solutions either. If you had made this specific point, I would have responded to it in kind but you didn't.
    I don't think Steve is flip-flopping at all. For one, 4MB is an awful lot of RAM for a 286 ;-). Secondly, different problem domains have different performance requirements. The way I interpret Steve's point is that Smalltalk has some issues with scaling in regards to performance and complexity (namespace issues). However, many (most?) applications will never hit the point where these issues actually become a limiting factor.
    Now I don’t know what the size of a project has got to do with performance.
    I would say they are generally correlated. Larger systems with more users tend to deal with larger datasets and more complex codebases. Making an application performant on a single server with minimal resource contention is a lot easier than doing so across many servers with high resource contention.
    Either the language is performant or it’s not, which is it?
    That's simply not true. Think about algorithms for finding prime numbers. The most performant algorithms in the asymptotic sense perform awfully for small inputs. This is common. Programs tend to have a "sweet spot." Scaleable solutions generally incur some overhead that isn't worth the cost for "small" problems.
    And I don’t see what namespaces has to do with open classes, the two issues are orthogonal.
    Not in the least. Namespaces are a tool for managing complexity by separate software into pieces that won't have naming collisions and between which dependencies should be minimized (and unidirectional). Open classes permit the introduction of dependencies in a ad-hoc fashion - thereby introducing complexity.
    I agree that with power comes responsibility and languages like Lisp and Smalltalk provide the developer with a great deal of power. I think the correct term is that these languages are highly "expressive" meaning a lot of functionality for very little code.
    You don’t hear people saying that dynamic proxies or the reflection API should be removed from Java because it is too dangerous for the average programmer. The truth is that the average Java programmer seldom if ever uses these features. If you are a framework programmer though writing JBoss, or involved with Spring or Hibernate then these features are priceless and the real truth is that you could do with a lot more.
    The problem here is that dynamic languages loose many of their advantages when their advanced features are not used by the application programmer - and in many cases the features like blocks/closures in Ruby must be used to effectively use the language; while features like reflection in Java are relatively hidden, difficult to use, and easy to ignore. Now that doesn't mean you can't have the best of both worlds. I think Python provides all (more, in my opinion) the elegance with advanced dynamic features that Ruby provides w/o pushing them on the programmer.
  26. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Eric, Read your post, and I'm sorry to say that you are factually wrong on almost every point. I will go through your points, but first of all may I make a general statement. I do not want to make this about static versus dynamic typing because: A) Smalltalk in the form of Strongtalk has static typing, and shows clearly that what can occurs statically at compile time in terms of testing for correctness is indeed very different then what can occur dynamically at runtime. I know no other static type system that does this, and I don't want to try and explain the difference again because last time I did it was lost on everyone involved. B) Dynamic programming requires a different, more incremental "suck-it-and-see" programming style. If you didn't learn to programme that way it does take a little getting use to and can be off putting. This doesn't make it inferior, infact I believe it to be a superior approach once you get use to it and it is exemplified by the TDD approach to programming which may I remind you came from Smalltalk (SUnit by Kent Beck). If you did learn to programme that way, it comes natural and you would probably fine static programming with all the verbose type declarations awkward and unatural. Having listened to what people have said over several threads I really just think it comes down to what you are use to. So ..
    I don't think Steve is flip-flopping at all. For one, 4MB is an awful lot of RAM for a 286 ;-). Secondly, different problem domains have different performance requirements. I think the main pillar of Steve's argument is that Smalltalk is too slow for production use not only today but in the future. The processors we use today are probably 10 to 20 times faster then that 286 and if moores law is to be believed is likely to double again in the next 18 months.
    Without giving specifics our talking about a specific bench mark or application type, then talking about performance is meaningless. If I was writing a first class chess programme then Java is too slow, for an enterprise web application it's fine.
    Now I don’t know what the size of a project has got to do with performance.
    I would say they are generally correlated. Larger systems with more users tend to deal with larger datasets and more complex codebases.
    You need to follow more closely. He didn't say as user load increases, he said as the project size (code size) increases. I repeat project size has nothing to do with performance.
    Either the language is performant or it’s not, which is it?
    That's simply not true. Think about algorithms for finding prime numbers. The most performant algorithms in the asymptotic sense perform awfully for small inputs. This is common. Programs tend to have a "sweet spot." Scaleable solutions generally incur some overhead that isn't worth the cost for "small" problems.
    Agreed. You make the point I made earlier, any discussion about performance needs to be specific. I won't acuse you of flip-flopping though ;^).
    The problem here is that dynamic languages loose many of their advantages when their advanced features are not used by the application programmer - and in many cases the features like blocks/closures in Ruby must be used to effectively use the language; while features like reflection in Java are relatively hidden, difficult to use, and easy to ignore. Now that doesn't mean you can't have the best of both worlds. I think Python provides all (more, in my opinion) the elegance with advanced dynamic features that Ruby provides w/o pushing them on the programmer.
    This is just plain wrong. The purpose of a DSL as used in Smalltalk or Lisp or Ruby for that matter is to hide the underlying complexity from the application programmer. That is why it is called a Domain Specific Language. The idea is to raise the level of abstraction. I could go into examples but I've done so in the past to no avail. In summary, I don't believe any of us here are qualified to talk about the applicability of dynamic languages because I get the strong feeling that all our experiences are strongly biased towards static languages. What I do is keep an open mind and talk to people who have years of relevent experience using dynamic languages in critical sectors like banking as I mentioned before (JPMorgan was a Smalltalk shop for years). What I have found is that more often then not any difficulty I may experience with dynamic languages is due to my lack of familiarity with the idioms and techniques that go with dynamic programming, and after perservering I tend to find that indeed what they had described to me as their experiences is infact true for me too. None of these experienced dynamic programmers that I have spoken to personally or corresponded with over the web make the claims that either yourself or Steve make. Infact most of them find dynamic programming a joy and miss it greatly. The only people that make these claims are static language programmers and they are the least qualified IMO to say. Paul.
  27. Re: Black Hole's and "innovation"[ Go to top ]

    In summary, I don't believe any of us here are qualified to talk about the applicability of dynamic languages because I get the strong feeling that all our experiences are strongly biased towards static languages.
    I was a Smalltalk developer for far longer than I have been developing with Java, and I have produced commercial Smalltalk applications, so I consider myself well qualified to discuss such matters.
    None of these experienced dynamic programmers that I have spoken to personally or corresponded with over the web make the claims that either yourself or Steve make. Infact most of them find dynamic programming a joy and miss it greatly. The only people that make these claims are static language programmers and they are the least qualified IMO to say.

    Paul.
    You asked me to provide some evidence that dynamic programmers have come across issues (such as performance) with these languages, and I did, with comments from Dave Griswold, so to claim that only static language programmers see issues with dynamic languages is evidently false. If there weren't such issues, then projects like Self and StrongTalk, which explored how to optimise dynamic languages, would not have been started. There would also be no point to the YARV project, attempting to speed up Ruby, or the Parrot project to speed up Perl (and possibly other languages like TCL as well). I find Smalltalk a fantastic language, and it was a real pleasure to use - it was the best development environment I have ever worked with, but I am realistic enough to recognise the potential failings of the language.
  28. Re: Black Hole's and "innovation"[ Go to top ]

    You need to follow more closely. He didn't say as user load increases, he said as the project size (code size) increases. I repeat project size has nothing to do with performance.
    I know what he said, and I'm saying that I think there is a correlation. I'm not saying there is a causal relationship.
    Without giving specifics our talking about a specific bench mark or application type, then talking about performance is meaningless. If I was writing a first class chess programme then Java is too slow, for an enterprise web application it's fine.
    It still depends on what the enterprise web application is doing. But I'm splitting hairs...
    This is just plain wrong. The purpose of a DSL as used in Smalltalk or Lisp or Ruby for that matter is to hide the underlying complexity from the application programmer. That is why it is called a Domain Specific Language. The idea is to raise the level of abstraction. I could go into examples but I've done so in the past to no avail.
    Underlying complexity of what? Concepts like blocks/closures and metaprogramming are not simple. Yes, they can be used to build abstractions that make application programming much more natural - but they are not in themselves simple. You can't program idiomatic Ruby without using blocks. The idea of people using RoR w/o a basic understanding of Ruby metaprogramming scares me. My point that there are ideas in many dynamic languages (and C++, for that matter) that for one reason or another many (most?) people have a very hard time grasping. This is complexity, even if it facilitates the elimination of greater complexity, and it can be an insurmountable barrier to adoption for some people. I think Java capitalized very well on this fact by being extraordinarily simple. Constructs like operator overloading and templates found in C++ can be very powerful, but they can also leave many people completely lost and confused. So can blocks/closures and metaprogramming. So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
  29. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Eric,


    Underlying complexity of what?

    Concepts like blocks/closures and metaprogramming are not simple. Yes, they can be used to build abstractions that make application programming much more natural - but they are not in themselves simple.

    You can't program idiomatic Ruby without using blocks. The idea of people using RoR w/o a basic understanding of Ruby metaprogramming scares me.

    My point that there are ideas in many dynamic languages (and C++, for that matter) that for one reason or another many (most?) people have a very hard time grasping. This is complexity, even if it facilitates the elimination of greater complexity, and it can be an insurmountable barrier to adoption for some people.

    I think Java capitalized very well on this fact by being extraordinarily simple. Constructs like operator overloading and templates found in C++ can be very powerful, but they can also leave many people completely lost and confused. So can blocks/closures and metaprogramming. So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
    Again, I believe this is all down to perspective. I personally find nothing complex about blocks. Iterating through collections by passing a block seems more intuitive to me then using iterators. Also passing a block as a callback parameter seems a lot more natural IMO then using anonymous inner class. On my last project we had two graduates using Ruby and they took to it like ducks to water. One of them had PHP experience (final year project), his comment was yeah it's just like PHP, you write what you want it to do and it just does it, no fuss no verbose types everywhere. Sometimes when you've too much prior context then things can seem more difficult then they are. I guess thats what they mean when they talk about teaching old dogs new tricks. Paul.
  30. Re: Black Hole's and "innovation"[ Go to top ]

    Sometimes when you've too much prior context then things can seem more difficult then they are. I guess thats what they mean when they talk about teaching old dogs new tricks.
    Sometimes people get so caught up in reviving old tricks that they forget why those tricks left the mainstream.
  31. So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
    I agree with that. I enjoy a language when it is powerful but also promotes clarity. I really liked developping in Smalltalk when I was still a student (2 years ago...) but it was always so hard to get in someone's else code. It takes a really long time to get started in a new project IMO, although my SmallTalk experience is fairly limited. By the way, I also had to work with ML in university. That was a really neat language, especially when working on collections. I hope closures make it to the VM although I'm not sure if it should be in Java directly or in another form.
  32. Re: Black Hole's and "innovation"[ Go to top ]

    If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed
    And the debates over Java performance have been going on for how long?
    Sorry Paul, but just because many well-known high-profile developers and some you have spoken too like the language, and can be productive with it, does not mean that these issues don't exist
    I'll add the need for traits to overcome single inheritance limitations in Smalltalk. I won't even get started with Java.
    This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.
    So Java performance is improved because of various factors, but Smalltalk implementations don't?
    This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?
    Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?
    I like Smalltalk a lot too, but I realise its limitations.
    I like Java, but I realize its limitations.
  33. Re: Black Hole's and "innovation"[ Go to top ]

    If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed


    And the debates over Java performance have been going on for how long?
    But that is my point. These things are debated; they matter. They matter for Java and they matter for dynamic languages too.
    This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.


    So Java performance is improved because of various factors, but Smalltalk implementations don't?
    Indeed. The reasons why you can better optimise languages with type information than dynamically typed languages are well understood.
    This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?


    Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?
    I don't get what your point is here. Much effort has indeed gone into optimising the Java VM; successfully. Java can approach the speed of C in very many situations. At least with Java, it was realised that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue as it often is with dynamic languages.
    I like Smalltalk a lot too, but I realise its limitations.


    I like Java, but I realize its limitations.
    Same here. My choice of Java for most of my development is pragmatic, not because I think it is in any way a perfect language.
  34. Re: Black Hole's and "innovation"[ Go to top ]

    If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed


    And the debates over Java performance have been going on for how long?


    But that is my point. These things are debated; they matter. They matter for Java and they matter for dynamic languages too.
    These so-called debates would only be useful in a context of a projects requirements.

    This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.


    So Java performance is improved because of various factors, but Smalltalk implementations don't?


    Indeed. The reasons why you can better optimise languages with type information than dynamically typed languages are well understood.

    This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?


    Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?


    I don't get what your point is here. Much effort has indeed gone into optimising the Java VM; successfully. Java can approach the speed of C in very many situations. At least with Java, it was realised that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue as it often is with dynamic languages.
    And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java. Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving. And even then it's pretty much meaningless depending on project requirements and what is willing to be given up for at least a perceived power and ease of use of a programming language.
  35. Re: Black Hole's and "innovation"[ Go to top ]

    These so-called debates would only be useful in a context of a projects requirements.
    I'll discuss below....
    And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java.
    But with Java, performance has not been put secondary to safety and garbage collection; at least not these days. This is precisely why I tend to choose Java over other languages that have safety and garbage collection.
    Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.
    Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.
    And even then it's pretty much meaningless depending on project requirements and what is willing to be given up for at least a perceived power and ease of use of a programming language.
    I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and , with those projects, you can hit a requirement that is demanding in terms of performance. At that point, you have several choices; throw more hardware at the problem, code that part of the application in a faster language, or rewite the whole application in a faster language. I have come across situations where the performance of a dynamic language was an order of magnitude less than acceptable, so the hardware option would not have been realistic. Also, mixed language development in these circumstances can be messy, involving extra issues of support, maintenance and portability (or lack of) - this is not just a matter of adding some scripting or testing to a project; we are usually talking about some core function. My view is that it is better to start with a language that is going to give good performance from the start, especially with a language that is undeniably easier to develop with than its mainstream predecessors - C and C++. Java is far from the most elegant language, but I really don't think you are giving up that much in terms of ease of development by using it as against, say, Ruby or Smalltalk, particularly with a good IDE; indeed, Java has features that make it particularly productive to work with as projects grow larger, such as static typing. Well, anyway, you may think my approach is wrong (many do), but that is what it is. I would rather try and stick with a general purpose language that I know will cope with any unforseen extra demands.
  36. Re: Black Hole's and "innovation"[ Go to top ]

    And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java.
    But with Java, performance has not been put secondary to safety and garbage collection; at least not these days. This is precisely why I tend to choose Java over other languages that have safety and garbage collection.
    It's doubtful that you're even doing anything where a fast Smalltalk or Lisp implementation wouldn't give you the necessary performance. I'm sure there's other reasons why you choose Java over other languages with safety or garbage collection.
    Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.
    Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.
    Yes really, you're still handwaving. You're just using the same arguments that people still use today about Java being slow and bloated, except you've turned it on dynamic languages and how Java "approaches" the performance of C "for much code". Here is an interesting post by Avi Bryant (of Seaside fame) about VM performance. And really the handwaving started with:
    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed. My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions. Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
    That's why Paul and I had to call you out on that. That entire post is just handwaving. Moore's law and compiler technology doesn't just work for Java. If these other solutions were too slow then people would abandon them. Ruby has a particularly poor implementation when it comes to performance because it works directly on the AST, but is in no way indicative of other implementations of other languages.
    I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and...
    There's your problem. You make these broad, sweeping remarks based on your experience and somehow think they are representative of others experience, and indicative of some overall trend (and thus your first handwavy post about "10 years from now people will rediscover...". It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today. There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
  37. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Frank,
    It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today.
    Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts. The implementation of a language is a very different thing from the semantics. Clearly seperating these things through indirection is one of the inherent advantages IMO that dynamic languages in general and Smalltalk in particular have over static languages like Java. So:
    There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
    Can be addressed within the language. There are experimental versions of Smalltalk with Traits and Mixins, (I've read a paper one one example by the same Gilad Bracha of Strongtalk fame), which are still Smalltalk. And ofcourse Strongtalk uses Mixins. Self can also be considered a distant dialect of Smalltalk, although this is stretching the dialect idea a bit far. Smalltalk through indirection is a fertile ground for research and investigation, which is why some 30-40 years after its invention (going back to say Smalltalk-70) it is still a crucible for innovation today. I just don't think we will be talking about Java in the same way 20 years from now! Paul.
  38. Re: Black Hole's and "innovation"[ Go to top ]

    Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts.
    Why do people so often bring up this irrelevant fact? Look - a large number of people, like me, accept that early Java was poor and did not use it. We put in through the same scrutiny as any other language, and only switched to it when it met our requirements. "Java was poor when it came out" is a tiresome straw-man argument.
  39. Re: Black Hole's and "innovation"[ Go to top ]

    Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts.


    Why do people so often bring up this irrelevant fact?

    Look - a large number of people, like me, accept that early Java was poor and did not use it. We put in through the same scrutiny as any other language, and only switched to it when it met our requirements.

    "Java was poor when it came out" is a tiresome straw-man argument.
    Hi Steve, The reason why raise this is two fold: A) To some degree through the use of a VM, Java had a reasonable seperation between implementation and language, so even though performance was a problem in 95/96 things could improve through changes to the implementation whilst not impacting the language. B) When backing technology we need to think longer term IMO. Given point A above, the longer term perspective for Java was always better then C++ when it came to a broad class of application programming duties. With the elapse of time Moores law was always on Java's side. As for C++, it was destined to suffer from memory leaks for an eternity. We are faced with the same choice today. The longer term view for dynamic languages IMO are a lot more promising then those for static imperative languages like Java when it comes to high level, high abstraction, componentised, possibly distributed application programming. The fact that if we had taken a longer view perspective back in 1995/6 we would most likel be 20 or so years further down the road isn't lost on people like Frank, Gilad (Sun), Dave(Sun), Amin and myself. Paul.
  40. Re: Black Hole's and "innovation"[ Go to top ]

    We are faced with the same choice today. The longer term view for dynamic languages IMO are a lot more promising then those for static imperative languages like Java when it comes to high level, high abstraction, componentised, possibly distributed application programming.
    I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other. And as was pointed out earlier in this thread, that will just lead to a pedulum swing. In 20 years people will be extolling the lost virtues of static languages over dynamic ones. But I don't think that will happen. At least I really hope it won't. I think we're headed towards some sort of convergence. IMHO, the debate should not be focused on why one type of language is superior to another, but on the strengths and weaknesses of different languages and their origin. I think Java is gradually becoming more dynamic, even if much of it is hacked in via reflection and runtime bytecode manipulation. Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk. Much of the debate in this thread has taken on a very religious tone, and I don't think that is productive. We're supposed to be scientists and engineers, not zealots.
  41. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Erik,
    I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other.
    No this is not whatI'm saying. I was very careful about indentifying the class of application I feel are suited to dynamic languages. I see a number of possibilities. For example static languages like C++ are very good at low level stable APIs like OpenGL. Dynamic languages IMO are better suited to scenarios where the interfaces need to be more malleable. So a "mixed-mode" is one possible outcome. Sorry for saying this but Corquet adopts this "mixed-mode" approach :^) My point as been all along that we should be able to use the right tool for the right job rather then slavishly sticking to one approach as a standard. Paul.
  42. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Erik,

    I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other.


    No this is not whatI'm saying. I was very careful about indentifying the class of application I feel are suited to dynamic languages. I see a number of possibilities. For example static languages like C++ are very good at low level stable APIs like OpenGL. Dynamic languages IMO are better suited to scenarios where the interfaces need to be more malleable. So a "mixed-mode" is one possible outcome. Sorry for saying this but Corquet adopts this "mixed-mode" approach :^)

    My point as been all along that we should be able to use the right tool for the right job rather then slavishly sticking to one approach as a standard.

    Paul.
    My point is I think (hope) that someday people will come up with a class of languages and runtimes that owes their heritage to both static and dynamic languages (and hopefully other more declarative ones like SQL and Prolog). People may still argue about whether it is more a "dynamic" or "static" or "X" type of language, but the argument will be largely academic. I'm going to place my bet on it being 5 years before such languages emerge as usable, 10 before they are mainstream, and 15 before they are "de facto standard." I also think they will still be largely imperative in nature and won't have sound theoretical foundations (because most don't care about sound theoretical foundations). Maybe in 25 years we'll start seeing declarative and theoretically grounded constructs emerging in mainstream languages. All this assumes the evolution of languages is going to accelerate, which I think we are seeing today, but it's too early to tell.
  43. Re: Black Hole's and "innovation"[ Go to top ]

    I think we're headed towards some sort of convergence. IMHO, the debate should not be focused on why one type of language is superior to another, but on the strengths and weaknesses of different languages and their origin.

    I think Java is gradually becoming more dynamic, even if much of it is hacked in via reflection and runtime bytecode manipulation.

    Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk.
    Absolutely. Things are changing, and for the better. Improvements in the range of languages on the JVM, and in the JVM itself, should help to deal with many of the problems discussed here. It really should be more practical to combine languages into a single application on the JVM when you can do things like tracing execution seamlessly from one language to another.... and you can combine different approaches with losing the advantage of a unified, high performance and portable platform. I look forward to that situation; Java is likely to form a far smaller proportion of my code with it happens.
    Much of the debate in this thread has taken on a very religious tone, and I don't think that is productive. We're supposed to be scientists and engineers, not zealots.
    +1
  44. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Erik,
    Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk.
    I agree. This is yet a another possible outcome. Paul.
  45. Re: Black Hole's and "innovation"[ Go to top ]

    It's doubtful that you're even doing anything where a fast Smalltalk or Lisp implementation wouldn't give you the necessary performance. I'm sure there's other reasons why you choose Java over other languages with safety or garbage collection.
    Well, OK. There is also the issue of language familiarity (if I worked in LISP, there would not be that many able to support the software). There is also the issue of portability - there are high-performance Smalltalks, but not cross-platform. I shall broaden it then - portable performance is a better description.

    Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.



    Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.


    Yes really, you're still handwaving. You're just using the same arguments that people still use today about Java being slow and bloated, except you've turned it on dynamic languages and how Java "approaches" the performance of C "for much code". Here is an interesting post by Avi Bryant (of Seaside fame) about VM performance.



    And really the handwaving started with:

    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.

    My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.

    Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.


    That's why Paul and I had to call you out on that. That entire post is just handwaving. Moore's law and compiler technology doesn't just work for Java. If these other solutions were too slow then people would abandon them.
    No, as I have carefully explained in other posts, you can't use Moore's law as an excuse for slow software. Software has to be very special indeed for customers to be willing to throw hardware at it to take up for performance issues, or the convenience of the developer. I have seen such products, but they are few. I have been through this argument, back and forth for a very long time, with Smalltalk advocates and Java advocates; you aren't quoting something I haven't already seen.
    I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and...


    There's your problem. You make these broad, sweeping remarks based on your experience and somehow think they are representative of others experience, and indicative of some overall trend (and thus your first handwavy post about "10 years from now people will rediscover...".
    I am not dumb enough just to base things on just projects I have worked on. I also based this on projects I have seen fail due to precisely these kinds of issues, both personally and otherwise. I was a very strong Smalltalk supporter until the mid 90s. The slow switch to Java was based on considerable research, and considerable attempts to fine-tune and optimise Smalltalk code. The extend to with others were attempting to do this (and even dropping through to C) made me (and many others) realise that things were just not good enough.
    It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today.

    There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
    Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time. The "performance is no longer an issue" is a tired old cliche that has been used by Smalltalk advocates for too long. Perhaps if StrongTalk takes of and performance finally isn't an issue, they can stop using it!
  46. Re: Black Hole's and "innovation"[ Go to top ]

    Well, OK. There is also the issue of language familiarity (if I worked in LISP, there would not be that many able to support the software). There is also the issue of portability - there are high-performance Smalltalks, but not cross-platform.
    VisualWorks?
    I shall broaden it then - portable performance is a better description.
    Actually, IMO, the biggest reason that Java took off was not performance (obviously), or portability in the sense of bytecode portability, but a large number of portable APIs out of the box and a C++-like syntax.
    No, as I have carefully explained in other posts, you can't use Moore's law as an excuse for slow software. Software has to be very special indeed for customers to be willing to throw hardware at it to take up for performance issues, or the convenience of the developer. I have seen such products, but they are few. I have been through this argument, back and forth for a very long time, with Smalltalk advocates and Java advocates; you aren't quoting something I haven't already seen.
    Actually, Moore's law is the reason that Java and Smalltalk and Ruby and Python and all these other languages are actually viable solutions these days.
    I am not dumb enough just to base things on just projects I have worked on. I also based this on projects I have seen fail due to precisely these kinds of issues, both personally and otherwise. I was a very strong Smalltalk supporter until the mid 90s. The slow switch to Java was based on considerable research, and considerable attempts to fine-tune and optimise Smalltalk code. The extend to with others were attempting to do this (and even dropping through to C) made me (and many others) realise that things were just not good enough.
    At what point did you switch from Smalltalk to Java? Java was certainly no speed-demon when it came out. Java would have been one of the last places I would have turned to if I was having problems with the speed of Smalltalk in the mid 90s.
    Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time.
    Self is not Smalltalk and doesn't even have classes. It's a prototype-based OO. So it's motivations for being started weren't to make a faster Smalltalk. Many of the ideas (if not code directly) of the Self VM were actually implemented in the Java hotspot VM.
    The "performance is no longer an issue" is a tired old cliche that has been used by Smalltalk advocates for too long. Perhaps if StrongTalk takes of and performance finally isn't an issue, they can stop using it!
    Hehe, will you be saying that "performance is no longer an issue" next time someone says Java is slow and a resource hog? You do realize that Smalltalk implementations like VisualWorks actually have a JITer don't you? Dolphin actually has a blindingly fast interpreter and I can't tell the difference performance-wise, or visually from a native windows application. That's more than I can say about released Java versions.
  47. Re: Black Hole's and "innovation"[ Go to top ]

    VisualWorks?
    VisualWorks was good (I have used it), but nowhere near C or Java or performance. Also, VisualWorks nearly died before Cincom took it over, then priced and licensed it out of my range.
    Actually, IMO, the biggest reason that Java took off was not performance (obviously), or portability in the sense of bytecode portability, but a large number of portable APIs out of the box and a C++-like syntax.
    I have no interest in why Java took off; my interest is in what it delivers now.
    Actually, Moore's law is the reason that Java and Smalltalk and Ruby and Python and all these other languages are actually viable solutions these days.
    No, it certainly isn't. Proof of this is that dynamic languages have always been viable for certain types of applications. Try telling an experienced Perl or Python programmer that their language was not a viable solution 10 years ago! There have been people saying 'the current speed of processing now means that dynamic languages are viable' for a very long time. Dynamic languages have been used as viable solutions to various problems for a very long time, but.... My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages. My requirements are for a general purpose language.
    At what point did you switch from Smalltalk to Java? Java was certainly no speed-demon when it came out. Java would have been one of the last places I would have turned to if I was having problems with the speed of Smalltalk in the mid 90s.
    Indeed, which is why it took me along time to switch. Although I still support Smalltalk applications, I moved to Java as main development language when performance got reasonable - 1.3.x. (I was particularly impressed by the IBM JVM at that time).
    Self is not Smalltalk and doesn't even have classes. It's a prototype-based OO. So it's motivations for being started weren't to make a faster Smalltalk. Many of the ideas (if not code directly) of the Self VM were actually implemented in the Java hotspot VM.
    I know it is not Smalltalk - we have been talking about dynamic languages in general. I know about the ideas being transferred to the Java VM. This is of no relevance, other than to describe how Java gained its speed advantage.
    Hehe, will you be saying that "performance is no longer an issue" next time someone says Java is slow and a resource hog?
    I never said 'performance is no longer an issue' with Java. It is always an issue, even with C and C++ code. The point is that it is LESS of an issue with Java, at least for what I want to do. I switched to Java because for my applications it was far less slow and far less of a resource hog than Smalltalk - up to an order of magnitude less in some cases.
    You do realize that Smalltalk implementations like VisualWorks actually have a JITer don't you?
    Of course I do - they have been implementing JITters for a LONG time. This has helped speed considerably, but still nowhere near C performance. JITting can only take you so far in a language like Smalltalk - typically I found a top-quality Smalltalk implementation could get between 20-30% of C speed for my use cases. That certainly made it competitive with Java for me for a while, as early Java only had that sort of performance too.
    Dolphin actually has a blindingly fast interpreter and I can't tell the difference performance-wise, or visually from a native windows application. That's more than I can say about released Java versions.
    I have used Dolphin for projects in the past. It is a nice system. The interpreter is not especially fast; what is fast is the GUI because it is native Windows. It also starts up fast because of the image system. But this does not help at all with, say, numeric work, or intensive file parsing, or image manipulation etc. I rarely write native GUI applications. Dolphin is also, unfortunately, only for Windows.
  48. Re: Black Hole's and "innovation"[ Go to top ]

    VisualWorks was good (I have used it), but nowhere near C or Java or performance. Also, VisualWorks nearly died before Cincom took it over, then priced and licensed it out of my range.
    Sounds like you want OCaml and not Java if you want something closer to C speed.
    My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages. My requirements are for a general purpose language.
    That's just completely untrue. Has Java always been fast? Why are they always working on ways to accelerate Java. What about Lisp? Even pre-1.0 SBCL is about a dead heat on the debian language shootout. And that's not even comparing to the high-performance commercial implementations like Allegro and Lispworks.
    I know it is not Smalltalk - we have been talking about dynamic languages in general. I know about the ideas being transferred to the Java VM. This is of no relevance, other than to describe how Java gained its speed advantage.
    and...
    Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time.
    Every language implementor would want a fast runtime. Java is no different. The goals of the Self group were to make a fast VM for the Self language. The goals of the StrongTalk team were to make a fast VM for Smalltalk. The goals of the Java VM team are to make a fast VM for Java. Strongtalk was essentialy shelved after Java started enjoying success. If Java had been shelved in favor of Strontalk, it would have been left with a poor performing VM.
    I never said 'performance is no longer an issue' with Java. It is always an issue, even with C and C++ code. The point is that it is LESS of an issue with Java, at least for what I want to do. I switched to Java because for my applications it was far less slow and far less of a resource hog than Smalltalk - up to an order of magnitude less in some cases.
    Fine, but you don't get to decide that other dynamic language aren't fast enough to be general purpose, when clearly languages like Lisp and Smalltalk are:
    My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages.
    Of course I do - they have been implementing JITters for a LONG time. This has helped speed considerably, but still nowhere near C performance. JITting can only take you so far in a language like Smalltalk - typically I found a top-quality Smalltalk implementation could get between 20-30% of C speed for my use cases. That certainly made it competitive with Java for me for a while, as early Java only had that sort of performance too.
    I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
  49. Re: Black Hole's and "innovation"[ Go to top ]

    Hi,
    I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank? Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone! Back on topic. One of the areas where IMO languages like Java and C# have struggled is programming "in the large". By this I mean component models. One success story from the nineties was NextStep, the component framework and operating system from Steve Jobs. Well my pair programming partner has bought himself a new laptop. He got himself a Mac Book, and we spent friday getting the project working on it. The Mac user interface is very impressive so I decided to google and find out what language it was written in. The OSX user interface is written in a framework called Cocoa whis as far as I can tell is the modern re-incarnation of NextStep, which is written in the dynamic language Objective-C. Apple also use another API called Carbon for low level system work whih I haven't looked at this, but my guess is that it is Unix (considering the OSX is build on the BSD "Darwin" Kernel ), and Carbon is in C/C++. Objective C can inline C/C++ code. They also mention something called Objective C++ which I haven't heard of before. Here is the Mac OSX developers page: http://developer.apple.com/macosx/ So there we have it the mixed-mode approach I mentioned earlier in everyday use on the Mac. I'm sure there is something to be learnt from this by the Java community. Incidently Cocoa has Java bindings so they may have solved the foreign language binding issue raised by Erik many posts ago :^). Paul.
  50. Re: Black Hole's and "innovation"[ Go to top ]

    Hi, Incidently for a primer on Objective-C, the wikipedia entry is very good: http://en.wikipedia.org/wiki/Objective-C Fittingly, the entry pays due homage to Smalltalk :^). Paul.
  51. Re: Black Hole's and "innovation"[ Go to top ]

    Paul, not sure if you've seen this video of Gilad Bracha giving a presentation at the Lang.NET symposium. I just started watching it, but I had to get a chuckle when he says "Any customer can have any language he/she wants so long as it's Java"
  52. Re: Black Hole's and "innovation"[ Go to top ]

    Paul, not sure if you've seen this video of Gilad Bracha giving a presentation at the Lang.NET symposium.

    I just started watching it, but I had to get a chuckle when he says "Any customer can have any language he/she wants so long as it's Java"
    Hi Frank, Thanks, for the video. Half way through. It confirms what I've read in several places, both the JVM and CLR aren't suited to dynamic languages. Take a look at the Strongtalk discusssion group I posted a link to earlier. http://tech.groups.yahoo.com/group/strongtalk/message/100 In response to my question, Dave Griswold makes it clear that they are considering utlising the Strongtalk VM for "other" languages. I think you can clearly substitue Ruby or Python for other. This could even be with Sun's implicit blessing. We are going through interesting times. Ruby on Strongtalk would really perform, and the Ruby syntax makes it easily accesible to Java programmers. I'd like to discuss more about Dylan. Perhaps offline, as speaking my mind here tends to upset people :^). Paul.
  53. Re: Black Hole's and "innovation"[ Go to top ]

    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
    Yeah, it seems to be any language as long as it's Java;)
    Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
    A somewhat weird trend I've seen is that some people are more interested in thinking that they get to limit the choices for others.
    So there we have it the mixed-mode approach I mentioned earlier in everyday use on the Mac. I'm sure there is something to be learnt from this by the Java community. Incidently Cocoa has Java bindings so they may have solved the foreign language binding issue raised by Erik many posts ago :^).
    I think Apple has stopped working on the Java-Cococa bindings. I've never used Objective-C, but I probably would have bought a Mac years ago if Apple had continued an interest in Dylan.
  54. Re: Black Hole's and "innovation" -Dylan[ Go to top ]

    Hi Frank, Looks like everyone has gone, so I can speak freely. Looked at Dylan, looks very much like CLOS (well at least in it's initial incarnation). Not sure what the Agiol-like syntax adds though, especially with generic funtions. Also shunning S-expressions means that they can't easily doLiap style self modifiying code and Lisp Macros. If they were going to go to a C++ like syntax to appeal to the mainstream, I can't see why they didn't go all the way (curly brackets and all). What is the diffeence between Dylan and CLOS (actually Common Lisp)? Other then the syntax. And does the Agol syntax reduce what you can do with Dylan versus Common Lisp? What does the type system add? Here is my e-mail: beckfordpatbtinternetdotcom, either e-mail me or I'll lok out for a response here. Reading the history it looks like the "Java phenomenom" was partly responsible for killing of Dylan too. Apealing to the lowest common denominator seems to be a winning strategy! Paul.
  55. Reading the history it looks like the "Java phenomenom" was partly responsible for killing of Dylan too. Apealing to the lowest common denominator seems to be a winning strategy!
    I think other companies incompetence is the cause of many technologies not to reach the masses. And the winning strategy is to provide solutions based on reality that solve real customers problems, instead of based on an "academically correct" idealized view of the world. You may not like Java for a variety of reasons, but it does solve most of developers problems and still provide a rich (huge class library, frameworks, opensource communitites, etc) and modern (IDEs and tools to assist development) environment for developing applications. Of course it's not perfect, but I don't see anything coming near it as a viable platform, maybe only .Net if you don't need to be crossplatform.
  56. Reading the history it looks like the "Java phenomenom" was partly responsible for killing of Dylan too. Apealing to the lowest common denominator seems to be a winning strategy!


    I think other companies incompetence is the cause of many technologies not to reach the masses. And the winning strategy is to provide solutions based on reality that solve real customers problems, instead of based on an "academically correct" idealized view of the world.

    You may not like Java for a variety of reasons, but it does solve most of developers problems and still provide a rich (huge class library, frameworks, opensource communitites, etc) and modern (IDEs and tools to assist development) environment for developing applications.

    Of course it's not perfect, but I don't see anything coming near it as a viable platform, maybe only .Net if you don't need to be crossplatform.
    Hi Thiago, It is not that I don't like Java. My comment was mostly 'tongue-in-cheek'. The problem isn't Java, IMO it goes much deeper. As a developer community, as I've said before we do tend to stick with the 'herd'. The fact that Dylan decided it was best to move away from S-expressions was a decision made as a consequence of this reality. To be fair to Sun, the idea of keeping Java as simple as possible, and as familiar (C-like) as possible was a sensible pragmatic move. If you remember the political climate at the time, Microsoft was looking to take over the Server, and the Java platform was away for Sun (IBM, Oracle and others) to maintain their Server dominance. The problem quite frankly is us. For so called profeesionals we seem unable to control our own destiny. Did you evaluate Dylan back in 1995? I didn't. How many people took a close look at Smalltalk? Like I said, it took me two years to convince people to take a look at Java. Our industry is extremely conservative, and as a consequence we often end up with "dumbded-down" lowest common denominator techology, look at the success of Visual Basic. If you look back through this discussion and see the links to presentations and blogs from people at Sun, you will see that to some degree many at Sun (even Gosling) are sympathetic to this view. Paul
  57. Re: Black Hole's and "innovation" -Dylan[ Go to top ]

    Paul - personally, I don't think any decent programmer who can code to save their life (or better), is going to reject a new programming language/platform that would make their life easier and increase their productivity n-fold (whatever n may be, is debatable I suppose, and can only be determined a posteriori). It really comes down to one thing and one thing only - how much time are you willing and/or allowed by your individual circumstances to sacrifice in order to become proficient at Ruby, Python, Lisp/Dylan and the like and will adding this opportunity cost pay off for 1) you, 2) the organization you work for? Academically speaking, we should all be programming Lisp - but we aren't. Because of X Y Z reason, that "language" never took off. And if you read Paul Graham(.com) for about 15 minutes, he'll make a believer out of you when it comes to Lisp - for a good reason too! So why aren't we all programming Lisp today? You could blame it on past performance issues (slower hardware at the time perhaps?), or "language" awkwardness (Lisp _is_ an AST, rather than a language in the sense of C, which needs LALR parsing to get to an AST), etc. Or you could blame it on the fact that since UNIX and its children/clones were developed in C, then anything that ever grew out of the UNIX platform and became popular - resembled C at the core, one way or another, so we should perhaps blame Dennis Ritchie ? Many many reasons, right? You could come up with some more, I'm sure. These purist/elitist debates about languages are extremely moot. Other than getting off on high intelectualism, it truly serves no other purpose. Once all is said and done on this thread, both you and I, along with everyone else will go back to programming our VBs, C#'s, C++'s, Java's, Perls or what have you, unless you are a pathologically confused anti-establishment college professor who has the time to gloat with his knowledge of higher level languages that will once and for all solve all our programming language ailments and has the luxury of his little classroom and the taxpayer's dollars at work to scoff at the "poor, little confused souls who couldn't see the light" in the way he did.... (just a theory, ok? I'm not saying college professors are like this :). I started with C, then went to assembly (x86), then C again, then C++, then Java, then Perl, then Java again, then C#, now Java again, and as of late Python and on my own time, Ruby (and I love the language as much as I did Java when I discovered it), in a matter of 10 years - and I'm not going to apologize for any of it. Can I learn another language? Sure thing - just bring along the entire Java/J2EE API to me , so I don't have to recode queues/stacks/linked lists all over. And I'll be more than happy to pick up on a new language even though I may suck at it for the next 6 months before I feel really comfortable using it at a level I feel using Java today.... The _industry_ is conservative for a reason - it can not afford to screw around. But if you pull it off the right way - the way that Sun did with Java/J2EE and the JVM - well you might get yourself a true following. If I can make a bold predicition now, Ruby will become as integrated into the JVM as Java is today within the next 2 years. Also, without a commercial backing, most of these "better" languages, will amount to nothing more than a fad, or a fringe benefit, not because the language sucks but because it would take too long to reproduce a useful set of APIs, middleware, etc. Really, this thread should've been about 5 posts long - congratulating the JRuby developers on their new undertaking, and let's hope that JSR 292 will become some sort of a 'panacea' for dynamic languages running on the JVM.
  58. Re: Black Hole's and "innovation" -Dylan[ Go to top ]

    Paul - personally, I don't think any decent programmer who can code to save their life (or better), is going to reject a new programming language/platform that would make their life easier and increase their productivity n-fold (whatever n may be, is debatable I suppose, and can only be determined a posteriori).

    It really comes down to one thing and one thing only - how much time are you willing and/or allowed by your individual circumstances to sacrifice in order to become proficient at Ruby, Python, Lisp/Dylan and the like and will adding this opportunity cost pay off for 1) you, 2) the organization you work for?

    Academically speaking, we should all be programming Lisp - but we aren't. Because of X Y Z reason, that "language" never took off. And if you read Paul Graham(.com) for about 15 minutes, he'll make a believer out of you when it comes to Lisp - for a good reason too! So why aren't we all programming Lisp today?

    You could blame it on past performance issues (slower hardware at the time perhaps?), or "language" awkwardness (Lisp _is_ an AST, rather than a language in the sense of C, which needs LALR parsing to get to an AST), etc. Or you could blame it on the fact that since UNIX and its children/clones were developed in C, then anything that ever grew out of the UNIX platform and became popular - resembled C at the core, one way or another, so we should perhaps blame Dennis Ritchie ? Many many reasons, right? You could come up with some more, I'm sure.

    These purist/elitist debates about languages are extremely moot. Other than getting off on high intelectualism, it truly serves no other purpose. Once all is said and done on this thread, both you and I, along with everyone else will go back to programming our VBs, C#'s, C++'s, Java's, Perls or what have you, unless you are a pathologically confused anti-establishment college professor who has the time to gloat with his knowledge of higher level languages that will once and for all solve all our programming language ailments and has the luxury of his little classroom and the taxpayer's dollars at work to scoff at the "poor, little confused souls who couldn't see the light" in the way he did.... (just a theory, ok? I'm not saying college professors are like this :).

    I started with C, then went to assembly (x86), then C again, then C++, then Java, then Perl, then Java again, then C#, now Java again, and as of late Python and on my own time, Ruby (and I love the language as much as I did Java when I discovered it), in a matter of 10 years - and I'm not going to apologize for any of it. Can I learn another language? Sure thing - just bring along the entire Java/J2EE API to me , so I don't have to recode queues/stacks/linked lists all over. And I'll be more than happy to pick up on a new language even though I may suck at it for the next 6 months before I feel really comfortable using it at a level I feel using Java today....

    The _industry_ is conservative for a reason - it can not afford to screw around. But if you pull it off the right way - the way that Sun did with Java/J2EE and the JVM - well you might get yourself a true following. If I can make a bold predicition now, Ruby will become as integrated into the JVM as Java is today within the next 2 years.

    Also, without a commercial backing, most of these "better" languages, will amount to nothing more than a fad, or a fringe benefit, not because the language sucks but because it would take too long to reproduce a useful set of APIs, middleware, etc.

    Really, this thread should've been about 5 posts long - congratulating the JRuby developers on their new undertaking, and let's hope that JSR 292 will become some sort of a 'panacea' for dynamic languages running on the JVM.
    Hi Martin, I mostly agree with you. I'm extremely pragmatic - it is the thought of having to deal with yet more configuration XML, whether Spring or EJB3.0, byte-code manipulation, Interceptors, AOP etc, that leads me to want to use a true dynamic language. The other big reason is that we were promised components 10 years ago, and where are they? What ever your opinion choice has got to be a good thing. As for JSR292, watch the presentation by Gilad. As well as being funny it is very imformative. As he rightly points out computer science is not destined to end with Java. Paul.
  59. Re: Black Hole's and "innovation" -Dylan[ Go to top ]

    Hi Paul Yes, Dylan was an attempt to give people a Lisp with an Algol-like syntax. Dylan does have macros, but without the s-expressions not as powerful as Lisps (who's macros are?). And of course, it has its version (limited?) of CLOS.
    If they were going to go to a C++ like syntax to appeal to the mainstream, I can't see why they didn't go all the way (curly brackets and all).
    I don't think the Java/C/C++ people really care about curly braces. I think they just dislike prefix notation and s-expressions.
    What is the diffeence between Dylan and CLOS (actually Common Lisp)? Other then the syntax. And does the Agol syntax reduce what you can do with Dylan versus Common Lisp? What does the type system add?
    Most of the implementation code of the Function Objects system seemed to emphasize the optional type declarations, which made an already, somewhat verbose syntax, more verbose.
    Reading the history it looks like the "Java phenomenom" was partly responsible for killing of Dylan too. Apealing to the lowest common denominator seems to be a winning strategy!
    Not really for Apple. Once Jobs was brought in and NeXTstep was decided as the platform that OSX would be based on, the writing was on the wall regarding Dylan. Objective-C does have the tremendous advantage of being able to use straight C source code. I'm sure it had an impact on Functional Objects though.
  60. Reading the history it looks like the "Java phenomenom" was partly responsible for killing of Dylan too. Apealing to the lowest common denominator seems to be a winning strategy!

    Paul.
    Sad but true. I for one (most likely unlike you and Frank here) am deeply in love with C++ and believe it's the most powerful and engineered programming language, and I was saddend to see Java rip it off to such an extent and make such a mess of it years later with generics for instance. It feels like listening to a turkish disco version of Pink Floyd's "The Wall".
  61. Re: Black Hole's and "innovation"[ Go to top ]

    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?

    Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
    I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
  62. Re: Black Hole's and "innovation"[ Go to top ]

    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?

    Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!


    I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
    Previous post meant to be in bold - should have previewed.
  63. Re: Black Hole's and "innovation"[ Go to top ]

    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?

    Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!


    I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.


    Previous post meant to be in bold - should have previewed.
    Sorry? What is unacceptable about it? It was meant to be light hearted, with the sole intent to make the point that we should all have the ability to exercise choice. The Gilad video makes the same point. Steve, try taking yourself less seriously. I apologise, but no malice was intended believe me. We are only talking about software and your software choices are not you as an individual. I am challenging your ideas not you as a person. Todays is a Saturday, I'm at my machine only because I've got work to do. Get out and about and do something else. We can discuss this again on Monday. It may all look very different by then! Wishing you a fun weekend! Paul.
  64. Re: Black Hole's and "innovation"[ Go to top ]

    Sorry? What is unacceptable about it? It was meant to be light hearted, with the sole intent to make the point that we should all have the ability to exercise choice. The Gilad video makes the same point.

    Steve, try taking yourself less seriously. I apologise, but no malice was intended believe me. We are only talking about software and your software choices are not you as an individual.
    If there is going to be a discussion, it should be about facts and issues. There has been too much assumption in this thread about what other people believe and about what other people's experiences are (such as a comment along the lines of 'none of us are experienced enough in dynamic languages to discuss this'). What I find unacceptable is people putting words into other people's mouths, or making assumptions about what other people think. For example, I have never said or implied that my critera for a general purpose language is tailored so that only Java meets them, as if you read my contributions to this and other threads I have made it clear that I have used and evaluated many languages as 'general purpose' over the years; C, C++, Smalltalk are just a few. For many years I developed mainly in Delphi, for example. If you want to know what my views are, why not just ask me? - discussing what my views seem like to someone else is inappropriate when I am participating in the discussion. I agree with Eric - this debate is stifled by political and almost religious attitudes. Perhaps it is just me, but with a scientific background, I am used to a calmer, less personalised, and more technical debate. Perhaps I am too naive :) But anyway, for pleasant personal reasons (which include a long holiday), I shall be distracted from further discussion for a time... enjoy the debate.
  65. Re: Black Hole's and "innovation"[ Go to top ]

    <
    Sorry? What is unacceptable about it? It was meant to be light hearted, with the sole intent to make the point that we should all have the ability to exercise choice. The Gilad video makes the same point.

    Steve, try taking yourself less seriously. I apologise, but no malice was intended believe me. We are only talking about software and your software choices are not you as an individual.


    If there is going to be a discussion, it should be about facts and issues. There has been too much assumption in this thread about what other people believe and about what other people's experiences are (such as a comment along the lines of 'none of us are experienced enough in dynamic languages to discuss this').

    What I find unacceptable is people putting words into other people's mouths, or making assumptions about what other people think. For example, I have never said or implied that my critera for a general purpose language is tailored so that only Java meets them, as if you read my contributions to this and other threads I have made it clear that I have used and evaluated many languages as 'general purpose' over the years; C, C++, Smalltalk are just a few. For many years I developed mainly in Delphi, for example.

    If you want to know what my views are, why not just ask me? - discussing what my views seem like to someone else is inappropriate when I am participating in the discussion.

    I agree with Eric - this debate is stifled by political and almost religious attitudes. Perhaps it is just me, but with a scientific background, I am used to a calmer, less personalised, and more technical debate.

    Perhaps I am too naive :)

    But anyway, for pleasant personal reasons (which include a long holiday), I shall be distracted from further discussion for a time... enjoy the debate.
    Hi Steve, The topic is "Sun Hires the JRuby-guys", not "Why Steve thinks everyone should use Java (mostly)". All I did was try and bring the discussion back on point. I am genuinely interested in "other" languages on the JVM, hence the desire to move away from your justifications of why you think Java is the best "general-purpose" choice for everyone. Getting back on point revealed something very useful. I would suggest that you watch the video supplied by Frank: http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/GiladBracha-final.wmv It is pretty conclusive, especially comming from the lead of the JSR292 committe which you are fond of refering to and is responsible for making cross language support on the JVM possible. Enjoy your Hols. Paul.
  66. Re: Black Hole's and "innovation"[ Go to top ]

    The topic is "Sun Hires the JRuby-guys", not "Why Steve thinks everyone should use Java (mostly)".

    All I did was try and bring the discussion back on point.
    This is a very distorted reading of things. It has been on topic all along; we have been discussing the matter of whether or not dynamic languages have issues that make them, in the views of many, not suitable for 'general purpose'. Why I use Java as my general-purpose language does certainly not apply to others, and I have never said it does. Others don't have my requirements (such as easy portability), so they use other languages, like C# and C++. However, any attempt to imply that dynamic languages have flaws, no matter what evidence is presented (such as the opinions of those who worked on Self and StrongTalk to try and overcome such flaws) seems to be re-directed into trying to imply that Java has similar flaws (which is largely irrelevant), and then trying to question me in detail about why I chose Java!
    I am genuinely interested in "other" languages on the JVM, hence the desire to move away from your justifications of why you think Java is the best "general-purpose" choice for everyone.
    Again, a very distorted reading of things, if you don't mind my saying so. All I have been doing, if you re-read, is to discuss why I believe that dynamic languages in general are not general purpose. To turn that round into a claim that I am saying that Java is the best general purpose choice for everyone is wrong. There aren't just these alternatives. Others may have somewhat different requirements, but what I am saying is that really good performance is a common factor in what many people will have in their definition of a 'general' language. I base this not just on personal experience, but on coming up to 30 years of following the industry and language development. I have said very clearly on this thread that I am also looking forward to mixed language use on the JVM. My primary concern with mixed language use is poor integration between the languages. I know this is available on .NET, but my 'general purpose' development requirement includes portability. I welcome this on the JVM, as it will mean, in my view, that, for me, increased dynamic language use is practical as I can seamlessly integrate Java when I need extra facilities or performance. My justifications as to why I think that Java is a general purpose language were primarily in response to a repeated questions. If you and others did not want to read my justifications for using Java, you and/or others need not have asked me to make them, again, and again, and again and again... quite why anyone is interested in the details of exactly what my personal uses of Java are, and exactly when and why I migrated to Java, and what my reasons where, and what my exact knowledge of a range of Smalltalk dialects are, I don't know, but I was simply responding to questions :)
    Enjoy your Hols.
    Thank you :)
  67. Re: Black Hole's and "innovation"[ Go to top ]

    Why I use Java as my general-purpose language does certainly not apply to others, and I have never said it does. Others don't have my requirements (such as easy portability), so they use other languages, like C# and C++.
    No, it wasn't just why you don't find dynamic languages acceptable as a general purpose language.
    My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages. My requirements are for a general purpose language.
    and then:
    All I have been doing, if you re-read, is to discuss why I believe that dynamic languages in general are not general purpose.
    You should have added for my purposes.
    However, any attempt to imply that dynamic languages have flaws, no matter what evidence is presented (such as the opinions of those who worked on Self and StrongTalk to try and overcome such flaws) seems to be re-directed into trying to imply that Java has similar flaws (which is largely irrelevant), and then trying to question me in detail about why I chose Java!
    Who is saying that dynamic languages or any other language doesn't have flaws? You're the one setting up the red herring.
    If you and others did not want to read my justifications for using Java, you and/or others need not have asked me to make them, again, and again, and again and again... quite why anyone is interested in the details of exactly what my personal uses of Java are, and exactly when and why I migrated to Java, and what my reasons where, and what my exact knowledge of a range of Smalltalk dialects are, I don't know, but I was simply responding to questions :)
    Oh no, all of this started with this statment:
    That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed. My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions. Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java. There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
    You start the handwaving, and people are calling you out on it. Stop trying to act so innocent.
  68. Re: Black Hole's and "innovation"[ Go to top ]

    You should have added for my purposes
    No, I shouldn't. Because, as I repeatedly provided evidence for, this is a widespread opinion. Let me quote yet again (and for the last time) from Dave Griswold, one of those involved in the development of StrongTalk. I could pick other quotes, but this is so accurate: "On the East Coast, I (Dave Griswold) was frustrated with the fact that there were still a lot of obstacles to using Smalltalk in most kinds of production applications. ParcPlace and Digitalk had made a lot of progress, especially with Deutsch/Schiffman dynamic translation technology, which sped up Smalltalk by a factor of 1.6 or so at the time. But it was still way too slow for any kind of compute intensive application (which I was doing), and I felt there were several other obstacles to widespread use as well. One of the biggest among these in my mind was the lack of any kind of type system, which although it makes the language extremely flexible, also means that organizing and understanding large-scale software systems is a lot harder. Another was poor support for native user interfaces, in the interest of portability. Although this was a nice idea for people who were ideologically dedicated to portability, in practice at the time (and to a large extent even now) people needed to write UIs that weren't out of place on Windows machines (emulated widgets just don't cut it)." The issues raised here apply, obviously, to more than just Smalltalk. I am sorry, but you can't keep dismissing these issues as if they are just my opinion. That is a not a satisfactory way to debate when you have been presented with evidence to the contrary. I really must stop now. I leave you to research this matter further if you wish... you will find plenty of evidence that others share my view. Perhaps, for others, you might wish to explain what you consider a general purpose language to be, and give your criteria? I believe that would be a more constructive way for this thread to proceed, if it does...
  69. Re: Black Hole's and "innovation"[ Go to top ]

    No, I shouldn't. Because, as I repeatedly provided evidence for, this is a widespread opinion. Let me quote yet again (and for the last time) from Dave Griswold, one of those involved in the development of StrongTalk. I could pick other quotes, but this is so accurate:
    And Java was a slow piece of shit in 1996. What is your point again? Hah, and by the quote you just gave, Java still doesn't cut it:
    Another was poor support for native user interfaces, in the interest of portability. Although this was a nice idea for people who were ideologically dedicated to portability, in practice at the time (and to a large extent even now) people needed to write UIs that weren't out of place on Windows machines (emulated widgets just don't cut it)."
    Perhaps, for others, you might wish to explain what you consider a general purpose language to be, and give your criteria? I believe that would be a more constructive way for this thread to proceed, if it does...
    And perhaps for yourself, you will one day realize that you don't get decide what is a general purpose language. Please, go on the Python, Ruby, Lisp, and Smalltalk newsgroups and explain to them why they aren't general purpose languages. That should be fun.
  70. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,
    Perhaps, for others, you might wish to explain what you consider a general purpose language to be, and give your criteria? I believe that would be a more constructive way for this thread to proceed, if it does...
    Well I guess that is obvious. General purposes, is a language for the things I generally do. So if I generally produce I/O bound CRUD Web Apps then Ruby and it's slow interpreter serves my general purpose. This is why this line of discussion was just plain stupid in the first place. It all depends, and will vary from one development organisation to the next. As for this thread continuing, well you've killed it for me. There are so many questions we could of discussed, when it comes to making developer choice on a mainstream platform a reality, but instead... See you next time. Paul.
  71. Re: Black Hole's and "innovation"[ Go to top ]

    No, I shouldn't. Because, as I repeatedly provided evidence for...
    This thread should be put in the frontapage as an example of how "discussions" get religious. Some people are just not willing to accept that Java is actually good for something. I have read it and I think I get what Steve means, there were some problems in Smalltalk implementations of the past and people today, in the "dynamic hype", choose to ignore it as if it never happened. Other funny aspect is that in this thread the argument "Java was shit in 1996" come all the time, what does it mean? A lot of other people and I only started using it in 2000 and something because it had reached a good level of maturity. Not all Java developers are "early adopters", and yes, Java sucked back then, and if it still sucked like that it wouldn't be the success it is.
  72. Re: Black Hole's and "innovation"[ Go to top ]

    Other funny aspect is that in this thread the argument "Java was shit in 1996" come all the time, what does it mean? A lot of other people and I only started using it in 2000 and something because it had reached a good level of maturity.
    Java was a stupid, little bytecode interpreted language for applets in 1996. But the actual context of that remark was that Steve Zara brought up some quotes from 10-15 years ago about the state of Smalltalk - when Java was either not even around as a released platform or just getting out there.
  73. Re: Black Hole's and "innovation"[ Go to top ]

    Other funny aspect is that in this thread the argument "Java was shit in 1996" come all the time, what does it mean? A lot of other people and I only started using it in 2000 and something because it had reached a good level of maturity.


    Java was a stupid, little bytecode interpreted language for applets in 1996. But the actual context of that remark was that Steve Zara brought up some quotes from 10-15 years ago about the state of Smalltalk - when Java was either not even around as a released platform or just getting out there.
    Back from a holiday.... One last belated attempt to make some sort of sense here.... Java being supposedly a stupid language in 1996 does not automatically remove the issues with other languages. This is one of the classical logical fallacies that turn up in debates. It is known as "Ignoratio elenchi" - putting forward a proposition that may well be valid ("Java was bad") and assuming that somehow it proves or supports a different proposition ("Smalltalk and other dynamic languages were generally good").
  74. Re: Black Hole's and "innovation"[ Go to top ]

    Other funny aspect is that in this thread the argument "Java was shit in 1996" come all the time, what does it mean? A lot of other people and I only started using it in 2000 and something because it had reached a good level of maturity.


    Java was a stupid, little bytecode interpreted language for applets in 1996. But the actual context of that remark was that Steve Zara brought up some quotes from 10-15 years ago about the state of Smalltalk - when Java was either not even around as a released platform or just getting out there.


    Back from a holiday....

    One last belated attempt to make some sort of sense here....
    Java being supposedly a stupid language in 1996 does not automatically remove the issues with other languages.

    This is one of the classical logical fallacies that turn up in debates. It is known as "Ignoratio elenchi" - putting forward a proposition that may well be valid ("Java was bad") and assuming that somehow it proves or supports a different proposition ("Smalltalk and other dynamic languages were generally good").
    Hi Steve, I can't see why you find it so difficult to "get it". Franks point isn't that because Java was bad that others are good, No. What he is saying is that what may superfically look bad could hold the long term potential to be very good. Java has been successful, but IMO it's success peaked with the realisation that the App Server/EJB/XML model is over complex and fundamentally flawed. People are looking for simpler more light weight solutions and this is leading to the use of DSLs (e.g Hibernate) which is ultimately leading to dynamic languages (Rails). It is not lost on many, that Java could have borrowed even more from dynamic languages, back in 1996 and we could have avoided having to re-invent ourselves (new language, new libraries, new tools, new IDEs, new APIs, etc) just 10 years later. XML and byte-code manipulation is a dead-end IMO. And for applications that can avoid it, many believe that there are more productive alternatives:
    Perhaps, for others, you might wish to explain what you consider a general purpose language to be, and give your criteria? I believe that would be a more constructive way for this thread to proceed, if it does...
    Well I guess that is obvious. General purposes, is a language for the things I generally do. So if I generally produce I/O bound CRUD Web Apps then Ruby and it's slow interpreter serves my general purpose.
    Paul.
  75. Re: Black Hole's and "innovation"[ Go to top ]

    I can't see why you find it so difficult to "get it". Franks point isn't that because Java was bad that others are good, No. What he is saying is that what may superfically look bad could hold the long term potential to be very good.
    But that isn't the point. The point Java has improved beyond recognition since those days. Other languages have generally lagged behind in terms of tools and performance. The change in quality of Java in that period makes me even less confident (for now) about transitioning much of my work to other languages (but note the 'for now'!) This is one of the reasons why I am so puzzled about the 'Java was crap' type of statement as a justification for use of other languages - it only serves to highlight how little those languages have evolved. Also, the 'Java was crap' proposition helps to illustrate that I am, in contrary to what many here seem to think, pragmatic and open minded. Java was not my preferred language years ago because it was crap! When some other language meets my criteria for my main development language, I would be happy to use it in place of Java. I have been constantly reviewing and benchmarking alternatives to Java, but so far, I have not found any language that matches the feature set for what I personally require: 1. Cross platform. 2. Multi-vendor. 3. Inexpensive or free. 4. Good IDE+tools+debugging. 5. OOP. 6. Very good performance. 7. Reasonably widely used (so other developers can take over what I am doing) To reiterate; these are not criteria to determine the only language I use - they define the language I would try and do most development in. For now, Java fits those criteria. My gut feeling is that very soon, other languages on the JVM will do so - I am keeping a close eye on Groovy and JRuby.
    Java has been successful, but IMO it's success peaked with the realisation that the App Server/EJB/XML model is over complex and fundamentally flawed. People are looking for simpler more light weight solutions and this is leading to the use of DSLs (e.g Hibernate) which is ultimately leading to dynamic languages (Rails).

    It is not lost on many, that Java could have borrowed even more from dynamic languages, back in 1996 and we could have avoided having to re-invent ourselves (new language, new libraries, new tools, new IDEs, new APIs, etc) just 10 years later.

    XML and byte-code manipulation is a dead-end IMO. And for applications that can avoid it, many believe that there are more productive alternatives:
    Byte code manipulation is neither here nor there - it has no relevance to the discussion. What matters is language and library features. I don't see why anyone should care about how these are implemented. Also, Hibernate is not a DSL. Also, there is simply no evidence that Java use has peaked yet - there is still a phenomenal volume of C and C++ development that can transition to Java. Anyway, you may be interested to know that byte code manipulation is used in other languages to add more power and flexibility - there is a Squeak package called ByteSurgeon, written by Marcus Denker, a major contributor to the Squeak documentation. So, some Squeak developers would not agree with you that byte code manipulation is a dead end! They consider it an exciting and productive way to extend functionality. The only people needing to re-invent things are those who are jumping on the 'Java is past it' bandwagon, and who are migrating to new languages, where the tools and APIs are usually of far less quality and maturity. XML is still, in my view, one of the most underrated technologies in IT. It has barely begun to be used for the purposes for which it was devised - to allow extensible data formats. You don't have to look far to see XML being misused - one example that particularly irritates me is the NetBeans project files, where much of the information is in XML, but not backwardly compatible, where XML would have easily allowed such compatibility. It is easy to jump on an 'XML is bad' bandwagon based on some common poor uses of XML (such as EJB configuration), but that does not do justice to the richness of XML. Let's just agree to differ? :)
  76. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, You still don't get it:
    Perhaps, for others, you might wish to explain what you consider a general purpose language to be, and give your criteria? I believe that would be a more constructive way for this thread to proceed, if it does...
    Well I guess that is obvious. General purposes, is a language for the things I generally do. So if I generally produce I/O bound CRUD Web Apps then Ruby and it's slow interpreter serves my general purpose.
    And of course the fact that the vast majority of web apps are produced using LAMP (Linux, Apache, MySQL and PHP), is of no consequence either.
    Let's just agree to differ? :)
    Good idea. Paul.
  77. Re: Black Hole's and "innovation"[ Go to top ]

    And of course the fact that the vast majority of web apps are produced using LAMP (Linux, Apache, MySQL and PHP), is of no consequence either.
    No, it isn't. It has no relevance to what I am discussing. If you want to find out what I have been discussing, read back through my posts. My experience is that a significant fraction of the projects I develop (and of the projects I have seen others develop) expand in requirements both in terms of load and in terms of types of functionality beyond what a pure LAMP approach can handle. Others decide to use interpreted languages as the foundation for their web apps. This has always been the case; all that has happened is that languages more tailored to this use case (such as PHP) have replaced previous approaches like C and PERL for the majority of small sites. A huge number of developers are prepared to take the risk of having to re-write their sites or implement new parts in different languages when requirements change, or they simply don't believe that their sites will ever change to that extent. Good for them. I am not, and I have explained repeatedly in great detail why not. You may believe that Java is not productive enough for you that you are prepared to take the risk of using less performant languages. I find Java highly productive (perhaps because I have never had to deal with the horrors of EJBs as you have - I have used lightweight alternatives), so I don't.
  78. Re: Black Hole's and "innovation"[ Go to top ]

    And of course the fact that the vast majority of web apps are produced using LAMP (Linux, Apache, MySQL and PHP), is of no consequence either.


    No, it isn't. It has no relevance to what I am discussing. If you want to find out what I have been discussing, read back through my posts. My experience is that a significant fraction of the projects I develop (and of the projects I have seen others develop) expand in requirements both in terms of load and in terms of types of functionality beyond what a pure LAMP approach can handle.

    Others decide to use interpreted languages as the foundation for their web apps. This has always been the case; all that has happened is that languages more tailored to this use case (such as PHP) have replaced previous approaches like C and PERL for the majority of small sites.

    A huge number of developers are prepared to take the risk of having to re-write their sites or implement new parts in different languages when requirements change, or they simply don't believe that their sites will ever change to that extent. Good for them. I am not, and I have explained repeatedly in great detail why not.

    You may believe that Java is not productive enough for you that you are prepared to take the risk of using less performant languages. I find Java highly productive (perhaps because I have never had to deal with the horrors of EJBs as you have - I have used lightweight alternatives), so I don't.
    Hi Steve, Haa, so you do understand! Great. Depending on the problem, specific tools become more or less applicable. The issue is what is the sweet spot for the type of application any given development shop tends to produce. Or the best tool for a given application (for shops with teams with different skills or with multi-skilled teams). For some its PHP for others its Ruby for another group it's Java/Spring and Hibernate and for some the best choice is EJB (yes I did say that!). I am arguing against "the Herd", mentality where everyone knows the solution before they have analysed the problem. As Bruce Tate once said on this forum, Java is one of the most mis-applied languages used today. That isn't a criticism of Java, but of Java Developers. I am happy to conceed that Java meets your needs, but for the vast majority of Java Web App developers out there, exploring alternatives is possibly a fruitful exercise (if only to reject them all in favour of Java). Choice on the Java platform will make alternatives to Java even more feasable. Incidently, it is not primarily the dynamic community that is driving change. The emergence of Groovy is in direct response to the same problems I outline, and is being driven by the "light wieght" container Java community. Incidently, Java with Closures is a new language and will require new libraries etc, as I described. So Java 7 and Groovy will be new languages, with all that implies. If you take your Java/JVM blinkers off, you will clearly see that change is comming, and the direction is back to the future. Paul.
  79. Re: Black Hole's and "innovation"[ Go to top ]

    I am arguing against "the Herd", mentality where everyone knows the solution before they have analysed the problem.
    My reading of that is exactly the contrary - choosing a relatively low-performance dynamic language is deciding beforehand what the range requirements will be, and the limits of the project might be. The 'Herd' today is those who write quick solutions with dynamic languages and don't take into account what may change in a project. People are doing this with PHP and RoR today. A decade ago they made the same mistakes with, for example, Visual Basic. What you call 'breaking from the herd' is what seems to me to be jumping on trendy bandwagons.
    I am happy to conceed that Java meets your needs, but for the vast majority of Java Web App developers out there, exploring alternatives is possibly a fruitful exercise (if only to reject them all in favour of Java).
    But, if you re-read my posts in detail, that is exactly what I do. There are circumstances where I have recommended PHP or RoR for some projects. All I am saying is that, generally, I use Java.
    If you take your Java/JVM blinkers off
    Why don't people read my posts before replying? I have said that I have tried a variety of languages and platforms, such as Delphi/Kylix and Smalltalk. I am not the one with blinkers.
    Incidently, Java with Closures is a new language and will require new libraries etc, as I described. So Java 7 and Groovy will be new languages, with all that implies.
    Well, if that is the political spin you want to put on things.... for the rest of us, we will be able to use the same syntax and library calls in Java 7 as we used in Java 1.3, which makes the 'new language' idea look somewhat mistaken.
  80. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve Remember this:
    Grails (and especially GORM) will reveal a dramatically different way of working from static Java.
    Well replace Groovy with Ruby, Python, Smalltalk etc. and you see my point. I think that you just have an emotional aversion to what you percieve as anti-Java propoganda. Other than that we actually agree. Paul.
  81. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve

    Remember this:

    Grails (and especially GORM) will reveal a dramatically different way of working from static Java.


    Well replace Groovy with Ruby, Python, Smalltalk etc. and you see my point.

    I think that you just have an emotional aversion to what you percieve as anti-Java propoganda. Other than that we actually agree.

    Paul.
    You are missing the whole point of what I am trying to say if you try and simply substitute Smalltalk and Ruby and Python for Groovy and Java. Groovy and Java run on a very high-performance VM, which means that much of the code can approach the speed of the equivalent C or C++ code (although more work will be needed for performance with Groovy). What I have is a strong desire to use languages where I don't have to make excuses for performance. Hopefully JRuby will join this elite group soon.
  82. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,
    What I have is a strong desire to use languages where I don't have to make excuses for performance. Hopefully JRuby will join this elite group soon.
    We agree on this too (I don't see Groovy as highly performant though). I see VisualWorks and VAST as already being in this group, alongside Squeak, Dolpin Smalltalk and Iron Python to a lesser degree. I too hope that Ruby 2.0, Strongtalk, Squeak on the Strongtalk VM and Python 3.0? joins them soon. Like I said, we agree, I just choose to cast my net further past the JVM. For most of my needs other options are just as worthy of consideration as JRuby or Groovy. Paul.
  83. Re: Black Hole's and "innovation"[ Go to top ]

    We agree on this too (I don't see Groovy as highly performant though).
    Well, I suggest you try it. It compiles to Java bytes codes, so it has the ability to be both JITted and Hotspotted. It is always best here to deal with facts, rather than what we feel or see.
    I see VisualWorks and VAST as already being in this group, alongside Squeak, Dolpin Smalltalk and Iron Python to a lesser degree.
    They aren't. We have already been over this. Even the best benchmarks show VisualWorks and VAST at a mere fraction of C speed apart from some specific cases (they are fast at object allocation, for example). Dolphin Smalltalk does not even have a JIT. Yet again, if they did have this performance advantage, there would have been no need for the StrongTalk work.
    I too hope that Ruby 2.0, Strongtalk, Squeak on the Strongtalk VM and Python 3.0? joins them soon.

    Like I said, we agree, I just choose to cast my net further past the JVM. For most of my needs other options are just as worthy of consideration as JRuby or Groovy.

    Paul.
    Yet again, as I said, I cast my net wide too. How many times do I need to post that I actually use and recommend PHP and other langauges? I guess I just have different criteria than you.
  84. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, To understand what I mean, take a look at dablleDb: http://www.dabbledb.com/ When your interface is a web client, and your application is I/O bound, then you can gain cross platform support and performance without needing a highly performant cross platform VM like the JVM. DabbleDB as won a number of awards and Smallthought is a thriving business. It is all written in Squeak. Paul.
  85. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,

    To understand what I mean, take a look at dablleDb:

    http://www.dabbledb.com/

    When your interface is a web client, and your application is I/O bound, then you can gain cross platform support and performance without needing a highly performant cross platform VM like the JVM.

    DabbleDB as won a number of awards and Smallthought is a thriving business. It is all written in Squeak.

    Paul.
    Maybe it is my fault; perhaps I am not communicating well. Let me try one last time. You can't predict how projects will evolve. A certain fraction will grow well beyond the initial requirements. The worst thing is you can't say which ones. This means you may start off with an application that is mainly an I/O bound web client, but it may grow beyond that. This has happened to me enough times for me to know it is a real problem. Your previously I/O bound application can soon become CPU-bound, due to any of a range of additional requirements. In my case, these requirements included substantial XML processing and image transformations. So what do you then do with your previously amazing Squeak appliction? Implement primitives in C, perhaps. But then you have a problem - two source code sets to support, one of which requires re-compilation for different platforms and CPUs (the C code base). Use Java, or well-integrated languages on the JVM, and this is far less of a problem; you can fall back to high-performance and portable Java libraries.
  86. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,

    To understand what I mean, take a look at dablleDb:

    http://www.dabbledb.com/

    When your interface is a web client, and your application is I/O bound, then you can gain cross platform support and performance without needing a highly performant cross platform VM like the JVM.

    DabbleDB as won a number of awards and Smallthought is a thriving business. It is all written in Squeak.

    Paul.


    Maybe it is my fault; perhaps I am not communicating well. Let me try one last time.

    You can't predict how projects will evolve. A certain fraction will grow well beyond the initial requirements. The worst thing is you can't say which ones.

    This means you may start off with an application that is mainly an I/O bound web client, but it may grow beyond that. This has happened to me enough times for me to know it is a real problem. Your previously I/O bound application can soon become CPU-bound, due to any of a range of additional requirements. In my case, these requirements included substantial XML processing and image transformations.

    So what do you then do with your previously amazing Squeak appliction? Implement primitives in C, perhaps. But then you have a problem - two source code sets to support, one of which requires re-compilation for different platforms and CPUs (the C code base).

    Use Java, or well-integrated languages on the JVM, and this is far less of a problem; you can fall back to high-performance and portable Java libraries.
    Hi Steve, I've understood you from the beginning. In the end this comes down to a business decision, and how you percieve the benefits of language X versus the potential risks. Languages which have a clear seperation between the semantics and the implementation allow this trade-off to move in their favor over time through improved implementation. Java has benefited from this through it's design, and Smalltalk is still benefiting from this (there is talk on adopting the Strongtalk VM across both open source and commercial Smalltalks). Smallthought is a business that has decided on Squeak and is succeeding. Many startups are looking at Ruby. We live in interesting times, and for sure with the right people and the right applications, dynamic languages will begin to steal market share. That is the beauty of the market. You pays your money, you take your choice. My point all along is that we should welcome an even playing field amongst languages and broader adoption of a wider set of languages amongst developers. For the future of computer science, this as got to be a good thing. Especially if you assume like I do, that we aren't there yet, and we still have a lot to learn and a lot more experimentation to do before Computer Science beomes a stable and mature discipline. Besides its fun :^). Paul
  87. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, I've been learning a lot about VM. Take a look at the presentation by Gilad Bacha on JSR292 (Frank supplied a link earlier). Also look into type feedback and Polymorphic Inline Caches as derived from Self research. We still have a lot to do. It is possible that using these technologys we can produce dynamic languages with dynamic compilers that peform faster than C++. They could do this by avoiding the indirection present in the VTable and hitting a hard-wired machine code cache instead. For debugging or for late-binding the VM would dynamically de-optimise back to a more interpretative form. White papers describing such approaches are on the Stongtalk website. Like I said, these are still early days, and the best implementations and ideas are still to be created. Paul.
  88. Re: Black Hole's and "innovation"[ Go to top ]

    We still have a lot to do. It is possible that using these technologys we can produce dynamic languages with dynamic compilers that peform faster than C++. They could do this by avoiding the indirection present in the VTable and hitting a hard-wired machine code cache instead. For debugging or for late-binding the VM would dynamically de-optimise back to a more interpretative form.

    White papers describing such approaches are on the Stongtalk website. Like I said, these are still early days, and the best implementations and ideas are still to be created.

    Paul.
    Yes, I know this. But you are backing exactly what I have been trying to say. In terms of this for dynamic languages, these are indeed early days, and they aren't there yet - the implementations of dynamic languages which generally match C++ performance have yet to be created. We can't build current systems on future promises. I am not currently going to build systems based on dynamic languages that might obtain performance at some possible future date from technologies that have not yet been fully implemented. I am afraid I have been let down too much by past promises of various technologies.
  89. Re: Black Hole's and "innovation"[ Go to top ]

    We still have a lot to do. It is possible that using these technologys we can produce dynamic languages with dynamic compilers that peform faster than C++. They could do this by avoiding the indirection present in the VTable and hitting a hard-wired machine code cache instead. For debugging or for late-binding the VM would dynamically de-optimise back to a more interpretative form.

    White papers describing such approaches are on the Stongtalk website. Like I said, these are still early days, and the best implementations and ideas are still to be created.

    Paul.


    Yes, I know this. But you are backing exactly what I have been trying to say. In terms of this for dynamic languages, these are indeed early days, and they aren't there yet - the implementations of dynamic languages which generally match C++ performance have yet to be created.

    We can't build current systems on future promises. I am not currently going to build systems based on dynamic languages that might obtain performance at some possible future date from technologies that have not yet been fully implemented. I am afraid I have been let down too much by past promises of various technologies.
    Hi Steve, Type feedback and Polymorphic inline caches will not happen unless there is a ready market. No one is asking you to bet the shop on dynamic languages. Java is not going away any time soon. All I'm saying is that a broader language base in the industry is healthy, with an incentive for research and development to occour in several areas rather than being narrowly focused on one (Java/C#). We can argue over the sweet spots for dynamic languages today, but they do exist and are increasingly being exploited commercially. This has got to be a good thing, I'm sure you agree? Paul.
  90. Re: Black Hole's and "innovation"[ Go to top ]

    We can argue over the sweet spots for dynamic languages today, but they do exist and are increasingly being exploited commercially. This has got to be a good thing, I'm sure you agree?

    Paul.
    Well, almost :) You see, I don't believe that much in 'sweet spots'. I have seen a few cases where dynamic/scripting languages work well, and I use them in such cases. For example, I can't now imagine doing sysadmin work without Python, and I know others who feel the same about Perl. As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.
  91. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve
    As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.
    Yes, I agree. I've seen this often with Java. I think deep down we do agree, although you are not ready to conceed (yet). All the best. Paul.
  92. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve

    As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.


    Yes, I agree. I've seen this often with Java.

    I think deep down we do agree, although you are not ready to conceed (yet).

    All the best.

    Paul.
    Erm, sorry, but this argument doesn't hold water. My whole point here - what I have been trying to emphasise for weeks - is that Java is not just a sweet-spot language. Like C and C++ it has become truly general purpose. Java used to be specifically targetted at networking/applet uses, but now it turns up everywhere: embedded, real-time, numerics, graphics, games and so on. It has been used to write not just applications, but the utilities that applications need, such as truly high-performance app servers and databases. There are not many languages that are able to deal with such a wide range of uses, but Java is certainly one of them. There are a few cases where Java remains deficient, such as system coding, but these are definitely few. What I believe we differ on is only one thing - it is it better to use (1) a general language, which may be less elegant and more verbose to code, or (2) a language with specific features suited to a task, but which may leave you high and dry if requirements change?
  93. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve

    As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.


    Yes, I agree. I've seen this often with Java.

    I think deep down we do agree, although you are not ready to conceed (yet).

    All the best.

    Paul.


    Erm, sorry, but this argument doesn't hold water.
    Which argument? I only made a statement. You clearly disagree. Differing opinions are good :^) All the best. Paul.
  94. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve

    As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.


    Yes, I agree. I've seen this often with Java.

    I think deep down we do agree, although you are not ready to conceed (yet).

    All the best.

    Paul.


    Erm, sorry, but this argument doesn't hold water.


    Which argument? I only made a statement. You clearly disagree.

    Differing opinions are good :^)

    All the best.

    Paul.
    The argument that Java is a language with certain sweet spots. I claimed that I had seen certain dynamic languages used inappropriately - beyond their 'sweet spots'. You claimed you had seen the same thing with Java. I am not sure that this makes sense, because Java is truly a general language, like C or C++. What I see is certain Java frameworks (such as full J2EE) used in situations that they were not designed for. But, Java itself is extremely versatile. I see a lot of confusion between the limitations of certain Java frameworks and the limitations of Java itself. Java frameworks can have 'sweet spots', however Java is general purpose, and so has a broader range of use than most dynamic languages. Which is why, for now, I use it for most development.
  95. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve

    As with Visual Basic in the past, I have seen so many people fall in love with the language they use for a what they think is a sweet spot that they do anything to justify its use outside of that spot. I know this, because I used to be guilty of this with Smalltalk. I see this now with Python and Ruby.


    Yes, I agree. I've seen this often with Java.

    I think deep down we do agree, although you are not ready to conceed (yet).

    All the best.

    Paul.


    Erm, sorry, but this argument doesn't hold water.


    Which argument? I only made a statement. You clearly disagree.

    Differing opinions are good :^)

    All the best.

    Paul.


    The argument that Java is a language with certain sweet spots. I claimed that I had seen certain dynamic languages used inappropriately - beyond their 'sweet spots'. You claimed you had seen the same thing with Java. I am not sure that this makes sense, because Java is truly a general language, like C or C++.

    What I see is certain Java frameworks (such as full J2EE) used in situations that they were not designed for. But, Java itself is extremely versatile. I see a lot of confusion between the limitations of certain Java frameworks and the limitations of Java itself.

    Java frameworks can have 'sweet spots', however Java is general purpose, and so has a broader range of use than most dynamic languages.

    Which is why, for now, I use it for most development.
    Hi Steve, Yes. This is the difference in opinion. I do not believe that there is anything as a truly general purpose language. There are languages that can be applied to a wide range of applications, but I do not believe that there is a language that can be appropriately applied to everything. If I was forced to only use one language, I would not choose Java. I would probably choose something like Common Lisp, which allows me to program in several paridgms all at once. But my point is that I do not have to use just one language for everything. I can choose. So I can decide to use Java for somethings and Ruby for others. So I opt to choose the right tool for the job. I believe that increasingly Java is the wrong tool (there are better tools) for many of the jobs to which it is being applied (simple web apps, components, late-binding, DSLs, etc). You disagree, which is fine. I accept your point of view, I just beg to differ. Paul.
  96. Re: Black Hole's and "innovation"[ Go to top ]

    es. This is the difference in opinion. I do not believe that there is anything as a truly general purpose language. There are languages that can be applied to a wide range of applications, but I do not believe that there is a language that can be appropriately applied to everything.

    If I was forced to only use one language, I would not choose Java. I would probably choose something like Common Lisp, which allows me to program in several paridgms all at once.
    No-one is implying that any language is suitable for everything. You are setting up a straw man argument.
    But my point is that I do not have to use just one language for everything. I can choose. So I can decide to use Java for somethings and Ruby for others.
    But then, if you use common lisp, or ruby you hit precisely the issues I have already raised. If you use Lisp, it is going to be hard, if required, to find other developers to support your code. If you use Ruby, you are going to, sooner or later, on one project or another where you have decided Ruby is appropriate, hit performance issues, and have to work with mixed languages. Been, there, done that, had to deal with the consequences.
    So I opt to choose the right tool for the job.
    So do I, of course. I mean, do you honestly believe anyone deliberately chooses the wrong tool for the job? :)
    I believe that increasingly Java is the wrong tool (there are better tools) for many of the jobs to which it is being applied (simple web apps, components, late-binding, DSLs, etc).
    And I believe I have clearly explained why I frequently find those to be the wrong tools, and why, based on huge experience, I find that approach to be risky, both for the developer and their clients. Good luck with your approach, but I am afraid that past experience and continued evaluation of languages and strategies has convinced me that until portable high-performance multi-language VMs are well-established (perhaps the JVM will move that way), so that different langauages and approaches can be seamlessly integrated, it is definitely unwise!
  97. Re: Black Hole's and "innovation"[ Go to top ]

    es. This is the difference in opinion. I do not believe that there is anything as a truly general purpose language. There are languages that can be applied to a wide range of applications, but I do not believe that there is a language that can be appropriately applied to everything.

    If I was forced to only use one language, I would not choose Java. I would probably choose something like Common Lisp, which allows me to program in several paridgms all at once.


    No-one is implying that any language is suitable for everything. You are setting up a straw man argument.

    But my point is that I do not have to use just one language for everything. I can choose. So I can decide to use Java for somethings and Ruby for others.


    But then, if you use common lisp, or ruby you hit precisely the issues I have already raised. If you use Lisp, it is going to be hard, if required, to find other developers to support your code. If you use Ruby, you are going to, sooner or later, on one project or another where you have decided Ruby is appropriate, hit performance issues, and have to work with mixed languages. Been, there, done that, had to deal with the consequences.

    So I opt to choose the right tool for the job.


    So do I, of course. I mean, do you honestly believe anyone deliberately chooses the wrong tool for the job? :)

    I believe that increasingly Java is the wrong tool (there are better tools) for many of the jobs to which it is being applied (simple web apps, components, late-binding, DSLs, etc).


    And I believe I have clearly explained why I frequently find those to be the wrong tools, and why, based on huge experience, I find that approach to be risky, both for the developer and their clients.

    Good luck with your approach, but I am afraid that past experience and continued evaluation of languages and strategies has convinced me that until portable high-performance multi-language VMs are well-established (perhaps the JVM will move that way), so that different langauages and approaches can be seamlessly integrated, it is definitely unwise!
    Hi Steve, You seem very sure! It may not have crossed your mind that I have my reasons (and my experiences) too. Your attitude to potential risk is common, and does have a down side. It tends to result in technology stagnation. Using the very same argument you could argue that C/C++ is the lowest risk approach. In the Agile community we have an acronym: YAGNI. It stands for you aint gonna need it. I make no attempt to future proof my work, because YAGNI. The time you spend building a single bullet proof, future proof application a Rails developer may have delivered several apps. Ultimately which is more important (delivery now versus eliminating potential risks in the future) is debateable. What is for sure is that the business need the app today, and may never need the features that you are protecting against in the future. If you look on the C2 wiki, there are countless discussions on this very point: http://c2.com/xp/YouArentGonnaNeedIt.html Infact companies like Smallthought are relying on this idea to gain a jump or slower moving "industrial strength" competitors (people who think like you do). I do not have a crystal ball and I cannot predict which approach will win out. But my experience has convinced me that a light-weight, highest productivity YAGNI approach is by far more effective overall. You may get caught out every now and then, but the increased business value delivered in the meanwhile far out ways any potential risk. And what happens when you do get caught out? Well you pay for that esoteric one off feature once. You don't pay for it ten times in advance just in case! Paul.
  98. Re: Black Hole's and "innovation"[ Go to top ]

    You seem very sure! It may not have crossed your mind that I have my reasons (and my experiences) too.
    When have I ever said that? I try not to mind-read :)
    Your attitude to potential risk is common, and does have a down side. It tends to result in technology stagnation.
    No, it doesn't. It helps advance software by putting more demands on the developers of languages, so that they meet the requirements of developers who need performance, stability and security.
    Using the very same argument you could argue that C/C++ is the lowest risk approach.
    No. C/C++ is nowhere near as easily portable as Java - the idea of having to re-compile for different platforms and CPUs and then support all those binaries....
    In the Agile community we have an acronym: YAGNI. It stands for you aint gonna need it. I make no attempt to future proof my work, because YAGNI.
    And this is the single aspect of 'Agile' I disagree most profoundly with. I have considerable experience of production in a range of areas of software where not only has the client been extremely pleased that we have 'future proofed' the product, but I have worked with a company that has built up a great reputation because of this, with a large number of return clients.
    The time you spend building a single bullet proof, future proof application a Rails developer may have delivered several apps.
    No. You are wrong. There are development techniques in Java which may take longer than rails, but I really don't believe they take THAT much longer. I could, for example, deliver a full data-linked web app with Studio Creator in a very short time indeed if required - I suspect even faster than Rails, thanks to the visual design.
    Ultimately which is more important (delivery now versus eliminating potential risks in the future) is debateable.
    Indeed. At last, we are getting to the heart of where we differ.
    What is for sure is that the business need the app today, and may never need the features that you are protecting against in the future.
    I am not talking about adding features in advance. I am talking about having the potential to add those features later. For example, simply by using Java, I automatically get the possibility of huge future performance , without adding a single extra feature. I am afraid that the 'we need it now, no matter what' attitude has led to software distasters over the years. Software should be a craft, not a production line.
    I do not have a crystal ball and I cannot predict which approach will win out. But my experience has convinced me that a light-weight, highest productivity YAGNI approach is by far more effective overall.
    And my experience over nearly 3 decades working on a large number of projects and in a range of languages has convinced me that it is a poor idea, and doing the opposite can be a very wise business approach, and get you a great reputation for solid products. Obviously there is a balance, but when simply using one language over another can possibly give your client considerable potential for future growth.
    You may get caught out every now and then, but the increased business value delivered in the meanwhile far out ways any potential risk. And what happens when you do get caught out? Well you pay for that esoteric one off feature once. You don't pay for it ten times in advance just in case!

    Paul.
    But the thing is, you certainly aren't paying for it ten times in advance. That is just hype. I have used a large number of static and dynamic languages since I started coding in the 70s and I really honestly don't believe there is that much productivity difference in coding for general use. (You know what I believe? Developers simply work fastest in the language they prefer, static or dynamic!) There are tools that allow very fast development indeed in Java. And, my experience is that getting caught out can be a serious disaster, leading to a loss of reputation with the client and major financial problems. I have seen enough 'getting caught out's' to realise how bad they can be. One single 'caught out' can wipe out the benfits of any number of successful projects. I guess I would rather 'wear my seatbelt' and use (at least for now) Java. So, I think it comes down to this - we both have different experiences and take different approaches to the risk of getting caught out by the wrong language choice. Perhaps it is because I have worked on long-term projects that I dare not get 'caught out' by the wrong language choice. Perhaps what may be a disaster for me could be far less of an issue for you. But, I respect your view - it may well be appropriate for the scales of projects you work on. I simply choose another way! Thank you for the discussion. It has not changed my mind at all, but simply responding has helped me clarify some long-held views....
  99. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,
    Thank you for the discussion. It has not changed my mind at all, but simply responding has helped me clarify some long-held views...
    You're welcomed. Perhaps I should have addressed your central concern a lot earlier. I'll listen more in future. Paul.
  100. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, Reading through your response, I feel that perhapss you I haven't explained myself fully. If you are happy with your views then fine, but if you are generally interested in exploring alternative ideas then I'm more than happy to debate them with you. On the C2 Wiki there is another acronym: IKIA. It stands for I Know It Allready. Many of the ideas I am expressing I did not believe untill I actually experienced them working in practice (I was lucky enough to work on a project where the coach was a director on the Agile Alliance). It radically changed my views, and knowadays I question everything!
    Your attitude to potential risk is common, and does have a down side. It tends to result in technology stagnation.


    No, it doesn't. It helps advance software by putting more demands on the developers of languages, so that they meet the requirements of developers who need performance, stability and security.

    I see this differently. IMO we as developers have a responsibility for our own destiny, and if we choose not to experiment and push the bounds of technology, then vendors will have no incentive to produce technology that more reflects our needs. If we choose the safe option, so will they. If anything the open source movement (Pico-container, Spring, Hibernate, Ruby, JRuby, Rails etc) has proved that developers taking the lead does result in inovation and change.
    What is for sure is that the business need the app today, and may never need the features that you are protecting against in the future.


    I am not talking about adding features in advance. I am talking about having the potential to add those features later. For example, simply by using Java, I automatically get the possibility of huge future performance , without adding a single extra feature.

    I am afraid that the 'we need it now, no matter what' attitude has led to software distasters over the years. Software should be a craft, not a production line.

    I said that you are protecting against future features. If in the future your custmers decide that they will need graphics processing, then deciding to use C++ today does protect you against that possibility. C++ is an ideal language for low level graphics. But C++ may be slow and difficult to maintain for the bulk of the features needed. So what do you do? Well you write the bulk of the code in Smalltalk and get it out the door (happy customers and market presence). Soon as you become aware of the need for advance graphics you start writing a graphics component in C++ with a Smalltalk wrapper. (Of course you ensure that your graphics component is ported to all the platforms you support, in the same way that your VM is cross-platform). My Smalltalk application programmers are now free to deliver graphics features in Smalltalk (implemented in C++ under the covers). I could choose to have a spcialist team for this purpose producing Smalltalk wrapped C++ libraries as needed.
    You may get caught out every now and then, but the increased business value delivered in the meanwhile far out ways any potential risk. And what happens when you do get caught out? Well you pay for that esoteric one off feature once. You don't pay for it ten times in advance just in case!

    Paul.


    But the thing is, you certainly aren't paying for it ten times in advance. That is just hype.
    Is it really? It depends how you do the calculation. Let's be conservative and say that Rails is 20% faster then Java. So you deliver to the market first with Rails, with your competitors delivering a 5th of the time again later. How much is that worth to a business? With Java, release cycles are 20% longer than Rails (say) so Rails can deliver 6 releases for your 5. What is that worth? Eventually you hit that feature where Java sings and Rails has to fall back on C/C++. You implement it in half the time in Java then it takes in Rails, great. But wait a minute. Over ten releases you have been 20% slower, so your overall costs have been (10 +0.5) = 10.5 units versus (10 * 4/5 + 1)= 9 for Rails. The Rails team is still ahead in costs, are first to market, and can respond to market changes (deliver releases) more often. This is the argument for YAGNI. Paul.
  101. Decision Maths and YAGNI[ Go to top ]

    Hi Steve, You've got me thinking. Let's do a more accurate calculation. Again on the C2 Wiki, someone as posted a methematical formula we can use based on Decision Maths: http://c2.com/cgi/wiki?DecisionMathAndYagni Now for some realistic data. I have ben producing web apps since 1997 and in all that time, I am yet to come across a requirement that wasn't I/O bound. For me I would say a 1 in 20 chance of this happening per release is a fair estimate (well actually it hasn't happend at all but 1:20 will do for the calculation). If I was using Rails all that time I would say that I would have been perhaps as much as 4 times more productive. This is consistent with Bruce Tate who quotes a ratio of 4-5 for Rails versus Spring/Hibernate. For argument sake lets choose a ratio of 2. So lets say preparing costs me 10 (the overhead of using Java) and implementing the CPU bound feature costs me 5 should it occur. I would estimate that when I did need to use C/C++ with Rails that it would take me 3 times as long as Java to implement (estimate 15). This is fair IMO. So the calculation: Preparation for CPU Bound Requirement: * X happens o preparation costs: 10 o full implementation costs: 5 o Total: 15 * X does not happen o preparation costs: 10 o full implementation costs: 0 o Total: 10 No Preparation for CPU Bound Requirement: * X happens o preparation costs: 0 o full implementation costs: 15 o Total: 15 * X does not happen o preparation costs: 0 o full implementation costs: 0 o Total: 0 If we assume X has a 5% chance (1:20), the calculations would go like this: Prepare: 0.05 x 15 + 0.95 x 10 = 10.25 Don't prepare: 0.05 x 15 + 0.95 x 0 = 0.75 We can play with the numbers. As you can see depending on the likelyhood of a feature (the problem domain) and the relative costs of implementation, choosing language A over language B becomes more or less attractive. I'm not saying that I believe these numbers, but it is sort of scientific (and fits in with my gut feel). Ofcourse there are other factors to be considered too. But it would be interesting running the same calculation with your estimates based on your experience. Paul.
  102. Re: Decision Maths and YAGNI[ Go to top ]

    Hi Steve,

    You've got me thinking. Let's do a more accurate calculation. Again on the C2 Wiki, someone as posted a methematical formula we can use based on Decision Maths:

    http://c2.com/cgi/wiki?DecisionMathAndYagni

    Now for some realistic data. I have ben producing web apps since 1997 and in all that time, I am yet to come across a requirement that wasn't I/O bound. For me I would say a 1 in 20 chance of this happening per release is a fair estimate (well actually it hasn't happend at all but 1:20 will do for the calculation). If I was using Rails all that time I would say that I would have been perhaps as much as 4 times more productive.

    This is consistent with Bruce Tate who quotes a ratio of 4-5 for Rails versus Spring/Hibernate. For argument sake lets choose a ratio of 2. So lets say preparing costs me 10 (the overhead of using Java) and implementing the CPU bound feature costs me 5 should it occur. I would estimate that when I did need to use C/C++ with Rails that it would take me 3 times as long as Java to implement (estimate 15). This is fair IMO.


    So the calculation:

    Preparation for CPU Bound Requirement:

    * X happens
    o preparation costs: 10
    o full implementation costs: 5
    o Total: 15
    * X does not happen
    o preparation costs: 10
    o full implementation costs: 0
    o Total: 10

    No Preparation for CPU Bound Requirement:

    * X happens
    o preparation costs: 0
    o full implementation costs: 15
    o Total: 15
    * X does not happen
    o preparation costs: 0
    o full implementation costs: 0
    o Total: 0

    If we assume X has a 5% chance (1:20), the calculations would go like this:

    Prepare:

    0.05 x 15 + 0.95 x 10 = 10.25

    Don't prepare:

    0.05 x 15 + 0.95 x 0 = 0.75


    We can play with the numbers. As you can see depending on the likelyhood of a feature (the problem domain) and the relative costs of implementation, choosing language A over language B becomes more or less attractive.

    I'm not saying that I believe these numbers, but it is sort of scientific (and fits in with my gut feel). Ofcourse there are other factors to be considered too. But it would be interesting running the same calculation with your estimates based on your experience.

    Paul.
    I personally don't believe the 4-5, or even 2x the development speed benefit of Rails over Spring + Hibernate, at least for some projects. The reason is this depends entirely on the size and type of project. I usually work on large projects (hundreds of thousands of lines, months or more of work at least). At that scale the 'getting started and set up' part of a project, in which Rails undoubtedly has a major advantage, is a mere fraction of what has to be done. At that scale, the ability to run large functional tests fast, and to browse and refactor substantial amounts of code becomes, in my opinion, essential. I also find compile-time checking of enormous benefit in such situations. So, I don't believe that advantage exists for the scale of project I mostly work with. You are also, I believe, missing the points I have made about 'implementing CPU bound features'. There is no overhead in implementing these - you simply code them up. The overhead only arises in mixed languages situations. Also, some parts of an application can become CPU-bound as load increases. At a rough estimate, about 1/4 of web projects I have worked with have included CPU-bound features (things like image manipulation, substantial XML processing, numeric work and so on), or have developed into that situation. You are also ignoring business factors I have described - the potential business advantage of return custom from clients who are happy you have not just delivered the 'bare essentials', and have seen your product scale as their business grew. From personal experience, that can be a real advantage. I don't mean to seem impolite, but I don't see any point in throwing figures into your equations, as I believe that for my scale of project, the ability to use a rich IDE and browsing/refactoring tools makes me more productive than with Rails. I have experience of dealing with large codebases of dynamic languages without good tools, and it was not a pleasant experience. The thing is, in the end, we can prove anything through exercises like yours. All I need to do is challenge one assumption - that there is an overhead to preparation, and it all falls apart. All we can do is combine personal experience, and information we glean from what we believe are reliable sources, and do our best.
  103. Re: Decision Maths and YAGNI[ Go to top ]

    Hi Steve,

    You've got me thinking. Let's do a more accurate calculation. Again on the C2 Wiki, someone as posted a methematical formula we can use based on Decision Maths:

    http://c2.com/cgi/wiki?DecisionMathAndYagni

    Now for some realistic data. I have ben producing web apps since 1997 and in all that time, I am yet to come across a requirement that wasn't I/O bound. For me I would say a 1 in 20 chance of this happening per release is a fair estimate (well actually it hasn't happend at all but 1:20 will do for the calculation). If I was using Rails all that time I would say that I would have been perhaps as much as 4 times more productive.

    This is consistent with Bruce Tate who quotes a ratio of 4-5 for Rails versus Spring/Hibernate. For argument sake lets choose a ratio of 2. So lets say preparing costs me 10 (the overhead of using Java) and implementing the CPU bound feature costs me 5 should it occur. I would estimate that when I did need to use C/C++ with Rails that it would take me 3 times as long as Java to implement (estimate 15). This is fair IMO.


    So the calculation:

    Preparation for CPU Bound Requirement:

    * X happens
    o preparation costs: 10
    o full implementation costs: 5
    o Total: 15
    * X does not happen
    o preparation costs: 10
    o full implementation costs: 0
    o Total: 10

    No Preparation for CPU Bound Requirement:

    * X happens
    o preparation costs: 0
    o full implementation costs: 15
    o Total: 15
    * X does not happen
    o preparation costs: 0
    o full implementation costs: 0
    o Total: 0

    If we assume X has a 5% chance (1:20), the calculations would go like this:

    Prepare:

    0.05 x 15 + 0.95 x 10 = 10.25

    Don't prepare:

    0.05 x 15 + 0.95 x 0 = 0.75


    We can play with the numbers. As you can see depending on the likelyhood of a feature (the problem domain) and the relative costs of implementation, choosing language A over language B becomes more or less attractive.

    I'm not saying that I believe these numbers, but it is sort of scientific (and fits in with my gut feel). Ofcourse there are other factors to be considered too. But it would be interesting running the same calculation with your estimates based on your experience.

    Paul.


    I personally don't believe the 4-5, or even 2x the development speed benefit of Rails over Spring + Hibernate, at least for some projects. The reason is this depends entirely on the size and type of project. I usually work on large projects (hundreds of thousands of lines, months or more of work at least). At that scale the 'getting started and set up' part of a project, in which Rails undoubtedly has a major advantage, is a mere fraction of what has to be done. At that scale, the ability to run large functional tests fast, and to browse and refactor substantial amounts of code becomes, in my opinion, essential. I also find compile-time checking of enormous benefit in such situations. So, I don't believe that advantage exists for the scale of project I mostly work with.

    You are also, I believe, missing the points I have made about 'implementing CPU bound features'. There is no overhead in implementing these - you simply code them up. The overhead only arises in mixed languages situations. Also, some parts of an application can become CPU-bound as load increases.

    At a rough estimate, about 1/4 of web projects I have worked with have included CPU-bound features (things like image manipulation, substantial XML processing, numeric work and so on), or have developed into that situation.

    You are also ignoring business factors I have described - the potential business advantage of return custom from clients who are happy you have not just delivered the 'bare essentials', and have seen your product scale as their business grew. From personal experience, that can be a real advantage.

    I don't mean to seem impolite, but I don't see any point in throwing figures into your equations, as I believe that for my scale of project, the ability to use a rich IDE and browsing/refactoring tools makes me more productive than with Rails. I have experience of dealing with large codebases of dynamic languages without good tools, and it was not a pleasant experience.

    The thing is, in the end, we can prove anything through exercises like yours. All I need to do is challenge one assumption - that there is an overhead to preparation, and it all falls apart. All we can do is combine personal experience, and information we glean from what we believe are reliable sources, and do our best.
    Hi Steve, I'm not ignoring anything. I agree that the analysis I presented is simplistic. I do feel that there is value in it however. My estimate of 2 times as fast with Rails doesn't actually factor into the calculation. The value of 10 as the preperation cost for Java is across the whole release. So if it costs 5 to do your XML processing in Java, then I am saying that it will cost 15 to do it in Rails, I am also saying that the Java release will cost 10 more than the Rails release (e.g. 100 for Rails release, 110 for Java). So on a release cost of 100 for Rails, this represents just 10% overhead for using Java. This sounds realistic, but I am interested in your numbers. I think we are making different assumptions. I am assuming that using Rails never becomes a show stopper, it just becomes inconvienient. I believe you are assuming the opposite. Also, there are other mixed splits to be considered. Pico-container for instance has experimented with using Java for the bulk of the work, and a scripting language as the glue (instead of XML). How does the productivity of this approach compare with XML Configuration/Java? These are interesting times, a lot of people are challenging long held assumptions, and it will be interesting to see what is discovered as a consequence. Paul.
  104. Re: Decision Maths and YAGNI[ Go to top ]

    I'm not ignoring anything. I agree that the analysis I presented is simplistic.
    Then, by definition, you are.
    I think we are making different assumptions. I am assuming that using Rails never becomes a show stopper, it just becomes inconvienient. I believe you are assuming the opposite
    That is because, for my projects, it is. For example, I almost always deal with legacy databases which don't comply with the requirements of Rails for indexes and primary keys. Even if this were not an issue, I am dealing with single transactions which may involve hundreds of thousands of records; Rails is known to be poor at this, due to object creation overheads.
    Also, there are other mixed splits to be considered. Pico-container for instance has experimented with using Java for the bulk of the work, and a scripting language as the glue (instead of XML). How does the productivity of this approach compare with XML Configuration/Java?
    Well, that fits with what I was saying about mixed language development being reasonable on something like the JVM, where integration between languages is seamless and you don't lose portability. We are going over old ground here.
    These are interesting times, a lot of people are challenging long held assumptions, and it will be interesting to see what is discovered as a consequence.

    Paul.
    You see, I think that people have always been challenging assumptions. The major transition from C/C++ to Java as most in-demand language was challenging major long-held assumptions such as the necessity for manual memory management and pointers for performance. This 'people are challenging assumptions' statement sounds to me precisely like what I was hearing in the mid-80s with Smalltalk, and Prolog, and LISP. This is nothing new....
    This sounds realistic, but I am interested in your numbers.
    But there is no point. As I said, I don't believe that for the projects I work with there is any significant disadvantage at all to using Java as primary language, so all the weightings between 'preparing' and 'not preparing' for CPU-bound work are the same. There is no cost for being able to meet CPU-bound requirements because I already use tools and languages that can do that, and I am already highly productive using them..... for my scales of projects. And, as I have said, for almost all my projects, Rails is simply not appropriate, as it was not designed for them. It would require major hacking to deal with some of the schemas I have do work with (I have researched this!).
  105. Re: Decision Maths and YAGNI[ Go to top ]

    I'm not ignoring anything. I agree that the analysis I presented is simplistic.


    Then, by definition, you are.

    I think we are making different assumptions. I am assuming that using Rails never becomes a show stopper, it just becomes inconvienient. I believe you are assuming the opposite


    That is because, for my projects, it is. For example, I almost always deal with legacy databases which don't comply with the requirements of Rails for indexes and primary keys. Even if this were not an issue, I am dealing with single transactions which may involve hundreds of thousands of records; Rails is known to be poor at this, due to object creation overheads.

    Also, there are other mixed splits to be considered. Pico-container for instance has experimented with using Java for the bulk of the work, and a scripting language as the glue (instead of XML). How does the productivity of this approach compare with XML Configuration/Java?


    Well, that fits with what I was saying about mixed language development being reasonable on something like the JVM, where integration between languages is seamless and you don't lose portability. We are going over old ground here.

    These are interesting times, a lot of people are challenging long held assumptions, and it will be interesting to see what is discovered as a consequence.

    Paul.


    You see, I think that people have always been challenging assumptions. The major transition from C/C++ to Java as most in-demand language was challenging major long-held assumptions such as the necessity for manual memory management and pointers for performance.

    This 'people are challenging assumptions' statement sounds to me precisely like what I was hearing in the mid-80s with Smalltalk, and Prolog, and LISP.

    This is nothing new....

    This sounds realistic, but I am interested in your numbers.


    But there is no point. As I said, I don't believe that for the projects I work with there is any significant disadvantage at all to using Java as primary language, so all the weightings between 'preparing' and 'not preparing' for CPU-bound work are the same. There is no cost for being able to meet CPU-bound requirements because I already use tools and languages that can do that, and I am already highly productive using them..... for my scales of projects. And, as I have said, for almost all my projects, Rails is simply not appropriate, as it was not designed for them. It would require major hacking to deal with some of the schemas I have do work with (I have researched this!).
    Hi Steve, Understood. I would not use Rails in a legacy situation either. But there are a lot of greenfield projects out there that are ripe for Rails, and where this type of simplistic "productivity" calculation has some meaning. I'm learning Rails in earnest now, and I am not as dismissive of it as I use to be. I think it has definately got it's place. The DSL's in Rails are extremely powerful, and Spring/Hibernate with XML configuration looks positively ancient in comparison. In fact I'm looking for A Rails project as my next contract. Wish me luck :^). Paul.
  106. Re: Decision Maths and YAGNI[ Go to top ]

    Understood. I would not use Rails in a legacy situation either. But there are a lot of greenfield projects out there that are ripe for Rails, and where this type of simplistic "productivity" calculation has some meaning.
    Ah, but let me tell you a cautionary tale :) I saw precisely such a greenfield project about 5 years ago. Was mainly static pages with a few forms. Was obviously going to be simple, and was written in a dynamic web scripting language, and not even one (like PHP) that could easily integrate with other languages. Then the site grew, and the static pages where a bit more dynamic. And the forms grew more complicated. And then some functionality was required (to simplify, I shall call it 'stock availability'). This latter functionality was both memory and cpu intensive. Load on the site increased dramatically. I was the guy who had to rewrite this project at short notice after the site collapsed. So, my bitter experience is to beware of simple solutions even for 'greenfield' sites.
    I'm learning Rails in earnest now, and I am not as dismissive of it as I use to be. I think it has definately got it's place. The DSL's in Rails are extremely powerful, and Spring/Hibernate with XML configuration looks positively ancient in comparison.

    In fact I'm looking for A Rails project as my next contract.

    Wish me luck :^).

    Paul.
    I will indeed!
  107. Re: Decision Maths and YAGNI[ Go to top ]

    Hi Steve,
    I saw precisely such a greenfield project about 5 years ago. Was mainly static pages with a few forms. Was obviously going to be simple, and was written in a dynamic web scripting language, and not even one (like PHP) that could easily integrate with other languages. Then the site grew, and the static pages where a bit more dynamic. And the forms grew more complicated. And then some functionality was required (to simplify, I shall call it 'stock availability'). This latter functionality was both memory and cpu intensive. Load on the site increased dramatically.
    I'm guessing that the language you speak of is Visual Basic? I've got mixed views on visual basic. IMO many applications have been produced in VB that would have not have been written otherwise. I know a few VB programmers and they were "Agile" before "Agile". The whole RAD approach in the 1990's was a sort of precursor to the Agile movement IMO. I agree many of those old client/server VB solutions, didn't scale well, but they provided busines value to end-user departments in a timely fashion. They didn't have to wait for the IT department to launch an "official" project and then wait two years to see the project canned. They got something simple that met their needs today in a relatively short time. In an industry where 70% of projects fail, then perhaps we can count the bulk of VB applications amongst our successes. At least they got out the the door and delivered business value. I think this comes down to the 80/20 rule. You can get 80% of the value for 20% of the effort most of the time. The thing is indetifying the right 20%. This is an important point when it comes to scoping projects in the first place, but I digress :^). My point though is that it is seldom sworth going for the whole 100% (e.g. delivered timely, feature rich and future proof). The advantage Smalltalk/Python/Ruby and Java in the early days (remember JNI ?), have over VB is that they provide a back door to drop down to a lower level of abstraction. So if your high level, high abstraction, dynamic language proves too slow, you can always drop down to C. I agree this is a bit messy, but most things in life come down to a compromise (the 80/20 rule again). So IMO it is a viable practical solution, at least until we get dynamic compilers, type feedback and polymorphic Inline caches. Paul.
  108. Re: Decision Maths and YAGNI[ Go to top ]

    I'm guessing that the language you speak of is Visual Basic? I've got mixed views on visual basic.
    No, it wasn't. It was a server-side web scripting language.
    I think this comes down to the 80/20 rule. You can get 80% of the value for 20% of the effort most of the time. The thing is indetifying the right 20%.
    Well, if you can come up with a foolproof method of identifying the right 20% that need to use optimization, I congratulate you!
    This is an important point when it comes to scoping projects in the first place, but I digress :^).
    My entire point is that the scope of a project can change, possibly over a long period.
    My point though is that it is seldom sworth going for the whole 100% (e.g. delivered timely, feature rich and future proof).
    My opinion is that it is, and I feel I have at least tried to explain why in great detail.
    I agree this is a bit messy, but most things in life come down to a compromise (the 80/20 rule again). So IMO it is a viable practical solution, at least until we get dynamic compilers, type feedback and polymorphic Inline caches.

    Paul.
    No, it is not just a bit messy. It can be a serious support issue. You have C or C++ code to maintain. You have to test that code. You have to possibly compile and test it for a range of platforms (Windows, Linux, Mac/OS), with a range of compilers, and different support libraries. You may have to test this for different CPUs, with different word lengths. It can remove the main advantage of using easy-to-deploy portable dynamic languages. Having experience of this, I really don't believe it is viable if you want to retain the advantages of fast development and simple deployment, except for the simplest cases (such as non-portable code), which I don't work on. I have heard of a successful PHP project that looked very portable, apart from the fact that one bit of the code was written in C and shipped as binary, which messes up the ability to run the PHP on a 64-bit platform. Do you really want to go through all these arguments again? :) I have run out of energy....
  109. Re: Decision Maths and YAGNI[ Go to top ]

    Hi Steve,
    Do you really want to go through all these arguments again? :) I have run out of energy....
    No I don't :^). I just got the idea that you thought that you did not understand my point of view. Now I know you understand, but you just disagree, which like I said before is fine. It's just a different (business) strategy. I respect your choices, mine are just different. Later, P.
  110. Re: Black Hole's and "innovation"[ Go to top ]

    I've understood you from the beginning. In the end this comes down to a business decision, and how you percieve the benefits of language X versus the potential risks.
    Indeed - and not, as has been implied, any particular bias towards Java.
    Smallthought is a business that has decided on Squeak and is succeeding. Many startups are looking at Ruby. We live in interesting times, and for sure with the right people and the right applications, dynamic languages will begin to steal market share.
    I think this sidesteps the argument. No-one with substantial experience of IT doubts that languages like Visual Basic (especially pre .NET) have sometimes been used beyond the appropriate situations. However, many companies made substantial amounts of money providing tools and components for it. Would you consider Visual Basic 6 to be an example of a high-quality system supporting modern software design techniques? How about PHP (also a huge base for tools and products)? I wouldn't. But large sections of the market chose them. In fact, Visual Basic stole market share from better, more OOP approaches to Windows development - Smalltalk, Actor, TPW, Delphi. Just because many startups and businesses are making money supporting one approach does not mean that that approach is the best; just that it happens to be currently popular. All I am saying here is that you can't always use the success of tool vendors and market share as a measure of quality.
    That is the beauty of the market.
    Actually, as illustrated above, the market can make bad decisions (after all, the market eventually largely rejected Smalltalk in the late 80s and early 90s).
    My point all along is that we should welcome an even playing field amongst languages and broader adoption of a wider set of languages amongst developers.
    Absolutely.
    For the future of computer science, this as got to be a good thing. Especially if you assume like I do, that we aren't there yet, and we still have a lot to learn and a lot more experimentation to do before Computer Science beomes a stable and mature discipline. Besides its fun :^).

    Paul
    It sure is! But, as I have said before, what I am after is a debate which is built on past experiences and past research. I have seen far too much posting on various forums and blogs that has basically forgotten that the past 20 years of IT has happened.
  111. Re: Black Hole's and "innovation"[ Go to top ]

    I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
    I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
    What I'm finding unacceptable is your trend of trying to make your personal development decisions applicable as a standard for others. You are in no position to do that.
  112. Re: Black Hole's and "innovation"[ Go to top ]

    Sounds like you want OCaml and not Java if you want something closer to C speed.
    Why? This seems a strange comment. Java gives me pretty much equivalent to C speed. I Why would I move to a language that has less support, less versatility, fewer frameworks?
    That's just completely untrue. Has Java always been fast?
    No, I have agreed that.
    Why are they always working on ways to accelerate Java.
    Because they are always working on ways to accelerate every language, C and C++ included. What matters to me is the performance differential between the langauage I use and that available for languages recognised to make close to optimal use of computing power.
    What about Lisp? Even pre-1.0 SBCL is about a dead heat on the debian language shootout. And that's not even comparing to the high-performance commercial implementations like Allegro and Lispworks.
    The debian-language shootout is a very poor set of benchmarks; for Java, it does not allow enough time for the hotspot optimiser to work. Multiply the run times by 5 or 10 times, and things change. LISP is still not close to C (or now Java) when it comes to numeric work - one of my use cases. I wish people would read previous posts before responding :) I have already mentioned why not LISP - there is not the developer base.
    Every language implementor would want a fast runtime. Java is no different.
    The goals of the Self group were to make a fast VM for the Self language. The goals of the StrongTalk team were to make a fast VM for Smalltalk. The goals of the Java VM team are to make a fast VM for Java. Strongtalk was essentialy shelved after Java started enjoying success. If Java had been shelved in favor of Strontalk, it would have been left with a poor performing VM.
    But it wasn't, was it? No point trying to re-write history. The fact is that Java was the one that got the fast VM.
    Fine, but you don't get to decide that other dynamic language aren't fast enough to be general purpose, when clearly languages like Lisp and Smalltalk are
    I can decide what I like for my purposes. Let me stress yet again. It is not just me who believes that dynamic languages aren't generally fast enough for general purpose. You should read the literature written by the authors of Self and StrongTalk - they refelected a widely-held view in the industry that dynamic languages weren't fast enough.
    I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
    A whole range of things. I do everything from scientific numerical work (simulation models) to commercial stock level and availability calculations for high-load sales systems, CAD software, image processing and so on; all this combined with more conventional software - database stuff, websites and so on. To be able to use largely a single language and set of frameworks for this range of stuff is phenomenal; no need for awkward cross-language bindings. So, Java certainly is my choice. I have been developing C and C++ projects on and off since the mid 80s. It was a support nightmare, especially during the windows 16-to-32-bit transition, and there have been migration difficulties between compilers and platforms and major problems with bug tracing. C++ with garbage collection solved some of these problems, but when I discovered that IBM's JVM could give exactly equal to C performance for some major mathematical benchmarks, I had no hesitation in switching. I have found no disadvantage. Why this 'anything-but-Java' attitude? Why try and push people to anything else - OCaml, LISP and so on? There is no other language that has the combination of performance, portability, support and tools. It is far from the best language I have ever used, but it is a good general-purpose solution.
  113. Re: Black Hole's and "innovation"[ Go to top ]

    BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)
    It will be interesting to follow this - the big step will to get the thing cross-platform. I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!
  114. Re: Black Hole's and "innovation"[ Go to top ]

    BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)


    It will be interesting to follow this - the big step will to get the thing cross-platform.

    I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!
    You may not have noticed but Strongtak is Smalltalk. Like I said make your specific point, or get back on topic. Paul.
  115. Re: Black Hole's and "innovation"[ Go to top ]

    BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)


    It will be interesting to follow this - the big step will to get the thing cross-platform.

    I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!

    You may not have noticed but Strongtak is Smalltalk. Like I said make your specific point, or get back on topic.

    Paul.
    My point is that StrongTalk was implemented because of performance and other issues with conventional Smalltalk implementations.
  116. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve, I'm not sure what is your point. Are you saying that a dynamic langauge is likey to be slower then a statically type language? Well if so the answer is yes. Are you saying that historically performance has been an issue for Smalltalk? Given that we are talking about processors of the late eighties and early nineties, again the asnwer is yes. Is any of this a reason why we should not use dynamic languages in the future and in 10 years we will all come running back to static languages? The answer to this one is an infatic no! Sorry about being impolite, but what is your point:
    My point is that StrongTalk was implemented because of performance and other issues with conventional Smalltalk implementations.
    Really? Sorry I thought it was performance, no I mean namespaces, woops what I really meant to say was open classes, oh yes I've got it now, static typing. You are not making a lot of sense :^). Paul.
  117. Re: Black Hole's and "innovation"[ Go to top ]

    Hi Steve,

    I'm not sure what is your point. Are you saying that a dynamic langauge is likey to be slower then a statically type language? Well if so the answer is yes.

    Are you saying that historically performance has been an issue for Smalltalk? Given that we are talking about processors of the late eighties and early nineties, again the asnwer is yes.
    I think that performance issues tend to be relative. Unfortunately, as computing performance increases over the years, so do the demands we put on applications! Today we handle volumes and types of data that would have been unimaginable 20 years ago. 20% the speed of C was considered slow decades ago, and it is still slow these days, even though that 20% is orders of magnitude faster than decades ago! Speed matters. For example, I am currently implementing a data loading and transformation application. It takes about 45 minutes to run. This is just about acceptable, but if implemented in a dynamic language with poorer performance, it could take hours, which would certainly not be.
    Is any of this a reason why we should not use dynamic languages in the future and in 10 years we will all come running back to static languages? The answer to this one is an infatic no!
    I don't think I put this point across well. The thing is, that I see a huge (and understandable) amount of enthusiasm for dynamic languages right now. But that enthusiasm is usually not tempered by a realisation that dynamic languages can have issues, and I read the exactly the same (in my view extreme) claims made for dynamic languages now that were made decades ago. Whether my views are correct or not, what really concerns me is the way so much debate is happening as if the experiences of so many developers over decades never happened! For example, I read again and again in articles and blogs the view that static typing has few benefits. This completely ignores a substantial body of research and work over a long period to introduce static typing into languages like Smalltalk. This work was not pointless! It was done for good reasons, but how many developers know of this work, and the reasons behind it? The sad fact is, that we are having debates today over issues that were, at least to some degree, settled long ago. I don't mean to imply that dynamic languages will be abandoned years from now! But, it would not surprise me if I read an article which suggested adding some sort of type information to Ruby to help with performance :)
    Really? Sorry I thought it was performance, no I mean namespaces, woops what I really meant to say was open classes, oh yes I've got it now, static typing.

    You are not making a lot of sense :^).

    Paul.
    I mentioned namespaces because I believe that Ruby's open classes, although incredibly powerful, will inevitably lead to the same issues of method conflicts (in sufficiently large and complex codebases) as happened with Smalltalk. The issues of static typing and performance, and why these drove the development of StrongTalk are been discussed in detail on the StrongTalk site.
  118. Re: Black Hole's and "innovation"[ Go to top ]

    Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management.


    Ok, here's another theory. There's this "Black Hole" theory Gosling was talking about recently:

    http://blogs.sun.com/jag/entry/the_black_hole_theory_of

    Goes something like this: "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". (quoted above)

    I have another theory. There are some fairly cool programming languages. They do some very cool things. But people have a hard time grasping them. For example, most people only see parentheses when they see LISP, they can't get past the syntax. And Smalltalk is just weird.. and way too touchy feely (see Squeak for example).

    So people tend to take the safe road. C++ was ok because it was just enhanced C. Java was ok, because we needed the sandbox (originally), the portability and it was a lot like C++ in syntax. Yet Java allowed us to reach a much larger potential than C++ did. It helped us see some of the cool features of Smalltalk and Self that we'd previously dismissed as weird.

    Now comes Ruby.. an language that is almost a replica of Smalltalk (minus the environment, minus the same level of cleanliness, minus the baby look, etc..). Ruby allows us to see the advantages of that older language.. so interest builds up and we get all excited about this "innovation".

    20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
    +1 Hi Amin, Just found the ParcPlace scuicide letter I mentioned earlier: http://www.parcplace.com/whatsnew/letter_r.htm I like the black hole analogy. Despite our best efforts to "dumb down", Smalltalk and Lisp still live on in a number of guises. I agree with Gosling we are living through interesting times. What happens over the next year or two will be very interesting to watch. Paul.
  119. Portability[ Go to top ]

    This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly. But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.
  120. Re: Portability[ Go to top ]

    This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly.
    The JRuby developers seem to be strongly emphasising compatibility, so I don't think this is going to be much of a worry.
    But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.
    see JSR 292.
  121. Re: Portability[ Go to top ]

    This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly.


    The JRuby developers seem to be strongly emphasising compatibility, so I don't think this is going to be much of a worry.

    But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.


    see JSR 292.
    Well, one of the advantages of JRuby (over Plain Ole Ruby - POoR) is that is can use Java libs (I know you've said this). The same is true of .Net versions of Languages. The purpose is not to have Perl or Java or Python or VB or... running in the CLR, but to have a syntax people are familiar with running in the CLR and thus can use other things written to that spec. Trying to use that code outside of .Net will be pretty difficult. Unless, of course, one avoids all the advantages of .Net.
  122. Re: Portability[ Go to top ]

    Well, one of the advantages of JRuby (over Plain Ole Ruby - POoR) is that is can use Java libs (I know you've said this). The same is true of .Net versions of Languages. The purpose is not to have Perl or Java or Python or VB or... running in the CLR, but to have a syntax people are familiar with running in the CLR and thus can use other things written to that spec. Trying to use that code outside of .Net will be pretty difficult. Unless, of course, one avoids all the advantages of .Net.
    I think this could be the downfall of multi-platform dynamic languages. IMO, one of the big weaknesses of today's popular dynamic languages is that so many of the libraries are written in C or C++ instead of in the language itself. This works because there is a single C/C++ codebase, but I think once ports to platforms like the JVM and CLR that promise huge high-quality libraries. The problem is once the developer starts using those libraries he is locked into a platform. So instead of having a Ruby developer, you have JRuby developer and a CRuby developer and a Ruby.NET developer. Let's face it - learning the syntax of most languages isn't that hard. It's learning the libraries. If a language doesn't have a big set of quality libraries that are the same on every platform, then it isn't a single language. This is even more true with dynamic languages. For example, unlike Ruby, Python does not support multiple class definitions for the same class (meaning define part of it one place, then some more in another, etc). However, it's relatively easy to add such support using metaclasses by overloading __new__ to find the existing metaclass object instead of allocating a new one. Consequently, you can have a library containing a metaclass that does something that looks a lot like a language feature. IMHO, this is the principle strength of dynamic languages - the line between language and library is thin and grey. Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
  123. Re: Portability[ Go to top ]

    I think this could be the downfall of multi-platform dynamic languages.

    IMO, one of the big weaknesses of today's popular dynamic languages is that so many of the libraries are written in C or C++ instead of in the language itself. This works because there is a single C/C++ codebase, but I think once ports to platforms like the JVM and CLR that promise huge high-quality libraries. The problem is once the developer starts using those libraries he is locked into a platform.

    So instead of having a Ruby developer, you have JRuby developer and a CRuby developer and a Ruby.NET developer.

    Let's face it - learning the syntax of most languages isn't that hard. It's learning the libraries. If a language doesn't have a big set of quality libraries that are the same on every platform, then it isn't a single language. This is even more true with dynamic languages.

    For example, unlike Ruby, Python does not support multiple class definitions for the same class (meaning define part of it one place, then some more in another, etc). However, it's relatively easy to add such support using metaclasses by overloading __new__ to find the existing metaclass object instead of allocating a new one. Consequently, you can have a library containing a metaclass that does something that looks a lot like a language feature.

    IMHO, this is the principle strength of dynamic languages - the line between language and library is thin and grey.

    Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
    I have been following the development of JRuby for some time, and my impression is that the developers are after as full an implementation of the core libraries as possible, and are working with the developers of many C-based libraries to get Java ports. The aim is for C-based Ruby applications to run unchanged on the JVM. It looks, at least for now, like JRuby and Ruby should share the set of quality libraries that you suggest is needed to avoid incompatibility.
  124. Re: Portability[ Go to top ]

    Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
    Hi Erik, You make a good point, but I don't believe library compatibility should be the single overriding concern. Ofcourse the language should be standard on all platforms and the languages standard library should be standard too, but beyond that I see no problem with libraries that start out on one platfrom (VM) or the other. Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby? Secoundly, I would agree with you if the libraries we are using today where stable and likely to last any decent length of time. In the last 10 years if I was interested in a container based persistence API for Java, I would have probably started with EJB2.1 or Toplink or perhaps plain JDBC and DTO's, maybe then moving on to JDO1.0 or maybe JDO2.0 or maybe Castor then perhaps to Hibernate and ultimately today I would be looking at JPA. And this is something as basic as persitence. These things aren't stable and are likely to last only a few years at most before being superceeded. This is the nature of the sofware industry, it is still very immature and we have very few "stable" standards. I've come to the view over the years that experimentation and exploration and finding the best tool for the job is more important both in the short term and the long term then compatibility and standards. Projects where they have made good technology choices by perhaps initially experimenting with a few tools before settling on something that works well for them, in my experience tend to be much easier to maintain, also they tend to be much easier to upgrade or interface to newer technology and in that way are longer lived. Scenarios where people have just used the latest standard whether or not it is well suited, tend to lead to poor code that is short lived (shorter lived then the standard used) and expensive to produce in the first place and then to maintain, leading to a short life before being re-written. In time if an approach is successful it is more than likely to turn up on all platforms as a defacto standard. I think things like Hibernate and Spring are good examples of this. Just an opinion, although somewhat contrary :^) Paul.
  125. Re: Portability[ Go to top ]

    Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
    (emphasis mine) Does it work well for C++? How long did it take? How much angst must C++ programmers go through in order to achieve portable code? Don't get me wrong - C++ has been and remains an enormously successful language. But I think much of Java's success has nothing to do with using a VM or having a GC or being "binary compatible" across operating systems and processor architectures as it does with having a rich standard library that is the same (or close enough) across platforms. In earlier years even implementation of core language features varied widely. IMHO, Java and C# are "beating" C++ not because they are based on superior languages or technologies, but because they are not fragmented. Preventing fragmentation stifles innovation, but excess fragmentation has the same effect. Take a look at strings in C++. How many C++ libraries are there out there that instead of using standard C++ strings, use their own implementation or simply use C-strings? Do you know what happens when two libraries that use two incompatible string-class implementations have to interact? They use C-strings instead. The have to use the lowest common denominator. So with Java we have frameworks that are hodge-podges of countless opensource libraries. Do you think that would be a pragmatic thing to do if every one included it's own custom string class? Sometimes you just need to standarize, and consistently enforce the standard, even if that standard isn't going to be perfect. Otherwise people constantly reinvent the wheel.
  126. Re: Portability[ Go to top ]

    Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?


    (emphasis mine)

    Does it work well for C++? How long did it take? How much angst must C++ programmers go through in order to achieve portable code?

    Don't get me wrong - C++ has been and remains an enormously successful language. But I think much of Java's success has nothing to do with using a VM or having a GC or being "binary compatible" across operating systems and processor architectures as it does with having a rich standard library that is the same (or close enough) across platforms. In earlier years even implementation of core language features varied widely.

    IMHO, Java and C# are "beating" C++ not because they are based on superior languages or technologies, but because they are not fragmented.

    Preventing fragmentation stifles innovation, but excess fragmentation has the same effect. Take a look at strings in C++. How many C++ libraries are there out there that instead of using standard C++ strings, use their own implementation or simply use C-strings? Do you know what happens when two libraries that use two incompatible string-class implementations have to interact? They use C-strings instead. The have to use the lowest common denominator.

    So with Java we have frameworks that are hodge-podges of countless opensource libraries. Do you think that would be a pragmatic thing to do if every one included it's own custom string class?

    Sometimes you just need to standarize, and consistently enforce the standard, even if that standard isn't going to be perfect. Otherwise people constantly reinvent the wheel.
    Hi Erik, What you say just isn't born out in my experience. I've written several bits of software in C++ using MS Visual C++, that I then ran on Unix, with nothing more than a recompile. If you write portable code (stick to cross platform API's like POSIX for instance) then you're fine. I tend to hold library programmers to a higher standard then application programmers and I think that portable libraries are well within their grasp. As for having to use the lowest common denominator for compatibility, well we have that today - look at web services :^). But seriously, the number of conflicting and incompatible Java API's are tremendous, for example JDO versus EJB, or PicoContainer versus Spring, and having to swap from one API to the next each time you move to a new project is a tremendous overhead. With the proliferation of further so called standard API's that you need to know, I see things just getting worst. My CV as already got enough TLAs to fill a page as it is :^). I don't think that cross platform language support will make things any better or any worst then they are today for application programmers. Granted library and framework programmers will have a little more work to do, but it's warranted IMO. Paul.
  127. Re: Portability[ Go to top ]

    What you say just isn't born out in my experience. I've written several bits of software in C++ using MS Visual C++, that I then ran on Unix, with nothing more than a recompile. If you write portable code (stick to cross platform API's like POSIX for instance) then you're fine.
    (emphasis mine) I've done the same and had the same experience. I've also tried to do the same and had awful experiences. It depends on the Unix, the compiler, and the libraries (although all my awful experiences have involved HP's C++ compiler on HP-UX...) Experience with code written by other people (especially ones long gone) and 3rd parties has been worse. The huge quantity of portable open-source C++ software out there proves that it can be done with a little discipline. The problem is often times that's more discipline than can be obtained...especially when "cross platform" isn't an immediate requirement. I'm not really worried about libraries and frameworks high up on the stack. The problem is difference in fundamental language constructs. Java and Python have immutable standard strings. C++ and Ruby have mutable standard strings. There's differences in standard containers and iterators as well. Sure, these differences can be hidden. But I think at the end of the day people programming Ruby-on-JVM and leveraging Java libraries/frameworks just start using the native strings/containers/etc. Ditto for .NET.
    I don't think that cross platform language support will make things any better or any worst then they are today for application programmers. Granted library and framework programmers will have a little more work to do, but it's warranted IMO.
    It will probably make it better for application programmers in the short term, but in my opinion in may delay progress by creating confusion. You'll get a lot of people calling themselves Ruby developers who are really JRuby developers, or vice versa. That dillutes the meaning of the term, and makes managers think Ruby isn't a real skill. I personally think dynamic languages for the JVM should be designed from the ground-up for the JVM with other dynamic languages as inspiration, rather than simply porting the languages. The ideas behind the languages are far more important than the languages themselves, so there is no point in introducing a bunch of impendance mismatches in the name of porting the languages. Anyway, that's just my opinion right now.
  128. Re: Portability[ Go to top ]

    It will probably make it better for application programmers in the short term, but in my opinion in may delay progress by creating confusion. You'll get a lot of people calling themselves Ruby developers who are really JRuby developers, or vice versa. That dillutes the meaning of the term, and makes managers think Ruby isn't a real skill.
    Hi Erik, I see your point. One way around this would be to get the compiler to enforce the use of the standard library or at least provide a warning. So for example if you use an Integer in JRuby code instead of using a Fixnum then the compiler should complain. After all this is just as inappropriate as a syntax error. IMO the language standard is the syntax, and the associated semantics and the standard library. Otherwise like you say you are just not writing Ruby.
    I personally think dynamic languages for the JVM should be designed from the ground-up for the JVM with other dynamic languages as inspiration, rather than simply porting the languages. The ideas behind the languages are far more important than the languages themselves, so there is no point in introducing a bunch of impendance mismatches in the name of porting the languages.
    I've got my concerns with bolting on dynamic behaviour to an otherwise static environment. If you go through the gang of four design patterns you will see that most of them are language (C++ like) specific. For example things like Iterators just do not exist in Smalltalk, and what is the use of a factory pattern when every class is an object with the instance method new? I can see this problem occuring in Java 1.7 when closures finally arrive. How long will it take for some one to write a Smalltalk style collections API using closures? And with closures what is the point of an inner class based API like Swing? New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy. But like you I could change my mind in time :^) Paul.
  129. Re: Portability[ Go to top ]

    Otherwise like you say you are just not writing Ruby.
    Which is the case of all the "languages" available for .Net (or the CLR).
  130. Re: Portability[ Go to top ]

    Otherwise like you say you are just not writing Ruby.

    Which is the case of all the "languages" available for .Net (or the CLR).
    It looks like JRuby has achieved a lttle better than this. As I understand it just from reading the docs on the website they map standard Java types to ruby and visa-versa:
    ...conversions are automatically done for numbers, booleans and strings, both to and from Java. However, it does *not* convert collection and array types like the old Java support did.
    Not sure why they stopped converting collections and arrays. This type of mapping seems analogous to what you get with CORBA and IDL when calling across languages. I guess the platform would need to define a set of standard types and each language binding would need to define the appropriate mapping, just like CORBA (not sure what this would do to performance!). It is definately an issue that needs to be addressed before a VM can claim cross language support IMO. It's interesting that .NET doesn't bother. Paul.
  131. Re: Portability[ Go to top ]

    New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy.
    But that would be completely pointless for Groovy, as the whole idea of the language is to provide scripting for existing Java libraries and classes. If you added new libraries you would end up with the same issues that JRuby is having to deal with; it would defeat the purpose of the Groovy language. Having used Groovy for a while, I really can't see any issues with the way it works with existing Java libraries. What specific issues have you come across?
  132. Re: Portability[ Go to top ]

    What specific issues have you come across?
    Hi Steve, I'm still open minded. I haven't used Groovy, and I guess it comes down to what you're looking for in a dynamic language. For me meta-facilities and DSLs are key. So the idea of using a dynamic language with the same old static libraries and frameworks doesn't appeal. I can see the general appeal though. Using Groovy to dynamicaly knit together Java code has got to be better then using XML. I guess if a compelling use case emerges then I'll pay more attention, but at the moment Groovy is not high on my list of technologies to watch. Paul.
  133. Re: Portability[ Go to top ]

    What specific issues have you come across?


    Hi Steve,

    I'm still open minded. I haven't used Groovy, and I guess it comes down to what you're looking for in a dynamic language. For me meta-facilities and DSLs are key. So the idea of using a dynamic language with the same old static libraries and frameworks doesn't appeal. I can see the general appeal though. Using Groovy to dynamicaly knit together Java code has got to be better then using XML.

    I guess if a compelling use case emerges then I'll pay more attention, but at the moment Groovy is not high on my list of technologies to watch.

    Paul.
    If you looked at Groovy you would sould see that it has meta-facilities and the ability to develop DSLs, pretty much like Ruby (with especially nice things like the builder syntax). Such capabilities are what makes things like Grails dynamic methods possible. This means you aren't using 'the same old static libraries and frameworks' - you can take innovative new approaches. Even a quick look at Grails (and especially GORM) will reveal a dramatically different way of working from static Java. It is far more than just a dynamic language with a few syntax enhacements sitting above Java libraries, and my view is that an understanding of what is available on the JVM is incomplete without at least some knowledge of Groovy.
  134. Re: Portability[ Go to top ]

    Hi Steve, Grails (and especially GORM) will reveal a dramatically different way of working from static Java. Tanks for the pointer. Paul.
  135. Re: Portability[ Go to top ]

    Hi Steve,

    Grails (and especially GORM) will reveal a dramatically different way of working from static Java.


    Tanks for the pointer.

    Paul.
    I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
  136. Re: Portability[ Go to top ]

    I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
    It's seemingly conflicting actions like this that worry me most about Sun. Now, 2 guys working on JRuby isn't exactly a major investment. How many people work on Java? But it's not really clear how it fits into the big picture.
  137. Re: Portability[ Go to top ]

    It's seemingly conflicting actions like this that worry me most about Sun. Now, 2 guys working on JRuby isn't exactly a major investment. How many people work on Java? But it's not really clear how it fits into the big picture.
    Also, I read Tim Bray talk about "integrating Rails into existing Java frameworks and applications". My reaction is.... What does that mean? It makes no sense to me at all... Rails is targetted at a specific niche, and as far as I can tell, intends to remain there. Quite how it is supposed to be integrated with more enterprise-based Java approaches, and what the point of is this puzzles me greatly. For we have (in my view) far better persistence frameworks in Java, such as JDO 2.0 and JPA - faster, more portable and more scalable. I would imagine a JRuby framework that integrates with those might be theoretically possible (although I get a headache trying to think about it), but that would not be Rails by any stretch of the imagination. And, this is the sort of thing Groovy was designed for from the ground up. I can at least see the point of trying to make the JVM a good platform for RoR. I can also see uses for Ruby as an alternative language on the JVM, but the above statement makes no sense to me at all..
  138. Re: Portability[ Go to top ]

    And, this is the sort of thing Groovy was designed for from the ground up.
    I can't believe someone actually used "Groovy" and "design" in the same sentence, without the latter being preceeded by strong, ferm negation or pointing out lack thereof.
  139. Re: Portability[ Go to top ]

    It seems to me to give developers an odd choice - pick a JSR >language with seamless integration with Java and libraries OR >pick a language with far less integration, some conflicting >classes that require work-arounds, but is funded by Sun. >Hmm..
    Your argument is based on the idea that compatibility with Java is some sort of goal for any new language it's not. Java has its uses, but its not a universal solution for every problem.
  140. Re: Portability[ Go to top ]

    >It seems to me to give developers an odd choice - pick a JSR >language with seamless integration with Java and libraries OR >pick a language with far less integration, some conflicting >classes that require work-arounds, but is funded by Sun. >Hmm..

    Your argument is based on the idea that compatibility with Java is some sort of goal for any new language it's not. Java has its uses, but its not a universal solution for every problem.
    I may not have been clear. I am not trying to say that - I can see uses for languages on the JVM that don't have Java compatibility; but my understaning of what Tim Bray has said is Sun is positioning JRuby as a language that will have compatibility and integration with Java. That is what is confuses me, as there are better solutions for that role.
  141. Re: Portability[ Go to top ]

    I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
    RoR is hyped (the net effect) over the past year or so by TSS and other Java sites, IronPython 1.0 gets released, and a day or two later the JRuby guys are hired by Sun. There's been quite a bit of grumbling on the groovy-dev list over the past few days about a lack of funding from Sun.
  142. Re: Portability[ Go to top ]

    I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..


    RoR is hyped (the net effect) over the past year or so by TSS and other Java sites, IronPython 1.0 gets released, and a day or two later the JRuby guys are hired by Sun.

    There's been quite a bit of grumbling on the groovy-dev list over the past few days about a lack of funding from Sun.
    Indeed. Quite understandable grumbling, in my view. The more I think about the promotion of JRuby, the more it seems to be purely a marketing decision and not a decision based on technical merit. The JRuby guys have done a great job, but for Sun to position JRuby as a real alternative to Groovy is seriously misjudged, and does not do justice to the work put into Groovy by many developers over the years.
  143. Re: Portability[ Go to top ]

    Paul,
    I see your point. One way around this would be to get the compiler to enforce the use of the standard library or at least provide a warning. So for example if you use an Integer in JRuby code instead of using a Fixnum then the compiler should complain. After all this is just as inappropriate as a syntax error. IMO the language standard is the syntax, and the associated semantics and the standard library.
    Ahhh, we agree now on the importance of the relationship between the library on the language. I suspect we always did, it was just a matter of communication. However, I think we disagree on the importance of the library.
    I've got my concerns with bolting on dynamic behaviour to an otherwise static environment.
    Rightly so. I think the JVM needs to evolve to support dynamic languages (e.g. invokedynamic) and I'm sure the standard library does as well.
    If you go through the gang of four design patterns you will see that most of them are language (C++ like) specific.
    I agree on the surface, but I don't think this is really true. I think the GoF design patterns are more about using object orientation and polymorphism to effectively leverage indirection without creating a tangled mess. The way of thinking that goes into them is more important than the patterns themselves.
    what is the use of a factory pattern when every class is an object with the instance method new?
    Either you and I have a very different understanding of the factory pattern or I have no understanding of the Smalltalk class object instance method new.
    I can see this problem occuring in Java 1.7 when closures finally arrive.
    I personally hope they never arrive. I've long been opposed to keeping out language features for fear the will be abused, but I think I have to draw the line on closures. I'd rather see support for nested functions (ala Pascal) and better syntax for functors. If in wasn't for the breakage that would result I'd be fine with dropping anonynmous inner classes as well.
    New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy.
    I think this is a big "it depends." Throwing out all the Java libraries just doesn't seem like a good idea. They're not perfect - but they're huge. IMHO, they are more important than the Java language and the JVM. Java can be natively compiled. Java bytecode can be generated from other languages. But the libraries provide the unity of the platform. That's where I think the value is. But you're right - if a language deviates too far from Java conventions then it should not use Java's standard libraries. It should have it's own.
  144. Re: Portability[ Go to top ]

    Preventing fragmentation stifles innovation, but excess fragmentation has the same effect.
    Slightly off-topic, but you could almost say the same about Linux distributions. The fact that everyone and their grandmother has decided to do it "their" way, just annoys me to no end. If there were like 3 to 5 distributions (and no others), with perhaps varying philosophies between them, I believe Linux will have gained even more popularity on both, server and desktop, and people, instead of wasting braincells on making the "perfect" distroy, could be adding _functionality_, which is what sells - both in terms of profit and wide adoption. But then again,I assume everyone here knew that... Last thing we want is too much fragmentation of the Java platform.
  145. Re: Portability[ Go to top ]

    Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
    I must be misunderstanding. Hibernate and NHibernate have completely different codebases. Or, are you simply describing the Utopia that would exist if things changed such that they could use the same codebase?
  146. Re: Portability[ Go to top ]

    Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?

    I must be misunderstanding. Hibernate and NHibernate have completely different codebases. Or, are you simply describing the Utopia that would exist if things changed such that they could use the same codebase?
    Yeap, I realised this mistake after I posted, but I'm sure you get the idea. Successful API's tend to find their way onto all the leading platforms, whether through re-implementation or simply through porting. Paul.
  147. Re: Portability[ Go to top ]

    Successful API's tend to find their way onto all the leading platforms, whether through re-implementation or simply through porting.

    Paul.
    I wish Hibernate 3+ would find its way.
  148. Re: Sun Hires the JRuby-guys[ Go to top ]

    In early 1995, I had a meeting with Eric Schmidt who was then the CTO of Sun. He had encouraged us (Documentum) to develop our web solutions on TCL, since this was Sun's official scripting language at the time. Vignette and Interwoven followed that same advise to their peril. It wasn't long before Sun changed course toward Java. In the end, the language that wins will win through Darwinian forces. Even though Sun backs something now, doesn't mean that something else might not win in the future. Java had the momentum over TCL. Ruby might have momentum over Groovy, jython, etc. It does if you ask O'Reilley.
  149. Re: Sun Hires the JRuby-guys[ Go to top ]

    I think this is good news regardless of JRuby's long term success. It is good to get more corporate support and attention of the JVM being a reasonable host for multi-languages. * Siphons a bit off .NETs main marketing points * Will help to lift all boats (Jython, Groovy, BeanShell, ...) * Will be a decent bridge for shops that support both platforms Good win for the Minneapolis team. ______________ George Coller DevilElephant
  150. Re: Sun Hires the JRuby-guys[ Go to top ]

    Ruby might have momentum over Groovy, jython, etc. It does if you ask O'Reilley.
    This is not the same situation. JRuby shows how Ruby can be used with Java, and even potentially with Groovy and Jython, not necessarily in place of these. This seems to me to be about opening up the JVM, not positioning Ruby against Groovy and other languages. Each of these languages has their roles. No matter how well implemented, JRuby will never be able to have the seamless integration with Java that Groovy was designed for. Also, a change of language emphasis by Sun did not mean that TCL vanished - far from it. It is a well-supported language. In fact, there is even an implementation for the JVM.
  151. Re: Sun Hires the JRuby-guys[ Go to top ]

    I'm very excited about this. I think this is one of the first steps in making Java a language for languages, in much the same way C is right now. It's just a natural progression in my mind. And of course I can wait until I can WAR up a Rails app and deploy it to Tomcat ;)
  152. Re: Sun Hires the JRuby-guys[ Go to top ]

    I'm very excited about this. I think this is one of the first steps in making Java a language for languages, in much the same way C is right now. It's just a natural progression in my mind.

    And of course I can wait until I can WAR up a Rails app and deploy it to Tomcat ;)
    +1
  153. Re: Sun Hires the JRuby-guys[ Go to top ]

    How about Groovy? It seems they are dead... :(
  154. Re: Sun Hires the JRuby-guys[ Go to top ]

    How about Groovy? It seems they are dead... :(
    I think groovy will ulitimately be a more useful choice than ruby or jruby. Groovy offers many of the same elegent dynamic OO syntax improvements that ruby offers. However, it's objects are "true" java objects. They compile to bytecode, support seamless integration with java bytecode, support interfaces, abstract classes, etc... With ruby you will have java implementations of the ruby class libraries that compete with equivalent functionlality implemented by the java libraries. Considerer something like grails, the groovy counterpart to rails. It uses spring and hibernate behind the scenes. This means that groovy progress is measured solely by the implementation of the syntax, not by class library development (because there are none!). Once the syntax becomes stable, it will be immediately useful to code to java libraries you already know. Until then, it's risky. This sort of all-or-nothing aspect to groovy has caused a number of people to (correctly) assess it's current usability as "nothing" and to (incorrectly) bash it, proclaim it as dead on arrival, etc... Hogwash!! The moment the syntax is stable it will toggle from "nothing" to "all". So, how is this progress? Well, it's slow but steady. As of this moment, groovy is down to 7 jira issues that are "blockers" before release candidate 1 rolls out. So no, groovy is not dead. My guess is that 3 or 4 RC releases will happen and then 1.0 will hit. A year from now there will be a lot of excitement about groovy as people realize that 1) it exists and they can use it without porting anything and 2) it's interoperability with the volumes of java class libraries gives it an undeniable advantage over ruby.
  155. Re: Sun Hires the JRuby-guys[ Go to top ]

    A year from now there will be a lot of excitement about groovy as people realize that 1) it exists and they can use it without porting anything and 2) it's interoperability with the volumes of java class libraries gives it an undeniable advantage over ruby.
    I agree. Also, I believe that as Grails progresses this will encourage far wider adoption of Groovy; the JVM should then have an alternative to Rails that is faster, easier to use with legacy systems, and unlike the 'opinionated' approach of Rails, works well in 'enterprise' environments as well as for smaller, 'greenfield' projects.
  156. Perhaps the Ruby guys needed a java job:)
  157. Perhaps the Ruby guys needed a java job:)
    I doubt it. I don't understand all the negativity toward Ruby here. Is it fear? Java will be a success for many years to come. In just the way C++ is still a success , Java will be too, if a popular "rival" language takes off. Java itself hasn't taken everything away from C++, there are still many problem areas (e.g. finance anlytics) that will be dominated by C++, thats not to say Java is poor. Languages should be used when they're the right tool for the job. A few years ago you couldn't move for the number of projects 'done' with EJB - even if EJB were a poor solution for that particular problem. People learnt they're lessons. To suggest some coders are poor b/c they've a personal preference over Java , or C++, or Ruby ... is plain ridiculous.