|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 156
Messages: 156
Messages: 156
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Sun Hires the JRuby-guys
Tim Bray has posted a blog on Sun’s surprising move to hire the JRuby guys Charles Nutter and Thomas Enebo.
According to Tim the move to hire came very quickly. In the entry, Tim gives praise to Bob Brewing and Rich Green for making this decision. The round of back slapping is followed up by a Q&A section where Tim answers questions posed by Jacki DeCoster.
Synopses of the answers is that both Charles and Thomas will be tasked to working full time to make sure that Ruby runs on the JVM. They will also have a mandate to think about tools as this is a current drawback to moving to Ruby.
Has Sun breathed a little life in the Ruby community by hiring Charles Nutter and Thomas Enebo? The party line as stated by Tim is that Sun is interested in anything that developers are interested in.
Dynamically-typed languages like Ruby are only beginning to be accepted in the software mainstream, and many of the best practices and tools remain to be invented.
While Sun may have given Ruby the nod as the second official language to be supported on the JVM, it doesn't mean the end to Groovey, Beanshell or jython according to Charles. This view is support by Tim as he states that Sun is actively looking at PHP, Perl, Python, VisualBasic and Rails. With all of this choice in the works it looks as though the focus on the JVM is well placed.
Message was edited by: kirk@javaperformancetuning.com
|
|
|
Message #217670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Second official language?
While Sun may have given Ruby the nod as the second official language to be supported on the JVM
I don't see any evidence of this in the blog entry.
I more get the impression that it's half marketing/responding to hype (that's not necessarily a bad thing, a company the size of Sun assigning two skilled guys to work on something that's getting so much attention is probably a very good move and more cost effective than what some companies would do) and half attempt to learn.
IMHO the learning half is probably what's more important to Sun R&D while the hype half is what get the reqs approved.
Personally I wish they would have hired someone to work on Jython, because I'm not too fond of Ruby (yet, it took me a while to love Python).
|
|
|
Message #217671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I think this is exciting news. Things will get interesting (and good for Ruby developers) if and when the JRuby guys get performance via compilation to byte codes, and also if good tools for JRuby appear in future. This should increase pressure on C-Ruby developers to provide similar improvements. Competition between implementations is good for developers.
|
|
|
Message #217675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Portability
This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly.
But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.
|
|
|
Message #217676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly.
The JRuby developers seem to be strongly emphasising compatibility, so I don't think this is going to be much of a worry.
But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.
see JSR 292.
|
|
|
Message #217678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
In early 1995, I had a meeting with Eric Schmidt who was then the CTO of Sun. He had encouraged us (Documentum) to develop our web solutions on TCL, since this was Sun's official scripting language at the time. Vignette and Interwoven followed that same advise to their peril. It wasn't long before Sun changed course toward Java.
In the end, the language that wins will win through Darwinian forces. Even though Sun backs something now, doesn't mean that something else might not win in the future. Java had the momentum over TCL. Ruby might have momentum over Groovy, jython, etc. It does if you ask O'Reilley.
|
|
|
Message #217679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I'm very excited about this. I think this is one of the first steps in making Java a language for languages, in much the same way C is right now. It's just a natural progression in my mind.
And of course I can wait until I can WAR up a Rails app and deploy it to Tomcat ;)
|
|
|
Message #217683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I think this is good news regardless of JRuby's long term success. It is good to get more corporate support and attention of the JVM being a reasonable host for multi-languages.
* Siphons a bit off .NETs main marketing points
* Will help to lift all boats (Jython, Groovy, BeanShell, ...)
* Will be a decent bridge for shops that support both platforms
Good win for the Minneapolis team.
______________
George Coller
DevilElephant
|
|
|
Message #217685
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Ruby might have momentum over Groovy, jython, etc. It does if you ask O'Reilley.
This is not the same situation. JRuby shows how Ruby can be used with Java, and even potentially with Groovy and Jython, not necessarily in place of these. This seems to me to be about opening up the JVM, not positioning Ruby against Groovy and other languages. Each of these languages has their roles. No matter how well implemented, JRuby will never be able to have the seamless integration with Java that Groovy was designed for.
Also, a change of language emphasis by Sun did not mean that TCL vanished - far from it. It is a well-supported language. In fact, there is even an implementation for the JVM.
|
|
|
Message #217702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I think this is exciting news. Things will get interesting (and good for Ruby developers) if and when the JRuby guys get performance via compilation to byte codes, and also if good tools for JRuby appear in future. This should increase pressure on C-Ruby developers to provide similar improvements. Competition between implementations is good for developers.
Hi Steve,
This is great news. The main advantage is true choice on the JVM platform.
Sun has never really marketed the Java platform as a seperate entity from the Java language. So Java everywhere meant the language and the platform.
This move can only give developers more choice over the language they choose.
I do have some concerns:
1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform?
2. Tim Bray at Sun is a Ruby advocate, and there seems to be many at Sun with a genuine interests in dynamic languages, but I can't help thinking that this move has more to do with recent anouncements by Microsoft that they will be providing a lot more dynamic language support on the CLR. So this could just be another example of Sun playing catch-up with Microsoft.
3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java. So like Groovy and JPython, the adoption of JRuby may remain low, with people sticking to Java only solutions like Seam.
Time will tell whether JRuby becomes a serious production language, but even if it remains in the "scripting" realm then the pseudo endorsement by Sun can only lead to more Java programmers giving it a go. Which IMO can only be a good thing.
If the only tool you have in your tool box is an hammer, then every problem you come across will look like a nail!
Paul.
|
|
|
Message #217720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform?
On a somewhat related note, Sun open sourced the StrongTalk VM yesterday. http://www.strongtalk.org
|
|
|
Message #217721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
1. I See static type checking as an optional subset of dynamic programming. In a dynamic language you can do both static and dynamic type checking if you choose (with the right annotations and tools), not so in a static language. Hence can a platform designed for a static language ever become the best "universal" platform?
On a somewhat related note, Sun open sourced the StrongTalk VM yesterday. http://www.strongtalk.org
Wow!
This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book.
Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too.
IMO, moving forward the platform will become more important then the language, so why lock yourself in to an inferior platform? Strongtalk with its polymorphic inline cache seems a lot more future proof then the JVM to me, ofcourse you would loose backward compatibility and access to a broad set of bytecode libraries.
For some this may be a trade off worth taking (in contrast to moving from Java to native Ruby say).
Lets see how long it takes for a Strongtalk based open source project to take off.
Sun are definately on a roll!
Paul.
|
|
|
Message #217729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java.
Have Ruby developers interest in exploring Java? Or are they just ex. Java developers? Either way, it does not seem more open or adventurous.
Java developers are quite far from being conservative IMHO. They might be in the middle somewhere, but hardly conservative. There is a group far more conservative and larger than the body of Java developers, if you ask me.
|
|
|
Message #217731
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
3. The Java community today IMO is mostly populated by people that are happiest in the middle of the herd. I guess this is the price of success. Java developers are conservative and I see no real interest in exploring alternatives beyond Java.
Have Ruby developers interest in exploring Java? Or are they just ex. Java developers? Either way, it does not seem more open or adventurous.
Java developers are quite far from being conservative IMHO. They might be in the middle somewhere, but hardly conservative. There is a group far more conservative and larger than the body of Java developers, if you ask me.
This is just pure opinion of course, and neither of us have any data to back any claim. I was a strong Java advocate back in 1996 where it seemed obvious to me Java's advantages over C++. At that time most C++ programmers where ridiculing Java as a toy in pretty much the same way many Java programmers ridicule Ruby today.
Also Java 1.0 was pretty limited. No event model (that turned up in Java 1.1), and hence no decent windowing toolkit. If wasn't fit for much more than simple applets. Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management.
Over time Java got better, and faster, and much of the C++ crowd where won over. It took two years where I where to finally convince them to pilot Java. I just see history repeating itself.
There are different types of personalities. Some people are constantly looking for ways to improve and push forward, others are happy with the status quo as long as they can find steady and reliable employment. As the Java bandwagon took off the "herd mentality" became firmly entrenched IMO. The focus became (premature) standardisation rather then innovation and technical excellence. With the right set of Java acronyms on your CV you knew that you where guaranteed to find work.
Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion.
Paul.
|
|
|
Message #217733
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
This is good, as long as we don't end up with scads of Ruby code that don't work in JRuby or Ruby code that only works in JRuby... Or Ruby code that needs 3 patches applied in order to run correctly.
The JRuby developers seem to be strongly emphasising compatibility, so I don't think this is going to be much of a worry.
But if Sun adds dynamic language support to the JVM, this will be good all around. .NET is ahead of Java on this one.
see JSR 292.
Well, one of the advantages of JRuby (over Plain Ole Ruby - POoR) is that is can use Java libs (I know you've said this).
The same is true of .Net versions of Languages. The purpose is not to have Perl or Java or Python or VB or... running in the CLR, but to have a syntax people are familiar with running in the CLR and thus can use other things written to that spec. Trying to use that code outside of .Net will be pretty difficult. Unless, of course, one avoids all the advantages of .Net.
|
|
|
Message #217744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion.
Paul.
I disagree with you 100%. I believe the best developers have a natural instinct of being skeptical about miracles, and they just jump to a new solution when they feel it's mature enough for their purposes.
They know there are trade-offs, and often when you gain something, like a feature, you lose something else, like simplicity, performance, etc.
I think that this move was the best Sun could do. And both Microsoft and now Sun are pulling the carpet from below the so called "dynamic languages". Once you get a good implementation (JRuby, Jython, IronPython, etc) with a good speed, that can easily be integrated with existing code, what's the point of using the original Ruby or the original Python?
Ruby, Python, etc are dead, so dead they don't even realize it yet. I see in the next 10 years the competition will be between platforms, the Java platform and its language forks against .Net and its language forks.
|
|
|
Message #217745
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Well, one of the advantages of JRuby (over Plain Ole Ruby - POoR) is that is can use Java libs (I know you've said this).
The same is true of .Net versions of Languages. The purpose is not to have Perl or Java or Python or VB or... running in the CLR, but to have a syntax people are familiar with running in the CLR and thus can use other things written to that spec. Trying to use that code outside of .Net will be pretty difficult. Unless, of course, one avoids all the advantages of .Net.
I think this could be the downfall of multi-platform dynamic languages.
IMO, one of the big weaknesses of today's popular dynamic languages is that so many of the libraries are written in C or C++ instead of in the language itself. This works because there is a single C/C++ codebase, but I think once ports to platforms like the JVM and CLR that promise huge high-quality libraries. The problem is once the developer starts using those libraries he is locked into a platform.
So instead of having a Ruby developer, you have JRuby developer and a CRuby developer and a Ruby.NET developer.
Let's face it - learning the syntax of most languages isn't that hard. It's learning the libraries. If a language doesn't have a big set of quality libraries that are the same on every platform, then it isn't a single language. This is even more true with dynamic languages.
For example, unlike Ruby, Python does not support multiple class definitions for the same class (meaning define part of it one place, then some more in another, etc). However, it's relatively easy to add such support using metaclasses by overloading __new__ to find the existing metaclass object instead of allocating a new one. Consequently, you can have a library containing a metaclass that does something that looks a lot like a language feature.
IMHO, this is the principle strength of dynamic languages - the line between language and library is thin and grey.
Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
|
|
|
Message #217752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Today IMO the type of C++ programmers who readily adopted Java back in 1996/7 is the same type of people taking a serious look at Ruby amongst other alternatives today. These people are in the minority IMO. The majority are pretty similar to the bulk of C++ herd back in 96; they just want to get paid. Like I said, this is just my opinion.
Paul.
I disagree with you 100%. I believe the best developers have a natural instinct of being skeptical about miracles, and they just jump to a new solution when they feel it's mature enough for their purposes.
They know there are trade-offs, and often when you gain something, like a feature, you lose something else, like simplicity, performance, etc.
I think that this move was the best Sun could do. And both Microsoft and now Sun are pulling the carpet from below the so called "dynamic languages". Once you get a good implementation (JRuby, Jython, IronPython, etc) with a good speed, that can easily be integrated with existing code, what's the point of using the original Ruby or the original Python?
Ruby, Python, etc are dead, so dead they don't even realize it yet. I see in the next 10 years the competition will be between platforms, the Java platform and its language forks against .Net and its language forks.
Sounds like you are reading things into my words, that I'm just not saying! And what is all this stuff about death?
I'm making a simple point. To exercise choice firstly you need to be informed. To become informed requires effort. Some just can't be bothered and find it easier to flow with the herd (whilst slinging mud at everyone else).
Hopefully an healthy ecosystem of languages supported on a common platform or on mutiple platforms will reduce the size of the herd, providing less of a place for developers to hide.
That way developers will have more of an incentive to actively choose what is the best tool for them, rather then just using the same as everyone else.
It looks like I've hit a nerve, and IMO the tone of your response just makes my point :^).
Paul.
|
|
|
Message #217754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I'm making a simple point. To exercise choice firstly you need to be informed. To become informed requires effort. Some just can't be bothered and find it easier to flow with the herd (whilst slinging mud at everyone else).
Hopefully an healthy ecosystem of languages supported on a common platform or on mutiple platforms will reduce the size of the herd, providing less of a place for developers to hide.
That way developers will have more of an incentive to actively choose what is the best tool for them, rather then just using the same as everyone else.
It looks like I've hit a nerve, and IMO the tone of your response just makes my point :^).
Paul.
I think you didn't understand anything of what I said at all.
You mentioned the similarities between C++ -> Java time, to a supposed "Java -> Ruby" happening now. First I disagree with that because what is driving the changes in Java land is .Net (as usual), not Ruby.
And I just said early adopters cannot be accounted as an "examples to follow". Java has come a long way to become a viable option and that is due to the work of many companies, not due to a few "enlightened" individuals.
The best developers have their reasons, and the reasons depend on the requirements, and the requirements go way beyond than just the code, for using this or that platform.
Second, I just illustrated what will happen to the "dynamic languages". Just use the logic. This is a death blow to their original implementations, and these forks will soon have more users than they ever had. Once they get more users, they will be free to add any "extensions" for improving it either for the JVM or for .Net.
I think this move is a sign of what is coming, it will help:
- To keep the Java ecosystem alive and competitive with .Net;
- To either kill or make it an isolated gueto of the original implementations (Ruby, Python, etc) by draining mindshare to a JVM language;
- The future to be platform vs. platform, not languages.
Record this day in your memory and 10 years from now tell me if I was right or not.
|
|
|
Message #217759
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
I think this could be the downfall of multi-platform dynamic languages.
IMO, one of the big weaknesses of today's popular dynamic languages is that so many of the libraries are written in C or C++ instead of in the language itself. This works because there is a single C/C++ codebase, but I think once ports to platforms like the JVM and CLR that promise huge high-quality libraries. The problem is once the developer starts using those libraries he is locked into a platform.
So instead of having a Ruby developer, you have JRuby developer and a CRuby developer and a Ruby.NET developer.
Let's face it - learning the syntax of most languages isn't that hard. It's learning the libraries. If a language doesn't have a big set of quality libraries that are the same on every platform, then it isn't a single language. This is even more true with dynamic languages.
For example, unlike Ruby, Python does not support multiple class definitions for the same class (meaning define part of it one place, then some more in another, etc). However, it's relatively easy to add such support using metaclasses by overloading __new__ to find the existing metaclass object instead of allocating a new one. Consequently, you can have a library containing a metaclass that does something that looks a lot like a language feature.
IMHO, this is the principle strength of dynamic languages - the line between language and library is thin and grey.
Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
I have been following the development of JRuby for some time, and my impression is that the developers are after as full an implementation of the core libraries as possible, and are working with the developers of many C-based libraries to get Java ports. The aim is for C-based Ruby applications to run unchanged on the JVM. It looks, at least for now, like JRuby and Ruby should share the set of quality libraries that you suggest is needed to avoid incompatibility.
|
|
|
Message #217762
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Ultimately you'll end up with libraries with language feature-esque functionality that are dependent on a given platform's libraries rather than the core language libraries - which from a practical standpoint will mean multiple incompatible versions of the same language.
Hi Erik,
You make a good point, but I don't believe library compatibility should be the single overriding concern. Ofcourse the language should be standard on all platforms and the languages standard library should be standard too, but beyond that I see no problem with libraries that start out on one platfrom (VM) or the other.
Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
Secoundly, I would agree with you if the libraries we are using today where stable and likely to last any decent length of time. In the last 10 years if I was interested in a container based persistence API for Java, I would have probably started with EJB2.1 or Toplink or perhaps plain JDBC and DTO's, maybe then moving on to JDO1.0 or maybe JDO2.0 or maybe Castor then perhaps to Hibernate and ultimately today I would be looking at JPA.
And this is something as basic as persitence. These things aren't stable and are likely to last only a few years at most before being superceeded. This is the nature of the sofware industry, it is still very immature and we have very few "stable" standards.
I've come to the view over the years that experimentation and exploration and finding the best tool for the job is more important both in the short term and the long term then compatibility and standards. Projects where they have made good technology choices by perhaps initially experimenting with a few tools before settling on something that works well for them, in my experience tend to be much easier to maintain, also they tend to be much easier to upgrade or interface to newer technology and in that way are longer lived.
Scenarios where people have just used the latest standard whether or not it is well suited, tend to lead to poor code that is short lived (shorter lived then the standard used) and expensive to produce in the first place and then to maintain, leading to a short life before being re-written.
In time if an approach is successful it is more than likely to turn up on all platforms as a defacto standard. I think things like Hibernate and Spring are good examples of this.
Just an opinion, although somewhat contrary :^)
Paul.
|
|
|
Message #217761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Lets see how long it takes for a Strongtalk based open source project to take off.
Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
|
|
|
Message #217763
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Lets see how long it takes for a Strongtalk based open source project to take off.
Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
Well, I wasn't holding my breath to see the VM source code open sourced. I didn't expect Sun to take Ruby support on the JVM seriously either.
Fortunately there are a lot of knowledgeable people out there bot inside and outside large companies like Sun, that feel that it is time for change. If they are right then anyone who chooses to graft say Ruby onto Strongtalk and port the C++ VM code to several platforms (a relatively trivial task) could end up being the next JBoss.
I'm not holding my breath. I think I'll just wait and see :^)
Paul
|
|
|
Message #217766
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Lets see how long it takes for a Strongtalk based open source project to take off.
Considering there are already good Smalltalk implementations, the StrongTalk dialect is not widely known, and the current version is Win32-only, my advice would be - don't hold your breath.
Besides, a quick look at the website shows that the project still lacks many basic stuff, like automatic GC, multithreading, etc., and is not recommended for production yet. It still has a long way before catching up with JVM in many aspects, although it may be more advanced in some specific areas.
|
|
|
Message #217767
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
(emphasis mine)
Does it work well for C++? How long did it take? How much angst must C++ programmers go through in order to achieve portable code?
Don't get me wrong - C++ has been and remains an enormously successful language. But I think much of Java's success has nothing to do with using a VM or having a GC or being "binary compatible" across operating systems and processor architectures as it does with having a rich standard library that is the same (or close enough) across platforms. In earlier years even implementation of core language features varied widely.
IMHO, Java and C# are "beating" C++ not because they are based on superior languages or technologies, but because they are not fragmented.
Preventing fragmentation stifles innovation, but excess fragmentation has the same effect. Take a look at strings in C++. How many C++ libraries are there out there that instead of using standard C++ strings, use their own implementation or simply use C-strings? Do you know what happens when two libraries that use two incompatible string-class implementations have to interact? They use C-strings instead. The have to use the lowest common denominator.
So with Java we have frameworks that are hodge-podges of countless opensource libraries. Do you think that would be a pragmatic thing to do if every one included it's own custom string class?
Sometimes you just need to standarize, and consistently enforce the standard, even if that standard isn't going to be perfect. Otherwise people constantly reinvent the wheel.
|
|
|
Message #217769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Firstly, with much of the real innovation occuring open-source knowadays it is easy to port across a number of different platforms as long as you have access to the source. Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
(emphasis mine)
Does it work well for C++? How long did it take? How much angst must C++ programmers go through in order to achieve portable code?
Don't get me wrong - C++ has been and remains an enormously successful language. But I think much of Java's success has nothing to do with using a VM or having a GC or being "binary compatible" across operating systems and processor architectures as it does with having a rich standard library that is the same (or close enough) across platforms. In earlier years even implementation of core language features varied widely.
IMHO, Java and C# are "beating" C++ not because they are based on superior languages or technologies, but because they are not fragmented.
Preventing fragmentation stifles innovation, but excess fragmentation has the same effect. Take a look at strings in C++. How many C++ libraries are there out there that instead of using standard C++ strings, use their own implementation or simply use C-strings? Do you know what happens when two libraries that use two incompatible string-class implementations have to interact? They use C-strings instead. The have to use the lowest common denominator.
So with Java we have frameworks that are hodge-podges of countless opensource libraries. Do you think that would be a pragmatic thing to do if every one included it's own custom string class?
Sometimes you just need to standarize, and consistently enforce the standard, even if that standard isn't going to be perfect. Otherwise people constantly reinvent the wheel.
Hi Erik,
What you say just isn't born out in my experience. I've written several bits of software in C++ using MS Visual C++, that I then ran on Unix, with nothing more than a recompile. If you write portable code (stick to cross platform API's like POSIX for instance) then you're fine.
I tend to hold library programmers to a higher standard then application programmers and I think that portable libraries are well within their grasp.
As for having to use the lowest common denominator for compatibility, well we have that today - look at web services :^). But seriously, the number of conflicting and incompatible Java API's are tremendous, for example JDO versus EJB, or PicoContainer versus Spring, and having to swap from one API to the next each time you move to a new project is a tremendous overhead. With the proliferation of further so called standard API's that you need to know, I see things just getting worst. My CV as already got enough TLAs to fill a page as it is :^).
I don't think that cross platform language support will make things any better or any worst then they are today for application programmers. Granted library and framework programmers will have a little more work to do, but it's warranted IMO.
Paul.
|
|
|
Message #217768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Wow!
This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book.
Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too.
You gotta wonder where we things would be right now if Sun had gone down the Self/Strongtalk VM route. Well, technically Sun did incorporate some Self VM ideas into the JVM. But it would have been interesting to have had a Strongtalk environment, along with a Algol-like language.
|
|
|
Message #217772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
Wow!
This is great news! IMO The Strongtalk VM is a much better starting place then the JVM. Ruby running on Strongtalk with Smalltalk integration would be a winner in my book.
Using Strongtalks support for static typing, Java and C# could be ported to Strongtalk too.
You gotta wonder where we things would be right now if Sun had gone down the Self/Strongtalk VM route. Well, technically Sun did incorporate some Self VM ideas into the JVM. But it would have been interesting to have had a Strongtalk environment, along with a Algol-like language.
+1
Agreed. Our industry is obsessed with short-termism. We tend to opt for short term gain, leading to long term pain. We then to re-invent ourselves every ten years or so. If we where to stop and take a long term view we could save ourselves so much wasted time and effort IMO.
My view is that eventually we will work our way back to the future. Back to the 80's or should I say Smalltalk-80 :^).
Paul.
|
|
|
Message #217773
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
>Perhaps the Ruby guys needed a java job:)
I doubt it. I don't understand all the negativity toward Ruby here. Is it fear? Java will be a success for many years to come. In just the way C++ is still a success , Java will be too, if a popular "rival" language takes off. Java itself hasn't taken everything away from C++, there are still many problem areas (e.g. finance anlytics) that will be dominated by C++, thats not to say Java is poor. Languages should be used when they're the right tool for the job. A few years ago you couldn't move for the number of projects 'done' with EJB - even if EJB were a poor solution for that particular problem. People learnt they're lessons.
To suggest some coders are poor b/c they've a personal preference over Java , or C++, or Ruby ... is plain ridiculous.
|
|
|
Message #217774
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
What you say just isn't born out in my experience. I've written several bits of software in C++ using MS Visual C++, that I then ran on Unix, with nothing more than a recompile. If you write portable code (stick to cross platform API's like POSIX for instance) then you're fine.
(emphasis mine)
I've done the same and had the same experience. I've also tried to do the same and had awful experiences. It depends on the Unix, the compiler, and the libraries (although all my awful experiences have involved HP's C++ compiler on HP-UX...)
Experience with code written by other people (especially ones long gone) and 3rd parties has been worse.
The huge quantity of portable open-source C++ software out there proves that it can be done with a little discipline. The problem is often times that's more discipline than can be obtained...especially when "cross platform" isn't an immediate requirement.
I'm not really worried about libraries and frameworks high up on the stack. The problem is difference in fundamental language constructs. Java and Python have immutable standard strings. C++ and Ruby have mutable standard strings. There's differences in standard containers and iterators as well.
Sure, these differences can be hidden. But I think at the end of the day people programming Ruby-on-JVM and leveraging Java libraries/frameworks just start using the native strings/containers/etc. Ditto for .NET.
I don't think that cross platform language support will make things any better or any worst then they are today for application programmers. Granted library and framework programmers will have a little more work to do, but it's warranted IMO.
It will probably make it better for application programmers in the short term, but in my opinion in may delay progress by creating confusion. You'll get a lot of people calling themselves Ruby developers who are really JRuby developers, or vice versa. That dillutes the meaning of the term, and makes managers think Ruby isn't a real skill.
I personally think dynamic languages for the JVM should be designed from the ground-up for the JVM with other dynamic languages as inspiration, rather than simply porting the languages. The ideas behind the languages are far more important than the languages themselves, so there is no point in introducing a bunch of impendance mismatches in the name of porting the languages.
Anyway, that's just my opinion right now.
|
|
|
Message #217799
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
How about Groovy? It seems they are dead... :(
I think groovy will ulitimately be a more useful choice than ruby or jruby. Groovy offers many of the same elegent dynamic OO syntax improvements that ruby offers. However, it's objects are "true" java objects. They compile to bytecode, support seamless integration with java bytecode, support interfaces, abstract classes, etc... With ruby you will have java implementations of the ruby class libraries that compete with equivalent functionlality implemented by the java libraries. Considerer something like grails, the groovy counterpart to rails. It uses spring and hibernate behind the scenes.
This means that groovy progress is measured solely by the implementation of the syntax, not by class library development (because there are none!). Once the syntax becomes stable, it will be immediately useful to code to java libraries you already know. Until then, it's risky. This sort of all-or-nothing aspect to groovy has caused a number of people to (correctly) assess it's current usability as "nothing" and to (incorrectly) bash it, proclaim it as dead on arrival, etc... Hogwash!! The moment the syntax is stable it will toggle from "nothing" to "all".
So, how is this progress? Well, it's slow but steady. As of this moment, groovy is down to 7 jira issues that are "blockers" before release candidate 1 rolls out. So no, groovy is not dead. My guess is that 3 or 4 RC releases will happen and then 1.0 will hit. A year from now there will be a lot of excitement about groovy as people realize that 1) it exists and they can use it without porting anything and 2) it's interoperability with the volumes of java class libraries gives it an undeniable advantage over ruby.
|
|
|
Message #217803
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
A year from now there will be a lot of excitement about groovy as people realize that 1) it exists and they can use it without porting anything and 2) it's interoperability with the volumes of java class libraries gives it an undeniable advantage over ruby.
I agree. Also, I believe that as Grails progresses this will encourage far wider adoption of Groovy; the JVM should then have an alternative to Rails that is faster, easier to use with legacy systems, and unlike the 'opinionated' approach of Rails, works well in 'enterprise' environments as well as for smaller, 'greenfield' projects.
|
|
|
Message #217814
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
It will probably make it better for application programmers in the short term, but in my opinion in may delay progress by creating confusion. You'll get a lot of people calling themselves Ruby developers who are really JRuby developers, or vice versa. That dillutes the meaning of the term, and makes managers think Ruby isn't a real skill.
Hi Erik,
I see your point. One way around this would be to get the compiler to enforce the use of the standard library or at least provide a warning.
So for example if you use an Integer in JRuby code instead of using a Fixnum then the compiler should complain. After all this is just as inappropriate as a syntax error. IMO the language standard is the syntax, and the associated semantics and the standard library.
Otherwise like you say you are just not writing Ruby.
I personally think dynamic languages for the JVM should be designed from the ground-up for the JVM with other dynamic languages as inspiration, rather than simply porting the languages. The ideas behind the languages are far more important than the languages themselves, so there is no point in introducing a bunch of impendance mismatches in the name of porting the languages.
I've got my concerns with bolting on dynamic behaviour to an otherwise static environment. If you go through the gang of four design patterns you will see that most of them are language (C++ like) specific. For example things like Iterators just do not exist in Smalltalk, and what is the use of a factory pattern when every class is an object with the instance method new?
I can see this problem occuring in Java 1.7 when closures finally arrive. How long will it take for some one to write a Smalltalk style collections API using closures? And with closures what is the point of an inner class based API like Swing? New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy.
But like you I could change my mind in time :^)
Paul.
|
|
|
Message #217816
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
I must be misunderstanding. Hibernate and NHibernate have completely different codebases. Or, are you simply describing the Utopia that would exist if things changed such that they could use the same codebase?
|
|
|
Message #217818
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Examples of this are Hibernate (JVM) and NHibernate (.Net). The same source all you need to do is recompile for each platform (VM), this works well for C++, so why not Java or Ruby?
I must be misunderstanding. Hibernate and NHibernate have completely different codebases. Or, are you simply describing the Utopia that would exist if things changed such that they could use the same codebase?
Yeap, I realised this mistake after I posted, but I'm sure you get the idea. Successful API's tend to find their way onto all the leading platforms, whether through re-implementation or simply through porting.
Paul.
|
|
|
Message #217824
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Otherwise like you say you are just not writing Ruby.
Which is the case of all the "languages" available for .Net (or the CLR).
|
|
|
Message #217825
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Successful API's tend to find their way onto all the leading platforms, whether through re-implementation or simply through porting.
Paul.
I wish Hibernate 3+ would find its way.
|
|
|
Message #217826
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Otherwise like you say you are just not writing Ruby.
Which is the case of all the "languages" available for .Net (or the CLR).
It looks like JRuby has achieved a lttle better than this. As I understand it just from reading the docs on the website they map standard Java types to ruby and visa-versa:
...conversions are automatically done for numbers, booleans and strings, both to and from Java. However, it does *not* convert collection and array types like the old Java support did.
Not sure why they stopped converting collections and arrays. This type of mapping seems analogous to what you get with CORBA and IDL when calling across languages.
I guess the platform would need to define a set of standard types and each language binding would need to define the appropriate mapping, just like CORBA (not sure what this would do to performance!).
It is definately an issue that needs to be addressed before a VM can claim cross language support IMO. It's interesting that .NET doesn't bother.
Paul.
|
|
|
Message #217830
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy.
But that would be completely pointless for Groovy, as the whole idea of the language is to provide scripting for existing Java libraries and classes. If you added new libraries you would end up with the same issues that JRuby is having to deal with; it would defeat the purpose of the Groovy language.
Having used Groovy for a while, I really can't see any issues with the way it works with existing Java libraries.
What specific issues have you come across?
|
|
|
Message #217834
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
What specific issues have you come across?
Hi Steve,
I'm still open minded. I haven't used Groovy, and I guess it comes down to what you're looking for in a dynamic language.
For me meta-facilities and DSLs are key. So the idea of using a dynamic language with the same old static libraries and frameworks doesn't appeal. I can see the general appeal though. Using Groovy to dynamicaly knit together Java code has got to be better then using XML.
I guess if a compelling use case emerges then I'll pay more attention, but at the moment Groovy is not high on my list of technologies to watch.
Paul.
|
|
|
Message #217836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
What specific issues have you come across?
Hi Steve,
I'm still open minded. I haven't used Groovy, and I guess it comes down to what you're looking for in a dynamic language. For me meta-facilities and DSLs are key. So the idea of using a dynamic language with the same old static libraries and frameworks doesn't appeal. I can see the general appeal though. Using Groovy to dynamicaly knit together Java code has got to be better then using XML.
I guess if a compelling use case emerges then I'll pay more attention, but at the moment Groovy is not high on my list of technologies to watch.
Paul.
If you looked at Groovy you would sould see that it has meta-facilities and the ability to develop DSLs, pretty much like Ruby (with especially nice things like the builder syntax). Such capabilities are what makes things like Grails dynamic methods possible. This means you aren't using 'the same old static libraries and frameworks' - you can take innovative new approaches. Even a quick look at Grails (and especially GORM) will reveal a dramatically different way of working from static Java.
It is far more than just a dynamic language with a few syntax enhacements sitting above Java libraries, and my view is that an understanding of what is available on the JVM is incomplete without at least some knowledge of Groovy.
|
|
|
Message #217838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Hi Steve,
Grails (and especially GORM) will reveal a dramatically different way of working from static Java.
Tanks for the pointer.
Paul.
|
|
|
Message #217844
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Hi Steve,
Grails (and especially GORM) will reveal a dramatically different way of working from static Java.
Tanks for the pointer.
Paul.
I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
|
|
|
Message #217848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
It's seemingly conflicting actions like this that worry me most about Sun. Now, 2 guys working on JRuby isn't exactly a major investment. How many people work on Java? But it's not really clear how it fits into the big picture.
|
|
|
Message #217851
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
It's seemingly conflicting actions like this that worry me most about Sun. Now, 2 guys working on JRuby isn't exactly a major investment. How many people work on Java? But it's not really clear how it fits into the big picture.
Also, I read Tim Bray talk about "integrating Rails into existing Java frameworks and applications". My reaction is.... What does that mean? It makes no sense to me at all... Rails is targetted at a specific niche, and as far as I can tell, intends to remain there. Quite how it is supposed to be integrated with more enterprise-based Java approaches, and what the point of is this puzzles me greatly. For we have (in my view) far better persistence frameworks in Java, such as JDO 2.0 and JPA - faster, more portable and more scalable. I would imagine a JRuby framework that integrates with those might be theoretically possible (although I get a headache trying to think about it), but that would not be Rails by any stretch of the imagination. And, this is the sort of thing Groovy was designed for from the ground up.
I can at least see the point of trying to make the JVM a good platform for RoR. I can also see uses for Ruby as an alternative language on the JVM, but the above statement makes no sense to me at all..
|
|
|
Message #217854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Paul,
I see your point. One way around this would be to get the compiler to enforce the use of the standard library or at least provide a warning.
So for example if you use an Integer in JRuby code instead of using a Fixnum then the compiler should complain. After all this is just as inappropriate as a syntax error. IMO the language standard is the syntax, and the associated semantics and the standard library.
Ahhh, we agree now on the importance of the relationship between the library on the language. I suspect we always did, it was just a matter of communication. However, I think we disagree on the importance of the library.
I've got my concerns with bolting on dynamic behaviour to an otherwise static environment.
Rightly so. I think the JVM needs to evolve to support dynamic languages (e.g. invokedynamic) and I'm sure the standard library does as well.
If you go through the gang of four design patterns you will see that most of them are language (C++ like) specific.
I agree on the surface, but I don't think this is really true. I think the GoF design patterns are more about using object orientation and polymorphism to effectively leverage indirection without creating a tangled mess. The way of thinking that goes into them is more important than the patterns themselves.
what is the use of a factory pattern when every class is an object with the instance method new?
Either you and I have a very different understanding of the factory pattern or I have no understanding of the Smalltalk class object instance method new.
I can see this problem occuring in Java 1.7 when closures finally arrive.
I personally hope they never arrive. I've long been opposed to keeping out language features for fear the will be abused, but I think I have to draw the line on closures. I'd rather see support for nested functions (ala Pascal) and better syntax for functors. If in wasn't for the breakage that would result I'd be fine with dropping anonynmous inner classes as well.
New language features call for new libraries in my opinion, which is why I'm currently not that enthusiatic about Groovy.
I think this is a big "it depends." Throwing out all the Java libraries just doesn't seem like a good idea. They're not perfect - but they're huge. IMHO, they are more important than the Java language and the JVM. Java can be natively compiled. Java bytecode can be generated from other languages. But the libraries provide the unity of the platform. That's where I think the value is.
But you're right - if a language deviates too far from Java conventions then it should not use Java's standard libraries. It should have it's own.
|
|
|
Message #217859
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
>It seems to me to give developers an odd choice - pick a JSR >language with seamless integration with Java and libraries OR >pick a language with far less integration, some conflicting >classes that require work-arounds, but is funded by Sun. >Hmm..
Your argument is based on the idea that compatibility with Java is some sort of goal for any new language it's not. Java has its uses, but its not a universal solution for every problem.
|
|
|
Message #217863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
>It seems to me to give developers an odd choice - pick a JSR >language with seamless integration with Java and libraries OR >pick a language with far less integration, some conflicting >classes that require work-arounds, but is funded by Sun. >Hmm..
Your argument is based on the idea that compatibility with Java is some sort of goal for any new language it's not. Java has its uses, but its not a universal solution for every problem.
I may not have been clear. I am not trying to say that - I can see uses for languages on the JVM that don't have Java compatibility; but my understaning of what Tim Bray has said is Sun is positioning JRuby as a language that will have compatibility and integration with Java. That is what is confuses me, as there are better solutions for that role.
|
|
|
Message #217869
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
RoR is hyped (the net effect) over the past year or so by TSS and other Java sites, IronPython 1.0 gets released, and a day or two later the JRuby guys are hired by Sun.
There's been quite a bit of grumbling on the groovy-dev list over the past few days about a lack of funding from Sun.
|
|
|
Message #217879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Black Hole's and "innovation"
Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management.
Ok, here's another theory. There's this "Black Hole" theory Gosling was talking about recently:
http://blogs.sun.com/jag/entry/the_black_hole_theory_of
Goes something like this: "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". (quoted above)
I have another theory. There are some fairly cool programming languages. They do some very cool things. But people have a hard time grasping them. For example, most people only see parentheses when they see LISP, they can't get past the syntax. And Smalltalk is just weird.. and way too touchy feely (see Squeak for example).
So people tend to take the safe road. C++ was ok because it was just enhanced C. Java was ok, because we needed the sandbox (originally), the portability and it was a lot like C++ in syntax. Yet Java allowed us to reach a much larger potential than C++ did. It helped us see some of the cool features of Smalltalk and Self that we'd previously dismissed as weird.
Now comes Ruby.. an language that is almost a replica of Smalltalk (minus the environment, minus the same level of cleanliness, minus the baby look, etc..). Ruby allows us to see the advantages of that older language.. so interest builds up and we get all excited about this "innovation".
20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
|
|
|
Message #217882
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
I would still not say Groovy is ready yet... but 1.0 is likely to be out soon, and then I will be far less cautious. However, this range features of Groovy does raise some issues. Why isn't Sun putting more effort into backing it? It has most if not all the features of Ruby. It seems to me to give developers an odd choice - pick a JSR language with seamless integration with Java and libraries OR pick a language with far less integration, some conflicting classes that require work-arounds, but is funded by Sun. Hmm..
RoR is hyped (the net effect) over the past year or so by TSS and other Java sites, IronPython 1.0 gets released, and a day or two later the JRuby guys are hired by Sun.
There's been quite a bit of grumbling on the groovy-dev list over the past few days about a lack of funding from Sun.
Indeed. Quite understandable grumbling, in my view. The more I think about the promotion of JRuby, the more it seems to be purely a marketing decision and not a decision based on technical merit. The JRuby guys have done a great job, but for Sun to position JRuby as a real alternative to Groovy is seriously misjudged, and does not do justice to the work put into Groovy by many developers over the years.
|
|
|
Message #217885
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
|
|
|
Message #217886
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
Preventing fragmentation stifles innovation, but excess fragmentation has the same effect.
Slightly off-topic, but you could almost say the same about Linux distributions. The fact that everyone and their grandmother has decided to do it "their" way, just annoys me to no end. If there were like 3 to 5 distributions (and no others), with perhaps varying philosophies between them, I believe Linux will have gained even more popularity on both, server and desktop, and people, instead of wasting braincells on making the "perfect" distroy, could be adding _functionality_, which is what sells - both in terms of profit and wide adoption.
But then again,I assume everyone here knew that... Last thing we want is too much fragmentation of the Java platform.
|
|
|
Message #217887
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago,
Becomes an issue for what implementation of what language? The commercial implementations of Common Lisp don't have performance issues. Dylan was/is fast. Strongtalk has a very fast VM. Ruby's implementation is irrelevant to everybody else.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
The advantages of static typing were never lost to be re-discovered. Most language research is done in the ML/Haskell family.
|
|
|
Message #217888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
Hi Steve,
I've seen you make this argument again and again, but I'm sorry it just isn't supported by the facts. I've spoken to several true Smalltalk developers over they years, who have written thousands of lines of production Smalltalk code mostly in critical environments like banking (the City of London), and none of them agree with what you say.
Infact try making this assertion on a Smalltalk forum and I'm sure that you'd be linched (metaphorically :^)).
All the ex-Smalltalkers I know are drepressed that they have to program in Java to make a living and would return to Smalltalk at the drop of an hat if they knew they could find secure work. This is the thing about herds, not everyone in the herd actually chooses to be there, many just get swept along!
Anecdotel I know, but we had a ex-Smalltalker on my last team (who incidently wrote the simplest and cleanest code I've seen for years) who was generally dis-interested and didn't particpate much in technical team decisions. One day I came in with a copy of the Purple book (the Smalltalk bible), and he came up to me a different man, all energised and enthusiatic - "Oh great, with Smalltalk we'll knock this out in days". I had to explain that I was just doing stuff in my spare time and we weren't using Smalltalk, the change is his body language was enormous.
For a person who likes to see claims backed by facts, how about comming up with some facts of your own? Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
Most of the best programmers out there (Kent Beck, Ward Cunningham, Ron Jeffries, Ralph Johnson, Gilad Bracha (Sun), Dave Griswold (Sun), etc), just to name a few come from a Smalltalk background and if you read their blogs you will see that they would all go back to Smalltalk in an instance if they got the chance.
BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^).
Take a look yourselves:
http://tech.groups.yahoo.com/group/strongtalk/messages
Smalltalk is a muched loved language.
Paul.
|
|
|
Message #217890
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago,
Becomes an issue for what implementation of what language? The commercial implementations of Common Lisp don't have performance issues. Dylan was/is fast. Strongtalk has a very fast VM. Ruby's implementation is irrelevant to everybody else.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
The advantages of static typing were never lost to be re-discovered. Most language research is done in the ML/Haskell family.
Hi Frank,
Exactly. The demise of Smalltalk had nothing to do with static typing. Try commercial mis-management like the infamous suicide note from ParcPlace Systems:
http://www.listserv.dfn.de/cgi-bin/wa?A2=ind9703&L=info-cls&D=0&T=0&P=36059&F=P
(A link to the original internal e-mail is out there somewhere)
And the fact that a single Smalltalk developer license would set you back around £3000 at the time (I think, some massive amount anyway), compared to Java which was free and marketed like crazy, and you can see why the writing was on the wall.
Smalltalks big percieved advantage over C++ was memory management. Java had "borrowed" that along with byte code and the use of a VM, and was free. So Java was seen by many as a "good enough" Smalltalk.
Like I mentioned earlier - we suffer from short-termism. So here we are again 10 years later picking through the bones of Smalltalk/Lisp for what we can "borrow" next!
Paul.
|
|
|
Message #217898
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Portability
And, this is the sort of thing Groovy was designed for from the ground up.
I can't believe someone actually used "Groovy" and "design" in the same sentence, without the latter being preceeded by strong, ferm negation or pointing out lack thereof.
|
|
|
Message #217919
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Yet I could see the advantages based on fundamental features "borrowed" from Smalltalk, like the use of byte code, a machine independent VM, and automatic memory management.
Ok, here's another theory. There's this "Black Hole" theory Gosling was talking about recently:
http://blogs.sun.com/jag/entry/the_black_hole_theory_of
Goes something like this: "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". (quoted above)
I have another theory. There are some fairly cool programming languages. They do some very cool things. But people have a hard time grasping them. For example, most people only see parentheses when they see LISP, they can't get past the syntax. And Smalltalk is just weird.. and way too touchy feely (see Squeak for example).
So people tend to take the safe road. C++ was ok because it was just enhanced C. Java was ok, because we needed the sandbox (originally), the portability and it was a lot like C++ in syntax. Yet Java allowed us to reach a much larger potential than C++ did. It helped us see some of the cool features of Smalltalk and Self that we'd previously dismissed as weird.
Now comes Ruby.. an language that is almost a replica of Smalltalk (minus the environment, minus the same level of cleanliness, minus the baby look, etc..). Ruby allows us to see the advantages of that older language.. so interest builds up and we get all excited about this "innovation".
20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
+1
Hi Amin,
Just found the ParcPlace scuicide letter I mentioned earlier:
http://www.parcplace.com/whatsnew/letter_r.htm
I like the black hole analogy. Despite our best efforts to "dumb down", Smalltalk and Lisp still live on in a number of guises.
I agree with Gosling we are living through interesting times. What happens over the next year or two will be very interesting to watch.
Paul.
|
|
|
Message #217933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
20 years ago Smalltalk and Lisp users (a very small group) were talking about the advantage of VMs, garbage collection, and dynamic typing. But people were not ready for it then. Now it is being repackaged in a more favorable environment (more favorable because CPUs are much better now, and RAM is cheap).
That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
There is little new in software development, and there seems to be a tendency to ignore the lessons of the past.
Hi Steve,
I've seen you make this argument again and again, but I'm sorry it just isn't supported by the facts. I've spoken to several true Smalltalk developers over they years, who have written thousands of lines of production Smalltalk code mostly in critical environments like banking (the City of London), and none of them agree with what you say.
Infact try making this assertion on a Smalltalk forum and I'm sure that you'd be linched (metaphorically :^)).
All the ex-Smalltalkers I know are drepressed that they have to program in Java to make a living and would return to Smalltalk at the drop of an hat if they knew they could find secure work. This is the thing about herds, not everyone in the herd actually chooses to be there, many just get swept along!
Anecdotel I know, but we had a ex-Smalltalker on my last team (who incidently wrote the simplest and cleanest code I've seen for years) who was generally dis-interested and didn't particpate much in technical team decisions. One day I came in with a copy of the Purple book (the Smalltalk bible), and he came up to me a different man, all energised and enthusiatic - "Oh great, with Smalltalk we'll knock this out in days". I had to explain that I was just doing stuff in my spare time and we weren't using Smalltalk, the change is his body language was enormous.
For a person who likes to see claims backed by facts, how about comming up with some facts of your own? Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
Most of the best programmers out there (Kent Beck, Ward Cunningham, Ron Jeffries, Ralph Johnson, Gilad Bracha (Sun), Dave Griswold (Sun), etc), just to name a few come from a Smalltalk background and if you read their blogs you will see that they would all go back to Smalltalk in an instance if they got the chance.
BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^).
Take a look yourselves:
http://tech.groups.yahoo.com/group/strongtalk/messages
Smalltalk is a muched loved language.
Paul.
Sorry, but it is clearly supported by fact. If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed, and as for the namespace issue, you need look no further than any commercial Smalltalk to see how these matters are having to be dealt with. As an experienced Digitalk Smalltalk user in the 80s, I had to deal with exactly this kind of namespace clash when installing libraries and extensions.
Sorry Paul, but just because many well-known high-profile developers and some you have spoken too like the language, and can be productive with it, does not mean that these issues don't exist. You can't hand-wave away well-established issues simply because certain people are productive with Smalltalk in certain applications. This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.
This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?
I like Smalltalk a lot too, but I realise its limitations.
|
|
|
Message #217938
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sun Hires the JRuby-guys
I'm very excited about this. I think this is one of the first steps in making Java a language for languages, in much the same way C is right now. It's just a natural progression in my mind.
And of course I can wait until I can WAR up a Rails app and deploy it to Tomcat ;)
+1
|
|
|
Message #217939
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)
It will be interesting to follow this - the big step will to get the thing cross-platform.
I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!
|
|
|
Message #217945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Steve,
No I think you are the one doing all the hand-waving.
Frank made the point about Smaltalk and performance which I agree with. At one time performance was a problem for Smalltalk, but you disagreed:
I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well.
A bit of flip-flopping going on here I think.
With regards to name spaces, yes I agree too that this was an oversight in Smalltalk-80 and I don't care much for the later commercial solutions either. If you had made this specific point, I would have responded to it in kind but you didn't.
Your points were:
The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
And
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
Now I don’t know what the size of a project has got to do with performance. Either the language is performant or it’s not, which is it? And I don’t see what namespaces has to do with open classes, the two issues are orthogonal. Also throwing in static typing as a solution for all ills at the end doesn’t strengthen your argument either.
Several people responded, (Frank, Amin and myself) highlighting your folly yet you continue to respond in the same vein.
Now I know that you have decided for your organisation that Java should be the standard, fine. Justifying your decision with mis-information and black-propaganda after the fact doesn't help. I challenge your to find a single blog entry from an experienced Smalltalk programmer who agrees in anyway with your assessment. There are people on this forum who have never tried a number of the languages we are discussing so we have a responsibility to be honest and truthful.
So again:
Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
A bad workman blames his tools. I agree that with power comes responsibility and languages like Lisp and Smalltalk provide the developer with a great deal of power. I think the correct term is that these languages are highly "expressive" meaning a lot of functionality for very little code.
I want a language with inherent power, so do many framework and library authors. This power does not have to be used by every day application developers as clearly demonstrated in Rails (and Spring and Hibernate and JBoss etc) and policing it’s use is a cultural issue in my view not a technical one (although there are technical solutions in the pipeline, see Martin Fowlers discussion on Language Workbenches). You don’t hear people saying that dynamic proxies or the reflection API should be removed from Java because it is too dangerous for the average programmer. The truth is that the average Java programmer seldom if ever uses these features. If you are a framework programmer though writing JBoss, or involved with Spring or Hibernate then these features are priceless and the real truth is that you could do with a lot more.
Even Gosling admits that his attempt to "police" developer power in Java with inner classes has lead to somewhat of a kludge. If even he can concede, I can't see why you can't. lLisp and Smalltalk just provide a lot more meta-capabilities “designed in” from conception through dynamic typing and late-binding.
The names I mentioned are not my mates, the list includes the names of people that got your beloved JVM running half decent. People like Gilad Bracha who have views that are considerably different from yours. So please make your specific points and I will respond to them as such. Otherwise cut out the noise.
Regards,
Paul.
|
|
|
Message #217946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)
It will be interesting to follow this - the big step will to get the thing cross-platform.
I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!
You may not have noticed but Strongtak is Smalltalk. Like I said make your specific point, or get back on topic.
Paul.
|
|
|
Message #217947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
BTW: I've been posting on the Strongtalk discussion group. The offers of help have been flooding in. Infact the first task (get the build working on modern MS Visual C++) has been done by a contributor before a repository for code fixes has been setup. People are distributing fixes by e-mail :^)
It will be interesting to follow this - the big step will to get the thing cross-platform.
I can't help but point out that you are talking about a language that was specifically designed to overcome performance issues with Smalltalk!
You may not have noticed but Strongtak is Smalltalk. Like I said make your specific point, or get back on topic.
Paul.
My point is that StrongTalk was implemented because of performance and other issues with conventional Smalltalk implementations.
|
|
|
Message #217949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
A bit of flip-flopping going on here I think.
No. This was in response to a claim that people were 'not ready' for the features of Smalltalk and LISP 20 years ago, and that improvements in hardware have changed this. The relatively widespread use of Digitalk Smalltalk (not that small a group!) 15-20 years ago is evidence against this claim.
Now I don’t know what the size of a project has got to do with performance. Either the language is performant or it’s not, which is it?
As described below in a quote from Dave Griswold, there are many issues that only arise in larger applications. As an application grows, new functionality can be added, and it is likely that at some point, such functionality can require high performance. Specific cases I have come across with Smalltalk were XML parsing and image processing.
And I don’t see what namespaces has to do with open classes, the two issues are orthogonal.
No, they aren't. The issue is about how extensions to the language can conflict. In Smalltalk this can happen when new methods are loaded from one package that conflict with those from another. The situation with open classes is worse, as the same conflicts can happen at run time. Smalltalk has attempted to resolve such matters with namespaces.
Also throwing in static typing as a solution for all ills at the end doesn’t strengthen your argument either.
I never said it was a solution to all ills, just that it can help.
Several people responded, (Frank, Amin and myself) highlighting your folly yet you continue to respond in the same vein.
Facts aren't a matter of votes on a thread.
Now I know that you have decided for your organisation that Java should be the standard, fine. Justifying your decision with mis-information and black-propaganda after the fact doesn't help.
As I have said before I use a range of languages. I use Java, Groovy, Ruby, Python - whatever suits.
I challenge your to find a single blog entry from an experienced Smalltalk programmer who agrees in anyway with your assessment.
First of all, I am an experienced Smalltalk programmer. I have been using the language for 20 years, and I am still supporting software written in the language. However, if you don't trust my experience, how about this from Dave Griswold:
http://strongtalk.org/history.html
"On the East Coast, I (Dave Griswold) was frustrated with the fact that there were still a lot of obstacles to using Smalltalk in most kinds of production applications. ParcPlace and Digitalk had made a lot of progress, especially with Deutsch/Schiffman dynamic translation technology, which sped up Smalltalk by a factor of 1.6 or so at the time. But it was still way too slow for any kind of compute intensive application (which I was doing), and I felt there were several other obstacles to widespread use as well. One of the biggest among these in my mind was the lack of any kind of type system, which although it makes the language extremely flexible, also means that organizing and understanding large-scale software systems is a lot harder. "
There were indeed obstacles to widepread use of the language. This is exactly my view.
There are people on this forum who have never tried a number of the languages we are discussing so we have a responsibility to be honest and truthful.
Absolutely.
Is what you describe truely the "global Smalltalk experience" or was it a "little local difficulty"?
It is a global experience, of course. If it were not, then why would StrongTalk have been developed?
A bad workman blames his tools.
Far worse is a workman who does not recognise the limitations of a tool.
So please make your specific points and I will respond to them as such. Otherwise cut out the noise.
Regards,
Paul.
Please try and respond politely, and to the points I make. You may wish to post specific information about Smalltalk performance, for example. Calling someone's honest contribution 'noise' is not helpful.
|
|
|
Message #217954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hey Paul,
Frank made the point about Smaltalk and performance which I agree with. At one time performance was a problem for Smalltalk, but you disagreed:
I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well.
A bit of flip-flopping going on here I think.
With regards to name spaces, yes I agree too that this was an oversight in Smalltalk-80 and I don't care much for the later commercial solutions either. If you had made this specific point, I would have responded to it in kind but you didn't.
I don't think Steve is flip-flopping at all. For one, 4MB is an awful lot of RAM for a 286 ;-). Secondly, different problem domains have different performance requirements.
The way I interpret Steve's point is that Smalltalk has some issues with scaling in regards to performance and complexity (namespace issues). However, many (most?) applications will never hit the point where these issues actually become a limiting factor.
Now I don’t know what the size of a project has got to do with performance.
I would say they are generally correlated. Larger systems with more users tend to deal with larger datasets and more complex codebases. Making an application performant on a single server with minimal resource contention is a lot easier than doing so across many servers with high resource contention.
Either the language is performant or it’s not, which is it?
That's simply not true. Think about algorithms for finding prime numbers. The most performant algorithms in the asymptotic sense perform awfully for small inputs. This is common. Programs tend to have a "sweet spot." Scaleable solutions generally incur some overhead that isn't worth the cost for "small" problems.
And I don’t see what namespaces has to do with open classes, the two issues are orthogonal.
Not in the least. Namespaces are a tool for managing complexity by separate software into pieces that won't have naming collisions and between which dependencies should be minimized (and unidirectional). Open classes permit the introduction of dependencies in a ad-hoc fashion - thereby introducing complexity.
I agree that with power comes responsibility and languages like Lisp and Smalltalk provide the developer with a great deal of power. I think the correct term is that these languages are highly "expressive" meaning a lot of functionality for very little code.
You don’t hear people saying that dynamic proxies or the reflection API should be removed from Java because it is too dangerous for the average programmer. The truth is that the average Java programmer seldom if ever uses these features. If you are a framework programmer though writing JBoss, or involved with Spring or Hibernate then these features are priceless and the real truth is that you could do with a lot more.
The problem here is that dynamic languages loose many of their advantages when their advanced features are not used by the application programmer - and in many cases the features like blocks/closures in Ruby must be used to effectively use the language; while features like reflection in Java are relatively hidden, difficult to use, and easy to ignore.
Now that doesn't mean you can't have the best of both worlds. I think Python provides all (more, in my opinion) the elegance with advanced dynamic features that Ruby provides w/o pushing them on the programmer.
|
|
|
Message #217982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Eric,
Read your post, and I'm sorry to say that you are factually wrong on almost every point. I will go through your points, but first of all may I make a general statement.
I do not want to make this about static versus dynamic typing because:
A) Smalltalk in the form of Strongtalk has static typing, and shows clearly that what can occurs statically at compile time in terms of testing for correctness is indeed very different then what can occur dynamically at runtime. I know no other static type system that does this, and I don't want to try and explain the difference again because last time I did it was lost on everyone involved.
B) Dynamic programming requires a different, more incremental "suck-it-and-see" programming style. If you didn't learn to programme that way it does take a little getting use to and can be off putting. This doesn't make it inferior, infact I believe it to be a superior approach once you get use to it and it is exemplified by the TDD approach to programming which may I remind you came from Smalltalk (SUnit by Kent Beck).
If you did learn to programme that way, it comes natural and you would probably fine static programming with all the verbose type declarations awkward and unatural. Having listened to what people have said over several threads I really just think it comes down to what you are use to.
So ..
I don't think Steve is flip-flopping at all. For one, 4MB is an awful lot of RAM for a 286 ;-). Secondly, different problem domains have different performance requirements.
I think the main pillar of Steve's argument is that Smalltalk is too slow for production use not only today but in the future. The processors we use today are probably 10 to 20 times faster then that 286 and if moores law is to be believed is likely to double again in the next 18 months.
Without giving specifics our talking about a specific bench mark or application type, then talking about performance is meaningless. If I was writing a first class chess programme then Java is too slow, for an enterprise web application it's fine.
Now I don’t know what the size of a project has got to do with performance.
I would say they are generally correlated. Larger systems with more users tend to deal with larger datasets and more complex codebases.
You need to follow more closely. He didn't say as user load increases, he said as the project size (code size) increases. I repeat project size has nothing to do with performance.
Either the language is performant or it’s not, which is it? That's simply not true. Think about algorithms for finding prime numbers. The most performant algorithms in the asymptotic sense perform awfully for small inputs. This is common. Programs tend to have a "sweet spot." Scaleable solutions generally incur some overhead that isn't worth the cost for "small" problems.
Agreed. You make the point I made earlier, any discussion about performance needs to be specific. I won't acuse you of flip-flopping though ;^).
The problem here is that dynamic languages loose many of their advantages when their advanced features are not used by the application programmer - and in many cases the features like blocks/closures in Ruby must be used to effectively use the language; while features like reflection in Java are relatively hidden, difficult to use, and easy to ignore.
Now that doesn't mean you can't have the best of both worlds. I think Python provides all (more, in my opinion) the elegance with advanced dynamic features that Ruby provides w/o pushing them on the programmer.
This is just plain wrong. The purpose of a DSL as used in Smalltalk or Lisp or Ruby for that matter is to hide the underlying complexity from the application programmer. That is why it is called a Domain Specific Language. The idea is to raise the level of abstraction. I could go into examples but I've done so in the past to no avail.
In summary, I don't believe any of us here are qualified to talk about the applicability of dynamic languages because I get the strong feeling that all our experiences are strongly biased towards static languages. What I do is keep an open mind and talk to people who have years of relevent experience using dynamic languages in critical sectors like banking as I mentioned before (JPMorgan was a Smalltalk shop for years). What I have found is that more often then not any difficulty I may experience with dynamic languages is due to my lack of familiarity with the idioms and techniques that go with dynamic programming, and after perservering I tend to find that indeed what they had described to me as their experiences is infact true for me too.
None of these experienced dynamic programmers that I have spoken to personally or corresponded with over the web make the claims that either yourself or Steve make. Infact most of them find dynamic programming a joy and miss it greatly. The only people that make these claims are static language programmers and they are the least qualified IMO to say.
Paul.
|
|
|
Message #217985
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Steve,
I'm not sure what is your point. Are you saying that a dynamic langauge is likey to be slower then a statically type language? Well if so the answer is yes.
Are you saying that historically performance has been an issue for Smalltalk? Given that we are talking about processors of the late eighties and early nineties, again the asnwer is yes.
Is any of this a reason why we should not use dynamic languages in the future and in 10 years we will all come running back to static languages? The answer to this one is an infatic no!
Sorry about being impolite, but what is your point:
My point is that StrongTalk was implemented because of performance and other issues with conventional Smalltalk implementations.
Really? Sorry I thought it was performance, no I mean namespaces, woops what I really meant to say was open classes, oh yes I've got it now, static typing.
You are not making a lot of sense :^).
Paul.
|
|
|
Message #217986
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
In summary, I don't believe any of us here are qualified to talk about the applicability of dynamic languages because I get the strong feeling that all our experiences are strongly biased towards static languages.
I was a Smalltalk developer for far longer than I have been developing with Java, and I have produced commercial Smalltalk applications, so I consider myself well qualified to discuss such matters.
None of these experienced dynamic programmers that I have spoken to personally or corresponded with over the web make the claims that either yourself or Steve make. Infact most of them find dynamic programming a joy and miss it greatly. The only people that make these claims are static language programmers and they are the least qualified IMO to say.
Paul.
You asked me to provide some evidence that dynamic programmers have come across issues (such as performance) with these languages, and I did, with comments from Dave Griswold, so to claim that only static language programmers see issues with dynamic languages is evidently false. If there weren't such issues, then projects like Self and StrongTalk, which explored how to optimise dynamic languages, would not have been started. There would also be no point to the YARV project, attempting to speed up Ruby, or the Parrot project to speed up Perl (and possibly other languages like TCL as well).
I find Smalltalk a fantastic language, and it was a real pleasure to use - it was the best development environment I have ever worked with, but I am realistic enough to recognise the potential failings of the language.
|
|
|
Message #217992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Steve,
I'm not sure what is your point. Are you saying that a dynamic langauge is likey to be slower then a statically type language? Well if so the answer is yes.
Are you saying that historically performance has been an issue for Smalltalk? Given that we are talking about processors of the late eighties and early nineties, again the asnwer is yes.
I think that performance issues tend to be relative. Unfortunately, as computing performance increases over the years, so do the demands we put on applications! Today we handle volumes and types of data that would have been unimaginable 20 years ago. 20% the speed of C was considered slow decades ago, and it is still slow these days, even though that 20% is orders of magnitude faster than decades ago! Speed matters. For example, I am currently implementing a data loading and transformation application. It takes about 45 minutes to run. This is just about acceptable, but if implemented in a dynamic language with poorer performance, it could take hours, which would certainly not be.
Is any of this a reason why we should not use dynamic languages in the future and in 10 years we will all come running back to static languages? The answer to this one is an infatic no!
I don't think I put this point across well. The thing is, that I see a huge (and understandable) amount of enthusiasm for dynamic languages right now. But that enthusiasm is usually not tempered by a realisation that dynamic languages can have issues, and I read the exactly the same (in my view extreme) claims made for dynamic languages now that were made decades ago. Whether my views are correct or not, what really concerns me is the way so much debate is happening as if the experiences of so many developers over decades never happened! For example, I read again and again in articles and blogs the view that static typing has few benefits. This completely ignores a substantial body of research and work over a long period to introduce static typing into languages like Smalltalk. This work was not pointless! It was done for good reasons, but how many developers know of this work, and the reasons behind it? The sad fact is, that we are having debates today over issues that were, at least to some degree, settled long ago. I don't mean to imply that dynamic languages will be abandoned years from now! But, it would not surprise me if I read an article which suggested adding some sort of type information to Ruby to help with performance :)
Really? Sorry I thought it was performance, no I mean namespaces, woops what I really meant to say was open classes, oh yes I've got it now, static typing.
You are not making a lot of sense :^).
Paul.
I mentioned namespaces because I believe that Ruby's open classes, although incredibly powerful, will inevitably lead to the same issues of method conflicts (in sufficiently large and complex codebases) as happened with Smalltalk.
The issues of static typing and performance, and why these drove the development of StrongTalk are been discussed in detail on the StrongTalk site.
|
|
|
Message #218003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
You need to follow more closely. He didn't say as user load increases, he said as the project size (code size) increases. I repeat project size has nothing to do with performance.
I know what he said, and I'm saying that I think there is a correlation. I'm not saying there is a causal relationship.
Without giving specifics our talking about a specific bench mark or application type, then talking about performance is meaningless. If I was writing a first class chess programme then Java is too slow, for an enterprise web application it's fine.
It still depends on what the enterprise web application is doing. But I'm splitting hairs...
This is just plain wrong. The purpose of a DSL as used in Smalltalk or Lisp or Ruby for that matter is to hide the underlying complexity from the application programmer. That is why it is called a Domain Specific Language. The idea is to raise the level of abstraction. I could go into examples but I've done so in the past to no avail.
Underlying complexity of what?
Concepts like blocks/closures and metaprogramming are not simple. Yes, they can be used to build abstractions that make application programming much more natural - but they are not in themselves simple.
You can't program idiomatic Ruby without using blocks. The idea of people using RoR w/o a basic understanding of Ruby metaprogramming scares me.
My point that there are ideas in many dynamic languages (and C++, for that matter) that for one reason or another many (most?) people have a very hard time grasping. This is complexity, even if it facilitates the elimination of greater complexity, and it can be an insurmountable barrier to adoption for some people.
I think Java capitalized very well on this fact by being extraordinarily simple. Constructs like operator overloading and templates found in C++ can be very powerful, but they can also leave many people completely lost and confused. So can blocks/closures and metaprogramming. So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
|
|
|
Message #218004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Eric,
Underlying complexity of what?
Concepts like blocks/closures and metaprogramming are not simple. Yes, they can be used to build abstractions that make application programming much more natural - but they are not in themselves simple.
You can't program idiomatic Ruby without using blocks. The idea of people using RoR w/o a basic understanding of Ruby metaprogramming scares me.
My point that there are ideas in many dynamic languages (and C++, for that matter) that for one reason or another many (most?) people have a very hard time grasping. This is complexity, even if it facilitates the elimination of greater complexity, and it can be an insurmountable barrier to adoption for some people.
I think Java capitalized very well on this fact by being extraordinarily simple. Constructs like operator overloading and templates found in C++ can be very powerful, but they can also leave many people completely lost and confused. So can blocks/closures and metaprogramming. So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
Again, I believe this is all down to perspective. I personally find nothing complex about blocks. Iterating through collections by passing a block seems more intuitive to me then using iterators. Also passing a block as a callback parameter seems a lot more natural IMO then using anonymous inner class.
On my last project we had two graduates using Ruby and they took to it like ducks to water. One of them had PHP experience (final year project), his comment was yeah it's just like PHP, you write what you want it to do and it just does it, no fuss no verbose types everywhere.
Sometimes when you've too much prior context then things can seem more difficult then they are. I guess thats what they mean when they talk about teaching old dogs new tricks.
Paul.
|
|
|
Message #218009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed
And the debates over Java performance have been going on for how long?
Sorry Paul, but just because many well-known high-profile developers and some you have spoken too like the language, and can be productive with it, does not mean that these issues don't exist
I'll add the need for traits to overcome single inheritance limitations in Smalltalk. I won't even get started with Java.
This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.
So Java performance is improved because of various factors, but Smalltalk implementations don't?
This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?
Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?
I like Smalltalk a lot too, but I realise its limitations.
I like Java, but I realize its limitations.
|
|
|
Message #218012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed
And the debates over Java performance have been going on for how long?
But that is my point. These things are debated; they matter. They matter for Java and they matter for dynamic languages too.
This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.
So Java performance is improved because of various factors, but Smalltalk implementations don't?
Indeed. The reasons why you can better optimise languages with type information than dynamically typed languages are well understood.
This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?
Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?
I don't get what your point is here. Much effort has indeed gone into optimising the Java VM; successfully. Java can approach the speed of C in very many situations. At least with Java, it was realised that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue as it often is with dynamic languages.
I like Smalltalk a lot too, but I realise its limitations.
I like Java, but I realize its limitations.
Same here. My choice of Java for most of my development is pragmatic, not because I think it is in any way a perfect language.
|
|
|
Message #218014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
So Java sacrificed some potential expressivity in the name of simplicity, for better or for worse.
I agree with that. I enjoy a language when it is powerful but also promotes clarity. I really liked developping in Smalltalk when I was still a student (2 years ago...) but it was always so hard to get in someone's else code. It takes a really long time to get started in a new project IMO, although my SmallTalk experience is fairly limited.
By the way, I also had to work with ML in university. That was a really neat language, especially when working on collections. I hope closures make it to the VM although I'm not sure if it should be in Java directly or in another form.
|
|
|
Message #218015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Sometimes when you've too much prior context then things can seem more difficult then they are. I guess thats what they mean when they talk about teaching old dogs new tricks.
Sometimes people get so caught up in reviving old tricks that they forget why those tricks left the mainstream.
|
|
|
Message #218018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
If you had been following this issue for years (as I have), you would know that debates over Smalltalk performance have been going on for a very long time indeed
And the debates over Java performance have been going on for how long?
But that is my point. These things are debated; they matter. They matter for Java and they matter for dynamic languages too.
These so-called debates would only be useful in a context of a projects requirements.
This is not just theoretical - I have had to deal with real performance issues with several Smalltalk implementations personally.
So Java performance is improved because of various factors, but Smalltalk implementations don't?
Indeed. The reasons why you can better optimise languages with type information than dynamically typed languages are well understood.
This is a real issue - why on Earth would so much effort be put into optimising VMs if it wasn't?
Why has so much effort gone into optimizing the Java VM? By the way, ever heard of Self?
I don't get what your point is here. Much effort has indeed gone into optimising the Java VM; successfully. Java can approach the speed of C in very many situations. At least with Java, it was realised that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue as it often is with dynamic languages.
And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java.
Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving. And even then it's pretty much meaningless depending on project requirements and what is willing to be given up for at least a perceived power and ease of use of a programming language.
|
|
|
Message #218023
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
These so-called debates would only be useful in a context of a projects requirements.
I'll discuss below....
And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java.
But with Java, performance has not been put secondary to safety and garbage collection; at least not these days. This is precisely why I tend to choose Java over other languages that have safety and garbage collection.
Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.
Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.
And even then it's pretty much meaningless depending on project requirements and what is willing to be given up for at least a perceived power and ease of use of a programming language.
I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and , with those projects, you can hit a requirement that is demanding in terms of performance. At that point, you have several choices; throw more hardware at the problem, code that part of the application in a faster language, or rewite the whole application in a faster language. I have come across situations where the performance of a dynamic language was an order of magnitude less than acceptable, so the hardware option would not have been realistic. Also, mixed language development in these circumstances can be messy, involving extra issues of support, maintenance and portability (or lack of) - this is not just a matter of adding some scripting or testing to a project; we are usually talking about some core function. My view is that it is better to start with a language that is going to give good performance from the start, especially with a language that is undeniably easier to develop with than its mainstream predecessors - C and C++.
Java is far from the most elegant language, but I really don't think you are giving up that much in terms of ease of development by using it as against, say, Ruby or Smalltalk, particularly with a good IDE; indeed, Java has features that make it particularly productive to work with as projects grow larger, such as static typing.
Well, anyway, you may think my approach is wrong (many do), but that is what it is. I would rather try and stick with a general purpose language that I know will cope with any unforseen extra demands.
|
|
|
Message #218029
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
And we can say: At least with C, it was realized that performance was an important issue for a general-purpose language; performance was not dismissed as a secondary issue to safety and garbage collection as was the case with Java.
But with Java, performance has not been put secondary to safety and garbage collection; at least not these days. This is precisely why I tend to choose Java over other languages that have safety and garbage collection.
It's doubtful that you're even doing anything where a fast Smalltalk or Lisp implementation wouldn't give you the necessary performance. I'm sure there's other reasons why you choose Java over other languages with safety or garbage collection.
Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.
Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.
Yes really, you're still handwaving. You're just using the same arguments that people still use today about Java being slow and bloated, except you've turned it on dynamic languages and how Java "approaches" the performance of C "for much code". Here is an interesting post by Avi Bryant (of Seaside fame) about VM performance.
And really the handwaving started with:
That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
That's why Paul and I had to call you out on that. That entire post is just handwaving. Moore's law and compiler technology doesn't just work for Java. If these other solutions were too slow then people would abandon them. Ruby has a particularly poor implementation when it comes to performance because it works directly on the AST, but is in no way indicative of other implementations of other languages.
I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and...
There's your problem. You make these broad, sweeping remarks based on your experience and somehow think they are representative of others experience, and indicative of some overall trend (and thus your first handwavy post about "10 years from now people will rediscover...".
It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today.
There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
|
|
|
Message #218034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Frank,
It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today.
Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts.
The implementation of a language is a very different thing from the semantics. Clearly seperating these things through indirection is one of the inherent advantages IMO that dynamic languages in general and Smalltalk in particular have over static languages like Java.
So:
There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
Can be addressed within the language. There are experimental versions of Smalltalk with Traits and Mixins, (I've read a paper one one example by the same Gilad Bracha of Strongtalk fame), which are still Smalltalk. And ofcourse Strongtalk uses Mixins. Self can also be considered a distant dialect of Smalltalk, although this is stretching the dialect idea a bit far. Smalltalk through indirection is a fertile ground for research and investigation, which is why some 30-40 years after its invention (going back to say Smalltalk-70) it is still a crucible for innovation today.
I just don't think we will be talking about Java in the same way 20 years from now!
Paul.
|
|
|
Message #218040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
It's doubtful that you're even doing anything where a fast Smalltalk or Lisp implementation wouldn't give you the necessary performance. I'm sure there's other reasons why you choose Java over other languages with safety or garbage collection.
Well, OK. There is also the issue of language familiarity (if I worked in LISP, there would not be that many able to support the software). There is also the issue of portability - there are high-performance Smalltalks, but not cross-platform.
I shall broaden it then - portable performance is a better description.
Once again, until you start talking about various concrete implementations vs other concrete implementations, then it's just handwaving.
Not really. For example, there are some specific Smalltalk implementations (such as MT) that are high performance, but in general, you are only getting a low percentage of C performance. And, in general, modern Java VMs approach the performance of C for much code. General statements can be made.
Yes really, you're still handwaving. You're just using the same arguments that people still use today about Java being slow and bloated, except you've turned it on dynamic languages and how Java "approaches" the performance of C "for much code". Here is an interesting post by Avi Bryant (of Seaside fame) about VM performance.
And really the handwaving started with:
That was exactly the argument 20 years ago, and nothing has changed. Smalltalk was available even then as a reasonably high-performance language. I know, because I was a Smalltalk user. I used Smalltalk V/286 on a DOS PC with 4MB of memory, and it worked well. People were ready for it. 20 years ago Smalltalk was hugely promoted, but it failed.
My prediction is that history will repeat itself. The dynamic language projects will grow to the point where performance becomes an issue; just as it did with many Smalltalk projects decades ago, and where management of code becomes an issue: the ability of anyone to add methods to existing Smalltalk classes - just as with Ruby open classes now - led to complex namespace solutions.
Here is my prediction: in, say 10 years or so, the cycle will repeat - the advantages of static typing will be re-discovered, and many developers will look back with fond memories of the simplicity of Java.
That's why Paul and I had to call you out on that. That entire post is just handwaving. Moore's law and compiler technology doesn't just work for Java. If these other solutions were too slow then people would abandon them.
No, as I have carefully explained in other posts, you can't use Moore's law as an excuse for slow software. Software has to be very special indeed for customers to be willing to throw hardware at it to take up for performance issues, or the convenience of the developer. I have seen such products, but they are few.
I have been through this argument, back and forth for a very long time, with Smalltalk advocates and Java advocates; you aren't quoting something I haven't already seen.
I have a controversial view about these things, but it is based on considerable experience. My experience is that a significant proportion of projects grow in terms of requirements and scale way beyond the initial estimates, and...
There's your problem. You make these broad, sweeping remarks based on your experience and somehow think they are representative of others experience, and indicative of some overall trend (and thus your first handwavy post about "10 years from now people will rediscover...".
I am not dumb enough just to base things on just projects I have worked on. I also based this on projects I have seen fail due to precisely these kinds of issues, both personally and otherwise. I was a very strong Smalltalk supporter until the mid 90s. The slow switch to Java was based on considerable research, and considerable attempts to fine-tune and optimise Smalltalk code. The extend to with others were attempting to do this (and even dropping through to C) made me (and many others) realise that things were just not good enough.
It's rather amusing watching strong Java advocates using the same tactics that were used against them for years and years. At the end of the day, broad sweeping discussions about performance for a whole language category were meaningless, and still are today.
There's some good reasons to bash Smalltalk (Traits or Mixins are needed for one), but performance just isn't one of them.
Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time.
The "performance is no longer an issue" is a tired old cliche that has been used by Smalltalk advocates for too long. Perhaps if StrongTalk takes of and performance finally isn't an issue, they can stop using it!
|
|
|
Message #218041
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts.
Why do people so often bring up this irrelevant fact?
Look - a large number of people, like me, accept that early Java was poor and did not use it. We put in through the same scrutiny as any other language, and only switched to it when it met our requirements.
"Java was poor when it came out" is a tiresome straw-man argument.
|
|
|
Message #218048
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Indeed! Like I said many posts ago, I remember Java 1.0 (infact I'm sure there was a Java 0.9, but don't old me to that :^)). It wouldn't have held up well to this type of scrutiny, believe me! But that still didn't invalidate the main concepts.
Why do people so often bring up this irrelevant fact?
Look - a large number of people, like me, accept that early Java was poor and did not use it. We put in through the same scrutiny as any other language, and only switched to it when it met our requirements.
"Java was poor when it came out" is a tiresome straw-man argument.
Hi Steve,
The reason why raise this is two fold:
A) To some degree through the use of a VM, Java had a reasonable seperation between implementation and language, so even though performance was a problem in 95/96 things could improve through changes to the implementation whilst not impacting the language.
B) When backing technology we need to think longer term IMO. Given point A above, the longer term perspective for Java was always better then C++ when it came to a broad class of application programming duties. With the elapse of time Moores law was always on Java's side. As for C++, it was destined to suffer from memory leaks for an eternity.
We are faced with the same choice today. The longer term view for dynamic languages IMO are a lot more promising then those for static imperative languages like Java when it comes to high level, high abstraction, componentised, possibly distributed application programming.
The fact that if we had taken a longer view perspective back in 1995/6 we would most likel be 20 or so years further down the road isn't lost on people like Frank, Gilad (Sun), Dave(Sun), Amin and myself.
Paul.
|
|
|
Message #218051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
We are faced with the same choice today. The longer term view for dynamic languages IMO are a lot more promising then those for static imperative languages like Java when it comes to high level, high abstraction, componentised, possibly distributed application programming.
I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other.
And as was pointed out earlier in this thread, that will just lead to a pedulum swing. In 20 years people will be extolling the lost virtues of static languages over dynamic ones.
But I don't think that will happen. At least I really hope it won't.
I think we're headed towards some sort of convergence. IMHO, the debate should not be focused on why one type of language is superior to another, but on the strengths and weaknesses of different languages and their origin.
I think Java is gradually becoming more dynamic, even if much of it is hacked in via reflection and runtime bytecode manipulation.
Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk.
Much of the debate in this thread has taken on a very religious tone, and I don't think that is productive. We're supposed to be scientists and engineers, not zealots.
|
|
|
Message #218055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Erik,
I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other.
No this is not whatI'm saying. I was very careful about indentifying the class of application I feel are suited to dynamic languages. I see a number of possibilities. For example static languages like C++ are very good at low level stable APIs like OpenGL. Dynamic languages IMO are better suited to scenarios where the interfaces need to be more malleable. So a "mixed-mode" is one possible outcome. Sorry for saying this but Corquet adopts this "mixed-mode" approach :^)
My point as been all along that we should be able to use the right tool for the right job rather then slavishly sticking to one approach as a standard.
Paul.
|
|
|
Message #218060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Erik,
I think this is a short-sighted statement. It assumes the strong dichotomy between "static" and "dynamic" languages that exist today will persist, and one will win out over the other.
No this is not whatI'm saying. I was very careful about indentifying the class of application I feel are suited to dynamic languages. I see a number of possibilities. For example static languages like C++ are very good at low level stable APIs like OpenGL. Dynamic languages IMO are better suited to scenarios where the interfaces need to be more malleable. So a "mixed-mode" is one possible outcome. Sorry for saying this but Corquet adopts this "mixed-mode" approach :^)
My point as been all along that we should be able to use the right tool for the right job rather then slavishly sticking to one approach as a standard.
Paul.
My point is I think (hope) that someday people will come up with a class of languages and runtimes that owes their heritage to both static and dynamic languages (and hopefully other more declarative ones like SQL and Prolog). People may still argue about whether it is more a "dynamic" or "static" or "X" type of language, but the argument will be largely academic.
I'm going to place my bet on it being 5 years before such languages emerge as usable, 10 before they are mainstream, and 15 before they are "de facto standard." I also think they will still be largely imperative in nature and won't have sound theoretical foundations (because most don't care about sound theoretical foundations). Maybe in 25 years we'll start seeing declarative and theoretically grounded constructs emerging in mainstream languages.
All this assumes the evolution of languages is going to accelerate, which I think we are seeing today, but it's too early to tell.
|
|
|
Message #218062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
I think we're headed towards some sort of convergence. IMHO, the debate should not be focused on why one type of language is superior to another, but on the strengths and weaknesses of different languages and their origin.
I think Java is gradually becoming more dynamic, even if much of it is hacked in via reflection and runtime bytecode manipulation.
Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk.
Absolutely. Things are changing, and for the better. Improvements in the range of languages on the JVM, and in the JVM itself, should help to deal with many of the problems discussed here. It really should be more practical to combine languages into a single application on the JVM when you can do things like tracing execution seamlessly from one language to another.... and you can combine different approaches with losing the advantage of a unified, high performance and portable platform. I look forward to that situation; Java is likely to form a far smaller proportion of my code with it happens.
Much of the debate in this thread has taken on a very religious tone, and I don't think that is productive. We're supposed to be scientists and engineers, not zealots.
+1
|
|
|
Message #218063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi Erik,
Python is adding type annotations in version 3.0, primarily in the name of (optional) increased safety and with optimization as a secondary concern. StrongTalk brings them to SmallTalk.
I agree. This is yet a another possible outcome.
Paul.
|
|
|
Message #218086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Well, OK. There is also the issue of language familiarity (if I worked in LISP, there would not be that many able to support the software). There is also the issue of portability - there are high-performance Smalltalks, but not cross-platform.
VisualWorks?
I shall broaden it then - portable performance is a better description.
Actually, IMO, the biggest reason that Java took off was not performance (obviously), or portability in the sense of bytecode portability, but a large number of portable APIs out of the box and a C++-like syntax.
No, as I have carefully explained in other posts, you can't use Moore's law as an excuse for slow software. Software has to be very special indeed for customers to be willing to throw hardware at it to take up for performance issues, or the convenience of the developer. I have seen such products, but they are few.
I have been through this argument, back and forth for a very long time, with Smalltalk advocates and Java advocates; you aren't quoting something I haven't already seen.
Actually, Moore's law is the reason that Java and Smalltalk and Ruby and Python and all these other languages are actually viable solutions these days.
I am not dumb enough just to base things on just projects I have worked on. I also based this on projects I have seen fail due to precisely these kinds of issues, both personally and otherwise. I was a very strong Smalltalk supporter until the mid 90s. The slow switch to Java was based on considerable research, and considerable attempts to fine-tune and optimise Smalltalk code. The extend to with others were attempting to do this (and even dropping through to C) made me (and many others) realise that things were just not good enough.
At what point did you switch from Smalltalk to Java? Java was certainly no speed-demon when it came out. Java would have been one of the last places I would have turned to if I was having problems with the speed of Smalltalk in the mid 90s.
Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time.
Self is not Smalltalk and doesn't even have classes. It's a prototype-based OO. So it's motivations for being started weren't to make a faster Smalltalk. Many of the ideas (if not code directly) of the Self VM were actually implemented in the Java hotspot VM.
The "performance is no longer an issue" is a tired old cliche that has been used by Smalltalk advocates for too long. Perhaps if StrongTalk takes of and performance finally isn't an issue, they can stop using it!
Hehe, will you be saying that "performance is no longer an issue" next time someone says Java is slow and a resource hog?
You do realize that Smalltalk implementations like VisualWorks actually have a JITer don't you? Dolphin actually has a blindingly fast interpreter and I can't tell the difference performance-wise, or visually from a native windows application. That's more than I can say about released Java versions.
|
|
|
Message #218094
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
VisualWorks?
VisualWorks was good (I have used it), but nowhere near C or Java or performance. Also, VisualWorks nearly died before Cincom took it over, then priced and licensed it out of my range.
Actually, IMO, the biggest reason that Java took off was not performance (obviously), or portability in the sense of bytecode portability, but a large number of portable APIs out of the box and a C++-like syntax.
I have no interest in why Java took off; my interest is in what it delivers now.
Actually, Moore's law is the reason that Java and Smalltalk and Ruby and Python and all these other languages are actually viable solutions these days.
No, it certainly isn't. Proof of this is that dynamic languages have always been viable for certain types of applications. Try telling an experienced Perl or Python programmer that their language was not a viable solution 10 years ago!
There have been people saying 'the current speed of processing now means that dynamic languages are viable' for a very long time. Dynamic languages have been used as viable solutions to various problems for a very long time, but....
My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages. My requirements are for a general purpose language.
At what point did you switch from Smalltalk to Java? Java was certainly no speed-demon when it came out. Java would have been one of the last places I would have turned to if I was having problems with the speed of Smalltalk in the mid 90s.
Indeed, which is why it took me along time to switch. Although I still support Smalltalk applications, I moved to Java as main development language when performance got reasonable - 1.3.x. (I was particularly impressed by the IBM JVM at that time).
Self is not Smalltalk and doesn't even have classes. It's a prototype-based OO. So it's motivations for being started weren't to make a faster Smalltalk. Many of the ideas (if not code directly) of the Self VM were actually implemented in the Java hotspot VM.
I know it is not Smalltalk - we have been talking about dynamic languages in general. I know about the ideas being transferred to the Java VM. This is of no relevance, other than to describe how Java gained its speed advantage.
Hehe, will you be saying that "performance is no longer an issue" next time someone says Java is slow and a resource hog?
I never said 'performance is no longer an issue' with Java. It is always an issue, even with C and C++ code. The point is that it is LESS of an issue with Java, at least for what I want to do.
I switched to Java because for my applications it was far less slow and far less of a resource hog than Smalltalk - up to an order of magnitude less in some cases.
You do realize that Smalltalk implementations like VisualWorks actually have a JITer don't you?
Of course I do - they have been implementing JITters for a LONG time. This has helped speed considerably, but still nowhere near C performance. JITting can only take you so far in a language like Smalltalk - typically I found a top-quality Smalltalk implementation could get between 20-30% of C speed for my use cases. That certainly made it competitive with Java for me for a while, as early Java only had that sort of performance too.
Dolphin actually has a blindingly fast interpreter and I can't tell the difference performance-wise, or visually from a native windows application. That's more than I can say about released Java versions.
I have used Dolphin for projects in the past. It is a nice system. The interpreter is not especially fast; what is fast is the GUI because it is native Windows. It also starts up fast because of the image system. But this does not help at all with, say, numeric work, or intensive file parsing, or image manipulation etc. I rarely write native GUI applications.
Dolphin is also, unfortunately, only for Windows.
|
|
|
Message #218103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
VisualWorks was good (I have used it), but nowhere near C or Java or performance. Also, VisualWorks nearly died before Cincom took it over, then priced and licensed it out of my range.
Sounds like you want OCaml and not Java if you want something closer to C speed.
My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages. My requirements are for a general purpose language.
That's just completely untrue. Has Java always been fast? Why are they always working on ways to accelerate Java. What about Lisp? Even pre-1.0 SBCL is about a dead heat on the debian language shootout. And that's not even comparing to the high-performance commercial implementations like Allegro and Lispworks.
I know it is not Smalltalk - we have been talking about dynamic languages in general. I know about the ideas being transferred to the Java VM. This is of no relevance, other than to describe how Java gained its speed advantage.
and...
Yes, of course performance is one of them. If it were not, then projects like Self and StrongTalk would not have been started, and attempts to defend Smalltalk performance would not have been a common topic of debate for a long time.
Every language implementor would want a fast runtime. Java is no different.
The goals of the Self group were to make a fast VM for the Self language. The goals of the StrongTalk team were to make a fast VM for Smalltalk. The goals of the Java VM team are to make a fast VM for Java. Strongtalk was essentialy shelved after Java started enjoying success. If Java had been shelved in favor of Strontalk, it would have been left with a poor performing VM.
I never said 'performance is no longer an issue' with Java. It is always an issue, even with C and C++ code. The point is that it is LESS of an issue with Java, at least for what I want to do.
I switched to Java because for my applications it was far less slow and far less of a resource hog than Smalltalk - up to an order of magnitude less in some cases.
Fine, but you don't get to decide that other dynamic language aren't fast enough to be general purpose, when clearly languages like Lisp and Smalltalk are:
My point (backed up by those who have been working on ways to accelerate dynamic languages all that time) is that they aren't fast enough to be general purpose languages.
Of course I do - they have been implementing JITters for a LONG time. This has helped speed considerably, but still nowhere near C performance. JITting can only take you so far in a language like Smalltalk - typically I found a top-quality Smalltalk implementation could get between 20-30% of C speed for my use cases. That certainly made it competitive with Java for me for a while, as early Java only had that sort of performance too.
I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
|
|
|
Message #218108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Hi,
I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
Back on topic. One of the areas where IMO languages like Java and C# have struggled is programming "in the large". By this I mean component models. One success story from the nineties was NextStep, the component framework and operating system from Steve Jobs.
Well my pair programming partner has bought himself a new laptop. He got himself a Mac Book, and we spent friday getting the project working on it. The Mac user interface is very impressive so I decided to google and find out what language it was written in.
The OSX user interface is written in a framework called Cocoa whis as far as I can tell is the modern re-incarnation of NextStep, which is written in the dynamic language Objective-C. Apple also use another API called Carbon for low level system work whih I haven't looked at this, but my guess is that it is Unix (considering the OSX is build on the BSD "Darwin" Kernel ), and Carbon is in C/C++. Objective C can inline C/C++ code. They also mention something called Objective C++ which I haven't heard of before.
Here is the Mac OSX developers page:
http://developer.apple.com/macosx/
So there we have it the mixed-mode approach I mentioned earlier in everyday use on the Mac. I'm sure there is something to be learnt from this by the Java community. Incidently Cocoa has Java bindings so they may have solved the foreign language binding issue raised by Erik many posts ago :^).
Paul.
|
|
|
Message #218110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
Yeah, it seems to be any language as long as it's Java;)
Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
A somewhat weird trend I've seen is that some people are more interested in thinking that they get to limit the choices for others.
So there we have it the mixed-mode approach I mentioned earlier in everyday use on the Mac. I'm sure there is something to be learnt from this by the Java community. Incidently Cocoa has Java bindings so they may have solved the foreign language binding issue raised by Erik many posts ago :^).
I think Apple has stopped working on the Java-Cococa bindings. I've never used Objective-C, but I probably would have bought a Mac years ago if Apple had continued an interest in Dylan.
|
|
|
Message #218111
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Paul, not sure if you've seen this video of Gilad Bracha giving a presentation at the Lang.NET symposium.
I just started watching it, but I had to get a chuckle when he says "Any customer can have any language he/she wants so long as it's Java"
|
|
|
Message #218117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
Sounds like you want OCaml and not Java if you want something closer to C speed.
Why? This seems a strange comment. Java gives me pretty much equivalent to C speed. I
Why would I move to a language that has less support, less versatility, fewer frameworks?
That's just completely untrue. Has Java always been fast?
No, I have agreed that.
Why are they always working on ways to accelerate Java.
Because they are always working on ways to accelerate every language, C and C++ included. What matters to me is the performance differential between the langauage I use and that available for languages recognised to make close to optimal use of computing power.
What about Lisp? Even pre-1.0 SBCL is about a dead heat on the debian language shootout. And that's not even comparing to the high-performance commercial implementations like Allegro and Lispworks.
The debian-language shootout is a very poor set of benchmarks; for Java, it does not allow enough time for the hotspot optimiser to work. Multiply the run times by 5 or 10 times, and things change.
LISP is still not close to C (or now Java) when it comes to numeric work - one of my use cases.
I wish people would read previous posts before responding :)
I have already mentioned why not LISP - there is not the developer base.
Every language implementor would want a fast runtime. Java is no different.
The goals of the Self group were to make a fast VM for the Self language. The goals of the StrongTalk team were to make a fast VM for Smalltalk. The goals of the Java VM team are to make a fast VM for Java. Strongtalk was essentialy shelved after Java started enjoying success. If Java had been shelved in favor of Strontalk, it would have been left with a poor performing VM.
But it wasn't, was it? No point trying to re-write history.
The fact is that Java was the one that got the fast VM.
Fine, but you don't get to decide that other dynamic language aren't fast enough to be general purpose, when clearly languages like Lisp and Smalltalk are
I can decide what I like for my purposes. Let me stress yet again. It is not just me who believes that dynamic languages aren't generally fast enough for general purpose. You should read the literature written by the authors of Self and StrongTalk - they refelected a widely-held view in the industry that dynamic languages weren't fast enough.
I'm curious what kind of work you're doing that you need performance that gets you to within a reasonable percentage of C? Java wouldn't be my first choice if that was what I was after.
A whole range of things. I do everything from scientific numerical work (simulation models) to commercial stock level and availability calculations for high-load sales systems, CAD software, image processing and so on; all this combined with more conventional software - database stuff, websites and so on.
To be able to use largely a single language and set of frameworks for this range of stuff is phenomenal; no need for awkward cross-language bindings.
So, Java certainly is my choice. I have been developing C and C++ projects on and off since the mid 80s. It was a support nightmare, especially during the windows 16-to-32-bit transition, and there have been migration difficulties between compilers and platforms and major problems with bug tracing. C++ with garbage collection solved some of these problems, but when I discovered that IBM's JVM could give exactly equal to C performance for some major mathematical benchmarks, I had no hesitation in switching. I have found no disadvantage.
Why this 'anything-but-Java' attitude? Why try and push people to anything else - OCaml, LISP and so on? There is no other language that has the combination of performance, portability, support and tools. It is far from the best language I have ever used, but it is a good general-purpose solution.
|
|
|
Message #218118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
|
|
|
Message #218119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
Previous post meant to be in bold - should have previewed.
|
|
|
Message #218122
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Black Hole's and "innovation"
I thought peace had broke out! We are a long way off topic. I guess you haven't seen Steves' criteria for selecting a "general purpose" programming language have you Frank?
Well I have and I'm not that interested in seeing it again. What is "general purpose" for Steve is possibly a short-term col-de-sac for others. So lets not discuss Steves choices he is welcomed to them. What we can all agree on is more choice for everyone!
I am sorry, but this is unacceptable. If you wish to post comments about me, at least have the decency to direct them to me personally. This is extremely ill-mannered, and no way to hold a debate on what is supposed (at least) to be a respected forum.
Previous post meant to be in bold - should have previewed.
Sorry? What is unacceptable about it? It was meant to be light hearted, with the sole intent to make the point that we should all have the ability to exercise choice. The Gilad video makes the same point.
Steve, try taking yourself less seriously. I apologise, but no malice was intended believe me. We are only talking about software and your software choices are not you as an individual. I am challenging your ideas not you as a person.
Todays is a Saturday, I'm at my machine only because I've got work to do. Get out and about and do something else. We can discuss this again on Monday. It may all look very different by then!
Wishing you a fun weekend!
Paul.
|
|
