|
Re: The departure of the hyper-enthusiasts
|
Posted: Dec 24, 2005 7:40 PM
|
|
> Remember when Java was supposed to save all us C > programmers because it didn't have pointers? We wouldn't > be dereferencing NULL. Well, null is just as deadly for a > Java app, static types and all.
What most Java developers fail to realize is that it doesn't have to be deadly. What you have to understand is that any long lived thread should be protected by a try {}catch block that makes sure that RuntimeException doesn't kill the thread. This is the first rule of Java Threading in my book.
The Java language lets you protect the software from the programmer in this way. If you don't take advantage of it then you will experience some dismay and amazement at how quickly things come to a screeching halt when RuntimeExceptions are not caught to protect the main threads from untimily death. Depending on the depth of the call tree that the thread is used for and the complexity of the task, you may find it important to Thread.sleep() for a second or so before the next task to keep a runaway situation from developing.
> Just so we're clear, a type to me is a set of values and > operations on those values.
Yes, and that implies a contract which should be checked and validated as early in the runtime of the application as possible. Compile time static type checking is just an earlier validation of the contract that makes it easier to feel comfortable about what will happen at runtime.
> I simply don't understand how static typing will make > these management and communication problems go away. > Examples, please. And if static typing is all that, then > why Java instead of Haskell, which has a far more > sophisticated type system and referential > transparency?
The primary reason I use Java is that interfaces in concert with mobile code let me create real services whose implementations are distributed at runtime, rather than in a deployment task. This is the "the power" of Java. If you aren't using this feature, then you probably have a wide choices of languages that will solve the problems you are solving.
> I'll give you a counter-example. Rails. This was > developed, after a number of folks started contributing > heavily, across at least 3 time zones and at least 2 > languages (although David's English puts many native > speakers to shame). I don't see how lack of static types > hampered them. But you might ask them about it.
The only fair comparison compared all of this amazingly biased dialog would be to have two equaly capable teams with equal experience in each langauge to be given the same application to develop, and then microscopically track every single task, thought and subsequent action. Time them all, and then correlate the data back to some "cost". That would be pretty much impossible!
Every language has features. Every language has warts. What you have to decide is that if a particular feature enables your application, then that is why you might choose that language. If you fail to recognize the other benefits of another language which might provide some other feature, down the road, then you'll be stuck without that feature, perhaps, forever.
The Jini platform is a specification that can interact with a wide range of transports and languages because it has a large number of service provider style mechanisms. All the things in Java that deal with the humdrum programming of add/subtract/multiply/divide, class hierarchies, packaging etc are not the power of Java. The power of Java comes at the point that you really understand the power of mobile code. The smart proxy concept is paramount improvement on remote procedure call mechanisms. The abilty to change how the client uses the servers, on the fly, without the client being changed is extremely powerful.
If all you're doing is building web servers that ship out web pages, then you may not need mobile code. But, look at the Jini usage in Orbitz's platform, and you'll see how they take a core set of services and dynamically and continuously evolve the service platform using dynamic code downloading and classloader mechanisms for version management.
Version management through the change in class implementation is interesting. But, it still is not up to par with the use of classloader based changes. With classloaders, you can put the same interfaces into a piece of software and use multiple versions, with the same names inside of the same software. You don't have to change everything, everywhere to get one thing to work in one place.
> I'd recommend looking over these slides by Jim Weirich on > 10 things every Java programmer should know about Ruby > (http://onestepback.org/articles/10things/index.html), if > you're really sincere about learning something here. He > happens to know _both_ Java and Ruby very well.
Any language comparison, when aimed at the right features can make one look better than the other, right?
> It's important to understand that types are not prominent > in Ruby. Ruby is about classes, which are objects > themselves, and instances of classes. There is no > 'documentation' provided by a type label that cannot be > provided by the class and it's documentation. And lest you > think that duck-typing somehow introduces confusion, every > object is indeed strongly 'typed' (in a sense): ask it > it's class (obj.class) and you'll get a definite answer. > You can also ask it what it's like (e.g. > obj.is_a?(String)). These are things that can be tested > for using good behavior driven development in a way much > more sophisticated than a compiler type-checking your > code. And the tests themselves provide immeasurable > assistance with communication.
The question is what is the best way to test type compatibilty. When is it easiest to do and what is the most return on investment. Compile time type checking is a built in test. I don't have to write it over and over for each class/object. I don't have to understand flow control through a method/function/module to correctly implement all possible tests that will prove that I have compatible objects.
Further, new users/uses of the same code get to use this free testing. They don't have to implement it either. Thus, my test construction is limited to tests that cover semantic behaviors where I cover the vast majority of issues that a human constructed test should have to deal with.
> I can't help but reiterate my main point in all my posts: > people, especially self-professed experts, should know > what they're talking about before shooting off at the > mouth. I'm not trying to convert you, or yank away your > little security blanket named Java, C#, Python, Lisp, or > whatever. But if you are a programmer, and you value your > intellectual capacity and problem solving skills, you do > yourself a grave dis-service by discounting Ruby and > spouting FUD about hype, scalability, maturity, enterprise > app, or whatever other topic is popular. And the reason > for that is simple: FUD propagates a hundred times faster > and farther than the truth. We already live in a world > where stupidity and stupid decisions abound. Why > contribute to them?
I think it is impossible for everyone to know everything about every language. Such knowledge is not free, and in the grand scale of software development progress, adds little value! What developers need to know if whether a particular problem is being solved by their language of choice or not. If the problem is being solved, that's the end need. Effeciency (time, space etc.) of the solution is part of the "is solved" answer, if that is part of the solution space.
What is most necessary in this day and age is to stop solving the same problems over and over with a new language that does one particular thing different than the others with no added value in other forms. That type of progress is extremely expensive. Look at the vast number of developers who have contributed the vast array of python and ruby software we have to date. I think that's productivity focused on many things that are just recreations of what we already have.
To some degree, it's the ignorance of some of those developers that are causing them to recreate existing solutions, in much the same way as there is allusion that Java developers are ignorant of Ruby and Python. For most developers, the ignorance of another language and platform is expected because they are solving problems that their language of choice handles for them.
For some, they've learned how to use the features of their language of choice to create new domain specific APIs that make their software simple to create and maintain.
> So rather than all your 'apprehensions' and 'hard time > imagining' and other hypothetical nonsense, why not learn > Ruby and actually demonstrate, in particular, why it fails > as an 'enterprise app' language.
I guess I'd have to have a language based platform, such as Jini, which provides distributed leasing and distributed transactions, plus a language built in security model, mobile code and method overides "int max(int,int)" vs "double max(double,double)" and finally binary data serialization between instances of the language runtime, over the network to consider a language enterprise worthy.
I don't do web services and I don't create web sites. Those are the features that I use the most often in Java and which I don't see available in Ruby, Python or many of the other non-statically typed languages which I've looked at.
Point me to these kinds of solutions for Ruby and/or Python.
|
|