Weblogs Forum - The departure of the hyper-enthusiasts

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The departure of the hyper-enthusiasts

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 262 replies on 18 pages [ « | 1 ... 14 15 16 17 18 | » ]

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Java / Ruby comparison

Posted: Jan 6, 2006 1:12 AM

> > 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 5:54 AM

> 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 7:36 AM

"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 8:21 AM

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 8:35 AM

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 8:45 AM

> 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. Thats somewhat like thinking Windows NT is simply a better Windows ME wrong, it looks the same, but its 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 wouldnt be anywhere without Rails. In fact this is exactly why Python hasnt taken off, somehow they werent 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 cant 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 thats 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 its 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 Microsofts forte its 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 8:11 PM

Mike O'Keefe wrote:

"And thats 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 12:30 AM

> 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 9:38 AM

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 9:54 AM

> "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...

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The departure of the hyper-enthusiasts

Posted: Jan 13, 2006 4:14 PM

Bruce Eckel wrote:
> The only thing I've seen that shows promise as an OO
> process model is Active Objects/Actors.

You may be interested in Zonnon's Active Object approach
http://www.bluebottle.ethz.ch/Zonnon/papers/The_Concepts_of_Zonnon_6_y041123.pdf

> On the other hand, I haven't seen how Erlang deals with
> objects -- or does it support objects?

They like to say that Erlang supports "Concurrency Oriented Programming"
http://www.sics.se/~joe/talks/ll2_2002.pdf

Erlang programs are structured around lightweight processes - that's fundamental to their notions of how to build reliable distributed software.
http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Verbose Java Code

Posted: Jan 17, 2006 11:19 AM

This is only slightly related, but I have to make a rant about incredibly bad Java code. In the project that I am currently assigned to, I'm about to correct about 700 occurrences of code like the following:

 
	public ArrayList getObjectList(String command) throws Exception {
		try {
			ArrayList list = new ArrayList();
			list = dao.getObjectList(command);
			return list;
		} catch (Exception e) {
			throw new Exception(e);
		}
	}

Of course this should be only one line of code in the method body instead of 7. While that is an outrageous example, I think it reflects some bad habits that are widespread among inexperienced, and even among some experienced Java coders and which may have contributed to Java's reputation of being such a verbose language. Sometimes I wonder whether newbies are deliberately taught that Java code has to contain as much redundancy as possible in order to be right. Book authors not striving for elegance, and often restrictive and inflexible coding guidelines make matters worse.

Exception handling is obviously one of the worst culprits. Java checked exceptions are often blamed (not least by Bruce) but in my eyes, the problem really is that too many developers don't understand the concept (as in the code snippet above) and courses and books don't give good, standard-setting examples. Java exception handling does force us to write some more code than we would otherwise have to but in my experience, the majority of catch handlers are redundant and could have been avoided if the programmer had spent a few minutes designing the appropriate flow of exception handling, rather than just mindlessly coding some handlers to please the compiler.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Verbose Java Code

Posted: Jan 18, 2006 12:17 AM

> This is only slightly related, but I have to make a rant
> about incredibly bad Java code. In the project that I am
> currently assigned to, I'm about to correct about 700
> occurrences of code like the following:

I concur, that is horrible code not only from a verbose
stand-point but also from the decision in what to return.
It doesn't allow for the flexibility enabled by Java to
at some later stage change the underlying implementation
by returning the interface instead of the actual object.
i.e. returning java.util.List allows for greater code
flexibility (from a maintenance stand point).

> Exception handling is obviously one of the worst culprits.
> Java checked exceptions are often blamed (not least by
> Bruce) but in my eyes, the problem really is that too many
> developers don't understand the concept (as in the code
> snippet above) and courses and books don't give good,
> standard-setting examples. Java exception handling does
> force us to write some more code than we would otherwise
> have to but in my experience, the majority of catch
> handlers are redundant and could have been avoided if the
> programmer had spent a few minutes designing the
> appropriate flow of exception handling, rather than just
> mindlessly coding some handlers to please the compiler.

The fact that only one line is needed in the try block
makes the code verbose - I agree with that. But I don't
think catching Exceptions in the code snippet makes it
verbose at all. Actually specifying the type of exception
in my opinion would make the code easier to understand -
in terms of Oh, at some point such and such an operation
occurs, e.g. interaction with hardware, or a datasource,
etc, this would only be evident by the type of exception
being thrown.

return dao.performSomeOperation();

doesn't really tell you much as to what type of operation
and what object is being returned, one may take a shot by
the variable name but I still don't think that helps much.

IMO there's a thin line between code
clarification/readability and verbosity.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Verbose Java Code

Posted: Jan 18, 2006 9:15 AM

"But I don't think catching Exceptions in the code snippet makes it verbose at all."

Verbose is not the right expression - the whole try-catch is redundant in that example. The programmer chose not to handle the exception, so he shouldn't catch it anyway. He obviously doesn't understand the concept. Creating a new exception instead of rethrowing makes matters worse, and declaring Exception instead of the specific exception is bad, but that's almost negligible in this case.

Thomas Gagne

Posts: 3
Nickname: tgagne
Registered: Aug, 2003

Re: The departure of the hyper-enthusiasts

Posted: Feb 7, 2006 1:07 PM

Bruce, what do you mean when describing Fowler as being a Smalltalker that, ".. because the Smalltalk relationship never really worked out in the real world?"

Flat View: This topic has 262 replies on 18 pages [ « | 14 15 16 17 18 | » ]

Previous Topic

Next Topic