The Artima Developer Community
Sponsored Link

Weblogs Forum
The departure of the hyper-enthusiasts

262 replies on 18 pages. Most recent reply: Dec 20, 2006 2:11 PM by Carlos Neves

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 262 replies on 18 pages [ « | 1 ... 14 15 16 17 18 | » ]
Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Java / Ruby comparison Posted: Jan 5, 2006 7:10 PM
Reply to this message Reply
Advertisement
"I have absolutely no idea how this relates to this discussion. If you're interested, I wrote a cover class for the java.awt.GridbagLayout class to provide a TK like pack facility because I liked that interface to layout. It's at
http://packer.dev.java.net. I did it back in 1995/1996 or so, and have used it without any version of Java breaking it since that time. This year, I made a change to it for JSE1.6 to allow it to support some new layout features added in JSE1.6."

Sorry, I see now. It was meant as an example of how to break an API may be important and achievable without breaking the idea of components for solidifying reusable code.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: Java / Ruby comparison Posted: Jan 5, 2006 7:10 PM
Reply to this message Reply
> ... Proponents of dynamic languages tend to
> identify the readability/complexity issue with number of
> characters, which is plain stupid. What is important is
> the number of logical entities that you have to keep in
> mind in order to understand the code, not the number or
> lengths of words to read. Type declarations actually
> reduce complexity because the reader doesn't have to try
> to infer what the code is about. Whatever may be the
> benefits of dynamic typing, readability is clearly not
> among them. I wish that we could get at least that one
> straight.


I strongly disagree. Readability assumes so many things. Readability necessarily impacts your ability to hold some number of things in short-term memory. And the reverse is also true: how many things you can hold in memory will impact how "readable" a passage is to you.

At a very basic level, readability assumes that you can "parse" the tokens of what you're looking at. So, at some point, we have to define a threshhold for "readability", let's say, knowledge of the language.

Given that, typing declarations may, in a limited way, disambiguate the first following block of code from the second.
int a, b, c;
c = a + b;
versus
c = a + b

But what percentage of cases does such a thing cover? What do you assume when you say that declaring the type of variables a, b enhance readability? Sure, it tells you that you're doing numerical addition versus string concatentation (assuming the language supports that meaning of +). But how much more do you really have? Very little I suggest. It doesn't tell you anything more about the meaning of those variables, how they're intended to be used, what their value boundaries are (except implicitly and I'll say why in a moment). If you have ever tried to understand some C code implementing a geographic transform, say from State Plane to UTM, you will clearly know that type declarations offer almost nothing to readability. There is a ton of context that tells you about those variables. For example, the function name, the algorithm, the use of the variables together, the operations performed on them. The declaration of the type adds so little, if anything, to all this.

In a statically typed system like C or Java there are several things with which you as the code writer and reader must continually wrangle:
1. The proper "class" for a declared variable, e.g. numerical versus string.
2. The proper size for the type, e.g. byte, int, double.
3. The proper "higher" type for the result of an operation, e.g. int + double = double.

Note that 1 and 2 usually act like a unit when you think about defining a number versus a string variable. However, it's hardly so trivial. The various sizes of numeric types hardly conveys much meaning but imposes a huge burden on the programmer to continually be considering boundary conditions that are entirely irrelevant to the algorithm but critical to the compiler given it's type system.

When you read the code, even though the types have been explicitly stated, you still have to think of all the other issues I mentioned above (or some subset of them) to understand the code. And if readability is not directly aimed at understanding, then what really is readability?

All the foregoing is mostly concerned with very rudimentary types like numbers and strings. When you start talking about objects, I think static typing even lends less understanding. If you have an object and you say obj.method, what can happen? The object may not have such a method, or you may have misunderstood what you thought method did and you don't get the result you're after. Both those can easily be tested for. All the other content is there and is just as critical, if not more so, to understanding the intention of what's being done than the type label of the object reference variable.

Again, the issue of the threshhold for readability comes up. If I use a type label for an object, say BlueWidget, but you don't know what that is, you have to go read about it. The label won't tell you anything. If there is no type label and all you have is obj.method, you still have to read something (e.g. a nearby comment, search for method in the class browser). Either way, the burden is about the same, and this assumes you haven't got a clue what you're looking at (except that you know the language) when you start reading. That, in itself, is a low percentage case, I'd say.

