Java Community News - Steve Yegge on Code's Worst Enemy

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Steve Yegge on Code's Worst Enemy

24 replies on 2 pages. Most recent reply: Dec 26, 2007 12:54 PM by Max Lybbert

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 24 replies on 2 pages [ « | 1 2 ]

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 20, 2007 9:52 PM

> Steve Yegge said that code's biggest enemy is bloat, not
> Java.
> I think he makes an important point and its much larger
> than a Java problem. One reason for the prevalence of
> bloat is that many intermediate programmers do not have a
> gut sense as to how large a given system *should* be.

That's right, but I think it's hard to gain that sense without working on similar problem domains in different languages, using different tools.

I love Java, and definitely would not say that Java is a source of bloat per se. But recently I wrote a data extraction/data cleaning system in Java, and then for some reason I had to re-write that in Ruby. The exact same functionality. The Ruby codebase is about 1/5 of the Java codebase. Not only that, but looking at the Ruby code is really easy on the eyes. Again, I definitely would not critique, let alone abandon, Java. But once you've seen that it's possible to provide the exact same functionality in 1/5 the code, it's hard to accept that that code base had to be 5X that big.

Once people see that there may be a way to get the same functionality with less bloat, perhaps people would not accept bloat as a necessary evil.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 20, 2007 10:07 PM

> I think there's some selective reading going on here.
>
> Steve Yegge said that code's biggest enemy is bloat, not
> Java.
> I think he makes an important point and its much larger
> than a Java problem.

Sure, but he addressed Java specifically and provided a funny example of a programmers mentality to accept bloat. The rationale is almost always the same: "I accept the restrictions and limitations of my programming language and I accept that I can't write as simple, concise and elegant code as with language L because of X". X is usually "safety", "raw speed", "huge ecosystems", "usable by refactoring tools", "cleaner design", "other programmers being worse than me" etc.

This is related but not entirely the same as the infamous Blub paradox:

http://c2.com/cgi/wiki?BlubParadox

It is indeed an enlighted version of it: he is aware there are more powerfull languages but they are worse if not considered as harmfull. One additional remark to the as-harmfull meme. Dijkstra, the originator was also the inventor of the software crisis: more powerfull machines lead to worse i.e. less reliable software. Since then academic software research got its destination and seeked for adding the right restrictions ( B&D programming ) to programming languages. In order to be on the right track you have to feel some pain. Only through suffering the mind can be liberated from its natural, uneducated habits. Refusing power is also a means to embrace civilization. It's always a little more complicated as it seems on the first sight.

Scott Peacock

Posts: 10
Nickname: speacock
Registered: Nov, 2007

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 11:43 AM

James Watson wrote:

I also take issue with the assertion that building something to run on the JVM implies it must be written in Java. There are a number of languages that compile directly to bytecode.

You're right, James. I apologize - I didn't do my homework. It would certainly be possible for Steve to write in something else and compile to Java bytecode. It still seems unnecessarily convoluted to me, though.

Frank Sommers wrote:

The Ruby codebase is about 1/5 of the Java codebase. Not only that, but looking at the Ruby code is really easy on the eyes. Again, I definitely would not critique, let alone abandon, Java. But once you've seen that it's possible to provide the exact same functionality in 1/5 the code, it's hard to accept that that code base had to be 5X that big.

I'm curious, Frank. Here's my question: "Would you be able to port the Ruby codebase back into Java, *without increasing the volume of code*?"

If you think that you'd be unable to do this, then I'd have to suggest that Java is incapable of the same concision that is possible in Ruby. If this is the case, I'm afraid you might have to critique Java (relatively speaking) on this point.
If you think you *could* write a Java implementation that matched the Ruby, then the simple answer is that you merely *didn't* the first time you wrote the code. The reasons *why* you didn't (mindset, habit, etc) would be a separate issue, but very interesting in their own right.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 12:14 PM

> James Watson wrote:
>
> I also take issue with the assertion that building
> something to run on the JVM implies it must be written in
> Java. There are a number of languages that compile
> directly to bytecode.
>
> You're right, James. I apologize - I didn't do my
> homework. It would certainly be possible for Steve to
> write in something else and compile to Java bytecode. It
> still seems unnecessarily convoluted to me, though.

