Beyond Java but not the Virtual Machine

Home

News: Beyond Java but not the Virtual Machine

  1. Beyond Java but not the Virtual Machine (100 messages)

    In his blog, John Reynolds make a short but sweet case as to why we should not abandon the JVM. This argument is further strengthened by Brian Goetz in this article on how Mustang (JSE 6.0) is being tooled to better optimize locking.

    In addition to the technical information, the article contains a few very astute observations such as “An optimization like this would not be possible in a statically compiled environment because the information about lock usage patterns is not available at static compilation time”.

    Is it time really time to look beyond Java and should the JVM be better equipped to handle languages such as JRuby or is Java providing the development community with what it needs to get the job done?

    Threaded Messages (100)

  2. In his blog, John Reynolds make a short but sweat case as to why we should not abandon the JVM.

    I'm not too sure I want to click on that link!
  3. How times have changed[ Go to top ]

    Interesting to see the general response. Especially on a Java based forum. I tried Smalltalk back in 93 (tried to learn OO with C++ and failed miserably, with Smalltalk it all made sense), and I knew then that I'd glimpsed the future. Looks like CPU power has finally caught up.

    We need higher abstraction, and we need late binding. We need message protocols seperate from class implementation. Bye bye static typing, bye bye non OO constructs. Hello block closures, duck typing, continuations etc.

    The interesting thing is that with .NET(Mono) you can use any language you like: Ruby, Smalltalk, Python and even Java.

    Why pay for EJB3 when Hibernate and Spring are out there for free? If the open source community where now to focus on .NET(Mono) and get the CLR to be truly language independent, then developers would be free to use the best language for the job whatever that might be. Not sure if this is in Suns plans for the future of the Java VM.
  4. How times have changed[ Go to top ]

    Why pay for EJB3 when Hibernate and Spring are out there for free? .

    There are two Spring uses:
    - Spring becomes ‘UberContainer’;
    - Spring works within a container;
    Spring is glue, Spring does not provide anything on its own (except Spring MVC), it needs implementations for everything: persistence, JMS, cache, and so on and so forth.
    Therefore if a container, product, package, really does not matter how we call it, provides us with necessary set of functionalities to glue them together with Spring – then it might make sense to buy it.

    It is like buying kit instead of buying all the parts separately.



    And by the way I heard that EJB3 cost is $0 in products like JBoss :)
  5. Spring is glue, Spring does not provide anything on its own (except Spring MVC), it needs implementations for everything: persistence, JMS, cache, and so on and so forth.

    EJB also is a glue , a programming model . It does not provide anything on its own. EJB would use persitence , JMS , etc.
  6. EJB and Spring[ Go to top ]

    Are very similar in what they want to achieve, EJBs patters were clearly derived from webobjects. Provide business facades so that the programmer in the end has a huge set of those facades to build the entire business solutions. Sort of high level componentization. Unlike WebObjects EJB failed on the technical side, to complex, too much glue code, lousy orm layer etc...

    That the pattern works, and is adapted if there is a good implementation cannot be denied. Spring is the perfect example. It simply provided the same mechanisms as EJB, high level components under transactional scope, glue into an orm layer on the same level, and people jumped on it in masses.

    Now EJB3 is on the line we get a standard in exactly what Spring achieved (Spring has moved on into other areas since then, so there is no real thread to Spring which I really like). Good high level componentization, with even less glue code than Spring, good ORM layer which was built upon the experiences gathered in Toplink and Hibernate, good tools at the day has been started (jsr220 from Versant now under the Eclipse umbrella)

    and no forced container anymore thanks to the embedding libraries where already one free LGPL one exists, thanks to the JBoss people.
  7. I'll be very happy if we can achieve this one day... ;-)

    NEVER import org.springframework.*, org.jboss.*., org.otherstuff.*, com.othercompanies.*

    ALWAYS and ONLY import java.*, javax.*

    At least for beginners this is very helpful since you don't have too many choices, just like in the Microsoft world ;-) Many choices are good for experts but confused beginners, IMO.

    So your codes will only depends on specifications, in which many companies (incl. Open Source corsortiums and projects) are agreed upon. I know this is a MISSION IMPOSSIBLE! ;-) since new inventions cannot be suppressed by standards and specifications. Mostly everything will happen contrary:
    - Hibernate first -> EJB3 persistence later,
    - Spring IoC first -> EJB3 annotations later.

    EJB3 will remove the need of other external frameworks (no need to have EntityAdapter or SessionAdapter anymore, etc.) but some problems still exist in Java EE area. Example: how can you start your own service within an application server which should be portable to different application servers (JOnAS, JBoss, Geronimo, Weblogic, ...)? Sometimes you need to start e.g. an FTP server or a video conferencing server within you app server... I hope the new Java EE specification has already an answer on this topic.

    This story will have no end, since the technology is driven by the innovations. So we are playing "cat and mouse" here.

    A solution can *ONLY* be achieved (let's name it as "workaround" instead of solutíon) if you go one abstraction layer higher. At least later on you can change the implementation without too much trouble:
    - Agreed upon a DSL (DSL for web presentation layer, DSL for business service layer, DSL for business entity layer). For the example above we should agree on a DSL for defining a service within an application server.
    - Write the tranformation definitions to transform your models which use the DSL above to your chosen platforms: transformation definition for JOnAS service, for JBoss service, etc.
    - If you need to upgrade to a new platform you only need to write a new transformation definition. The model stays the same.

    With this workaround we can at least minimize the cost of rewriting the applications to use the new specifications and the "cat and mouse" game won't disturb us anymore ;-)

    Cheers,
    Lofi.
  8. ..- Agreed upon a DSL (DSL for web presentation layer, DSL for business service layer, DSL for business entity layer).

    Yes, DSLang-s (pronounced Dee-slang :: Domain-Slang) have bright future IMO especially when LanguageWorkbenches will reach maturity (it is not ‘if’ it is ‘when’) http://www.martinfowler.com/articles/languageWorkbench.html

    Paul Graham has
    an interesting article called Revenge of the Nerds
    (http://www.paulgraham.com/icad.html) that says:

    "If you look at these languages in order, Java, Perl, Python,
    you notice an interesting pattern. At least, you notice this
    pattern if you are a Lisp hacker. Each one is progressively
    more like Lisp."
  9. If you need to upgrade to a new platform you only need to write a new transformation definition. The model stays the same.With this workaround we can at least minimize the cost of rewriting the applications to use the new specifications and the "cat and mouse" game won't disturb us anymore ;-) Cheers,Lofi.

    It looks like this "workaround" is more expensive than "rewriting" :) but it is a cool idea.
  10. This means nothing[ Go to top ]

    I guess you think theres some magic about javax or whatever. Thats the antithesis of developing in Java.

    If you need a "net" (.net?) to catch you maybe you should use another tool. If you can't factor out behavior and hide implementation details maybe you should use C# so MS can be your saviour.

    There is no magic in a package there is no magic in software. Why not develop and maintain applications like the rest of us. EJB 9.0 wont save you either.

    Enough with being a Java slave. Use the language as you see fit. SUN has little to do with it.
  11. How times have changed[ Go to top ]

    Spring does not provide anything on its own (except Spring MVC), it needs implementations for everything: persistence, JMS, cache, and so on and so forth.

    That's not 100% true. Spring provides a great implementation of AOP which extends into declarative transaction management (which is what EJB was created for in the first place). The AOP can also team up with Acegi to provide an exellent security solution for your project. The reason Spring doesn't provide implementations for everything is because the philosophy of Spring is to give the developer as many options as possible.
  12. How times have changed[ Go to top ]

    Interesting to see the general response. Especially on a Java based forum. I tried Smalltalk back in 93 (tried to learn OO with C++ and failed miserably, with Smalltalk it all made sense), and I knew then that I'd glimpsed the future. Looks like CPU power has finally caught up.We need higher abstraction, and we need late binding. We need message protocols seperate from class implementation. Bye bye static typing, bye bye non OO constructs. Hello block closures, duck typing, continuations etc.The interesting thing is that with .NET(Mono) you can use any language you like: Ruby, Smalltalk, Python and even Java.

    Why pay for EJB3 when Hibernate and Spring are out there for free? If the open source community where now to focus on .NET(Mono) and get the CLR to be truly language independent, then developers would be free to use the best language for the job whatever that might be. Not sure if this is in Suns plans for the future of the Java VM.

    Java already has jruby, jython, beanshell, groovy, lisp, jelly and more. http://java-source.net/open-source/scripting-languages

    I don't think it's Sun's job to come up with new scripting languages for Java and fund the development. It's in Sun's interest to do so, but I think the best way to make things happen is write it yourself.

    peter
  13. If the open source community where now to focus on .NET(Mono) and get the CLR to be truly language independent, then developers would be free to use the best language for the job whatever that might be. Not sure if this is in Suns plans for the future of the Java VM.
    It doesn't need to be in Sun's plans, simple because it does happen today already:
    http://www.robert-tolksdorf.de/vmlanguages.html
  14. Good news, Frankly I don't care which VM it is, as long as I don't have a Vendor (or more importantly a Vendors marketing department) telling me which language I should be programming in.

    Java/J2EE in the end was about vendors making money and preventing Microsoft from stealing Market share in the Server Market. This may be good for IBM, Oracle, BEA, Sun et al. But it is not necessarily good news for me or for my clients in the long term.

    I want the freedom to write in any language I choose, and to use the best class libraries irrespective of the language they're written in.

    I don't expect the vendor community to deliver this. The only concerted effort out there that I can see offering me this possibility is Mono. If greater momentum for multiple language support occurs on the JVM, then so much the better.
  15. How times have changed - indeed[ Go to top ]

    The only concerted effort out there that I can see offering me this possibility is Mono. If greater momentum for multiple language support occurs on the JVM, then so much the better.

    As has already been pointed out, there is already greater multiple language support on the JVM. The Mono website mentions around 14 languages. I have seen 22 mentioned for .NET.

    The URL already mentioned (http://www.robert-tolksdorf.de/vmlanguages.html) lists around 200 for the JVM, including the languages you mentioned - Ruby, Smalltalk, Python.You can even run C# and VB.NET! No vendor is dictating which of those languages you should be using. A large number of these 200 languages are open source. A large number of them give you access to Java classes and libraries, and compile to class libraries so they can be used from Java and other languages.

    The issue is not language support on Mono as such, as Mono simply allows .NET applications to run on a wider range of operating systems, so I am having trouble understanding why you are mentioning Mono in this context.
  16. How times have changed - indeed[ Go to top ]

    The only concerted effort out there that I can see offering me this possibility is Mono. If greater momentum for multiple language support occurs on the JVM, then so much the better.
    As has already been pointed out, there is already greater multiple language support on the JVM. The Mono website mentions around 14 languages. I have seen 22 mentioned for .NET.The URL already mentioned (http://www.robert-tolksdorf.de/vmlanguages.html) lists around 200 for the JVM, including the languages you mentioned - Ruby, Smalltalk, Python.You can even run C# and VB.NET! No vendor is dictating which of those languages you should be using. A large number of these 200 languages are open source. A large number of them give you access to Java classes and libraries, and compile to class libraries so they can be used from Java and other languages.The issue is not language support on Mono as such, as Mono simply allows .NET applications to run on a wider range of operating systems, so I am having trouble understanding why you are mentioning Mono in this context.

    if you count IKVM, Mono does support Java. not that it matches the number of languages available for JVM, but it's better than nothing. given that microsoft is the primary force pushing for other languages on their CLR, I doubt MS would attempt 100 different languages. that's one case where I think OSS clearly wins. but then again, I am totally bias in favor of OSS.

    peter
  17. How times have changed - indeed[ Go to top ]

    I'll spell it out. I'm not an evangalist for any VM. The only reason for mentioning Mono is to highlight the fact that Java doesn't have a monopoly on the VM concept. I could choose to mention any one of a number of VMs, for instance Squeak or VW Smalltalk. All these could possibly support multiple languages including Java.

    The other reason for mentioning .NET and Mono is that Microsoft has spent/is spending a lot of money marketing the CLR as a multi-language platform. No one is currently spending that kind of money marketing the JVMs multi-language support.

    Marketing counts. It is that simple.
  18. How times have changed - indeed[ Go to top ]

    I'll spell it out. I'm not an evangalist for any VM. The only reason for mentioning Mono is to highlight the fact that Java doesn't have a monopoly on the VM concept. I could choose to mention any one of a number of VMs, for instance Squeak or VW Smalltalk. All these could possibly support multiple languages including Java.

    The other reason for mentioning .NET and Mono is that Microsoft has spent/is spending a lot of money marketing the CLR as a multi-language platform. No one is currently spending that kind of money marketing the JVMs multi-language support.

    Marketing counts. It is that simple.

    Microsoft may hype multiple languages, but .NET doesn't have AntLR or JavaCC. It would be nice if Microsoft wrote something similar to AntLR and JavaCC.

    peter
  19. How times have changed - indeed[ Go to top ]

    Hi Peter,
    I'm not pro-Microsoft or pro-Sun as it happens. I'm a strong believer in open source like yourself. Vendors have used all kinds of devices to "look" developers in to their platform. With the advent of the VM developers have gained hardware and OS independence. Multi-language support will offer language and library independence too.

    The question is which VM should the OS community target as the open source platform of the future. It seems to me that the CLR has some advantages politically over the JVM. The most significant being that it is backed by an open standard: ECMA/ISO.

    http://www.mono-project.com/ECMA

    Also as I understand it both the JVM and the CLR suffer from technical difficulties when it comes to supporting dynamic languages. Now Microsoft seems to be more commited then Sun in addressing these limitations. Also Mono backed by Novell are committed to producing their own implementation of the CLR (against the ECMA/ISO spec)and porting it to a broad number of platforms. As I understand it JVM implementations must be licensed from Sun.

    This combined with the Marketing power of Microsoft, does make the CLR an attractive proposition.
  20. How times have changed - indeed[ Go to top ]

    .The question is which VM should the OS community target as the open source platform of the future.

    Why should there be a question? The OS community (whatever that is) is already targetting both. OS should be about choice.
    It seems to me that the CLR has some advantages politically over the JVM. The most significant being that it is backed by an open standard: ECMA/ISO.
    ....
    Also Mono backed by Novell are committed to producing their own implementation of the CLR (against the ECMA/ISO spec)

    Some inconsistency here, perhaps?
    As I understand it JVM implementations must be licensed from Sun.

    Only if they want to be labelled as 'Java'. In the same way that Mono can't be called '.NET'.

    The difference is that Sun is prepared to certify open-source non-Sun Java as 'Java'. Microsoft is extremely unlikely to certify Mono etc. as '.NET compatible'.

    There is a danger (I consider it an inevitability) that Mono and .NET will diverge. Then, the decision to base Mono on the CLR may look mistaken.
  21. How times have changed - indeed[ Go to top ]

    There is a danger (I consider it an inevitability) that Mono and .NET will diverge. Then, the decision to base Mono on the CLR may look mistaken.

    You make some good points. Thanks for clearing up the licensing thing. My biggest fear with Mono is the point you make above.

    But I don't trust Sun to make the JVM truly open to other languages either. As I understand it neither the CLR or the JVM support dynamic languages well. I just don't see Sun wanting to do this on the JVM, and perhaps any Open Sourced JVM based on the Sun JVM may ultimately end up diverging too.
  22. How times have changed - indeed[ Go to top ]

    Hi Peter,

    I'm not pro-Microsoft or pro-Sun as it happens. I'm a strong believer in open source like yourself. Vendors have used all kinds of devices to "look" developers in to their platform. With the advent of the VM developers have gained hardware and OS independence. Multi-language support will offer language and library independence too.

    The question is which VM should the OS community target as the open source platform of the future. It seems to me that the CLR has some advantages politically over the JVM. The most significant being that it is backed by an open standard: ECMA/ISO.http://www.mono-project.com/ECMAAlso as I understand it both the JVM and the CLR suffer from technical difficulties when it comes to supporting dynamic languages. Now Microsoft seems to be more commited then Sun in addressing these limitations. Also Mono backed by Novell are committed to producing their own implementation of the CLR (against the ECMA/ISO spec)and porting it to a broad number of platforms. As I understand it JVM implementations must be licensed from Sun.This combined with the Marketing power of Microsoft, does make the CLR an attractive proposition.

    Not sure I agree MS is more committed to dynamic languages. Microsoft research definitely is working in that area, but it's got a specific MS goal in mind. Understandably, Microsoft can't support 100 different languages on the CLR because it has implications on Visual Studios .NET.

    I think each developer should target the VM they want. I don't think supporting just one VM is good for the community. Sure there's duplication of effort, but there's several million programmers in the world. I work on open source stuff on both Java and .NET, so I prefer to support open source without locking myself to a single VM.

    my bias opinion. I'm sure there are plenty of people who disagree and say, "why not work together and all work on the same project?" That's fine for some people, but I prefer small groups. I have a love/hate relationship with open standards. some standards rock, while other ones suck. Whether something is an official standard doesn't make it better in my mind. At the end of the day, I program because I like to program and all the other political stuff is just noise :)

    peter lin
  23. Parrot; How times have changed - indeed[ Go to top ]

    Microsoft may hype multiple languages, but .NET doesn't have AntLR or JavaCC.
    Someone mentioned Ruby, earlier in this thread, and I just learnt that the Ruby community rejected both .NET CLR and the JVM. They picked Parrot (Perl6's VM), and Python community also interested in Parrot, open source freeware. Parrot supports continuations and closures. It was even said something about the JVM and CLR are too slow for scripting languages. So Ruby picked Perl's VM since "...the issue is one of speed." I never thought of HotSpot as slow.
  24. Maybe times haven't changed enough[ Go to top ]

    I tried Smalltalk back in 93 (tried to learn OO with C++ and failed miserably, with Smalltalk it all made sense), and I knew then that I'd glimpsed the future. Looks like CPU power has finally caught up.We need higher abstraction, and we need late binding. We need message protocols seperate from class implementation. Bye bye static typing, bye bye non OO constructs. Hello block closures, duck typing, continuations etc...

    The responses to my original post (above) seem to have missed the point. My main point is that freeing developers to use dynamic OO languages will improve what is currently possible in the web development space.

    This point seems to have been missed. Instead everyone has focused on my mentioning of .NET and Mono. The same old J2EE versus .NET debate. Times have changed and the VM is not the issue. The big issue now is dynamic versus static languages.
  25. Maybe times haven't changed enough[ Go to top ]

    The responses to my original post (above) seem to have missed the point. My main point is that freeing developers to use dynamic OO languages will improve what is currently possible in the web development space.This point seems to have been missed. Instead everyone has focused on my mentioning of .NET and Mono. The same old J2EE versus .NET debate. Times have changed and the VM is not the issue. The big issue now is dynamic versus static languages.

    Actually, I agree. But you were the one focussing on .NET/Mono vs Java, and making the VM an issue:
    The interesting thing is that with .NET(Mono) you can use any language you like: Ruby, Smalltalk, Python and even Java.

    Implying that you can't do this with Java.
    I want the freedom to write in any language I choose...The only concerted effort out there that I can see offering me this possibility is Mono.

    Implying you don't have the freedom to write in a wide range of languages on the JVM.

    You can use dynamic OO languages right now, on both Mono/.NET and the JVM. If you want a larger choice of such languages, go for the JVM. Further optimisation of these frameworks for a wide range of languages is not likely to happen, as both .NET and the JVM are designed at the core to run Java, C# and similar languages and Mono is attempting to track .NET. So the current situation is likely to be the best you are going to get.

    If there is some project to expand Mono beyond .NET in terms of it's support of dynamic languages I have not heard of it, and would be interested.
  26. Maybe times haven't changed enough[ Go to top ]

    I want the freedom to write in any language I choose...The only concerted effort out there that I can see offering me this possibility is Mono.
    Implying you don't have the freedom to write in a wide range of languages on the JVM.

    Fair dues, but I did say "the only concerted effort out there that I can see". Maybe I have been taken in by the .NET marketing machine. If so, then I won't be the only one. I will look into the cross language options available on the JVM as you suggest.

    Thanks.
  27. Maybe times haven't changed enough[ Go to top ]

    Fair dues, but I did say "the only concerted effort out there that I can see". Maybe I have been taken in by the .NET marketing machine. If so, then I won't be the only one. I will look into the cross language options available on the JVM as you suggest.Thanks.

    I have always thought that multiple-language marketing of .NET was always rather misleading. As I understand it, the CLR was designed primarily to support Java-style languages (primarily procedural with OOP). So, that is what you get: C#, J#, VB.NET. Any other type of language usually has to make compromises, either in terms of the language of performance. Here is a relevant blog entry:

    http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3279770893

    The same applies to the JVM.

    By the way, thanks for the debate. It has been interesting.
  28. As I understand it, the CLR was designed primarily to support Java-style languages (primarily procedural with OOP). So, that is what you get: C#, J#, VB.NET. Any other type of language usually has to make compromises, either in terms of the language of performance
    Will you stop spreading this misleading remark everywhere you go? I am following all your posts and this constant refrain to mirror everything coming out of MSFT as some kind of Sun-rip-off is getting really annoying. Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!

    BTW, its been proved once via IronPython that the CLR is indeed capable of supporting dynamic languages. Please read Jim Hugunin's paper before spouting yet another unsupported statement about how they have to make "compromises". Unless you can support this statement with facts I'd wish you stop misleading everyone in this forum.
  29. Maybe times haven't changed enough[ Go to top ]

    As I understand it, the CLR was designed primarily to support Java-style languages (primarily procedural with OOP). So, that is what you get: C#, J#, VB.NET. Any other type of language usually has to make compromises, either in terms of the language of performance

    Will you stop spreading this misleading remark everywhere you go? I am following all your posts and this constant refrain to mirror everything coming out of MSFT as some kind of Sun-rip-off is getting really annoying. Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!BTW, its been proved once via IronPython that the CLR is indeed capable of supporting dynamic languages. Please read Jim Hugunin's paper before spouting yet another unsupported statement about how they have to make "compromises". Unless you can support this statement with facts I'd wish you stop misleading everyone in this forum.

    even though I use .NET I have to say it wasn't always clear what .NET really meant. Regardless of what Microsoft says, I consider .NET a platform, which includes CLR, Visual Studios, Sql Server, Biztalk, IIS, VB, C# and C++. To me the CLR is basically equivalent to the JVM. Ignoring the obvious differences of course.

    peter
  30. Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!

    Dilip - you're on the wrong thread. This is the "Java people get defensive" thread. The ".NET people get defensive" thread is being hosted elsewhere.

    Peace,

    Cameron Purdy
    Tangosol Coherence: This space available.
  31. Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!
    Dilip - you're on the wrong thread. This is the "Java people get defensive" thread. The ".NET people get defensive" thread is being hosted elsewhere.
    IOW -- defensiveness is in, objectivity is out. I get it.
  32. As I understand it, the CLR was designed primarily to support Java-style languages (primarily procedural with OOP). So, that is what you get: C#, J#, VB.NET. Any other type of language usually has to make compromises, either in terms of the language of performance
    Will you stop spreading this misleading remark everywhere you go? I am following all your posts and this constant refrain to mirror everything coming out of MSFT as some kind of Sun-rip-off is getting really annoying.

    Calling C#, J# and VB.NET 'Java-Style' is not misleading. It is a fact, and has nothing to do with whether or not .NET is a 'Sun-rip-off'. All these languages are basically procedural with OOP in an Simula/Object Pascal sort of way.
    Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!

    I'm afraid this is common usage - even used correct or not. Microsoft admit to having fudged what '.NET' means. I think you are going to find a LOT of people tiresome.

    VB.NET is a language. Java is a language. To compare them is fair.
    BTW, its been proved once via IronPython that the CLR is indeed capable of supporting dynamic languages.

    That is not the point. It is matter of efficiency. Obviously both the CLR and the JVM (happy now?) are capable of supporting dynamic languages. The question is how easy this is to implement and how effective the result is.
    Please read Jim Hugunin's paper before spouting yet another unsupported statement about how they have to make "compromises".

    Running a wide range of types of language on any single processor instruction set involves "compromises"; this is a fact of life. Just because one extremely clever developer manages to get around such issues does not counteract this. You need to look beyond one language.

    Here is what Hugunin says (in http://www.python.org/pycon/dc2004/papers/9/):

    "I found the CLR to be a surprisingly good target for dynamic languages, or at least for the highly dynamic specific case of Python." (My emphasis)

    Others, working on other languages think differently:

    http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3279770893

    ".NET supports any language, so long as it ultimately behaves a lot like C#. Going back to our ObjectStudio plans - we've taken a good initial look at the platform, and our engineers have found a number of issues - any Smalltalk built on top of .NET is going to have to make a lot of compromises, because there are a lot of things you can't do:"

    This is a blog of someone who has been a world expert in Smalltalk for a very long time.

    Different dynamic languages have different requirements and features. What works for Python almost certainly won't work generally.
    Unless you can support this statement with facts I'd wish you stop misleading everyone in this forum.

    Hugunin has more to say (again, my emphasis):

    "However, implementing a dynamic language for the CLR is not a simple process. The CLR is primarily designed to support statically typed OO and procedural languages. Allowing a dynamic language to run well on this platform requires careful performance tuning and judicious use of the underlying CLR constructs."

    Which is basically what I have been saying all along.

    From what I have found out in this thread it looks like both Microsoft and Sun are working on adapting their runtimes to cut back on the need for tuning and fiddling.
  33. As I understand it, the CLR was designed primarily to support Java-style languages (primarily procedural with OOP). So, that is what you get: C#, J#, VB.NET. Any other type of language usually has to make compromises, either in terms of the language of performance
    Will you stop spreading this misleading remark everywhere you go?

    I agree with him. C# and Java have pretty much the same requirements from a runtime. Allowing for 'Turing Equivilence', languages like LISP, Scheme, Smalltalk,Ruby and Python have significantly different requirements to run efficiently.

    DOTNET introduced the concept of the 'skinable' language.

    Even the MS delivered dotnet language JScript compromises to support either
    a) Performance
    b) Javascript/ECMAScript compatabilty.

    Read the documentation on the jsc /fast switch for further info.

    Regardless Javascript prototype objects are not first class dot net citizens and cannot interop (be called by )with natively supported 'class' style objects. Classes are added to the JScript language ( which I think is in the new ECMA standard ), but they make the language look less like javascript and more like C#/Java, as do the restrictions imposed by the /fast+ switch.

      I am following all your posts and this constant refrain to mirror everything coming out of MSFT as some kind of Sun-rip-off is getting really annoying. Also please stop equating .NET with the JVM and VB.NET with Java -- its getting really tiresome. I have pointed out to a zillion times that .NET is a moniker for writing applications for the CLR which is the RUNTIME!BTW, its been proved once via IronPython that the CLR is indeed capable of supporting dynamic languages. Please read Jim Hugunin's paper before spouting yet another unsupported statement about how they have to make "compromises". Unless you can support this statement with facts I'd wish you stop misleading everyone in this forum.
  34. I entered this forum glad finally for an opportunity to debate the strengths and weaknesses of various programming languages for agile development, and web development in particular:
    We need higher abstraction, and we need late binding. We need message protocols seperate from class implementation. Bye bye static typing, bye bye non OO constructs. Hello block closures, duck typing, continuations etc.

    Instead I managed to get embroiled in a debate over the abilities of vendor specifc VMs (Sun vs Microsoft).
    As it stands today, vendors have got developers locked into either Java or C#. True multi-language support is the answer, not sure that the JVM or the CLR will be offering that anytime soon.

    So the lessons learned are:

    1. Don't mention .NET or the CLR on a Java forum
    2. If I want to move beyond "C with classes" style programming then forget the JVM and the CLR.
    3. If I choose Ruby as my agile language then use native Ruby with native Ruby libraries (RoR, Wee, etc.)
    4. If I choose Smalltalk as my agile language then use native Smalltalk (VW, Dolphin, Squeak, etc) and native Smalltalk libraries (Seaside, GLORP, etc).
    5. Cross language libraries are still a myth.

    If the level of this debate is anything to go by, then I don't believe that the Java Community is ready to move beyond a "C with Classes" view of the world. People are already voting with their feet and looking for enviroments that are more productive and more agile (and are not Java).

    The interesting thing about the J2EE vs .NET argument is that both environments have much in common. The least of which is that they share a common "C" heritage, and share all the same inherent limitations.

    Some of us want to move beyond "C with Classes" and its limitations, and experiment with programming concepts from the lisp language family, for example continuations.

    I mean languages like Smalltalk, Scheme, Lambda, and even Self from Sun Microsystems :^).

    Peace (and out).
  35. Don't mention .NET or the CLR on a Java forum

    No-one is stopping you doing this. However, if you state that Mono/.NET is actively moving towards dynamic language support, and that you don't see such movement in Java, it is not reasonable to expect not to be contradicted. My impression is that right now the CLR is better at dynamic language support, but there has (apparently) been a lot more interest in porting to the JVM, probably because of its cross-platform nature.
    If I want to move beyond "C with classes" style programming then forget the JVM and the CLR.

    Better tell that to those working on and using Smalltalk, LISP, Prolog, Python, Ruby etc. on both environments.
    5. Cross language libraries are still a myth.

    Except for the fact they are being used all the time in mixed language environments on the JVM and CLR.
    If the level of this debate is anything to go by, then I don't believe that the Java Community is ready to move beyond a "C with Classes" view of the world.

    I had assumed that the debate was amicable and interesting, even if you seem to persist in ignoring repeated posts that show conclusively that there is active work in this Java Community both outside and inside the JCP to incorporate dynamic languages, and that people are actually using dynamic languages on the JVM right now.
     
    People are already voting with their feet and looking for enviroments that are more productive and more agile (and are not Java).

    Sure, there is a lot of interest, but to generalise that there is some kind of a mass movement away from Java is a huge exaggeration.
    Some of us want to move beyond "C with Classes" and its limitations, and experiment with programming concepts from the lisp language family, for example continuations.

    No-one is stopping you doing this right now with the JVM or the CLR.

    Many of the 200 or so languages that run on the JVM include LISP implementations:

    SISC - a Scheme interpreter.
    HotScheme - the same.
    Kawa - yet another.

    As for continuations you may want to look at RIFE.
  36. .
    If the level of this debate is anything to go by, then I don't believe that the Java Community is ready to move beyond a "C with Classes" view of the world.
    I had assumed that the debate was amicable and interesting, even if you seem to persist in ignoring repeated posts that show conclusively that there is active work in this Java Community both outside and inside the JCP to incorporate dynamic languages, and that people are actually using dynamic languages on the JVM right now.  

    The "tone" of the debate has been amicable. I just think that the focus (the JVM) is the wrong one.

     I'll shut up now and allow others to have a say (I won't be as rude to suggest that you do the same :^)).

    Peace (and out)
  37. I entered this forum glad finally for an opportunity to debate the strengths and weaknesses of various programming languages for agile development, and web development in particular:
    We need higher abstraction, and we need late binding. We need message protocols seperate from class implementation. Bye bye static typing, bye bye non OO constructs. Hello block closures, duck typing, continuations etc.

    Instead I managed to get embroiled in a debate over the abilities of vendor specifc VMs (Sun vs Microsoft).
    As it stands today, vendors have got developers locked into either Java or C#. True multi-language support is the answer, not sure that the JVM or the CLR will be offering that anytime soon.

    So the lessons learned are:1. Don't mention .NET or the CLR on a Java forum2. If I want to move beyond "C with classes" style programming then forget the JVM and the CLR.3. If I choose Ruby as my agile language then use native Ruby with native Ruby libraries (RoR, Wee, etc.)4. If I choose Smalltalk as my agile language then use native Smalltalk (VW, Dolphin, Squeak, etc) and native Smalltalk libraries (Seaside, GLORP, etc).5. Cross language libraries are still a myth.If the level of this debate is anything to go by, then I don't believe that the Java Community is ready to move beyond a "C with Classes" view of the world. People are already voting with their feet and looking for enviroments that are more productive and more agile (and are not Java).

    The interesting thing about the J2EE vs .NET argument is that both environments have much in common. The least of which is that they share a common "C" heritage, and share all the same inherent limitations.Some of us want to move beyond "C with Classes" and its limitations, and experiment with programming concepts from the lisp language family, for example continuations. I mean languages like Smalltalk, Scheme, Lambda, and even Self from Sun Microsystems :^).

    Peace (and out).

    I don't agree the Java community isn't read to move on. Why should businesses move on? Forgetting platforms for a few minutes, the phrase "move on" gives me the impression of leaving something behind. I'm guessing you mean "move forward" to a better approach, while keeping the good bits that shouldn't be thrown away.

    Back to the topic of high level languages. I've been thinking about this specific problem for the last few years as a result of teaching others JESS and LISP syntax. Many programmers think procedurally and cannot shift their mode of thinking. This is especially true in an environment like a rules engine.

    I love the benefits of declarative languges, but there is a high cost associated with learning a new mode of thinking. I have no proof of this, but I suspect the popularity of C/C++, Java and C# is because it fits nicely with procedural thinking. With that in mind, the question I ask myself is this.

    How far can a language move away from C syntax before the syntax becomes a barrier?

    I ask this because any programming language that wants to succeed has to successfully balance the human issues. Clearly smalltalk and ruby have merits and provide a different model of development. Without answering the question "why didn't smalltalk or ruby become the dominant language?" it's hard to plot a path to the future. VM's written for statically typed languages do make it harder for those working on scripting languages, but perhaps a better path is a gradual evolution. I've been working on a LISP interpreter and rule engine in my free time, so I've seen a few of these issues first hand.

    my hope is the community will continue the debate and hopefully someone really smart will figure out the path to get people from procedural to a more declarative style. debates should be heated, otherwise they would be boring.

    peter lin
  38. <blockquoteThe responses to my original post (above) seem to have missed the point. My main point is that freeing developers to use dynamic OO languages will improve what is currently possible in the web development space...
    ...
     The big issue now is dynamic versus static languages.
    There is another alternative to make the same as usual (writing letters to GOD, with/without object oriented).
    If you change the language, and continue building architectures...you have changed nothing.
    You continue working object "ORIENTED".

    Object Technology is not related with Object Orientation.
    Object Technology can have real application in an Ambience (a virtual ambience, like Smalltalk -that is NOT a language-)

    The main problem with OO is that is confined to formal methods and reductionism (reduction to objects).
    Object Ambiences let you complement formal work with non-formal activities; breaking the limitations imposed by only using a language.
  39. How times have changed[ Go to top ]

    Agree with some comments said here, buy must say that Smalltalk is not a language.
    Considering Smalltalk a language denote non-understanding of diferences between Object "orientation" and real Object Technology.
    We can put in the same level comments on OOLs and Object ORIENTED architectures (like .NET and other OO architectures); but never compare with an Ambience like Smalltalk, because comparation make people thing that Object Orientation will reach Object Technology in the future...
    There is too much time and evidence that demostrates failure of proposal on crossing the hypotetical bridge to reach Objects...
    Smalltalk let you break the limits imposed by formal design and reduction (OO method), realizing (in practice) non-formal activities. This activities can´t be realized using languages (nor OOL).

    best,
    Ale.
  40. Use JRE and make sure we can use all the JARs and simplofiy the language and you got:
    http://groovy.codehaus.org/faq.html#whats-groovy

    We use groovy here and it rocks.
    bye bye EJB, JSF, ORM, anotations, everyone is now sick of it.

    .V
  41. Beyond Java but not the Virtual Machine[ Go to top ]

    thank ejb for killing j2ee:
    http://www.indicthreads.com/news/323/effective_ejb.html
    "Worse yet, these complexities are so overwhelming that the actual business problems take a back seat."

    I said this like 4 years ago!

    .V
  42. Party Pooper[ Go to top ]

    Can't sell $15K app servers for POJO architectures though.

    Seriously, EJB was a poorly contrived attempt to steal server license revenues from DB vendors, or do the other trick to milking money from customers: add another layer.
  43. $15K a server[ Go to top ]

    That is the different matter.
    Just step for a moment in the software vendor shoes:
    If stuff just works – how can I sell next version? Consultancy? Etc.

    Seriously :)
    There is new era coming (I believe) – the era of department developers and system integrators driving software rather than software vendors.

    And IT department developers face this dilemma too: what if business automation will be done. We can say that it will never be done, and it is true to some degree. Think about all those people in IT departments who were busy writing databases, text editors, and stuff like that.

    It might seem logical to accept it and go with the flow but history teaches us that it never happens, people always trying to stop innovations or innovate in a way that produce lots of activity but does not really change anything. ( look at the luddites movement or more recent dispute http://comment.cio.com/soundoff/100302.html )

    Some people go with the flow (some OpenSource), and others fight changes.

    Back to money: I feel good when I pay reasonable price for stuff I need, just because I expect to be paid as well. And I hate when I forced to pay extra and unreasonable premium.

    Remember: the art of salesperson is to convince that premium is ‘right’ and that is much more difficult when they deal with ‘educated’ client.

    Slowly people start to understand IT better and better and therefore it makes sales more and more difficult…

    Expect more gimmiks...
  44. $15K a server[ Go to top ]

    It might seem logical to accept it and go with the flow but history teaches us that it never happens, people always trying to stop innovations or innovate in a way that produce lots of activity but does not really change anything. Some people go with the flow (some OpenSource), and others fight changes. Back to money: I feel good when I pay reasonable price for stuff I need, just because I expect to be paid as well. And I hate when I forced to pay extra and unreasonable premium.

    All you said are correct theorectically.

    Therefore, your employer feels good when paying reasonable price for employees. And your employer hates when he/she is forced to pay extra and unreasonable premium.

    And your reasonable salary should be no more than $15K/year. (AFAIK, that's a bit more than a senior programmer/manager make in Shanghai, China. It may be a bit more in India.)

    In fact, your reasonable salary should be less because most of system you work on consists of free open-source software.
  45. $15K a server[ Go to top ]

    All you said are correct theorectically.Therefore, your employer feels good when paying reasonable price for employees. And your employer hates when he/she is forced to pay extra and unreasonable premium. And your reasonable salary should be no more than $15K/year. (AFAIK, that's a bit more than a senior programmer/manager make in Shanghai, China. It may be a bit more in India.)In fact, your reasonable salary should be less because most of system you work on consists of free open-source software.

    Is not it exactly that happens with the outsourcing: employers hate to pay XXXXXX when they can pay XXXXX.
    Even more: employers hate to pay XXXXXX when they can pay XX. Think of numbers of people in the past (some places even now) writing infrastructure code and frameworks in every single company: CORBA analogs, databases, editors, Struts analogs, ORMs, etc.
    Guess what: they get replaced by OpenSource frameworks and code generators.

    How about that?
  46. I've waited for quite sometime for there to be a debate on the serverside about the relative merits of different languages.

    The real issue facing developers is complexity. The best tool we have to tackle complexity is abstraction. The best ideas around abstraction to date can be found in pure object orientated programming. The problem is that most developers today have been introduced to OO throught the "C with classes" camp.

    "C" people never really understood OO and its full power. You only need to look at C++ to see that. Objective-C was a bit better, but mixing procedural and object orientated constructs in the same language was never a good idea.

    Most C++/Java/C# programmers I know still don't have a full grasp of OO concepts and continue writing procedural code in a "C with classes" style. Much of the power of full OO abstraction is lost to them and what OO abilities exists in these languages are obscured by non OO constructs and a restrictive type system.

    Rod Johnson once said that EJB is less than Java, I agree. What I would also say is that Java is less than pure Object Orientation. We need to forget App Servers, XML, Annotations and byte code manipulation and get back to pure OO concepts.

    I've briefly skimmed Bruce Tates beyond Java, and I largely agree with what he has to say. Where I feel that he has missed an opportunity is by restricting his "contender" languages to those with C like syntax. I love Ruby, but I just know that "C with Classes" programmers will carry on writing procedural code using Ruby.

    The C legacy is holding us back. Many need to look afresh at programming and reinvent what is possible in their own minds. For me the break through came when I tried Smalltalk.
  47. We need to forget App Servers, XML, Annotations and byte code manipulation and get back to pure OO concepts....For me the break through came when I tried Smalltalk.

    I had the same 'breakthrough' with Smalltalk in the 80s. However, I now feel that pure OO concepts just aren't enough. I need more than inheritance. I remember the mess that pure OO led to in many Smalltalk versions, with poor attempts to implement namespaces and developers adding dozens of their own methods to 'Object'. The way Java and various Java tools do things with Interfaces and Annotations gives an increased ability to express relationships in the language. These things are so useful that there are implementations of them in OO dynamic languages.

    Also, I just don't get this 'anti-XML' thing. XML is good and useful. Dynamic languages are a great way to work with it.

    Finally, I have to say that knocking procedural code isn't always a good thing. Well-written procedural code can be efficient, and very easy to follow (even for non-programmers). One of the issues of languages like Smalltalk is that using clever tricks and shortcuts to express things is easy and fun. I did it all the time. The problem is that it can be very hard for anyone else to understand what is happening. I can imagine the same situation can easily arise with Ruby.
  48. One of the issues of languages like Smalltalk is that using clever tricks and shortcuts to express things is easy and fun. I did it all the time. The problem is that it can be very hard for anyone else to understand what is happening. I can imagine the same situation can easily arise with Ruby.

    You make a valid point. With all that power comes a lot of responsibility. I wouldn't consider using a dynamic language for anything large without a disciplined approach like Test Driven Development and XP. With a highly skilled and disciplined programmer dynamic languages are extremely productive, but in the wrong hands they could be very dangerous.

    My difficulty with procedural programming is that often it breaks the agile tennent of "Once and Once Only". If you intend to evolve your design through refactoring then "travelling light" is very important.

    As for XML I agree that its fine. My reference to it was in the context of an add-on to your programming language as away of providing "late binding". You know, ejb descriptors, xdoclet and hibernate, etc.

    The point I'm making is:

    Pure dynamic OO language + Agile development = Highly productive (and fun) environment.

    But of course the most important ingredient is the one driving the keyboard :^).
  49. With a highly skilled and disciplined programmer dynamic languages are extremely productive, but in the wrong hands they could be very dangerous.

    Which is why I view the potential widespread use of languages like Ruby with mild concern. This may sound very condescending, but it is based on experience. It could lead to a large number of 'write once' applications that are a major problem to maintain or extend. I have been guilty of this sort of development.
    The point I'm making is:Pure dynamic OO language + Agile development = Highly productive (and fun) environment. But of course the most important ingredient is the one driving the keyboard :^).

    Absolutely! But I'm not sure that it really is the best way for the majority of development to be done by the majority of developers (and that includes me!). I am prepared to be convinced otherwise....
  50. Absolutely! But I'm not sure that it really is the best way for the majority of development to be done by the majority of developers (and that includes me!). I am prepared to be convinced otherwise....

    Thats fair and honest. I guess thats why we need the freedom to use the language and the libraries of our own choosing.

    I won't force you to use Ruby if you don't force me to use Java. As it stands today, vendors have got developers locked into either Java or C#.

    True multi-language support is the answer, not sure that the JVM or the CLR will be offering that anytime soon.
  51. As it stands today, vendors have got developers locked into either Java or C#.True multi-language support is the answer, not sure that the JVM or the CLR will be offering that anytime soon.

    I still don't see how you are locked into Java or C#. Apart from many languages available on Mono/.NET and the 200 (200!) languages available on the JVM, there already JSRs for dynamic languages on the JVM - BeanShell and Groovy. The is already JCP support for multiple languages (including dynamic OOP languages) right now.
  52. there already JSRs for dynamic languages on the JVM - BeanShell and Groovy. The is already JCP support for multiple languages (including dynamic OOP languages) right now.

    The hottest dynamic language out there right now is Ruby, and as I understand it you can't run Ruby on Rails on the JVM.

    Things may be as open as you say. I just haven't "seen it". I will take your advice and look more into what is available today.
  53. The hottest dynamic language out there right now is Ruby, and as I understand it you can't run Ruby on Rails on the JVM.

    Why should that matter? I predict that when the next version of PHP comes out, then that will be the hottest language for a while. We are already beginning to see the hype:

    http://zdnet.com.au/news/software/soa/Andreessen_PHP_succeeding_where_Java_isn_t/0,2000061733,39218171,00.htm

    I dislike the way that a focus RoR seems to dominate the dynamic language debate. My views on its flaws (OK, what I consider to be it's flaws!) are probably well known here by now :)

    I don't know the details of why RoR can't yet run on JRuby, but it is one of the future JRuby milestones, and should not stop anyone from using most of the Ruby language on the JVM right now.
  54. The hottest dynamic language out there right now is Ruby, and as I understand it you can't run Ruby on Rails on the JVM.
    Why should that matter? ..

    I don't know whether you've been following the other thread of this debate that I've been contributing to. But there appears to be a consensus that both the CLR and the JVM only fully support languages from the "C family". Here is a link to a Smalltalk blog that talks about .NET.

    http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3279770893

    I have read in several places, including this forum, that the same applies to the JVM.

    Now in another one of my posts I say that we are all being held back by the "C legacy". If we want to think and program differently, rather than just changing syntax, we will need VMs that support fully dynamic languages.

    Microsoft claim that it is their intention for .NET. As far as I've seen Sun as made no such statment about the JVM.
  55. If we want to think and program differently, rather than just changing syntax, we will need VMs that support fully dynamic languages.Microsoft claim that it is their intention for .NET. As far as I've seen Sun as made no such statment about the JVM.

    Then you may be interested in this:
    http://www.tbray.org/ongoing/When/200x/2004/12/08/DynamicJava

    and this
    https://coyote.dev.java.net/

    and these JSRs: 223, 241 and 274.
  56. Thanks for the links. I wonder if this stuff is just driven by the Sun Engineers, or whether Marketing is behind it too. Sun just isn't marketing Java as a multi-language platform. I haven't looked in detail at the JSRs, but all the descriptions I've seen for languages like GROOVY are as "scripting" adjuncts to Java, rather than replacement languages in their own right.

    What I'm waiting for is a full blown Smalltalk development environment running on top of the JVM. Amongst the JVM supported languages I came a cross this:

    http://www.architur.de/ (go to Produkte and Talks2 in englisch)

    Smalltalk with class browser, transcript, workspace inspector, debugger etc All running on top of the JVM. It is still experimental though.

    If you've got evidence that Sun is making fundamental changes to the JVM to better support dynamic languages then I would be interested in that too.

    Thanks for the info.
  57. If you've got evidence that Sun is making fundamental changes to the JVM to better support dynamic languages then I would be interested in that too.Thanks for the info.

    I found this:
    http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1102081,00.html

    "At the JVM level, Sun said they are working on special bytecodes that would facilitate dynamic script language support, specifically in method dispatching."

    You will have to wait for Java 7.0, but it looks like the support you are interested is coming.
  58. Beyond Java but not the Virtual Machine[ Go to top ]

    With a highly skilled and disciplined programmer dynamic languages are extremely productive, but in the wrong hands they could be very dangerous.
    Which is why I view the potential widespread use of languages like Ruby with mild concern. This may sound very condescending, but it is based on experience. It could lead to a large number of 'write once' applications that are a major problem to maintain or extend. I have been guilty of this sort of development.
    The point I'm making is:Pure dynamic OO language + Agile development = Highly productive (and fun) environment. But of course the most important ingredient is the one driving the keyboard :^).
    Absolutely! But I'm not sure that it really is the best way for the majority of development to be done by the majority of developers (and that includes me!). I am prepared to be convinced otherwise....

    It's interesting to me that I think a beginner can have much more success with Ruby on Rails than the Java stacks, though Ruby is presented as the "expert" langauge. Ruby allows us to freely use power, so the designs are often more simple and clear. Java tries to save developers from themselves (typing, exceptions, etc), and the frameworks require much more training and experience to use well.

    Ironic.
  59. Beyond Java but not the Virtual Machine[ Go to top ]

    It's interesting to me that I think a beginner can have much more success with Ruby on Rails than the Java stacks, though Ruby is presented as the "expert" langauge. Ruby allows us to freely use power, so the designs are often more simple and clear. Java tries to save developers from themselves (typing, exceptions, etc), and the frameworks require much more training and experience to use well.Ironic.

    I don't find the success of beginners with dynamic languages that surprising, as some of the more interesting languages have arisen from teaching - Smalltalk being a classic case.

    As for designs - they may be more simple and clear, but I would suggest that this is only if such a language is used by well-trained or skilled developers who know what they are doing and have sufficient time and resources. Unfortunately, if this sort of power is free to use you can end up with IT disasters, not necessarily because developers aren't trained or skilled (although that can be a factor) but simply because of human nature.

    I strongly believe that Java's attempt to save developers from themselves has been one of the best things to have happened in IT for a very long time, if only because I have so frequently over the years dealt with the consequences of projects in other languages where this sort of protection was not there.

    Just to give one example of how this sort of freedom can mess things up, I remember in the 80s how the freedom to browse and modify all Smalltalk classes as part of development led to just about everyone adding their own methods to key classes such as Object, so when you loaded a new package into your Smalltalk image you could not be sure what would break or what would be over-written.

    I'm not saying that more dynamic language features aren't going to make us more productive. What I am highly cautious about is whether the total freedom of languages such as Ruby doesn't have it's downsides.
  60. ...
     I strongly believe that Java's attempt to save developers from themselves has been one of the best things to have happened in IT for a very long time
    ...
     I remember in the 80s how the freedom to browse and modify all Smalltalk classes as part of development led to just about everyone adding their own methods to key classes such as Object, so when you loaded a new package into your Smalltalk image you could not be sure what would break or what would be over-written.
    ...
    Absolutely.... the JVM is all about security - which is why CLR is not even an adequate rip off of the JVM - code can be verified, types are strong. The basis of all security is stopping unauthorised (especially if unanticipated) actions - by definition opposed to the type of flexibility required in a "universal" VM.

    At this time I'm not even sure a universal VM is even possible, let alone desireable; the argument commonly advanced is that of multilanguage development. Communication between different languages is very ticky (really different languages - think about an system composed of say Prolog, Ruby, Java and Haskell) and really will never be seamless no matter how much security you remove, whatever Microsoft says. The closest you will get is a multilanguage implementation of a common comunications protocol (pipes & sockets anyone?), possibly with some sort of structuring (ASN, IIOP, Web services, JSON, whatever). Maybe somesort of super VM is possible that can provide optimised services for more specific VMs is possible (an OS, but with VM hooks for IPC, JITC ect). I have a feeling that this area is going to be very interesting over the next few years.
  61. Hi Steve,

    I'm back, and I actually agree with much of what you say. From what I can see the demise of Smalltalk was partially due to the type of own goals you describe.


    I also agree with Peter Lin:
    Why should businesses move on? Forgetting platforms for a few minutes, the phrase "move on" gives me the impression of leaving something behind. I'm guessing you mean "move forward" to a better approach, while keeping the good bits that shouldn't be thrown away.

    So we need to find we need to keep the best from the past whilst adding new ideas. I not sure the Java designers achieved this in the long term.
    I strongly believe that Java's attempt to save developers from themselves has been one of the best things to have happened in IT for a very long time, if only because I have so frequently over the years dealt with the consequences of projects in other languages where this sort of protection was not there.

    But I don't think that trying to protect developers from themselves by limiting the power of the programming language to what the designers feel is safe is a good thing.

    At the time Java came out this approach allowed C++ programmers to get on board quickly, but in the longer term it has ment that innovation in the Java development space has been fraught with difficulties (think byte code manipulation).

    In contrast Smalltalk is still bringing new innovative programming ideas to main stream developers. A good example of this is Seaside a Smalltalk Continuation based Web Framework. So the issue is how to enforce some discipline, whilst giving people the power to be creative.
    Unfortunately, if this sort of power is free to use you can end up with IT disasters, not necessarily because developers aren't trained or skilled (although that can be a factor) but simply because of human nature

    It would be interesting to hear form Kent Beck. But my feeling is that XP was created partially in response to some of the failings in human nature you describe. So I don't think that it is a total accident that XP came out of the Smalltalk camp. In XP teams developers are protected from themselves by "common code ownership". We work in pairs, each watching the back of each other. We also swap pairs on a regular basis. This way best practice quickly spreads around the team, and most of the abuses you describe are avoided.
    I remember in the 80s how the freedom to browse and modify all Smalltalk classes as part of development led to just about everyone adding their own methods to key classes such as Object, so when you loaded a new package into your Smalltalk image you could not be sure what would break or what would be over-written..

    One of the things I like about Java is the fact that it is an extensible language. So you have a standard library J2SE, which you can extend using standard interfaces - JDBC, Servlet API etc. These standards are enforced by the Java Community and a standard package naming scheme. Smalltalk talks about class protocols in the purple book, but the only explicit implementation that I've seen is in Dolphin Smalltalk where you can associate "protocols" to classes in the same way a class "implements" interfaces in Java.

    Using this approach Smalltalk could adopt the extensible language idea with standard classes and standard "protocols". When viewing standard classes, your Smalltalk browser could become read-only forcing you to subclass (Another way of forcing you to sublcass is working with a partner who will tell you "don't do that, it's a bad idea").

    My point is all these languages have their strengths and weaknesses and they can borrow from each other. From a personal point of view, my ideal "Agile" language would have Smalltalk syntax (after all we should be talking objects not procedures). Would give me as much power and fexibility as possible but enforce standards by adopting the "extensible" language concept in the same way as Java/J2EE.
  62. Hi Steve,I'm back, and I actually agree with much of what you say. From what I can see the demise of Smalltalk was partially due to the type of own goals you describe....
    From a personal point of view, my ideal "Agile" language would have Smalltalk syntax (after all we should be talking objects not procedures). Would give me as much power and fexibility as possible but enforce standards by adopting the "extensible" language concept in the same way as Java/J2EE.

    I also agree with a lot of your post, although I am somewhat more biased towards a language being restrictive on the developer!

    However, changing the subject somewhat, there is something that I can't figure. Firstly, Smalltalk is not dead yet! There are good implementations out there like VisualWorks, Smalltalk/X, Dolphin and Squeak. There is even GNU Smalltalk. All of these have decent GUI-based IDEs. It is a mature language with a huge quantity of code out there in the public domain. There are great ideas on Smalltalk like Seaside. There have been ORM systems on Smalltalk for many years. Smalltalk is now easy to set up for headless use in non-GUI situations (something of a problem in the past).

    So why aren't more developers using it?

    Why work with a language with (in my opinion) too much syntax and a lack of quality IDEs like Ruby? I would have thought quality of the tools and maturity of the language would have proved irresistible.
  63. Firstly, Smalltalk is not dead yet! There are good implementations out there like VisualWorks, Smalltalk/X, Dolphin and Squeak. There is even GNU Smalltalk. All of these have decent GUI-based IDEs. It is a mature language with a huge quantity of code out there in the public domain. There are great ideas on Smalltalk like Seaside. There have been ORM systems on Smalltalk for many years. Smalltalk is now easy to set up for headless use in non-GUI situations (something of a problem in the past).So why aren't more developers using it?Why work with a language with (in my opinion) too much syntax and a lack of quality IDEs like Ruby? I would have thought quality of the tools and maturity of the language would have proved irresistible.

    In a word... MARKETING

    Both Java and C# are what I would call "Manufactured languages". I maybe cynical, but I'm sure when the Sun Engineers where playing around in the lab with "Oak" they never dreamt that it would become the universal server side platform to conquer the world, but then the marketing people got hold of it...

    At the same time Sun was doing research on Self, an advanced prototype language loosely based on Smalltalk, but where is Self today? I just think Sun saw a market opportunity, pulled together some much needed ingredients (VM, garbage collection, no more pointers), packaged them so they would be palitable ("C"-like) and bingo, a platform to compete with Microsoft Windows on the Server.

    You only need to look at AWT in Java 1.0 to see that the Java language was "rushed" to market.

    I read an article by Alan Kay where he says that Software development in the last 30 years have been dominated by short termism. I agree. In this regard Java was a missed opportunity. Then again they probably made the right compromises at the time. We could have ended up writing C++ a lot longer.

    Think about the people who make "technology platform" decisions in most organisations. Even though Java looked like C++ it took me 2 years to get my boss to agree to use it. In the UK the only people using Smalltalk at the time where the banks. Everyone else was taking the save C to C++ to Java route.

    I spend a lot of time following Smalltalk blogs this is a good one:

    http://www.cincomsmalltalk.com/blog/blogView

    It is probably best that you ask them this question. My professional career has been on the "safe" C path. What I can say though is that we've got an ex-Smalltalker on our team and he bitches all the time that he has to program this Java stuff just to pay the bills. He would love if he could get his beloved Smalltalk back again.

    Now with the advent of Open Source, and open communication on the web (blogs), I think the balance of power between vendors and developers has shifted. There are some good open source Smalltalk implementations out ther. You mention Squeak. The Squeak crowd seem to have given up on the corporate world and are bussy building multi-media applications for Kids (Education). But I'm sure they wouldn't mind if a group of Corporate developers branched the code and came up with a version better suited to the main stream.

    As for Ruby over Smalltalk. Well I kind of like Ruby and if Mohmamed won't come to the mountain then... I see Ruby as a Trojan horse for Smalltalk style programming (for example collection classes that make use of block closures). Ruby holds onto the C-like syntax which is probably one of the reasons why its caught on, but removes primitives (yes) and makes classes first class objects much like Smalltalk.

    Personally, I think it would be easier for people to learn an object orientated language if all the procedural stuff was left out. So keywords like 'if', 'while', 'else' (thankfully they've got rid of 'new') just shouldn't be there (IMHO). And I agree with you on the proliferation of syntax in Ruby that you've got to learn. Adding new keywords and new syntax seems to be popular at the minute (generics and annotations in Java 1.5). On balance Ruby is a step in the right direction, but I agree that its not as elegant and as developed as Smalltalk. Interestingly a lot of the leading Ruby developers program in Smalltalk too, so like I said Ruby could turn out to be a Trojan horse.
  64. I spend a lot of time following Smalltalk blogs this is a good one:http://www.cincomsmalltalk.com/blog/blogView
    It is probably best that you ask them this question.

    That company's pricing and licensing terms were one of the reasons I stopped using Smalltalk.
  65. And the reason why I had to learned Smalltalk using Smalltalk/X back in 93. I think the cost back then was about £3K, but I wouldn't swear to it!

    Fortunately they do a free non-commercial license knowadays, so you can download it for free.
  66. And the reason why I had to learned Smalltalk using Smalltalk/X back in 93. I think the cost back then was about £3K, but I wouldn't swear to it!Fortunately they do a free non-commercial license knowadays, so you can download it for free.

    Yes, but any commercial work involved (and probably still does) some sort of strange (to me) licensing system based on a proportion of your company profits. If I had suggested using a development tool with those conditions of use, my boss would have given me a very strange look indeed.

    In the end, high-performance Smalltalk made itself much too troublesome to use.
  67. Can we build a new Smalltalk?[ Go to top ]

    Smalltalk, even today, is hanging on to it's pre-80s UI. I used IBM Smalltalk and I loved it (too bad they are pulling it from the market). I wish Squeak had learnt from it.

    There's a "port" of Squeak to the Java VM (which is a good thing because Squeak's UI is just plain childish). However it's still would need some work. (Imagine integrating with Eclipse!):

    http://www.architur.de/deutsch/produkte/talks2/index.html
  68. Can we build a new Smalltalk?[ Go to top ]

    Smalltalk, even today, is hanging on to it's pre-80s UI.

    I don't think so.

    For example:
    Dolphin Smalltalk has a full Windows GUI.
    VisualWorks has a customisable rich GUI.
    GNU Smalltalk uses TK.
    Squeak used to have a very 'Smalltalk-80' GUI, but switched to a newer system called Morphic.

    As far as I know there is no current Smalltalk that by default presents a typical Smalltalk-80 UI.
    I used IBM Smalltalk and I loved it (too bad they are pulling it from the market)

    Not quite. VisualAge Smalltalk will still be available from another company - Instantiations.
  69. Can we build a new Smalltalk?[ Go to top ]

    This as got to be on of the most active discussions I've seen on the serverside in a while. Over 90 comments and counting.

    I wonder if the Vendors are listening? An exercise in direct customer feedback. IBM backed away from Smalltalk towards Java (short termism). Now they seem to be moving towards PHP (short term again).

    If one of the big vendors had the courage and long term vision to back Smalltalk and stick with it, I'm sure they would clear up.

    The thing is have they got that vision?
  70. Can we build a new Smalltalk?[ Go to top ]

    This as got to be on of the most active discussions I've seen on the serverside in a while. Over 90 comments and counting.I wonder if the Vendors are listening? An exercise in direct customer feedback. IBM backed away from Smalltalk towards Java (short termism). Now they seem to be moving towards PHP (short term again).

    I think to say they they are moving towards PHP is a bit extreme. IBM has a huge investment in Java, and not just for web-page scripting!

    The thing about a large company like IBM is that there is (in my experience) rarely a unified approach. I can remember years ago hearing about development tools from both Smalltalk and Java groups at IBM. The opinions about IBM's direction seemed very different!
  71. Can we build a new Smalltalk?[ Go to top ]

    Ok. I admit I haven't used too many versions of Smalltalk.
    But the cheap choice (Squeak) has a pre-80s style UI. Why do I say this? Because of its overloaded context menu.. and morphic?? well that's just weird.

    I loved IBM's Smalltalk (previously OTI Smalltalk), even back in the mid-90s it had a look and feel of a Windows app (or OS/2 app). [This is a veiled endorsement for SWT which was created by OTI same as IBM Smalltalk]

    Also, Smalltalk has such a high barrier of entry (I don't have 3k around just to play w/ a platform). Whereas Java is free (in the monetary sense).

    I wish IBM just contributed their Smalltalk to open source.. but that would be bad for their Java business (IBM already competes too much for itself).
  72. Can we build a new Smalltalk?[ Go to top ]

    Smalltalk has such a high barrier of entry (I don't have 3k around just to play w/ a platform). Whereas Java is free (in the monetary sense). I wish IBM just contributed their Smalltalk to open source.. but that would be bad for their Java business (IBM already competes too much for itself).
    +1
    After your first post, I downloaded IBM Smalltalk, and it does look great. The price when the trail period runs out is over £1000 though!
  73. Can we build a new Smalltalk?[ Go to top ]

    Ok. I admit I haven't used too many versions of Smalltalk.But the cheap choice (Squeak) has a pre-80s style UI. Why do I say this? Because of its overloaded context menu.. and morphic?? well that's just weird.

    Morphic may be weird, but the one thing it certainly isn't is pre-80s style, either in appearance or mechanism. Morphic was part of the Self language.
    I loved IBM's Smalltalk (previously OTI Smalltalk), even back in the mid-90s it had a look and feel of a Windows app (or OS/2 app). [This is a veiled endorsement for SWT which was created by OTI same as IBM Smalltalk]

    It is interesting to see how much influence Smalltalk has! If I remember right Swing came from a Smalltalk GUI - VisualWorks, and SWT (as you say) was at least based on the way that IBM VisualAge Smalltalk handled cross-platform issues.
    Also, Smalltalk has such a high barrier of entry (I don't have 3k around just to play w/ a platform). Whereas Java is free (in the monetary sense). I wish IBM just contributed their Smalltalk to open source.. but that would be bad for their Java business (IBM already competes too much for itself).

    There are plenty of Smalltalks that are either free or Open source:

    Squeak, Smalltalk/X, GNU Smalltalk, Bistro, Talks2. There are non-free implementations that are not very expensive: Dolphin, Smalltalk/MT, S#.

    By definition, GNU Smalltalk has zero barrier to entry...
  74. At the same time Sun was doing research on Self, an advanced prototype language loosely based on Smalltalk, but where is Self today?
    I think it's now called ECMAScript, an international standard.
  75. At the same time Sun was doing research on Self, an advanced prototype language loosely based on Smalltalk, but where is Self today?
    I think it's now called ECMAScript, an international standard.

    Wow. From Self -> JavaScript - That darn marketing department again! No, just joking. Thanks for the info I always wondered what happended to it:^)

    For those out there interested you can see the orginal syntax on wikipedia: http://en.wikipedia.org/wiki/Self_%28computer_language%29

    And download the language from Sun: http://research.sun.com/self/
  76. Wow. From Self -> JavaScript - That darn marketing department again! No, just joking. Thanks for the info I always wondered what happended to it :^)

    Believe it or not, Hotspot (the JVM) used to be the Self VM. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  77. I read an article by Alan Kay where he says that Software development in the last 30 years have been dominated by short termism.
    +1
    I love the expression: “short termism”.
    I think that not only IT is plagued by “short termism” but a lot of other human activeties as well. I think we should admit the diagnosis and start moving to the healthier “eternity” :) oriented sustainable models.
  78. I think a beginner can have much more success with Ruby on Rails than the Java stacks, though Ruby is presented as the "expert" langauge. Ruby allows us to freely use power, so the designs are often more simple and clear. Java tries to save developers from themselves (typing, exceptions, etc), and the frameworks require much more training and experience to use well.Ironic.

    This is an area that has allways interested me. I taught myself Smalltalk back in the early nineties, because I just knew that after years of trying that I just wan't doing "the OO thing" right with C++. With Smalltalk OO made sense straight away. I had no choice with Smalltalk even program control (if, else, while etc) are messages to objects( a brilliant class library to learn from helped too). So I take your point to the fresh mind, new approaches are often easier to pick up. We have two young grades in our team using Ruby and they have taken to it straight away (within days).

    After learning Smalltalk I want back to using C++ in my day job. Now I program in Java for a living, but I have allways wondered how "viable" a dynamically typed language would be on a large project with say >5 developers.

    I've gotten heavilly into XP and test driven development in recent years so I know that TDD will provide me with a lot more "safety" then type checking ever did. But it would be nice to here from others that have used dynamic languages on large projects.

    Did Smalltalk suffer from a lack of "type safety" and if so is TDD the solution?
  79. Languages[ Go to top ]

    I've waited for quite sometime for there to be a debate on the serverside about the relative merits of different languages.The real issue facing developers is complexity. The best tool we have to tackle complexity is abstraction. The best ideas around abstraction to date can be found in pure object orientated programming. The problem is that most developers today have been introduced to OO throught the "C with classes" camp."C" people never really understood OO and its full power. You only need to look at C++ to see that. Objective-C was a bit better, but mixing procedural and object orientated constructs in the same language was never a good idea.Most C++/Java/C# programmers I know still don't have a full grasp of OO concepts and continue writing procedural code in a "C with classes" style. Much of the power of full OO abstraction is lost to them and what OO abilities exists in these languages are obscured by non OO constructs and a restrictive type system.Rod Johnson once said that EJB is less than Java, I agree. What I would also say is that Java is less than pure Object Orientation. We need to forget App Servers, XML, Annotations and byte code manipulation and get back to pure OO concepts.I've briefly skimmed Bruce Tates beyond Java, and I largely agree with what he has to say. Where I feel that he has missed an opportunity is by restricting his "contender" languages to those with C like syntax. I love Ruby, but I just know that "C with Classes" programmers will carry on writing procedural code using Ruby.The C legacy is holding us back. Many need to look afresh at programming and reinvent what is possible in their own minds. For me the break through came when I tried Smalltalk.

    I agree with you. We need to be at a higher abstraction. I hope we can do it within the Java virtual machine.
  80. Don't say that[ Go to top ]

    Java is great language

    and they ara listing the community, they incorporate Groovy end they make EJB3.0 like hibernate.

    That more do you want ?

    small and good steps is the rigth things
  81. I'll say that[ Go to top ]

    Some of this are just ideas.

    Personally I whant support plugable inheritance types (like Duck Typing, functional). It should be able to handle macros and structs (although I dont like them), better support for versioning and simpler ways to call librarys (dlls).

    All this at the JVM level. Also we should be able to create custom bytecode operators (providing a class to handle them whem they are unknown to the JVM).

    The isolation API is a must (but it will not be released soon).
  82. Beyond Java but not the Virtual Machine[ Go to top ]

    Use JRE and make sure we can use all the JARs and simplofiy the language and you got:http://groovy.codehaus.org/faq.html#whats-groovyWe use groovy here and it rocks.bye bye EJB, JSF, ORM, anotations, everyone is now sick of it..V

    Whether or not you use Groovy has nothing to do with EJB, JSF or ORM. For example I'm using Groovy and JSF together.
  83. Beyond Java but not the Virtual Machine[ Go to top ]

    I still don't get when and where and why I should use Groovy instead of Java. I am using Java and Drools. Not that I wouldn't like to. I can see it maybe being used like providing scripting/macros for an application.
  84. Beyond Java but not the Virtual Machine[ Go to top ]

    I still don't get when and where and why I should use Groovy instead of Java. I am using Java and Drools. Not that I wouldn't like to. I can see it maybe being used like providing scripting/macros for an application.

    I find it more expressive for some aspects of business logic, because of operator overloading. I like to be able to use normal math operators with BigDecimal for example. This is so expressive it makes things like financial logic clear even to non-developers.
  85. Groovy benefits[ Go to top ]

    I still don't get when and where and why I should use Groovy instead of Java. I am using Java and Drools. Not that I wouldn't like to. I can see it maybe being used like providing scripting/macros for an application.
    I find it more expressive for some aspects of business logic, because of operator overloading. I like to be able to use normal math operators with BigDecimal for example. This is so expressive it makes things like financial logic clear even to non-developers.

    Additionally, in a web app environment, it is very easy to set Groovy up a la PHP. So you get all the above, plus zero turnaround time (change script, refresh browser) as well as all the benefits of the capabilities built into the language and access to java libraries.
  86. Groovy benefits[ Go to top ]

    It can also be used for rapid prototyping. Type some code in the Groovy console like this.
            
            Access access = new Access();
    access.init();
    tx = access.transaction();
    Jobs jobs = new Jobs()
    jobs.setDescription("Test")
    jobs.setMinimum(21)
    jobs.setMaximum(180)
    access.save( jobs )
    tx.commit();
    access.close()

    I am using a simple Hibernate class for doing CRUD operations and it is so straightforward. You don't have to open a IDE and explicitly compile anything.
  87. Groovy benefits[ Go to top ]

    Additionally, in a web app environment, it is very easy to set Groovy up a la PHP. So you get all the above, plus zero turnaround time (change script, refresh browser) as well as all the benefits of the capabilities built into the language and access to java libraries.

    It is very easy to set up Groovy (or any other decent dynamic language on the JVM) to work like this in any environment. One of the uses I have for this kind of thing is to allow non-Java developers to develop and play around with interactive business logic scripts. I'm playing around with both Groovy and Jython to see which 'feels' best combined with JDO 2.0/EJB 3.0 and Swing, for this purpose.
  88. Groovy benefits[ Go to top ]

    I still don't get when and where and why I should use Groovy instead of Java. I am using Java and Drools. Not that I wouldn't like to. I can see it maybe being used like providing scripting/macros for an application.
    I find it more expressive for some aspects of business logic, because of operator overloading. I like to be able to use normal math operators with BigDecimal for example. This is so expressive it makes things like financial logic clear even to non-developers.
    Additionally, in a web app environment, it is very easy to set Groovy up a la PHP. So you get all the above, plus zero turnaround time (change script, refresh browser) as well as all the benefits of the capabilities built into the language and access to java libraries.
    I didn't think PHP was that easy to set up. I could do the Zero turn around thing with ASP but the scriptyness of it made me turn to putting code in VB so I could compile and test it. And use the code somewhere else.

    As for using Math operators - I haven't run across that need in a while. :)
  89. EJB used to be complex[ Go to top ]

    I played around with EJB3 lately and that thing is the best
    which could have happened to EJB, defining a session bean is basically a walk in the park, one annotation to a class, one interface and you are basically set.

    Getting the object over JNDI is equally easy.

    The ORM Layer of EJB3 is basically a simplified and cleaned up Hibernate, proven concepts, good speed, this stuff is absolutely loveley.
  90. EJB used to be complex[ Go to top ]

    I played around with EJB3 lately and that thing is the bestwhich could have happened to EJB, defining a session bean is basically a walk in the park, one annotation to a class, one interface and you are basically set

    This type of walk is available for Session Beans for years via XDoclet. And XDoclet does not require Java5.
    Still something has prevented wide use of this type of functionality with EJBs. I do not think that annotations will help much to address those unarticulated causes..
  91. Why it EJB never was adopted[ Go to top ]

    actually it was but to its full extent.
    There were several problems, EJB first of all required a full blown app server, many devs including me simply want to have a lightweight server which starts and stops swiftly.
    Secondly, until EJB3 the entity beans were not really that good.
    Thirdly even with the usage of xdoclet you had a lot of glue code, which many people hate, do you really like to shift between several glue files and a bunch of xml files to have just one class you need.

    EJB until3 was a mess, now that 3 is in the line, the first embeddable libraries come out I see a huge future.
    One of the reasons why Spring got so popular was, that it basically delivered the core patterns of EJB but without having the need of a dedicated full blown ejb server and with the glue reduced basically to xml files. Now EJB3 tops even that by pushing the glue in 1-2 annotations per class.
  92. Dynamic Languages not the cure-all[ Go to top ]

    I write a app in Jython/Java and I know that it can be a real pain in the butt trying to decipher what the heck someone else's code is. I would guess it takes me an order of magnitude longer to figure out a dynamic piece of code as opposed to a static typed language like Java. I can go into the Jython interpreter code and figure things out rather quickly, hmm... this Object is this Object, that Object is that Object. In a dynamic language I get an object, hmmm, its called 'c'. What the heck is c? Maybe Ill go look at the constructor: oh c is a commander. But wait, maybe it doesn't retain its reference, maybe its something different. That has happened to me before when I was converting a python/tk piece to a jython/swing piece.

    I like the speed of writing in such a language but it just isn't fun to work with as time goes on. That's my experience with it. I was able to relearn some java code I wrote 6+ months ago in like a day, if it was in jython who knows it may have taken longer. Well I guess it probably would have taken about the same amount of time. But if someone else wrote, dont know.

    With that said, I still think dynamic languages built for the JVM are very cool. I hope they don't kill Java off. I would prefer to work in a language-scape where both exist and enrich each other.
  93. Dynamic Languages not the cure-all[ Go to top ]

    I would guess it takes me an order of magnitude longer to figure out a dynamic piece of code as opposed to a static typed language like Java.

    You would guess wrong. Type signifies representation. It does not signify intent.
  94. Dynamic Languages not the cure-all[ Go to top ]

    That's fine and dandy. Im just saying I have an easier time figuring out what is what in Java than Jython. Its somewhat irrefutable that I don't have an easier time figuring stuff out raw if its in Java than in Python. But if your theory tells me that I am actually having a harder time figuring Java code out then I guess thats ok as well.
  95. Dynamic Languages not the cure-all[ Go to top ]

    I would guess it takes me an order of magnitude longer to figure out a dynamic piece of code as opposed to a static typed language like Java.
    You would guess wrong. Type signifies representation. It does not signify intent.

    At the end of the day though, isn't the primary issue with languages the learning curve? It doesn't matter if 10% of the programming population love and understand Ruby, if the other 90% think the opposite?

    I'm all for moving development forward and making it easier, but I think it's misleading to forget the learning curve challenge. Those who like to look at new languages and constantly try new things, it's probably going to be easier. For those who don't work that way, no amount of pushing or bashing is going to bridge the gap. I think it's critical to ask, "how do we bridge the gap and ease the transition?"

    without asking and answering the question, it doesn't matter how nice python, ruby or smalltalk is. I don't think it's enough to just say, "hey, this is a better way to do things." Bruce is doing is part and writing about it, but I think a lot of work is still needed to bridge the gap.

    my bias 2 cents

    peter lin
  96. Dynamic Languages not the cure-all[ Go to top ]

    I'm all for moving development forward and making it easier, but I think it's misleading to forget the learning curve challenge. Those who like to look at new languages and constantly try new things, it's probably going to be easier. For those who don't work that way, no amount of pushing or bashing is going to bridge the gap.

    Good points.

    I think part of the problem may be the way programming languages and paradigms are taught. I don't know if it is still like this, but years ago I saw OOP languages like C++, Java and Delphi taught in the following way: Firstly, procedural programming was discussed, then object orientation was introduced afterwards. This tended to make developers think that object orientation was a large-scale approach to development - something that is applied after much procedural code has been written - sort of like a neat way to manage modules and libraries. I think this is the reason that (in my view) inheritance and polymorphism aren't used as often or as well as they should be, and why we end up with antipatterns like the Anaemic Domain Model.

    I think the way around this might be to re-introduce Smalltalk as a first language for teaching. Let developers treat everything as an object, and play around with sending messages to them and inspecting them. Only after this should the compromises and syntax of languages such as C++, Java and C# be introduced. The same sort of thing could be applied to other programming paradigms. Of course, this is a pretty unrealistic suggestion....
  97. I'm all for moving development forward and making it easier, but I think it's misleading to forget the learning curve challenge. Those who like to look at new languages and constantly try new things, it's probably going to be easier. For those who don't work that way, no amount of pushing or bashing is going to bridge the gap.

    Good points.I think part of the problem may be the way programming languages and paradigms are taught. I don't know if it is still like this, but years ago I saw OOP languages like C++, Java and Delphi taught in the following way: Firstly, procedural programming was discussed, then object orientation was introduced afterwards. This tended to make developers think that object orientation was a large-scale approach to development - something that is applied after much procedural code has been written - sort of like a neat way to manage modules and libraries. I think this is the reason that (in my view) inheritance and polymorphism aren't used as often or as well as they should be, and why we end up with antipatterns like the Anaemic Domain Model.I think the way around this might be to re-introduce Smalltalk as a first language for teaching. Let developers treat everything as an object, and play around with sending messages to them and inspecting them. Only after this should the compromises and syntax of languages such as C++, Java and C# be introduced. The same sort of thing could be applied to other programming paradigms. Of course, this is a pretty unrealistic suggestion....

    I completely agree part of the problem is how programming is taught. changing how institutions teach is a monumental task and isn't something that happens over night. I would think that if Ruby or some other dynamic language wants to make in roads, they have to convince academia to change. Without that, I don't see how the shift will occur.

    peter lin
  98. I spent some time with some instructors, in Wisconsin and in Arizona this year. Their impression was that Python was probably the best language to teach, but Ruby was also a very good language for education. Java was far lower on most lists.
  99. I spent some time with some instructors, in Wisconsin and in Arizona this year. Their impression was that Python was probably the best language to teach, but Ruby was also a very good language for education. Java was far lower on most lists.

    A family member is a Computer Science professor and many in the CS field think that undergraduate and graduate courses aren't there to teach programming. From what I am told by some profs, their job is teaching theory. Not all colleges are the same and they do vary quite a bit.

    I don't envy the job of teaching students how to program. The task is rather difficult and ultimately, each person learns their own way. One trend profs are complaining about is departments being bought out by businesses. When Java came out, Sun convinced universities to teach it. When .NET came out, MS did the same thing.

    For a language like Ruby, or python to get a foot hold, I think the drive has to come from the professors and students. many of us working in the field today are far to crusty and "stuck-in-the-mud" to move quickly. Eventually, we change to the next thing, but it's not without a big learning curve.

    peter
  100. As someone who *HAS* taught beginners for several years I can say Python is particularily attractive as a teaching language because:

    - it's dynamic (beginners never can understand the need for typing)
    - there are less barries to success and less protocol
    - the whitespace helps to teach indentation.. it's amazing how many students just don't get this point.

    With Generics Java is becoming a lot harder to teach as a beginner's language. And teachers can never figure out how to explain "static" to students (if you use an Object-First methodology).
  101. I agree that the developers don't use a lot of OO features. They don't use the full power of a OO language. I understood so many interesting things about dynamically typed languages when I started to use Groovy. Now I am hooked on languages that let you do these things. I also understand that these ideas help me write better Java code.