With dynamic typing in the situation above, your familiarity quickly grows and you have to look up less and less as you learn about the classes being used. More importantly, the emphasis switches to how objects are interacting, or being acted on, rather than on type labels.

With static typing, you are continually confronted with questions about picking the right type label for your variable and what the programmer intended in picking his. You have to worry about casting or declaring a variable as a base type of several derived types, etc. And the fact that you now have this label doesn't help you to understand much about the intent as the code starts calling methods on that object.

Reading code that has explicit type labels imposes the, often superfluous, task of putting into my short term memory that a is an int or something so I can then get on to look at what operations are performed or methods called on a. That additional effort often reduces readability for me. More importantly, when writing code I'm confronted with a number of concerns that are probably irrelevant for my problem domain; I shouldn't care how many bytes the compiler has to allocate for my numeric types so I can add a couple of numbers. And the more distracted the code writer's mind is, the more likelihood he will introduce bugs. Or so it seems reasonable to me. How many times do distracted people have accidents compared to those clearly thinking and carefully concentrating on the task at hand?

Of course, if that consideration is important, critically so, as in, it goes to the core of the algorithm itself, then I'll probably be writing C code and it will be important for me to pay attention to these points. Most of the time, my experience has been that worrying about types is more trouble than it's worth. Now, an interesting language might dispense with labeling all rudimentary types like numerics and strings and reserve the types for classes. But I don't see this gaining much over a simple comment or two. And then, when it's totally clear from context, I don't have to type a type label.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Java / Ruby comparison Posted: Jan 5, 2006 9:40 PM
Reply to this message Reply
> I strongly disagree. Readability assumes so many things.
> Readability necessarily impacts your ability to hold some
> number of things in short-term memory. And the reverse is
> also true: how many things you can hold in memory will
> impact how "readable" a passage is to you.

Variable names are inexact. Types can help qualify any information that the variable names might impart.

int lat, lon;

is very different from

double lat, lon;

> It doesn't tell you anything more about
> the meaning of those variables, how they're intended to be
> used, what their value boundaries are (except implicitly
> and I'll say why in a moment). If you have ever tried to
> understand some C code implementing a geographic
> transform, say from State Plane to UTM, you will clearly
> know that type declarations offer almost nothing to
> readability. There is a ton of context that tells you
> about those variables. For example, the function name, the
> algorithm, the use of the variables together, the
> operations performed on them. The declaration of the type
> adds so little, if anything, to all this.

It might seem to add little to you, but it tells me something about the types of calculations to expect to see. It also tells me how to manage injecting new code.

Whether or not you feel this adds value for you, is a matter of preference, education, or knowledge of the subject matter.

What types of math intensive applications do you have experience with? I'd be interested in know how complex these applications are to better understand how you perceive the impact types might have on your typing in math expressions. If the type names on the variables are more effort than the expressions you type, then that's a very interesting application/module/library that I'd like to know more about.

> In a statically typed system like C or Java there are
> several things with which you as the code writer
> and reader must continually wrangle:
> 1. The proper "class" for a declared variable, e.g.
> numerical versus string.
> 2. The proper size for the type, e.g. byte, int, double.
> 3. The proper "higher" type for the result of an
> operation, e.g. int + double = double.
>
> Note that 1 and 2 usually act like a unit when you think
> about defining a number versus a string variable. However,
> it's hardly so trivial. The various sizes of numeric types
> hardly conveys much meaning but imposes a huge burden on
> the programmer to continually be considering boundary
> conditions that are entirely irrelevant to the algorithm
> but critical to the compiler given it's type system.

There are distinct advantages to the programmers ability to control the complexity of the programs execution through the use of types. For example, time the execution of a FFT using double values in java vs implementing the same algorithm using BigDecimal. This would demonstrate the difference if we just dropped type designations for numeric values and implemented infinite precision math as the native implementation.

This is still an important issue in my mind. I have a Java application that does GSM VOIP compression (http://javecho.dev.java.net) to provide a realtime voice communications system. I'd be interested in see Ruby or Python implementations of this kind of mathematically complex algorithms to get an idea about how their untyped math systems would perform.

> When you read the code, even though the types have been
> explicitly stated, you still have to think of all the
> other issues I mentioned above (or some subset of them) to
> understand the code. And if readability is not directly
> aimed at understanding, then what really is readability?

One of the things about typing is that you can confine an algorithm to using only methods in a superclass. This is often an important part of OO design. This also applies to limiting the exposure of your interface implementation to just the methods in the interface. Java provides this type of control through the type system, and with a security manager active, you can control the access that the reflection API yields to foreign code as well.

> All the foregoing is mostly concerned with very
> rudimentary types like numbers and strings. When you start
> talking about objects, I think static typing even lends
> less understanding. If you have an object and you say
> obj.method, what can happen? The object may not
> have such a method, or you may have misunderstood what you
> thought method did and you don't get the result
> you're after. Both those can easily be tested for. All the
> other content is there and is just as critical, if not
> more so, to understanding the intention of what's being
> done than the type label of the object reference
> variable.

As I said above, typing helps control the visibility of parts of your implementation in Java. The fact that Ruby and Python have no security built into the language is perhaps one of the reasons why users of those languages don't understand some of the finer points of final classes and immutable implementations.

In Java, we have javadoc that is meant to detail exactly what the outcome of calling that method will be. In other languages, and IDEs supporting those languages, similar facilities are available. I don't know whether Ruby or Python has such context sensitive information available.
Does it? When you are writing Ruby code, how do you correlate your use of an API with the actual implementation details. Do you memorize all the APIs you use, or do you have some type of integrated or secondary documentation system that you access?

> Again, the issue of the threshhold for readability comes
> up. If I use a type label for an object, say BlueWidget,
> but you don't know what that is, you have to go read about
> it. The label won't tell you anything. If there is no type
> label and all you have is obj.method, you still
> have to read something (e.g. a nearby comment, search for
> method in the class browser). Either way, the burden is
> about the same, and this assumes you haven't got a clue
> what you're looking at (except that you know the language)
> when you start reading. That, in itself, is a low
> percentage case, I'd say.

In Java IDEs, type information controls, through polymorphism based analysis, which set of methods you can see in IDEs providing code completion. The names of methods with matching prefixes are displayed and it all works easily.

I don't generally use a fancy IDE, so I have a Folder in my Windows-XP taskbar that pops up a list of javadoc sources that I can select from to get the javadocs for a particular package. From there, I can find the class and look at the methods to find the one that I need.

I, in general, don't fight with the java APIs in a way that your simple confusion base examples are based.

Most of your arguments go on about how typing doesn't solve all problems. It's not meant to solve all problems. It's one of the portions of the total language system that provide the set of features particular to a language.

My experience with first C, then my own dynamic language, then Java have convinced me that the benifits of typing in Java are a good and useful part ofthe language.

> With dynamic typing in the situation above, your
> familiarity quickly grows and you have to look up less and
> less as you learn about the classes being used. More
> importantly, the emphasis switches to how objects are
> interacting, or being acted on, rather than on type
> labels.

Again, you seem to expect types to solve all types of problems summarily Types can help reduce the choices you have to consider, which can make programming faster. They can also keep you from having methods names with slight variations because you don't have polymorphism. And, they can remove ugly type checking in cases where you decided to keep the same name for a single argument method that handles multiple types of arguments.

int add(int);
double add(double);
String add(String);
Integer add(Integer);
Double add(Double);

In dynamic languages, type polymorphism for overrides like this require type checks, or method name changes. This, I think adds some of the confusion regarding locating the correct method or reading the code that you talk about above.

> With static typing, you are continually confronted with
> questions about picking the right type label for your
> variable and what the programmer intended in picking his.
> You have to worry about casting or declaring a variable as
> a base type of several derived types, etc. And the fact
> that you now have this label doesn't help you to
> understand much about the intent as the code starts
> calling methods on that object.

I disagree that the type doesn't help. The specific types that you seem to allude to are native types in Java such as int vs double. This is informative and necessary for particular types of algorithms.

Casting in Java that is aimless, or confusing, will decrease as people make more use of Generics. It typically only collections or other generic packaging classes that have this issue. It's a known quantity. I've found 2 different long standing bugs, but in dead code, by using generics in Java.

I've found some miss used collections that had duplicate uses where I had intended separation that generics revealed. The type system is a testing system that you can take advantage of without having to write tests. In the case of Generics, you are adding more information for the test system to look at.

> Reading code that has explicit type labels imposes the,
> often superfluous, task of putting into my short term
> memory that a is an int or something so I can then get on
> to look at what operations are performed or methods called
> on a. That additional effort often reduces readability for
> me.

What happens with me is that the shorter variable names and types are, the more likely I am to forget. They say that most people can put 5-7 things in their short term memory.
It takes about 30 seconds for things in your short term memory to migrate to longer term memory. So, small amounts of information that convey a large amount of information are important.

Your examples of int vs double vs no-type are really not providing much convincing force. These are in fact the least of the advantage to the type system in Java any ways. The use of types for polymorphic overrides, the use of types for subclass access and interface implementation access control are important parts of the whole package.

> More importantly, when writing code I'm confronted
> with a number of concerns that are probably irrelevant for
> my problem domain; I shouldn't care how many bytes the
> compiler has to allocate for my numeric types so I can add
> a couple of numbers. And the more distracted the code
> writer's mind is, the more likelihood he will introduce
> bugs. Or so it seems reasonable to me. How many times do
> distracted people have accidents compared to those clearly
> thinking and carefully concentrating on the task at hand?

But that is not a related argument. Distraction and confusion comes from multiple sources. If the concepts of typing are confusing to you, then you may well have problems developing in a typed language. But, there are so many other sources of confusion, including the lack of types which help you to understand the scope of the reference to a particular variable.

Without interfaces in Ruby, you wouldn't be concerned with limiting scope of access to certain parts of your object. Without typing, you wouldn't be familar with the benefits of superclass restrictions to help manage the linkage between callers and callees which is an important part of managing the ability of replacing one implementation of an API with another.

In particular, consider the JDBC api in Java. The fact that there is an interface for Connection, Statement, ResultSet, etc allows for me to write a database independent application from a software interface perspective.

Bugs in implementation might cause me to use particular logic to manage the impact of those bugs on my software, but that would happen without types.

The types provide the ability for me to easily try a different implementation, at will. You'll need a template class or some other standard definition in a non-typed/typeless language. That is a type definition.

> Of course, if that consideration is important, critically
> so, as in, it goes to the core of the algorithm itself,
> then I'll probably be writing C code and it will be
> important for me to pay attention to these points. Most of
> the time, my experience has been that worrying about types
> is more trouble than it's worth. Now, an interesting
> language might dispense with labeling all rudimentary
> types like numerics and strings and reserve the types for
> classes. But I don't see this gaining much over a simple
> comment or two. And then, when it's totally clear from
> context, I don't have to type a type label.

Again, I appreciate your sticking with a single example, but you aren't providing any convincing arguments about how the lack of numeric based typing (or other native types) would NOT impact the performance or portability of the software to different systems.

I'm just not seeing how there could not be an impact. I care about performance and I care about portability. Java's type system lets me manage those issues explicitly.

I'd really like to see a VOIP application in Ruby with the codec written using Ruby. Do you know of such a thing that I could look at and play with?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Java / Ruby comparison Posted: Jan 5, 2006 10:14 PM
Reply to this message Reply
Ruby Taint Mode (security in a lower scale than in Java):
http://www.rubycentral.com/book/taint.html

Of course we won't see Ruby Applets yet, although, just like Flash and activescript, maybe we could in the future. Hint. Hint. :-)

Ruby-DBI - database independent access:
http://ruby-dbi.sourceforge.net/

If you want you may create a fake database driver to test something, though maybe it does not compare to the substitution that you can get in Java.

I have created my own "DBI" in Ruby, and I support Oracle, PostgreSQL, MySQL, Firebird, SQL Server (ODBC), Access (kind of, ODBC), SQLite and KirbyBase. KirbyBase is a database in Ruby, and even though it does not support SQL, I created a custom SQL interface to it so it would work in the same way of the other databases; though maybe I should support SQL-less databases.
http://www.netpromi.com/kirbybase.html

I don't know of performance intensive applications written in Ruby, though I wouldn't be surprised if some people have created some already; although I concede that the dynamicity of Ruby has its price, though people might create the algorithms in C and access them from Ruby (it may be worth it).

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: Java / Ruby comparison Posted: Jan 5, 2006 11:25 PM
Reply to this message Reply
Gregg,

You make a lot of points and I appreciate your in-depth analysis. Let me clarify a couple of points.

I definitely understand the different types in C; I don't claim they are equivalent. I also understand the impact of the choice of type on the performance of an algorithm. I wouldn't expect to do floating point math with integers, but with a particular library implementation, one could of course. Depending on the platform, using ints could be much faster. Obviously that would be true of a CPU with no FPU or equivalent.

But even understanding types, are you saying that in C you always know which of short, int, long, long long is most appropriate? And is it signed or unsigned? Of course, if you are coding a carefully designed math algorithm, that will provide guidance, but what about the general case? How often will the general programmer doing some math have to make this choice. And how often has the value being pushed into an int wrapped while the test was for a value greater than zero? Of course that's a bug. But for tons and tons of math done in simple programs, it shouldn't matter a wit to the programmer whether they're using a int, long, unsigned, signed, etc. They just want to add, multiply, or something. That's where I see a big advantage of a dynamically typed language.

I don't propose, not expect, that a type system will solve all programming problems. I think the post I responded to overstates the importance of types in promoting "readability" and I think you should restrict yourself to that context if you are to understand what I'm saying. To extrapolate what I've said to other areas of concern, like performance, scope or access control, etc. is to stretch it beyond my intention. I'm simply saying that
Foo widget = new Foo(a, b);
widget.buzz();
widget.bark();
is not dramatically more readable than
widget = Foo.new(a,b)
widget.buzz
widget.bark
And if you have a object being passed in, the documentation for that argument provides just as much knowledge as the type label. In other words
int foo(int a, double b) { ... }
is not more helpful, vis-a-vis readability than
# a - integer, b - float
def foo(a,b) ...
Substitute more complex types for int and double, the argument doesn't change.

I'm not trying to speak for every dynamically typed language out there. In Ruby, with the concept of duck-typing, you are more concerned that the object you interact with does some particular thing you want, than with the class of the object. In general, although you can ask any object obj.class, you would more likely do obj.respond_to?("laugh") if that's what you are wanting your object to do.

I typically do not use an IDE when writing Ruby, Python, or C/C++, unless Emacs is an IDE. ;) With Ruby, I have the docs open in a web browser and look up stuff as needed, which isn't that often once I'm a little familiar with the code I'm working on. I've used visual studio and I like completion. But that doesn't change the fact that I find the extra burden of types hardly worth it for a lot of programming. Of course, I must add, the problem domain isn't high precision math libraries or something of that sort. For example, I've worked on many helper applications in the GIS field using AML, Avenue, MDL and even VB for integrating with apps like ARC/Info and Microstation. AML and Avenue are ESRI dynamically typed scripting languages and I didn't find them noticeably worse for writing the utilities than MDL or VB. In other user interface heavy applications and web applications I find static typing to be superfluous.

You're right, Ruby does not have a security manager like Java does, but I hardly think that means you can't do the same things. And I don't see how types are necessarily implicated. Proxy classes, I think, could provide restricted access to other classes in the way that you describe interfaces doing in Java (I haven't used interfaces this way in Java). Objects in Ruby can be frozen at some point in their lifetime, prohibiting further changes. The Ruby interpreter can be set to run in various safe levels.

There are, of course, various idioms one could use to program in Ruby. The idiom(s) that utilize duck-typing are just much less focused on the particular "type" of an object than on what that object does. And depending on your situation, you may want only to know that it has one particular method and obj.respond_to?(method) works, or you may want to check obj.class, or obj.is_a?(class) or obj.instance_of?(class). I fail to see why Ruby crumbles into a silly little toy language incapable of solving "real-world" problems because one doesn't put type labels on object references.

Ruby's math support is by no means perfect. Some things are nice and simple: 5**1024 (exponentiation in Ruby) spits you out a nice long number. 5.0**1024 returns the value Infinity from the Float class. Ruby doesn't have the floating point equivalent of its BigNum. Now, assuming I were to use Ruby to program a math intensive library, I'm sure it would be a mixture of Ruby and C, or probably better, I'd use http://raa.ruby-lang.org/project/libgmp-ruby/ unless that wouldn't work for some reason.

I do appreciate your questioning of Ruby's suitability to several domains. So far, you pointed out RMI, Jini, and VoIP as areas you'd like to see if Ruby can provide useful solutions. I am looking at this carefully. Sorry, I can't wave my hand and have examples for you, but hopefully I and others who are very interested in Ruby will be able to provide more information over time. Or better yet, perhaps we could collaborate to investigate Ruby's boundaries in such areas. The language is hardly "finished", but I think it's an excellent start. And try as I might to understand, I cannot find a major fault with dynamic typing.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Java / Ruby comparison Posted: Jan 6, 2006 4:12 AM
Reply to this message Reply
> > When I see people use "this" when they don't have to,
> it
> > always makes me wonder how well they really understand
> the
> > language.
>
> Some people are as AR about using this as some are about
> importing every single class, instead of a package.
>
> In the worst case, not importing by class causes later
> compilation errors when a new class by the same name is
> introduced into another package also imported.
>
> In the case of not using 'this', you run into the problem
> that sometimes, people will declare new method parameters
> that have the same name as a class member and miss the
> fact that they might cause the scope of a reference to
> change to a different value/instance!

I totally concur; I for one am also guilty of placing "this"
in places where its not necessary (simply habitual); though
it was not due to the insight Greg has given above - though
its great to know this is actually a good habit :o) - it
was more so for the benefit my own thought process on
with regards to scoping.

Verbosity sometimes does wonders!!

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Java / Ruby comparison Posted: Jan 6, 2006 8:54 AM
Reply to this message Reply
> I totally concur; I for one am also guilty of placing
> "this"
> in places where its not necessary (simply habitual);
> though
> it was not due to the insight Greg has given above -
> though
> its great to know this is actually a good habit :o) - it
> was more so for the benefit my own thought process on
> with regards to scoping.
>
> Verbosity sometimes does wonders!!

The microsoft C++ standard, of course, is to put the prefix "m_" on the name of a class member so that all chances of scope changes are eliminated.

In Java, with inner classes, the "m_" rule doesn't help as much because an inner class declaration can hide an outer class definition.

This is not a type related issue, but it is an important issue to come to grips with developing Java software.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

this reference Posted: Jan 6, 2006 10:36 AM
Reply to this message Reply
"I totally concur; I for one am also guilty of placing "this" in places where its not necessary (simply habitual); though it was not due to the insight Greg has given above - though its great to know this is actually a good habit :o) - it was more so for the benefit my own thought process on with regards to scoping."

If you prefer making "this" explicit, that's all right with me. Iprefer not to, and I pointed out that it's optional and shouldn't be used to accuse Java of being too verbose. I know that there is a danger of name collisions but this shouldn't happen if variable names are chosen judiciously. What I absolutely can't stand are code conventions which make it mandatory under all circumstances. It feels like being treated as a moron.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Type declarations and readability Posted: Jan 6, 2006 11:21 AM
Reply to this message Reply
If only your comments were not too long, Brian and Gregg... I won't try to go through all the details, just to restate the main point.

"If you have ever tried to understand some C code implementing a geographic transform, say from State Plane to UTM, you will clearly know that type declarations offer almost nothing to readability."

C is not my domain but I think it's not a good example to discuss the topic. The primitive C types may not add much to understanding what's going on in the code. In an OO language, you create your own types. In a sense, this is what OO is all about. By designing your object model, you specify your own vocabulary. If this is well done, then OO code can be read almost like natural language (you know, objects as nowns and methods as verbs). For that to be possible, it is absolutely crucial that the reader knows what types the code is talking about. If you look at the Ruby example in Glover's article (it's the first Ruby code I've been reading so it will have to serve as my standard example ;-)) without having read the explanation, you can only guess what's going on. You have to actually read the code in order to guess, for example, that some variables are collections (and you could still be wrong, the overloaded operators may mean anything). You can't even know what the member variables word, definition and spelling mean. They are absolutely unrestricted. You cannot even tell what the class is composed of by reading its definition! You might say that you can guess from the variable names but it's always guesswork. spelling and definition are strings but word is of class Word.

How do you know there isn't an extra Spelling class? Maybe spelling was a string yesterday, but then the author decided it has to be a class of its own. Your code passes a string but somewhere down the road, it blows up without warning. I'm not stressing the security aspect here. I trust that your tests will sooner or later point you to the problem, although static compiler checks would have revealed it at once. What I'm stressing here is readability, clarity and ease of maintenance. I just can't see how you can have those without type declarations. Glover's Ruby code is short but it's not clear, the semantics are not obvious. I like Java most for its interfaces. There is no guesswork, the semantics are known to the world and that's it.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Type declarations and readability Posted: Jan 6, 2006 11:35 AM
Reply to this message Reply
Readability, clarity and ease of maintenance aren't easy goals in any language, but I think I have reached an optimum balance now with the latest progresses in the development of my libraries. The secret was to use DSL for programs which can get kind of messy in any language. The OO in the backend works like a charm for solid code.

So, by adopting a DSL with a "framework" things improve imensely. I think the complexity in my own code becomes 3 times less complex now.

Mike O'Keefe

Posts: 16
Nickname: kupci2
Registered: Mar, 2005

Re: The departure of the hyper-enthusiasts Posted: Jan 10, 2006 11:45 AM
Reply to this message Reply
> Sam Gendler, you've certainly got a lot of experience.
> Unfortunately, just like Bruce, you tend to speak on a
> topic you apparently do not know.
>
> Does it scale? Hmm, according to this,
> http://www.oreillynet.com/pub/wlg/8274, "the second
> largest online record store in the world ( second only to
> Amazon)" is being rewritten to run on Rails.

Nice, that's what we call "vaporware". But if you try hard enough, you can scale just about anything (hardware, clustering, etc), but I think it says alot that ebay, which handles billions of transactions a day, chose Java. So that's fine, prototype in Ruby, scale to Java when you need to.

It's really rather foolish to disregard the tremendous amount of work done in optimizing the JVM, and the incredibly competitive App Server market, from Apache Geronimo, Tomcat, Weblogic, WebSphere, Oracle.

This is where the fresh-faced web designer, ready to try the new new thing, is doing the customer a disservice. This is what Eckel is talking about when he says "We can identify hyper-enthusiasts because the arguments have a strongly faith-based flavor to them. X is the true way, therefore anyting X is best by definition, and all other languages lack X's goodness."

And this is what is missed in this Ruby discussion - there is much, much more to software design than I can write a for loop easier in language X. Anaylysis, Design, Testing, standards support (unicode anyone?), commercial & open source support. I don't care if you rewrote a Java app in a quarter the time (as Rubyists claim), and you think it didn't matter that this was a rewrite. That shows a lack of knowledge on what it takes to design anything more than a mom & pop web app.

If their claim is that Java is bad because it's just "a better C++", that's a misunderstanding. It was certainly the intention of Java's designer's to make it _look_ like C++, and that suredly helped their learning curve, but underneath the covers it is quite different, and actually borrows much from Objective-C. In fact, Java's designers didn't think too much of C++, see below. That’s somewhat like thinking Windows NT is simply a better Windows ME – wrong, it looks the same, but it’s a complete rewrite. So again, I think Eckel's point that the bandwagonists don't understand the competition too well is correct, and therefore I take much of the hype Rubyist's say with a grain of salt.

"Java Was Strongly Influenced by Objective-C...and not C++"
http://cs.gmu.edu/~sean/stuff/java-objc.html

Now, one point about Eckel's interesting article. It is great for a "down-to-earth/back-to-reality" comment, I think the whole Ruby thing is a bit overblown, and wouldn’t be anywhere without Rails. In fact this is exactly why Python hasn’t taken off, somehow they weren’t able to come up with the “Killer app”. Obviously if the "early-adopters" are able to convince the brilliant developers behind all the fantastic work done in Java (Struts, Spring, Hibernate, Tomcat, JUnit, TestNG, Eclipse, NetBeans, Log4J, Castor, JibX, Xerces, Apache Commons), to move to Ruby, it will certainly take off, and the early-adopters like Tate will stand to benefit enormously since they were there first.


I disagree with Eckel that only C# has the chance of unseating Java, and that C# is too forward thinking – I think JDK 1.5 has shown that Sun is making every effort to appease the hyper-evangelists and move Java forward (generics, doclets), perhaps too fast. The question really is whether C# and .NET will ever catch up to Java. I admire Hjelsberg, but watching his presentations is a bit of a yawn. Sorry, I can’t get excited about a new and improved for loop. Or how great and easy it will be when they improve persistence, fix the impedance mismatch blah blah. With Hibernate, Castor, JAXB, JDO, EJB3, Java developers have a plethora of ways to persist data. And that’s always been the tricky part of Java – which great tool do I use? Struts? Enhydra XMLC? JSF? So C# and .NET have a long long way to go. Obviously Microsoft will always have it’s installed base, but as this article has shown, C# is not the only game in town, and I would venture to say that Ruby, especially with Rails, is more of a contender than C#. Because that has always been Microsoft’s forte – it’s easier with Microsoft.

Finally I will say that I certainly look forward to working with Ruby, just as I also do some work in perl (much less now that Java has RegEx), Python, and C++ - where they provide a benefit. Certainly Ruby has some good ideas – everything is an object (although, again, the reason why Java succeeded was it was a compromise). Ruby is simply a better perl (Eckel says that, not me). But if Sun can get a handle on the language, and keep to the original philosophy of a simple, robust language, and not make changes according to the whim, or threat, of the hyper-evangelists, it will continue to be the king.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Jan 11, 2006 11:11 PM
Reply to this message Reply
Mike O'Keefe wrote:

"And that’s always been the tricky part of Java – which great tool do I use? Struts? Enhydra XMLC? JSF?"

But, but, but... weren't you guys all telling us that the real strangth of Java is that there's always one, and only way way to do things? Can't you at least maintain certain minimum level of consistence and coherence in your views?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The departure of the hyper-enthusiasts Posted: Jan 12, 2006 3:30 AM
Reply to this message Reply
> But, but, but... weren't you guys all telling us that the
> real strangth of Java is that there's always one, and only
> way way to do things? Can't you at least maintain certain
> minimum level of consistence and coherence in your views?

No. All guys have never said that there is always one and only way to do things in Java. By applying so many extreme interpretations into a single sentence you make your argument self defeating. It would be true to say, however, that many guys have said that there is frequently a best way to do things in Java but then that's true of any language, including Ruby et al.

In any case, you're confusing only ever having only one way to do something in Java syntax with only ever having only one application that does something. The latter does not follow from the former.

João Marcus Christ

Posts: 1
Nickname: joaomarcus
Registered: Jan, 2006

Re: The departure of the hyper-enthusiasts Posted: Jan 12, 2006 12:38 PM
Reply to this message Reply
Scaling is mostly a matter of doing the right thing with the tool you're using. Now, if we're to talk about Ruby's performance, well, it may really suck, period. However, many times performance is *not* critical, because concise and clean applications are much more important. I'm not saying it's okay to have an absurdly slow application. I'm saying that faster is not always better.
It's to have a Rails app 2x slower than a J2EE app if adding new stuff to a Rails app is more than 2x faster than adding stuff to a J2EE app.
Really, the Java hype is over. Let's face it: it has been *absurdly* overhyped, over and over and over. Now it's time to absurdly overhype Rails. It's part of the process.
"Java scales better" is nonsense. Do you guys realize how much effort it takes to build a scalable J2EE app? It's not really easy. The same applies to other frameworks and languages.

(BTW: I'm not into Rails, I've developed some things in Rails, but I decided to go for Django. It suits my needs better)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Jan 12, 2006 12:54 PM
Reply to this message Reply
> "Java scales better" is nonsense. Do you guys realize how
> much effort it takes to build a scalable J2EE app? It's
> not really easy. The same applies to other frameworks and
> languages.

It's important to understand that Java != J2EE. J2EE is a programming platform built on the Java language. The JVM and the Java language are the performance and stability scaling point.

If you pick the wrong platform to develop your Java application on, you may find that the platform can't support your application.

There is a lot of noise and buzz about POJO for a reason...

Flat View: This topic has 262 replies on 18 pages [ « | 14  15  16  17  18 | » ]
Topic: The departure of the hyper-enthusiasts Previous Topic   Next Topic Topic: Java Applets + Ajax = ?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us