I'm not sure why it would be convoluted. The JVM is designed for Java, no doubt, but in the end, it doesn't really matter how the bytecodes were generated. I think more an more we will see that Java is just one of a set of languages that are commonly used on the JVM.

> I'm curious, Frank. Here's my question: "Would you be able
> to port the Ruby codebase back into Java, *without
> increasing the volume of code*?"

I had the same kind of thought when I saw this anecdote. It's probably not the sole reason but I'd wager that a lot of the reduction in code came from a better up-front design based on the knowledge gained from implementing the Java version. The second Java version would likely also require less code than the first.

Jesse Kuhnert

Posts: 24
Nickname: jkuhnert
Registered: Aug, 2006

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 12:29 PM

Right, and in fact this isn't all that new of an idea. Even traditionally very anti java/dynamic language supporters can easily recognize the benefit of bootstrapping off of the jvm to do other non java like things.

http://alex.dojotoolkit.org/?p=587

> > James Watson wrote:
<snipped>
> I'm not sure why it would be convoluted. The JVM is
> designed for Java, no doubt, but in the end, it doesn't
> really matter how the bytecodes were generated. I think
> more an more we will see that Java is just one of a set of
> languages that are commonly used on the JVM.
<snipped>

Scott Peacock

Posts: 10
Nickname: speacock
Registered: Nov, 2007

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 12:57 PM

> It's probably not the sole reason but I'd wager that a
> a lot of the reduction in code came from a better up-front
> design based on the knowledge gained from implementing the
> Java version. The second Java version would likely also
> require less code than the first.

Cleaner design will certainly go a long way towards reducing code volume. However only Frank can say how close his Ruby port was to his Java one.

I don't want to preempt Frank or suggest his answer, but I know when I write Java, I tend to think in a "Java way" and when I write Ruby I think in a "Ruby way". These can be quite different at times. I'm tempted to say that if the code design was radically different between the two, at least part of that was due to the Ruby approach.

Practically, it's irrelevant whether or not you *can* achieve the same level of terseness in Java as in (language of the future x). The real question is whether or not you *will*.

Personally, the answer to the second question is, "No."
And given my limited Java skills, the answer to the first is also, "No."

Lou Marco

Posts: 8
Nickname: loumarco
Registered: Nov, 2007

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 1:12 PM

I'm looking at come C++ functions/methods with > 100 lines of code. I break these up; I increase the codesize. I also make this code more maintainable in the process.

No redesign - just your old fashioned process abstraction at work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 6:27 PM

> Practically, it's irrelevant whether or not you *can*
> achieve the same level of terseness in Java as in
> (language of the future x). The real question is whether
> or not you *will*.

I'm inclined to agree but I know from experience that often my first attempt at something results in a lot of unnecessary duplication. It takes some refactoring or a rewrite (is required) to consolidate these common elements in a clean way.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 21, 2007 9:52 PM

I break these up; I increase the codesize. I also make this code more maintainable in the process.[\i]

I agree with this statement. It is better to increase the size of the code base to add modularity.

However note that C++ has capabilities that are not available in Java, particularly in terms of functions. Function pointers and functors (objects that behave as functions) are not available in Java.

Any missing ability to create an abstraction or to reuse code is sorely obvious.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Steve Yegge on Code's Worst Enemy

Posted: Dec 26, 2007 12:54 PM

> I'm looking at some C++ functions/methods with > 100 lines
> of code. I break these up; I increase the codesize. I also
> make this code more maintainable in the process.

Given two separate ways to code up a solution to a problem, I try not to pick the "most efficient" unless I know that the code in question is a bottleneck. Nor do I always try to pick the solution with the fewest lines of code (we can refuse to hit the "Enter" key in all languages other than Python, after all). Instead, I try to select an answer that's reasonably easy to follow without comments.

One trick I took from the Linux kernel style guidelines is that whenever I'm tempted to write a comment that "the next ten lines of code do X" I instead write a function called, say, do_X() and call that function instead. The function name serves as some documentation and do_X() can be refactored as needed without need to update the comment. And if I need to do_X() somewhere else, I don't have the troubles associated with cut-n-paste code.

But even if do_X() is called a single time, this tactic may add two lines of code in C or C++ (one line for the prototype, and one line for the final '}'). I really can't see what generic refactoring you're looking at that would increase C++ code size. Unless you're talking about creating new datatypes as well as new functions/methods. Or you're talking about more invasive, but problem-specific refactoring.

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic