Skip to main content

Chapter 4: Glass Breaking

34 replies [Last post]
invalidname
Offline
Joined: 2003-06-09
Points: 0

Chapter 4 begins laying out the case against Java:

"I've developed a good instinct for trouble on the river, and at work. In this profession, I generally know when a technology smells wrong, or dangerous, and I guide my customers away. I'm sensing that danger around Java right now. It's getting too difficult to manage, and both evolutionary and revolutionary steps to remedy the problem are failing us. In this chapter, I'll introduce some of the basic problems."

In this chapter, Tate looks at what he considers Java's worst problems today: over-complexity and its many sources:

* Frameworks that make life easier for experienced developers, at the expense of approachability for new developers
* Over-reliance on XML, caused by Java's inability to represent structured data
* "Compromises", like primitives, which were introduced to lure the C++ crowd
* A long compile/deploy cycle
* The costs of strong, static typing
* Over-reliance on tools to mitigate complexity

"Over the next five years or so, the question in play will be this: are the Java community and expansive code library base worth sacrificing the productivity that other alternatives will bring to bear? So far, the answer has been a resounding "Yes." But we're nearing a point of no return. Java needs radical changes if it wants to continue to be all things to all people, but the community, culture, and leadership behind Java have never produced the kind of structural, sweeping changes that we need. Sun has always treated Java conservatively. The community process has always built the kind of software you'd imagine a community process would build: bloated compromises that please no one in the end. The Java community has always tolerated too much architecture, too much XML, and too many layers."

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwalden
Offline
Joined: 2005-12-03
Points: 0

> I'm not a language geek, languages are a necessary
> evil, I have to express the logic somehow and the
> language does it

Having a better notation to express the logic is why we have children solving algebraic problems in minutes that used to take the best mathematicians in the world hours. The introduction of modern algebraic notation transformed the solving of equations from a problem that only a few experts could solve to a completely mechanical problem we can solve with a computer.

> now listening to "Wow! this
> language gives me 10x all that much power" leads me
> to wonder:
>
> "How is this language different from the other 2513
> computer languages ever invented so far!?"

It means that it's easier to build abstractions in that language and thus it's more like the powerful languages like Lisp and Smalltalk than it is like the less powerful languages like Cobol and FORTRAN.

> Buzz, hype, fanaticism, this is the fuel for the Ruby
> bubble.

True, just as it was for Java. Ruby is another small step away from ALGOL and its decendents and toward Smalltalk and Lisp, but like Java, even though Ruby's not there yet, it's important to make these steps because programmers are conservative so if we're going to get to a language that makes programmer much easier for everyone, we're going to have to do it in small steps like C to C++, C++ to Java, and Java to Ruby.

jwalden
Offline
Joined: 2005-12-03
Points: 0

> The point I guess is that Bruce's original assertion that
> static typing sucks, is just as much chest beating as my
> assertion that it doesn't.

I'm not sure that I agree with Bruce that static typing sucks, but the primary advantage that static typing provides that dynamic typing doesn't is performance. However, the performance difference has grown smaller (the difference between VisualWorks Smalltalk and Sun Java is minor) at the same time as computers have become faster, making it unimportant for many applications.

The performance reason still influences today when it's no longer such a compelling logical argument, but the more difficult issues a new language must address are that programmers are conservative about language choice and managers are strong followers of large corporate marketing campaigns (hence the popularity of C#.)

The main advantage of dynamic typing is less complexity and increased speed of development, so the question is the old one of programmer time versus machine time. Many programmers sacrificed machine time for programmer time in moving from C++ to Java or C#, so the choice has be made in favor of improved programmer productivity in the past and likely will be again in the future.

However, the question isn't simply which language will offer a sufficient improvement in programmer producitivity for a small loss of performance. There are plenty of choices (Lisp, Smalltalk, OCaml, Haskell) that offer a tremendous gain in productivity and three of the four are faster than Java. The question is what choice can do that and also overcome programmer conservatism and manager fashionism.

It's also worth pointing out that two of the languages above are staticly typed but not explicitly typed. Both Haskell and OCaml use type inferencing to determine types, allowing generics to be expressed with none of the effort required in C++ or Java. While I don't expect a major migration to OCaml or Haskell, type inferencing will become widely discussed as it has been announced as a feature of C# 3.0.

rickcarson
Offline
Joined: 2004-03-04
Points: 0

> [...] but the more difficult issues a new language must
> address are that programmers are conservative about
> language choice and managers are strong followers of
> large corporate marketing campaigns (hence the
> popularity of C#.)

Note that there have been transitions in the past despite those factors, eg my vaguely historical timeline where I talk about COBOL being replaced by VB which is then replaced by Java.

> [...] The main advantage of dynamic typing is less
> complexity

And yet we continually see offhand comments about how for instance Lisp is too hard for the average developer.

An interesting contradiction. That it is 'less complex' and at the same time 'too hard'?

People talking about the dynamic languages say that they allow a higher level of abstraction. Okay, fine. Java also allows some pretty high levels of abstraction through OO. That then leads into a discussion of 'domain specific languages'. But of course every time you define a new object class it is like adding a noun to the language, interfaces are like adjectives, and methods are like verbs. The problem with that analogy is that if I want to have a kick verb I can only kick things which I then add that method to, whereas in natural languges whenever a new verb is made up you can apply it to pretty much anything immediately.

NB: Objective-C which is otherwise quite similar to Java takes the approach that method calls are like messages to the object (derived from Smalltalk I think) - and that you can send any message to any object. In that respect I suppose Objective-C is less strongly typed than Java. While it makes certain kinds of things easier (ie any object can be a proxy for any other object) it does not seem like that big a deal. Eg if you want it you can go out and find a c syntax language with that feature. I think that is where the debate would veer off into a discussion about functional languages vs procedural. Because I think that dynamic typing is just a smaller part of a larger argument.

> [...] However, the question isn't simply which language
> will offer a sufficient improvement in programmer
> producitivity for a small loss of performance.
> There are plenty of choices (Lisp, Smalltalk, OCaml,
> Haskell) that offer a tremendous gain in productivity
> and three of the four are faster than Java.
> The question is what choice can do that and also overcome
> programmer conservatism and manager fashionism.

You do a good job of laying out the case that the next big language will be one which continues the trend of sacrificing a little bit of runtime speed for a lot of developer productivity.

But - it is an old saw that going with Java forces you to sacrifice execution speed. I'm not convinced that that is necessarily the case. After all, with hotspot and runtime profiling I understand that in some cases optimizations can be made at runtime which could not be made at compile time, which means that for some things Java actually runs faster than native code.

For my own projects, I've always found Java to be blazingly fast. I admit that when I've worked with some other people's code that the performance has been less stellar - but in those cases it seems to me that the codebase has been 4-10x the size it actually needed to be - and I've seen the same thing said about Lisp, that it is easy for an unsophisticated approach to be hideously inefficient.

So I'm not convinced that the languages you list are faster than Java. I think well written Java is 'fast enough'.

But... at least two of those languages were around at the same time that not one, but two major language transitions occurred in the marketplace (when COBOL handed over the crown to VB, and then Java took it off VB)

Why did the languages you list not seize the day on those occassions? The performance of VB for instance (being an interpreted language) was terrible... if those languages were:
(a) less complex than Java
(b) faster than Java

Why weren't they the ones to push VB off the throne?

It seems to me that the people going on about these other languages are like kids bragging about how their Dad can beat up your Dad - whilst their Dad is lying in hospital on a life support machine after having been beaten within an inch of his life.

So why are dynamic/functional languages so unpopular? Is it because of conservatism? Hardly, as there have been numerous upheavals in the computer industry.

In fact, it must be that they simply fail to offer any compelling advantages. The people who learn them at university simply don't go on to use them in the real world. Perhaps they are initially 'forced' to use other languages (like VB), but then they find that those languages are perfectly adequate, and over time the zeal for functional languages dies down (or withers on the vine or what have you).

By analogy, I had a friend I introduced to Java who was a big fan of Pascal. Initially he complained about a lack of enums. Later on I found out he was using arrays for everything because he didn't trust other people's libraries for things like ArrayList and Vector (due largely to bad experiences with Microsofts IIS libraries). I convinced him to give the sun ones a chance. A couple of years later I caught up with him again and asked him about enums. He said that he didn't miss them any more, somewhat surprised I asked him why not - and he said that if you program properly in 'the Java way' you don't need them.

jwalden
Offline
Joined: 2005-12-03
Points: 0

> And yet we continually see offhand comments about how
> for instance Lisp is too hard for the average developer.
>
> An interesting contradiction. That it is 'less complex'
> and at the same time 'too hard'?

Lisp is much easier to learn than Java. The syntax is so simple you can pick it up in an hour. Languages like Lisp (Scheme) work wonderfully to teach children how to program. The C-family of languages, including Java, are much harder for people to learn.

The contradiction arises in the adult programmer who's familiar with one of more C like languages. For that adult, learning Java is easy because there's such a great similarity between the two languages. However, learning your first functional language, whether it's Lisp, OCaml, or Haskell, is going to be quite hard because it's a fundamentally different paradigm of programming. Most imperative programmers have a difficult time imagining programming without lists of statements that execute in order, variables, and loops, but that's what they're giving up in using a functional language.

I need to leave now, so I'll have to answer the rest of your message later.

rickcarson
Offline
Joined: 2004-03-04
Points: 0

But if these languages are 'so much better than Java' why aren't there more open source projects built around them?

Other than Perl, Python and PHP all the other scripting languages put together amount to diddly squat.

So I think there must be some factor (or factors) inhibiting the uptake of those languages.

Example: abstraction
John Reynolds (I think it was) posted recently about how COBOL programmers were interchangeable, whereas Java programmers were not. And that Java code tended to take on a personality specific to its writer because Java encourages abstractions. So if functional languages encourage abstraction, only more so, then it would be even harder for them to be 'shared' between programmers.

So for an individual they might be highly productive (the porridge is just right), whereas for a group, unless they are all on the same wavelength, it will be much harder (the porridge will be too hot, cold, salty or sweet). Which would make them really good for tools, scripting style tasks and prototyping... but when you were going to share it around you'd pretty much have to choose another language.

This could explain the Yahoo store phenomenon: originally written in Lisp in record time (allegedly) and then later on rewritten in Java because noone could maintain the Lisp (allegedly).

jwalden
Offline
Joined: 2005-12-03
Points: 0

> But if these languages are 'so much better than Java'
> why aren't there more open source projects built
> around them?

I explained that in the post directly above. Most programmers already have learned an imperative language like C, Java, or Python, and so have developed many assumptions about how programming works that aren't true for functional languages where programs aren't sequences of statements that work by changing a shared state. That's why functional languages aren't likely to replace Java, though we are seeing more and more functional features in dynamic languages like perl, python, and ruby.

> Example: abstraction
> John Reynolds (I think it was) posted recently about
> how COBOL programmers were interchangeable, whereas
> Java programmers were not. And that Java code tended
> to take on a personality specific to its writer
> because Java encourages abstractions. So if
> functional languages encourage abstraction, only more
> so, then it would be even harder for them to be
> 'shared' between programmers.

There may be a sweet point on the abstraction continuum, but it seems unlikely to me that a language as low level as Java is it. I think what we're seeing today is like the type of resistance that was presented by the goto users when structured programming arose, though it was nice to see Java 1.5 add a modern control structure (the foreach loop), though the syntax is not as clean as I wish it was.

Language features have always evolved slowly. It took about a quarter century from Simula to C++ growing popular for object-oriented programming to become a part of most programmer's mindset. Java contains no feature that's newer than 1974. Computer languages change slowly because languages aren't just a tool; to some extent, they're what programmers think in.

A computer language needs several things to become popular:

1. It needs to be the programming language of some software system that many people need to use, like C was the language of UNIX or Java with its focus on the web. Lisp had emacs, but emacs isn't sufficiently popular; Python and Zope have the same problem. Ruby may have this with Rails, but it's too early to tell.

2. It needs a free, high quality implementation. This is one point many of the dynamic languages lack to some degree, hence all the work on implementations like Jython and Iron Python and JRuby and Rite.

3. It needs marketing. A good book, and either corporate, university, or open source "hype." Java and C# had their corporate sponsors, but C and C++ became big through word of mouth without major support from AT&T.

4. It can't be too different from what people already know. This is why Ruby is more likely to be the next language than Smalltalk or Lisp, despite the fact that both of those languages are faster and more powerful than Ruby.

Anonymous

> I explained that in the post directly above. Most
> programmers already have learned an imperative
> language like C, Java, or Python, and so have
> developed many assumptions about how programming
> works that aren't true for functional languages where
> programs aren't sequences of statements that work by
> changing a shared state. That's why functional
> languages aren't likely to replace Java, though we
> are seeing more and more functional features in
> dynamic languages like perl, python, and ruby.

Right, and Perl, Python and Ruby are so "brand new 1.0 versions". One thing that I think is wrong about this line of thinking is that dynamic languages and static ones are not excludent. They have existed for a long time, and both have their spaces, Java will never replace Perl, and Perl will never replace Java.

Some people are not resisting to the idea NOT because they are affraid of changes, but because it makes no sense at all.

(unnecessary slashdot-like-oversimplification: were the german jews concerned about Hitler rise to power for being "affraid of changes"? Not all changes are good ones.)

Another thing, the "development cycle faster myth". That makes me wonder if people are using vi to develop in Java and Tomcat for running it. I'm not going to bash Tomcat because I used it for more time than I'd like to admit, but a real app server would be better. I hope Geronimo will save the opensource guys.

I work in a project of considerable size and basically my routine for changes is:

- Update a line a JSP: refresh the browser screen, 1 or 2secs;
- Update a class: the local testing appserver gets it automatically, update the browser screen, 1 or 2 secs;
- Use Struts components? Drag ad drop.
- Create a Webservice? Click, click, there.
- Mess with Struts config? Fill out a few nice user interfaces, no need to edit XML by hand.
- JSTL? Drag and drop.
- JSF? Drag and drop.
- Build? Export the EARs and place them in the proper server.

Now, if you have to drastically change Struts config at every new version, it's because you app is badly designed to begin with. Once it's initially set, little will change over time.

Please, is Java that productivity killer? Only you're either using vi or Eclipse with no decent plug-ins. If so, it's programmer's fault, not language's.

I agree, though, that the entry point for J2EE and Java in general should be made more straight forward with less "letter soup".

Now, some people just don't learn. XML was way over hyped, and now some are saying that the excess of XML is bad. Could you please make up your mind? The next big crap is called AJAX (like "we weren't supposed to be building web applications anyway, so this is a broken workaround on a broken solution"). Please stop the Ruby madness while there's still time.

Note: The first time I heard of "Java dominance" of something was when those "language critics" started shouting the (not so new because it's older than Java itself) big new thing. Isn't it convenient? It's like cheap propaganda for making it look like it has reached the peek and has nowhere to go from there but down.

Anonymous

> Well, that is actually why I think people are
> "threatened". The Rails success comes along... and
> many immediately say "XXX will kill Java"?
> Where does this association come from? Some new tech
> appears and people immediately think "Could this
> *kill* my favourite tech"? Doesn't that sound like a
> person is worried about something? That there's a
> suspicion that the tech that's used might not be the
> best anymore...

No, it doesn't. It comes from the much crap we read these days on the internet and websites like this one. "Perplexed developers with question marks above their heads" is a better definition I think. Not even in my worst dreams I see myself loosing my job because all systems from my company now run on Ruby instead of Java. It's like saying that all Windows sys admins will loose their jobs because tomorrow all servers will run Linux.

BTW, Linux is what it is today because of big companies such as IBM. Who's the big company supporting Ruby?

Who should worry about it is the Perl, Python and PHP crowd. Do you know how many websites run on PHP? Far more than JSP/J2EE. And there are lots of open source software based on PHP such as forums, CMS, etc around. Does it mean that PHP is killing Java? No. PHP is simpler and quicker for certain kinds of applications.

I'm not a language geek, languages are a necessary evil, I have to express the logic somehow and the language does it, now listening to "Wow! this language gives me 10x all that much power" leads me to wonder:

"How is this language different from the other 2513 computer languages ever invented so far!?"

Buzz, hype, fanaticism, this is the fuel for the Ruby bubble.

The next question I make to myself is:

"There's not a language that's good for all things, they usually fit in niches. There are other that are more of a general use like Java, but that doesn't mean they are the better, what makes a language successful?"

murphee
Offline
Joined: 2003-06-10
Points: 0

> Buzz, hype, fanaticism, this is the fuel for the Ruby
> bubble.

Well... surprisingly, "Buzz and Hype" were the things that put Java where it is today. If it hadn't been for "WORA" or "NCs + Applets will kill $COMPETITOR" etc, Java wouldn't have grabbed mindshare.

And "fanaticism": surprisingly, I don't see that in the Ruby community, which is generally more relaxed than the Java crowd (TheServerSide, Javalobby, etc).

Ruby has a major chance now, because it has Rails as catalyst (as Bruce Tate) calls it. That's what gives it an edge over current other dynamic languages, puts it in peoples minds and pulls in developers. You can't develop in Rails without learning Ruby and it's ways. When these ideas are in peoples minds, they'll stay there and support for them will be demanded... Like Java has introduced Garbage Collection to the masses... just try taking GC away from a Java dev...

VMs, JIT and DynamicCompilers, Garbage Collection and other technologies have advanced significantly since 1995... and now it's possible to avoid all the compromises that the Java creators had to make *without* causing (problematic) performance overhead. And with JRuby, the move can be seamless...
To be honest: I really don't want to be programming the same Java (as today) in 10 years time, just like I don't want to use zero-terminated strings and strcpy in C in 2005.

Anonymous

> And "fanaticism": surprisingly, I don't see that in
> the Ruby community, which is generally more relaxed
> than the Java crowd (TheServerSide, Javalobby, etc).

It's me from the anonymous answer to you. Just to mention, I was called from all kinds of name from a gang of Ruby zealots another day in one forum, because I was questioning the value of the "must have" buzz on dynamic languages. Dynamic languages exist for a long time and today this is a kind of categorical imperative for "power" according to some. I don't remember such behavior from the Java crowd.

The stranger thing, that was a JAVA forum. Now, why would Ruby developers be marketing Ruby in a JAVA forum other than fanaticism?

I don't think Ruby developers are relaxed, at least not this new generation of ex-Java Ruby developers that have found the 8th wonder of the world in Ruby.

Another thing that makes me wonder about the Nietzschean "will to power" unconscious desire in Ruby devs, carefully rationalized to look moral from the eyes of the community, are the silliest arguments.

Even about being "closer to english language". Unless they mean to internationalize computer languages (which is a pretty bad idea), with versions of langs in chinese, japanese, german, etc, by doing that you're just screwing everyone that's not a native english speaker's life.

I know some people that have the very basic knowledge of english enough to use today's languages. Making it more english is a good tool, for FIGHTING OFFSHORING, although the indians speak english fairly well. Some professionals have problems reading the javadocs for Christ's sake! Englishfying a computer language is like englishfying math. Everyone can understand math because its symbols are universal.

> Ruby has a major chance now, because it has Rails as
> catalyst (as Bruce Tate) calls it. That's what gives
> it an edge over current other dynamic languages, puts
> it in peoples minds and pulls in developers. You
> can't develop in Rails without learning Ruby and it's
> ways. When these ideas are in peoples minds, they'll
> stay there and support for them will be demanded...
> Like Java has introduced Garbage Collection to the
> masses... just try taking GC away from a Java dev...
>
>
> VMs, JIT and DynamicCompilers, Garbage Collection and
> other technologies have advanced significantly since
> 1995... and now it's possible to avoid all the
> compromises that the Java creators had to make
> *without* causing (problematic) performance overhead.
> And with JRuby, the move can be seamless...
> To be honest: I really don't want to be programming
> the same Java (as today) in 10 years time, just like
> I don't want to use zero-terminated strings and
> strcpy in C in 2005.

Ok, that's your wish. I don't see anything plain wrong and I like the conservative approach that's used in Java. If compared to the "wild west open source" or the "right to innovate, screw the developers, micro$oft" style it's really better.

I'd rather have platform improvements over syntactic sugar. Platform improvements would be anything related to VM, libraries, etc.

rickcarson
Offline
Joined: 2004-03-04
Points: 0

> Even about being "closer to english language". Unless
> they mean to internationalize computer languages
> (which is a pretty bad idea), with versions of langs
> in chinese, japanese, german, etc, by doing that
> you're just screwing everyone that's not a native
> english speaker's life.
>
> I know some people that have the very basic knowledge
> of english enough to use today's languages. Making it
> more english is a good tool, for FIGHTING OFFSHORING,
> although the indians speak english fairly well. Some
> professionals have problems reading the javadocs for
> Christ's sake! Englishfying a computer language is
> like englishfying math. Everyone can understand math
> because its symbols are universal.

What I was thinking of was that your IDE should be able to translate certain of the symbols (particularly keywords) into your own (human) language.

From an English programmers point of view, I find warting and hungarian notation to be eyesores. However, I am open to the concept that if I didn't speak English, then most of the 'nicely named' methods in the APIs wouldn't mean much to me anyway, so I might be more open to languages making much greater usage of 'symbolic notation' instead of using words to describe the same thing.

Perhaps a counter example to that would be the example of Forth, which I am told has a strong similarity to formal Japanese (eg their sentence structure is (kind of) stack based). And so you'd expect Forth to be the 'killer language' for Japanese developers, and yet for some reason, that appears to not be the case. Then again if closeness to a particular natural language counted for anything, then surely Basic would have been the killer language (arguably Visual Basic reigned supreme* till the late 90s when Java kicked it off the throne, and MS put the stake in its heart with their .net strategy).

* With perhaps COBOL being the previous champion - both of these languages are 'similar' to English (certainly more so than, say, Perl or PHP :D

But of course when we speak of Visual Basic and COBOL - it raises images of 'the great unwashed' the 'lowest common denominator'. One company I worked at as a junior developer in the 90s had about 70 VB and Oracle developers, and some C work came in, I was surprised when noone put up their hand for it. I put my hand up, did the job, and then conducted an informal survey amongst my co-workers about why noone else had wanted to even volunteer for it (and this was back when the university in that city taught C and not VB) - the consensus was that C was 'too hard'.

Recently Paul Graham went on a big diatribe against Java, and that the thrust of what he was saying was that Java had become the language of the great unwashed, and that if you wanted a good programmer, don't hire Java programmers because they were the lowest common denominator.

This is relevant for consideration in this context - because there are plenty of 'high falutin' languages that have their handful of rabid adherents, but most of them never go anywhere. So I suggest that 'the next big thing' is going to have to appeal to the lowest common denominator, or it will remain nothing but a boutique language. If the language is going to get big, being accessible to the masses is infinitely more important than how sexy the syntax of its closures is.

So if we want to look for the next big thing, we should look at the other big languages, of which there are a handful:
VB
COBOL
JAVA
PERL
(Where big = number of jobs/programmers, or lines of code, or numbers of legacy apps, these languages rate well above the boutique languages)

Nothing else comes close (you could argue that embedded processors are a larger market than applications and add assembler to the top of that list - but I think the context of this discussion is applications programming).

Perl of course is the antithesis of the argument, unlike the other three it does not pander to the masses by being easy, rather it is so difficult it is proverbial. Perhaps you could say that Perl is the language of systems administrators, and lump it into the 'not applications programming' category with assembler.

That would drop the list down to:
COBOL
VB
JAVA

Also rearranged into historical order.

So... what was good about those languages?
COBOL was good for data processing.
VB was good for quickly putting together GUI applications.
Java was good for networked or distributed applications.

In some respects Java suffers by comparison with VB, particularly when it comes to the ease of putting together a GUI.

Now lets consider that in the context of 'the other Tiger' Mac OS X 10.4...

We have fast good GUI design (XCode/Project Builder + binding), data processing with Core Data, networking with rendezvous/bonjour...

So why hasn't GNUStep/OpenStep become 'cocoa for windows' and already become the next big thing? What is holding them back? Is Objective-C the anchor around its neck? Is it that it is an open source thing (no big economy company driving it)?

Anonymous

> What I was thinking of was that your IDE should be
> able to translate certain of the symbols
> (particularly keywords) into your own (human)
> language.

This is a bad idea. Imagine yourself working on a global team with such "feature". Not to mention documentation.

> Recently Paul Graham went on a big diatribe against
> Java, and that the thrust of what he was saying was
> that Java had become the language of the great
> unwashed, and that if you wanted a good programmer,
> don't hire Java programmers because they were the
> lowest common denominator.

I have to agree partially. It's always good to learn other languages, but I don't think one language makes the developer a good developer. Usually C and Perl programmers write crappy Java code, because they try to either program C or Perl in Java, and complain that "Java doesn't have
, that's why it sucks" instead of learning how to think in terms of platform, leverage the J2SE libs, VM, etc.

So, I'd say that to be a good developer one must learn the platform it develops on in order take the most advantage of it, and it comes only with experience. No C++ developer will ever do as good code in Java as an experienced Java developer.

mthornton
Offline
Joined: 2003-06-10
Points: 0

> Yes, but they're not necessary anymore. Primitives
> that fit inside CPU registers can be handled with
> Tagged Types (Immediate Types, or however they are
> called) which have basically the same performance as
> primitives, and won't have to be heap allocated. All
> of this can be done with modern VMs and dynamic
> compilers (Smalltalk has always used immediate
> types).
>

As I understand it, while SmallTalk can optimise many uses to give equivalent performance to primitives it doesn't work efficiently for all types of code. So primitives are still necessary for some work and also for some environments where a sufficiently powerful JIT still doesn't fit.

murphee
Offline
Joined: 2003-06-10
Points: 0

> As I understand it, while SmallTalk can optimise many
> uses to give equivalent performance to primitives it
> doesn't work efficiently for all types of code.

Be that as it may, the rift between primitives and reference types is quite annoying. New Java devs always have problems with them ("How can I get a dynamic list of ints"? "You can't, use ArrayList." "But the compiler complains". "Well, of course, you'll have to wrap the values",... I don't want to know how often I had that discussion with people, mostly ending with me pointing them to the Apache Commons Primitives library etc.).

What does that have to do with performance?
Well, Java has always put developer productivity before raw performance.

Actually... AutoBoxing and Unboxing is such a tradeoff;
the newbie trying to stuff an int into a reference type based container, won't get an error message, and won't even know the difference... except for the bad performance (for large numbers).

Again: I know that primitives were a necessary tradeoff, considering the first implementations of the JVM.

>So primitives are still necessary for some work and also
> for some environments where a sufficiently powerful
> JIT still doesn't fit.

You're right... although that area is shrinking too (current Sun MIDP JVMs already support parts of Hotspots capabilities).
Not to mention, that old LISP, Smalltalk,... implementations also ran on - what we would call - limited platforms (16 bit CPUs, less memory than a modern applications splash screen).

rickcarson
Offline
Joined: 2004-03-04
Points: 0

> > The compile/debug cycle complaint is just wrong.
> > Javac and Jar are actually really really fast.
>
> That's not the point; Eclipse has basically removed
> the compile cycle by pushing it in the background (I
> haven't called javac & friends for years).

That was one of the six points that this chapter discussion is about. So it is the point. You bring up Eclipse. The last project I was on which used Eclipse did have an enormously long build/compile cycle (so I can relate to Bruce's pain), but is the source of the problem Java itself? I have tried to show that it isn't the fault of Java, but rather the source of the problem is the tool set (eg Eclipse/Ant). That's not to say that you shouldn't use Eclipse, (or rather: I don't want to get into that, I'll just file it under the category of self inflicted wound and move on) you might choose to use the slow build set because you believe that there are other benefits, whether that is a particular refactoring command you cannot live without, or that you love putting it all back together when it crashes because it is a buggy piece of ... (must not go there, must remain calm, breathe deeply, go to the happy place) ;-)

> A problem is that Hotswap (code replacement) is very
> limited and will stop working even for trivial
> changes (just edit an anonymous class to access some
> local var... it'll need changes in the containing
> class to add accessors, thus changing class
> signature).

I'm not sure what you are getting at with the Hotswap thing, I don't understand the relevance to a slow build/debug cycle.

> > using some automated tool - and we don't have to
> poke
> > around much to see that the problem is actually
> Ant,
> > not Java.
>
> Well... there's a great build tool for Ruby called
> rake... and it doesn't actually need XML or anything:
> it's a DSL in Ruby. See:
> http://www.martinfowler.com/articles/rake.html

There is a kick butt build tool for Java, it is called javac. Sometimes we also need to use another really good tool called jar.

Where things go off track of course is when we need to deploy signed jars, and include W-ars and E-ars and all the other pomp and circumstance which goes with EJB/J2EE.

At that point people do start looking around for other tools (like Ant or Maven). But I think that there is a kind of 'gravitational pull' to these tools... because it is easy to add things like automated tests, code coverage, javadoc generation, metadata generation, run some sql scripts to rebuild a test database from scratch... And sometimes they for some reason didn't quite work, so you end up doing a full clean and build each time 'just in case'...

And before you know it... you're waiting 30 minutes for a build because you changed one class!

That is a true source of pain.

Oh, and changing language [b]absolutely will not make that pain go away[/b]. Because if you were trying to do all those other things, it doesn't matter if it is Ruby, Python or COBOL... because it is the *build* part that is the pain, not the *compile* part.

To avoid this kind of 'own goal' people just need to ensure that in order to debug, they don't need to do a deploy. If they need to deploy to do a debug, something is wrong with their choice of process.

> > thing. However an alternative way of looking at
> them
> > is that they are an optimisation of the things
> that
> > programmers do most.
>
> Yes, but they're not necessary anymore. Primitives
> that fit inside CPU registers can be handled with
> Tagged Types (Immediate Types, or however they are
> called) which have basically the same performance as
> primitives, and won't have to be heap allocated. All
> of this can be done with modern VMs and dynamic
> compilers (Smalltalk has always used immediate
> types).

Well, that is an argument about how Java should have been implemented. I understand where you and Bruce are coming from, but I think that boat sailed ten years ago.

I also think that if we were using modern vms to reimplement Java from scratch we might well choose to do things differently. You might find that as they make changes to support scripting languages, then a lot of the 'missing' smalltalk stuff might 'sneak in the back door'.

But, other than university researcher types (ie the purest of the purists), out in the real world I don't see anyone wailing and gnashing their teeth over the whole primitives thing. Autoboxing looks like it is causing some pain, but that goes more in my category of 'look how badly tiger was stuffed up' ('the love of generics being the root of all evil' and all that jazz).

> The problem with Java: if you want to have proper
> performance, you use primitives... but you can't keep
> that up if you want to handle them with container
> classes. So Sun brought up Autoboxing/AutoUnboxing...
> which added further little complexity to the language
> (subtle ones... like the fact that Autoboxing some
> values (-128 -- +127) causes no allocation, whereas
> the rest *does* cause heap allocation).

And equals vs ==

> Now: if all types had been reference types,
> optimizations could have been added in transparently,
> ie. speeding up code; with the rift between
> primitives and wrappers, this isn't possible.
> And let's not start talking about the mess that is
> BigInteger & Co; the issues with those would be non
> existant in a primitive-less world. We're constantly
> bumping into size limits in IT... and it's the same
> with bit widhts of types; thing is: it wouldn't be
> necessary.

Spilt milk. And how much space should 1/3 take up anyway? Or e, or pi?

> Don't get me wrong: I know why primitives happened
> (first VMs with the very simple interpreter plus
> simple GC), but that doesn't mean that we should have
> to live with that nonsense longer than necessary.

Eh. I don't mind it. Even if it means that Java is really actually two different languages, since there are a set of operators for primitives, (eg +/- && || true, false) and a set of operators for objects (new . ()) and some for arrays ([]) which are objects that pretend to be primitives etc.

Java is reasonably comact in terms of operators, while still being reasonably expressive, while still being reasonably readable. Sounds to me like they did a great job.

> > For strong static typing, I think that is a matter
> of
> > taste. But... perhaps in the interest of
> introducing
> |...|
> > In terms of productivity - strong typing is king.
> > Strong typing has (in those competitions),
> > convincingly laid the smack down.
> [...]
> >This is not a 'ring out', this is not a victory
> because > someone interferred by throwing a chair
> into the ring
>
> Sorry... but do you actually have any specific
> arguments for static typing? All your paragraphs just
> contained empty victory metaphors and chest
> beating... but no content.

Since I'm not involved in those competitions no. I was hoping that someone would pop up with proof either for what I was saying, or against (the web page which I saw the non-static-typing person lamenting the inability of non-static-typed-languages to win is also several years out of date).

Frankly the nuances of the differences between Dylan and Haskell and Scheme seem a bit academic to me. I also think that it is not necessarily a strict duality, it is not just 'evil' ie static-typing vs 'good' (whatever the opposite of static typing is).

There is static, weak, strong, dynamic... looks like a multi-dimensional thing to me. Looks like the opening volley of the standard 'language holy war'.

What makes it interesting though, is that Bruce is of course supposed to be one of the 'faithful true believers' - and he has 'gone over to the other side', as though Patton had said "hey, maybe the soviets* are actually a good idea"

*Brief history lesson: soviets good, communists bad (soviets were actually a really good thing, and the communists got into power because they said 'if you like the soviets, vote for us').

But I digress. The point I guess is that Bruce's original assertion that static typing sucks, is just as much chest beating as my assertion that it doesn't. *Except* that I suggest that there is an easy to find long term example where static typing has consistently won out time and time again. If I'm wrong, it should be easy to prove me wrong. Whereas Bruce's assertion doesn't seem to be testable...

> > As for the choices that people make, you cannot
> > legislate against stupidity.
>
> Indeed.......

> > When the revolution comes, the book authors and
> gurus
> > should be right behind the architects in the line
> of
> > people that need shooting.
>
> It's funny to read statements like this... it shows
> that the Java world is *really* scared shitless over
> competition like Ruby, Python, and other dynamic
> languages....

No, it shows that if I'm scared of anything, it is the snakeoil salesmen that call themselves architects, who usually have half or less the experience that I do in Java, making decisions about what tools and technologies I am told to use (even though they may know nothing about the tools and don't use them themsleves), and making design decisions about code they never have to write or maintain.

If I am scared of anything, it is the people who are looked to to make these calls, but are then not held accountable for the decisions they make. Power without accountability is *always* a dangerous thing.

This whole 'you are scared of change' thing is annoying. You see it all the time from the Agile zealots. Anyone that has tried their way of doing things, and didn't like it is 'afraid of change'. How rude is that? And wrong too, if they were really afraid of change they never would have tried agile in the first place.

In this case, if someone has tried Ruby and Python and doesn't like them, does that make them 'afraid of change'? Of course not! My personal objections to Ruby were the special characters on the front of variable names - which give me flashbacks to hungarian notation. My objection to Python was based on their use of the underscore as a special character (for constructors or something like that) - which gives me flashbacks to visual basic.

But those are subjective things. Some people don't mind having horrible mangled variable names. And I can see that Python has a point about the extra 'fluff' of C/Java syntax ( {}s and ;s ). But they have their own problems, just ask a Python fan about whether spaces or tabs are the proper way to go...

> Hey, I'm a Java developer... but how about this:
> let's use the dynamic languages to improve the Java
> platform... move the crufty old Java language to
> write the nasty stuff... and then write the
> interesting bits of the software with dynamically
> type languages on top.
> How about this: instead of slagging of static typeing
> and blatherin about "static typing is king"...

You're not getting into the spirit of this whole my language is better than yours flamewar thing.

Please practice your posturing and soapbox standing thing some more.

> how
> about doing something productive? Like: thinking how
> the *benefits* of static typing could be added to
> dynamic languages? (How about a extension library for
> Ruby that allows you to write protocols/interfaces,
> or enforce certain class signatures).

Or, better yet, taking the good stuff from Rails (eg using reflection to create table classes - sorry Hibernate, you're too slow and ugly, you lose), and subsuming it into our own web frameworks?

Some people just don't like Java, they never have, they never will. That is their problem, not ours. As the saying goes you cannot please all of the people all of the time. Perhaps they find that they are 'magically' more productive in another language, because it fits their style better.

murphee
Offline
Joined: 2003-06-10
Points: 0

> I'm not sure what you are getting at with the Hotswap
> thing, I don't understand the relevance to a slow
> build/debug cycle.

OK: you can replace code in running Java Code using Hotswap, which works nicely... except that the changes must not touch the class structure; if they do, the update can't be applied.
Ruby (or Smalltalk for that matter) can update even class definitions at runtime and can update object trees with the new methods, data,...

This means: fewer restarts (if at all) during development. This is one major annoyance for me when developing (web apps, or Eclipse plugins) because even a minor change in a class (or the code of an anonymous class) will stop Hotswap working.

> been implemented. I understand where you and Bruce
> are coming from, but I think that boat sailed ten
> years ago.

Weeeell... the nice bit about JVM language implementations like Jython, Rhino or JRuby is the fact that they can make the right decisions on top of the JVM, while still keeping the available libraries, the powerful GC,...
So I think while Smalltalks train might have rusted in the station (to use Bruce's words)... there's now a chance to get higher level languages without major upgrade pain. Sure, Jython (or Rhino,...) have been available for years, but now they've managed to get more air time and space in the mindset to really take off.

> purest of the purists), out in the real world I don't
> see anyone wailing and gnashing their teeth over the
> whole primitives thing.

Weeeell... there must have been a reason for MS to add AutoBoxing to C#, which caused Sun to rush and add it too.

> > with bit widhts of types; thing is: it wouldn't be
> > necessary.
> Spilt milk.

Well... I mostly annoyed to see, that milk will be spilt again, over and over. Like the fact that NIO Buffers measure their size in int...

>And how much space should 1/3 take up anyway? Or e, or pi?

That's a matter of precision. Define one that takes the same precision as a double. Make another accessor for PI, where you can add in a precision parameter (PI'd have to be calculated then, if you really need that).

> This whole 'you are scared of change' thing is
> annoying. You see it all the time from the Agile
> zealots.

Well, I know that rhetoric too, but mostly from grumpy, bitter old LISPers or Smalltalkers who still can't believe that people didn't flock to their tools, despite the fact that they've been telling them what idiots they were for not using them..........

My "scared shitless" argument doesn't come from that; I get that impression from following many Java-releated blogs, Javalobby, ... And there's just the impression, that devs (at least the more vocal ones) feel like they've been caught off guard by Rails & Co.
While the J2EE world has been busy developing Web Framework #58 ("Now with 20% more AOP and less DIY" or whatever), the Rails guys managed to truly make a tool
that makes you more productive and takes away the pain of J2EE Web development. (And no; I'm not just talking about Rails' scaffolding support or ActiveRecord; it also facilitates MVC without bragging about it; it comes with tools to set up controllers, data binding,... and other elements without requiring an IDE; it comes with templating and tiles support (without requiring you to evaluate all the 42 Java templating Frameworks); it doesn't need Taglibs, because the language is expressive enough on its own,......).

I think many Java devs just feel like they've been caught off guard; while their world was busy building more complexity, someone else managed to achieve the same thing in a simple manner.
Oh... it's not that all feel that way; many have recognized the problems before too... the folks who started Spring, or whoever gave the impuls to do EJB3...

I also perceive some sense of fear (although those people would probably not admit it) from all the bloggers and poster who like to spread FUD about dynamic languages.
I remember a recent JavaPosse newscast, where the hosts were also talking about Beyond Java... but they dismissed dynamic langs by claiming that Java just allows to write more stable code... for I/O for instance... without any rational explanation.
Static type checking can do a lot of things... but it won't tell you to catch Runtime Exceptions; it won't prevent you from casting to a wrong type, it won't tell you to close those InputStreams (because you're leaking resources, file descriptors,...).

FUD is used by people who are scared (or I should've use the word "threatened" instead of "scared").

Oh... of course, I should clarify: a statement like "the Java world is FOOO", is necessarily an over generalization... There are millions of Java devs and the only statements that hold true for all of them are things like "They have to eat" or "They know what an if statement must look like".

Anonymous

> FUD is used by people who are scared (or I should've
> use the word "threatened" instead of "scared").

I wouldn't take the words of others as FUD so quickly. What's happening is beyond my comprehension, yes, I have taken a look at Ruby, yes, I did look Rails, and just don't get it. That simple. The world is not CRUD apps, so you realize there's so much more out there that needs to be addressed by a language.

It seems more like a stampede. All of a sudden everyone is running in one direction and they don't even know why. :) It's just ridiculous. Every once in a while this happens, XML was the cure for all diseases not so long ago, C# was also "the killer", so many times better than Java as I used to read, now look again.

I use also Perl at my job, and used PHP for quite a while(I like Perl the most). The same way as I could be using Python or Ruby, I just don't understand how this would be a threat to Java.

The scope of Java (EE, SE and ME), the tons of free or commercial libraries and tools available. The IDEs are a real productivity boost, I can't imagine myself programming without one. I just can't see Perl, nor PHP, nor Ruby, not Python,
, beating that.

If the argument were .Net and Visual Studio I'd understand. But this!?

Dynamic languages is the word of the day (curiously Ruby is older than Java itself). People are arguing against primitives for reasons that are the stupidest.

I think what you call "scared" devs are more like "perplexed devs with huge questions marks above their heads while thinking: Is THIS that is supposed to kill Java!? I don't get it.".

Yes, I don't get it.

murphee
Offline
Joined: 2003-06-10
Points: 0

> I wouldn't take the words of others as FUD so
> quickly.

Well... "FUD" == "Fear, Uncertainty, Doubt". If someone spreads arguments about some topic that induce F, U, and D ... then we can call that FUD.
Someone saying "Well, I FOO seems nice, but I think that you will lose your eyesight doing it" without providing conclusive evidence is FUD.

> Rails, and just don't get it. That simple. The world
> is not CRUD apps, so you realize there's so much more
> out there that needs to be addressed by a language.

Rails is not about CRUD apps. The scaffolding and ActiveRecord are the things that are the ones, that most people refer to. For me: these are useful, but features like trivial MVC (without having to jump through XML hoops), default templating system, many default extensions (what JSPers would do with Taglibs), no recompilation step, ... are the things that make it very easy to use.
I come from having to fret with Struts for 2 years... (again: not database apps)... and *every* little change to the Struts app involved a lot of cursing and staring at StackTraces coming from having to edit tiles.xml, struts-config.xml, whatever.xml to even add a simple new action...
Rails just works like a charm for that... it just works, and I didn't even have to download 100 MB of specialized GUI tools for this.

Oh... and to use your argument: "The world is not Huge Enterprise projects with 50+ developers".
If you do that, use J2EE all the way up and down.
Rails, on the other hand, makes it trivial to write a well designed web app; Many people (me included) have found that they were writing an app with Rails... that they would have never thought of writing with J2EE.
The good thing: it's not some quick'n dirty solution, but instead can be a properly designed OOP app; considering the fact that Rails fosters MVC, Testing (creating a controller etc in Rails creates test skeletons for it),... it's better at this than many other web framework.

> a while this happens, XML was the cure for all
> diseases not so long ago,

I'm not saying that Rails or Ruby is the solution to everything (neither are the Rails developers, BTW).
But the J2EE environement has grown to a certain size and has accumulated a lot of cruft, much of it in the Form of overused XML.
A shedding of some of that is quite useful, and actually what happens right now (just look at EJB3, Spring, ...)
And Rails is one of the signs of that happening...

> be using Python or Ruby, I just don't understand how
> this would be a threat to Java.

Because Java's big claim to success has always been that it's higher level than C/C++, has higher developer productivity than C/C++, is much easier to learn,...

And now suddenly a language (Ruby) has come in to the spotlight ... and it boasts the very same advantages.

Now: Ruby has been around for as long as Java; same thing for other dynamic languages.
BUT: Rails has now provided a Killer App for Ruby, and has propelled it into the public eye in less than a year.

Hype... yes... but you need to remember that Java woudln't be here if it wasn't for Hype. Due to Applets, NetworkComputers, WORA... Java was hyped into every magazine and article in 95/96.
And now it's Ruby's time ... if the Ruby community plays it's cards right, then Ruby will have major success in the future.

*That's* the reason why *I* think Ruby is different from those other dynamic languages. Smalltalk, LISP, Python,... none of them had major killer apps... they might be just as good as Ruby (better?) ... but it's all about marketing.
Hey... XML was no innovation... SGML had been here for decades... yet the marketing campaign in 98 (the fact that W3 made it a standard) made it popular so we're using it all day nowadays...

> or commercial libraries and tools available. The IDEs
> are a real productivity boost, I can't imagine myself
> programming without one.

Weeeeell... if it's IDEs you want:
http://www.radrails.org/
or for pure Ruby
http://rubyeclipse.sourceforge.net/

Not to mention that Rails is productive without an IDE, it already comes with scripts that create controllers, actions,...
Sophisticated Deployment also comes in the form of Switchtower: http://manuals.rubyonrails.com/read/book/17
which facilitates multiple deployments including rollbacks in the case of a failure,...

> I think what you call "scared" devs are more like
> "perplexed devs with huge questions marks above their
> heads while thinking: Is THIS that is supposed to
> kill Java!? I don't get it.".

Well, that is actually why I think people are "threatened". The Rails success comes along... and many immediately say "XXX will kill Java"?
Where does this association come from? Some new tech appears and people immediately think "Could this *kill* my favourite tech"? Doesn't that sound like a person is worried about something? That there's a suspicion that the tech that's used might not be the best anymore...

Message was edited by: murphee

Message was edited by: murphee

rickcarson
Offline
Joined: 2004-03-04
Points: 0

@murphee

I agree 100% with your assessment of Struts. I don't see anyone else disagreeing with you about that. Let us take as given the statement:

Struts is horrible.

Let us also, notice that "Struts is horrible" is different from "Java is horrible".

I find it entirely plausible that Ruby development is much faster than Struts development. However, I think Java *done right* can probably give Ruby on Rails a jolly good run for its money.

In software, I think there are two fundamental forces - on the one hand, you have the forces of simplification (the good guys). These people live and breathe Einstein's dictum "make it as simple as possible, and no simpler". On the other side, you have the forces of complication (the ungood guys). These people love to take simple things and make them really complicated. If they had a truthful motto it would be "there is no design so simple that it cannot be made more complicated with an extra layer of indirection".

How to tell if you're working with someone who makes things overly complicated:

They have a static Handler to a Singleton Factory. And it turns out that there is only one class that fits anyway, but you have to reference it by the string of its class name anyway. In order to use it you would say something like:

Handler.getFactory().getInstance("MyConcreteClass");

when you could have just as well said:

new MyConcreteClass();

(And no, the factory method won't do anything useful other than hiding the 'bad' and 'evil' new keyword.)

An easy way of telling if the framework you are dealing with is Simple or Complex is to look at (a) the doco, and (b) who is trumpeting it and what they stand to gain. If the framework can be described well enough to get up and running after looking at a couple of webpages, it is good and simple (eg RMI, SMTP, JDBC). It doesn't mean they don't have depth, but you can start doing useful stuff almost straight away. A complex framework on the other hand, has multiple hefty tomes describing it, and there is a cloud of consulting companies trumpeting about it - like the buzzing of flies around a week old corpse.

Due to the nature of their business, it is difficult to find a consulting company that will actually promote a technology that will make you less dependent on their expertise...

So it may be that noone is making money from the 'on Rails' framework. If noone is making money off it, everyone has an incentive to make it easier to use...

gd
iukj
batate
Offline
Joined: 2004-03-12
Points: 0

It's interesting reading this thread after it's been out there for a while. Let me clarify a couple of things.

- Re. static typing, I think it's interesting to look at some of the most productive languages of all time, and look at the typing structure. The best systems languages have tended to be statically typed. The most productive applications languages have tended to be dynamically typed. Why? Because dynamic typing allows greater flexibility and higher abstractions. For one example, to add an interceptor to a Ruby class, you rename a method, and insert a new method in front of it that calls the original method. Around 6 lines of code, plus whatever you wanted to do. With a strongly typed language, you break the type when you rename the original method...can't use that strategy. For similar reasons, dependency injection is easy in dynamic languages, but needs a whole framework in Java.

- Primitives were absolutely the right call for Java, but to say they don't matter is wrong. Primitives hit you hardest when you're building frameworks. When the basic atom that you're dealing with is not a single, united concept, it complicates your frameworks, especially when you're trying to do things transparently. Try this. Solve a basic XML emitter with Java. And then pick the language of your choice that doesn't support primitives. I contend that it's the developers of Hibernate, Spring, JBoss and the like that would gain the most. And that's why we have Spring/Hibernate/Tapestry, and Ruby developers have Rails. They are able to work at a higher abstraction, and that's important.

- Compile/debug/deploy cycle matters, and more than you think. Exploration matters too. Seaside is perhaps the most impressive example of this...experience a problem, open your Smalltalk browser within your web browser, write the few lines of code that fix the bug, hit the back button twice, and reload. You never break stride.

But if you've been reading carefully, you'll notice that my points are that

1) Java's founders made some important, careful compromises. One is conservative leadership. Another was C++ syntax with primitives and static typing. These compromises were critical. If they don't make those compromises, there's no Java as we know it today. Great choices; great execution. But they were compromises, and they were not free.

2) I don't annoint a winner in the book. I pick Ruby to talk about because I didn't want this book to be a dissertation on language. I wanted the book to be about Java, and to be a wake up call to the community. I could have used such a book, but none existed. it's the dynamic language with a catalyst, and that makes it slightly more interesting than the alternatives. I personally think we're solving too many small problems with Java. A cleaner, simpler alternative would be better.

As to shooting authors, I do think it's healthy to be a skeptic. There's a whole lot of crap out there. And this book may or may not be part of the dung heap, but you should draw your own conclusions.

Hope this all helps.

rickcarson
Offline
Joined: 2004-03-04
Points: 0

> - Re. static typing, I think it's interesting to look
> at some of the most productive languages of all time,
> and look at the typing structure. The best systems
> languages have tended to be statically typed. The
> most productive applications languages have tended to
> be dynamically typed.

I rate them thus: the most productive applications languages are VB, COBOL, Java, C and Perl (though Perl may be in a different category as a system admin tool rather than an application language).

Where I define 'productive' as 'most stuff produced'. Most of the applications out there are written in VB, COBOL, Java or C. And that is where most of the applications programmers jobs are too (maybe add .net if we are talking about current jobs rather than historical accumulation).

I don't know much about COBOL, so if you tell me it is dynamically typed I guess I would have to believe that until it was proven otherwise.

VB had the notion of a Variant, which was a data type which could pretend to be any of a dozen other things (numbers/dates/strings all rolled into one) ... so I guess that is kind of dynamic.

Java objects can be referenced as any of their super types or interfaces, which can be quite dynamic...

But I suspect that is not what you really mean by 'dynamically typed languages'. I would have said they were more in the 'statically typed' camp myself. Perhaps I just don't understand the distinction between statically typed and dynamically typed.

Or maybe your definition of 'productive' is enormously different. But, from my point of view, if there is hardly any code written in those languages, I don't see how they can be described as being 'productive'.

Please provide some examples of dynamically typed languages that have been as productive as the ones I've named.

Maybe you are talking about 'theoretical productivity', ie 'theoretically, if all the VB programmers had been using Lisp instead of VB they would have been much more productive than they actually were'.

But then that puts the burden back on you to explain why all these 'theoretically superior' languages are left in the dust by all these 'lowest common denominator' languages.

> Why? Because dynamic typing
> allows greater flexibility and higher abstractions.
> For one example, to add an interceptor to a Ruby
> class, you rename a method, and insert a new method
> in front of it that calls the original method. Around
> 6 lines of code, plus whatever you wanted to do. With
> a strongly typed language, you break the type when
> you rename the original method...can't use that
> strategy.

So... if I understand you right you are saying that in a dynamic language you can:

change this:

class Foo {
public doFoo() {
//...Y...
}
}

to this:

class Foo {
public doFoo() {
//...X...
oldFoo();
}
public oldFoo() {
//...Y...
}
}

... and you are also saying that cannot be done in Java?
Or are you merely asserting that it cannot be done at runtime?

Because of course the thing can be done easily when we are writing the code, and is done all the time in Java with inheritance for instance, where you call the super method.

Doesn't that boil down to saying that Java is not very good at changing existing classes on the fly?

And doesn't that boil down to saying that you know that you will write some code which changes a particular class, but for some reason even though you know that when you write the class, you don't want to subclass it there and then, you want to wait till the last minute?

... Must be a Lambda Calculus kind of thing I guess...

> For similar reasons, dependency injection
> is easy in dynamic languages, but needs a whole
> framework in Java.

Dependency Injection is way overblown. But such is the way of patterns... those who sit down and slap a bunch of patterns around as their design phase invariably end up with a horrible design. Fortunately for them they will soon be promoted to architects and not have to deal with the messes they have made.

Bitter? Moi? Por quoi?

> - Primitives were absolutely the right call for Java,
> but to say they don't matter is wrong. Primitives hit
> you hardest when you're building frameworks.

Not if you can design/code your way out of a paper bag.
Evidence of good frameworks despite primitives:
Servlets, RMI, Java sockets, Applets etc.

Most of the core Java apis are pretty darn good. Most of the 'silver bullet of the month club' ones are horrible. And yet they both use the same language: Java.

So obviously, it is not the language that makes the difference.

> Try this. Solve a basic XML emitter with Java.

Ha! Bad example! Java pojos make superb XML emitters if you code the hierarchy properly.

At the end of last year I was working with a chap who liked (and was advocating the use of) JAXB. I'd never worked with JAXB. To see if the claims for it were true, I handed him the XML schema we had lying around, and then grabbed the spec for what XML we wanted our system to spit out. It took him about an hour to create the 200+ JAXB files, whereas in the same time I had (from scratch) hand rolled, tested and integrated into our application a solution using a dozen or so pojo classes.

(Where the JAXB might have had an advantage would have been reading the XML - but in that case our needs were very very basic and we could just use a DOM parser and pull the bits we wanted off that - or, if the spec or the schema had changed constantly, but invariably it was easier and faster to modify the hand rolled code than it was to regenerate all the JAXB classes).

Another thing which made it hard for our JAXB loving friend was that none of our 'ordinary' programmers could figure out where to even start using the JAXB classes - personally if I was writing a framework like JAXB I'd make sure to make the one class you will work with the most actually stand out from the sea of helper classes. (Like shove all the stuff you won't use directly into a different package or something)

> And then pick the language of your choice
> that doesn't support primitives. I contend that it's
> the developers of Hibernate, Spring, JBoss and the
> like that would gain the most. And that's why we have
> Spring/Hibernate/Tapestry, and Ruby developers have
> Rails. They are able to work at a higher abstraction,
> and that's important.

I had a piece of work once maintaining an app which used C sockets. The people who were using the app were really unhappy because it had suddenly stopped working one day, and another app they used which did something similar had kept working. Turns out they changed the network protocol, so of course the C sockets barfed big chunks. Whereas the VB app just kept working and didn't even notice the difference.

That was quite a powerful lesson on the advantage of working with high levels of abstraction.

> - Compile/debug/deploy cycle matters, and more than
> you think. Exploration matters too.

No, I think that exploration is important. That is just one of the reasons that I think deciding up front that you are going to use a whole lot of infrastructure apis like Struts and EJBs is wrong for most small/mid size projects... and *especially* wrong for very large projects.

Same thing with patterns. Patterns are solutions to problems, and they have drawbacks. So an architect that sits down and says here is our design, and hands you a bunch of patterns as step one is causing trouble. If they decide what problems they are going to have, and start making compromises before they even explore what the problems are actually going to be... no wonder so many large projects are in trouble!

I see lots of Java adds begging for senoir programmers experienced with Struts... and I just think "you fools, if you hadn't used Struts you could have finished by now with much cheaper/less experienced programmers".

> Seaside is
> perhaps the most impressive example of
> this...experience a problem, open your Smalltalk
> browser within your web browser, write the few lines
> of code that fix the bug, hit the back button twice,
> and reload. You never break stride.

Eh. Find problem in running Java program. Alt tab to Wordpad. Fix code. Hit X (or Alt Q) in corner to kill Java program. Alt tab to DOS prompt. Hit up arrow twice, then return (to compile). Hit up arrow twice then return (to launch the app again).

I count that as 10-12 keystrokes... seriously, it is not that big a deal.

If it is a big deal for you, then throw out whichever massively over engineered IDE is the anchor around your neck (and they all have their moments - even (especially) Intellij which is not just over engineered but over hyped too).

I mean... who wants to have 80% of the space on their monitor taken up by millions of tiny buttons, menus, views and tabs anyway?

Liberate yourself! It is just like a big bra burning - only not quite as interesting to watch perhaps. :D

> But if you've been reading carefully, you'll notice
> that my points are that
>
> 1) Java's founders made some important, careful
> compromises. One is conservative leadership. Another
> was C++ syntax with primitives and static typing.
> These compromises were critical. If they don't make
> those compromises, there's no Java as we know it
> today. Great choices; great execution. But they were
> compromises, and they were not free.

I don't think C syntax is really all that special. If nothing else, Python shows us that there is some cruft in that syntax that we could get rid of (not that we could not have learned exactly the same lesson from VB... :)

Java does suffer a bit from being two languages, one of primitives and one of objects. *

But it is not all bad. Logical operations for instance make a lot more sense when you are dealing with primitives.

I've seen examples of how to code up your own if and booleans in Lisp and... it ain't pretty.

> 2) I don't annoint a winner in the book. I pick Ruby
> to talk about because I didn't want this book to be a
> dissertation on language. I wanted the book to be
> about Java, and to be a wake up call to the
> community.

But what it sounds like you are saying is that there are all these fundamental problems with Java - things that can pretty much never be changed (like primitives and dynamic vs static) that are horribly wrong... oh and by the way, it just so happens (ta da!) that there is this language called Ruby which has none of those problems...

Why sound a warning call about things that cannot be changed? The horse has bolted, the milk has been spilt, and the barn burned to the ground years ago - no point in calling out the fire brigade now.

> As to shooting authors, I do think it's healthy to be
> a skeptic. There's a whole lot of crap out there. And
> this book may or may not be part of the dung heap,
> but you should draw your own conclusions.

Thanks for not taking that too badly :D

> Hope this all helps.

* Java also has its own meta-language. Anyone that regularly writes methods which return hashmaps (and particularly hashmaps of hashmaps**) does not speak this meta-language. Neither does anyone that is overly fond of the static keyword, or handlers or factories and singletons.

** May I recommend to anyone in this category that they apply themselves to mastering Perl, everyone will be happier that way all around.

murphee
Offline
Joined: 2003-06-10
Points: 0

> enormously different. But, from my point of view, if
> there is hardly any code written in those languages,
> I don't see how they can be described as being
> 'productive'.

Read your sentence again and think about it. You already stated why those languages are deemed more productive (Hint: less code written...).
BTW: where do you get the idea that there's hardly any code written in dynamic languages (see Perl, PHP, Python, Ruby, etc. for use in Web projects).

I hate to bring up Rails again, but just looking at the code Java solutions for what Rails does (Hibernate+Struts+Tapestry+Tools for creating the app)
shows that. (Take just one of the source of thementioned Java tools ... it's source will be larger than the whole Rails package).

> So... if I understand you right you are saying that
> in a dynamic language you can:
> change this:
SnippedCode
> ... and you are also saying that cannot be done in
> Java? Or are you merely asserting that it cannot be
> done at runtime?

It's not possible to do that at runtime in Java. That means adding the redirection, updating or removing it.
What you *could* do is use a DynamicProxy to do that, but then you still have to write a the delegation code yourself, not to mention that you can't do that to a live object (ie.you have to give the reference of the DynamicProxy to the user of the class).
Not to mention that this gets more difficult/tedious for non-Interface methods (then you'll have to engineer a class with the same methods) or impossible (if the method needs to be of a certain class and that class is final).

> Doesn't that boil down to saying that Java is not
> very good at changing existing classes on the fly?

A) It means that.
B) it means that you have to jump through many hoops to do anything like that. Just observe the many efforts to do AspectOriented Programming in Java. There are Source solutions (AspectJ I think, maybe others) or runtime/bytecode modification ones (JBoss I think, others,...). Both solutions are difficult, have problems (the source ones need tools support and require developers to learn the new syntax), the dynamic ones are always a bit fiddly (messing with bytecode always is).

With Ruby (or Smalltalk or whatever), it's trivial to simply change the methods of classes and even of individual objects at runtime, using only the Ruby language.
For classes: basically, the class definition of a Ruby class is also code that is executed, thus you can run code at "compile time" or "class load time", which can add methods, wrap methods, or whatever you want.
Reflection & Co is very easy and less verbose in Ruby, not to mention that you can do all the above mentioned tools.

Writing tools like (remote) proxies or anything like that is trivial, as you only need to implement the method_missing methods and use an Object instance. Any non-defined method called on this object will trigger the method_missing method, which can then ... do whatever it wants (forward it to the remote receipient, ...).
As I mentioned above, this is similar to the DynamicProxy class in Java, BUT without the problems that I also described above.

Not to mention, that this kind of thing can do things that will/can/do improve the maintenance and updating of systems without shutting them down. Hotswap can do things, but not change class definitions. In dynamic languages, this is possible at runtime; if you see that you can actually enumerate all live objects in the heap (not possible in Java at all), you can do this update at once, or using the method_missing tools for incremental update.

> particular class, but for some reason even though you
> know that when you write the class, you don't want to
> subclass it there and then, you want to wait till the
> last minute?

No, it means that you want to do the change at runtime, that you want to do and undo the change at runtime, that you want to do it to classes/objects that you don't have source control over, etc.
And again: if you don't like this, then you'll probably also don't like anything AOP-like or any bytecode-instrumentation at all. (Talking about that: you could actually do a JFluids/Netbeans-like profiler in Ruby/Smalltalk/... without having to resort to Hotswap/BytecodeInstrumentation... simply using the Ruby language).

> > Try this. Solve a basic XML emitter with Java.
> Ha! Bad example! Java pojos make superb XML
> emitters if you code the hierarchy properly.

I don't think that's what the poster (Bruce?) was referring to. Look at this tools written in Ruby
http://builder.rubyforge.org/
which makes it easier to emit XML without resorting to messing with Strings.

On your rant with JAXB: You were probably better off with your hand rolled solution, although it depends on the situation.

> > and reload. You never break stride.
> Eh. Find problem in running Java program. Alt tab
> to Wordpad. Fix code. Hit X (or Alt Q) in corner to
> kill Java program.

Weeeeell... that's the point: killing the Java app.
The "reload" that was referred to, didn't require a restart of the whole application.

> spilt, and the barn burned to the ground years ago -
> no point in calling out the fire brigade now.

So... (to stay in the metaphor) you prefer to huddle down in the charred remains of the house for the rest of your days without ever thinking of improving the situation?

rickcarson
Offline
Joined: 2004-03-04
Points: 0

> if
> > there is hardly any code written in those
> languages,
> > I don't see how they can be described as being
> > 'productive'.
>
> Read your sentence again and think about it. You
> already stated why those languages are deemed more
> productive (Hint: less code written...).

No, that was Bruce's definition. I've gone meta. I am stating that productivity = finished apps.

Now when I look at my machine at work (windows) and my machine at home (mac), these are the languages used to write the apps which I use:

C
Visual Basic
Java (I eat some of my own dogfood)
Objective-C

Where are the apps written in Ruby, Smalltalk and Perl? At least if I used Emacs I would be using Lisp - but that is like 1 lousy program out of thousands.

On the 'number of apps = productivity' scale the dynamic typed languages are like unto the fart of a mosquito versus a hurricane.

Another way of looking at it is that I'm saying that NO lines of (applications programming) code are being written in those languages.

I guess in your mind that makes them infinitely productive because there 0 lines of code and productivity = apps writeen / lines of code to write those apps.

I'm just pointing out that the numerator is zero too.

It is similar to the question of extra-terrestrial life, if we make certain (reasonable sounding) assumptions, then the logical conclusion is that ET should *already* have phoned home from here, ie we should have already encountered the aliens.

If dynamic languages are so gosh darned compelling and productive, why is noone using them? And the burden of proof then falls on the people asserting the superiority of dynamic typing.

From what I've seen the arguments go like this:
(a) most programmers are too stupid to understand dynamic programming (the 'Paul Graham' theory)
or
(b) ... there is no b ...*

Interestingly, as someone else pointed out, it is not Java that is under threat per se, but the scripting languages like PHP - Rails is not a threat to a Java/Swing developer for instance.

However - if AJAX really takes off, and Ruby becoems the language of choice for Web 2.0 - then it might start to gain some traction.

So to talk about Ruby, particularly Ruby on Rails and 'applications programming productivity' and thereby suggest that Ruby is an applications programming language is rather disingeneous.

In this case, P does not imply Q

* This has got to be a major source of embarrassment for the fans of dynamic languages. I'd love to see a decent explanation for this. :D

> BTW: where do you get the idea that there's hardly
> any code written in dynamic languages (see Perl, PHP,
> Python, Ruby, etc. for use in Web projects).

From a quick unscientific survey of my own experience with computers.

I've seen more programs written in Delphi (for crying out loud) than all the dynamic languages put together. They just aren't there, they're not even a blip on the radar.

> I hate to bring up Rails again, but just looking at
> the code Java solutions for what Rails does
> (Hibernate+Struts+Tapestry+Tools for creating the
> app)
> shows that.

You must not have read my post where I agreed with you that Struts is horrible. However Hibernate+Struts is not 'the one true Java way of doing webapps'. There are other choices.

I'll say it again, just because Struts is horrible, does not mean that Java is horrible.

What Rails does is not that hard to do in Java. There was a post on the Java.Net frontpage the other day where someone said half the solution: use metadata to slap a rowset into a JTable.

You can use metadata to generate (at compile time) the classes which go and fetch data from the database. And you can use dynamic class loading to load new ones on demand.

It will take more lines of code than the Ruby solution, and it will be more complicated, but then you get a nice front end 'for free'... I wonder if Ruby does that part too?

> (Take just one of the source of
> thementioned Java tools ... it's source will be
> larger than the whole Rails package).

Just take it a long way away from me please :D

> > So... if I understand you right you are saying
> that
> > in a dynamic language you can:
> > change this:
> SnippedCode
> > ... and you are also saying that cannot be done in
> > Java? Or are you merely asserting that it cannot be
>
> > done at runtime?

> It's not possible to do that at runtime in Java. That
> means adding the redirection, updating or removing
> it.

... You can reload classes at runtime...

> With Ruby (or Smalltalk or whatever), it's trivial to
> simply change the methods of classes and even of
> individual objects at runtime, using only the Ruby
> language.

Well, see this is the thing that gets me. You still need to write the code to do that. And you need to deploy the code to do that. And that means that you basically have a 'I hand you the code' phase.

Now, in Java, that phase includes a compile phase. But the point I'm trying to make is that if you know when you finish writing the code prior to performing that phase that you have some code to modify one of your classes... why not just go the whole hog and actually modify (or subclass) the class at that point?

So in that sense, the advantage of being a dynamic language is gone if you ever hand over a 'completed' app.

============

It seems that like AOP (with its logging example) 'dynamic' languages have only one advantage, that being that you can fiddle with things 'on the fly'.

This advantage ends as soon as development ends and you hit the 'I hand you the code' phase.**

And the usefulness of this advantage is proportional to the amount of time spent debugging. If the bug takes a couple of seconds to find, then the stop/compile/restart portions are significant. On the other hand, if it takes an hour or more to track down the bug, spending an extra 15 seconds on stop/compile/restart is trivial, and hardly worth trumpeting about (much like AOP and logging IMHO).

What sort of bugs take mere seconds to fix? Typos. Variable names spelt wrong.

... in fact, the sort of stuff that the compiler would have caught for you if you weren't using a dynamic language ...

Sounds like the main advantage of dynamic languages is only useful because of the main disadvantage of those languages.

I chalk this one up to 'sure its an own goal, but did you see how fast I kicked it?'

============

** This is not the end of the story - but only where the developer is of a level of sophistication and familiarity with the product to be able to change it on the fly. It would be nice to 'unbreak' Eclipse for instance when it falls over and dies whilst simultaneously corrupting its configuration information. But where would we find such sophisticated users? Perhaps the only ones would be developers who are also programmers?***

*** Maybe, this points the way to the missing (b) - that dynamic languages are not especially productive for applications, but rather their specific advantages come to the fore when talking about developer tools? After all, the Lisp guys are always bragging about the good old days on Lisp machines and how wonderful the toolset was...

But then why can't they make the jump from tools to apps?

Is it critical mass? Is it that there are so many of these boutique languages to choose from?

Why? Why have dynamic languages failed so massively in the marketplace?

> > particular class, but for some reason even though
> you
> > know that when you write the class, you don't want
> to
> > subclass it there and then, you want to wait till
> the
> > last minute?
>
> No, it means that you want to do the change at
> runtime, that you want to do and undo the change at
> runtime, that you want to do it to classes/objects
> that you don't have source control over, etc.

But how often does this happen?

And aren't we talking about 'the next big thing' surely then we are talking about the choice of languages - and if its a language I chose, surely we are talking about code that I wrote, and that means I do indeed have the source code?

> And again: if you don't like this, then you'll
> probably also don't like anything AOP-like or any
> bytecode-instrumentation at all.

Guilty as charged. It is nothing a proper design in the first place would not have fixed.

> (Talking about that:
> you could actually do a JFluids/Netbeans-like
> profiler in Ruby/Smalltalk/... without having to
> resort to Hotswap/BytecodeInstrumentation... simply
> using the Ruby language).

Tools. Not apps.

> > > Try this. Solve a basic XML emitter with Java.
> > Ha! Bad example! Java pojos make superb XML
> > emitters if you code the hierarchy properly.
>
> I don't think that's what the poster (Bruce?) was
> referring to. Look at this tools written in Ruby
> http://builder.rubyforge.org/
> which makes it easier to emit XML without resorting
> to messing with Strings.

But messing with strings is dead easy. Pretty much all of programming is just mucking around with some numbers and some strings.

> > > and reload. You never break stride.
> > Eh. Find problem in running Java program. Alt
> tab
> > to Wordpad. Fix code. Hit X (or Alt Q) in corner
> to
> > kill Java program.
>
> Weeeeell... that's the point: killing the Java app.
> The "reload" that was referred to, didn't require a
> restart of the whole application.

Only important when time to find and fix the bug is very very short.

> > spilt, and the barn burned to the ground years ago
> -
> > no point in calling out the fire brigade now.
>
> So... (to stay in the metaphor) you prefer to huddle
> down in the charred remains of the house for the rest
> of your days without ever thinking of improving the
> situation?

No, the rest of us built new barns, with better fire safety controls. The cost of a couple of extra sprinklers and a fire exit is really not that bad.

We moved on, we built a bridge and got over it.

Anonymous

sadasd

invalidname
Offline
Joined: 2003-06-09
Points: 0

Near the end of chapter 4, Tate wonders: "You might argue that we need to fix Java, not scrap it. That would be easy if you could pinpoint the problems. If you thought the problems were in the language itself, you could just do some major surgery and offer a new version of Java. That's easier said than done. Sun has been very careful to preserve backward compatibility at all costs. If you look at the lack of commercial acceptance for Visual Basic .NET, it's easier to respect Sun's point of view. Microsoft made some radical changes to the language and libraries , and they weren't well received. Regardless of whether it's a good idea, Sun will continue to be conservative to protect customers.

Still, even if you look at relatively aggressive changes, most experts that I interviewed tend to think Sun is even now moving in the wrong direction. Instead of making Java more nimble and dynamic at the foundation, the changes, for the most part, amount to additional type safety—syntactic sugar hacks built into the syntax rather than the JVM that often lead to inconsistent behavior."

Rob Abbe

Tate my call it being conserative, I call it being responsible. As someone with an unusually large VB6 codebase, one major appeal of Java has been Sun's commitment to backward compatibility while still advancing the standard. It's difficult to migrate VB6 code to VB.Net and arguably not worth the trouble.

rickcarson
Offline
Joined: 2004-03-04
Points: 0

Lets break that down by classification:

Problems with the language:
* "Compromises", like primitives, which were introduced to lure the C++ crowd
* The costs of strong, static typing

Problems with the language tools:
* A long compile/deploy cycle

Problems based on [b]choices that people make[/b] that are unrelated to the language at all.
* Frameworks that make life easier for experienced developers, at the expense of approachability for new developers
* Over-reliance on XML, caused by Java's inability to represent structured data
* Over-reliance on tools to mitigate complexity

The compile/debug cycle complaint is just wrong. Javac and Jar are actually really really fast. The problem here is overly complex build and deploys using some automated tool - and we don't have to poke around much to see that the problem is actually Ant, not Java.

Using Ant is a choice the developer makes, so that one really belongs in the 'shooting yourself in the foot' or 'cultural' problem category.

Lets look at the first two problems:
Primitives (and operator overloading for Strings) are, from a language purists point of view, a bad thing. However an alternative way of looking at them is that they are an optimisation of the things that programmers do most. Procedural programming, at a very abstract level is nothing but operations on 1s and 0s - if we get a bit more concrete it is operations on bytes. If we come down another layer of abstration it is simply maths and strings.

So is this language level optimisation a good thing or not? Primitives for numbers is a performance optimisation, whereas using + for String concatenation is a 'conceptual' optimisation. But of course we have all heard the phrase: "premature optimisation is the root of all evil". So are these premature optimisations? I would argue that they are clearly not, since they are the things which happen *all the time*. The warning against premature optimisation is not to waste time optimising something that is rarely used and unimportant.

For strong static typing, I think that is a matter of taste. But... perhaps in the interest of introducing some objectivity into the discussion we could perhaps look at the functional programming contests, which is where languages with strong typing are pitted against those without, on the same task. And the point I would make is that so far as I am aware, it is the languages with strong typing that always take home the honours.

In terms of productivity - strong typing is king.

Strong typing has (in those competitions), convincingly laid the smack down. This is not a 'ring out', this is not a victory because someone interferred by throwing a chair into the ring at the right time, this is not won by dirty tactics. It is a series of clear and clean victories where strong typing pins the opposition in the middle of the ring and gets a good count 1, 2, 3.

Or to use a baseball analogy, this is a clean sweep 4-0 in the world series. Strong typing wins hands down, it isn't even close. And the fans all complain about how boring it was. :D

As for the choices that people make, you cannot legislate against stupidity.

But, in most cases, did the people involved deliberately set out to make the worst possible decision? No, probably not. So what is the cause of the problem? Is it not that we have all these pundits and experts (self proclaimed usually), who tout the latest 'silver bullet' solution to all that ails us - whether that is Struts, Agile programming, XML or whatever. (See also: todays Dilbert)

People like Bruce run around proclaiming the latest and greatest thing. And sometimes they are even correct (ie that technology X provides a benefit in a very narrow situation). But more often what happens is that we at the coal face get lumped with the grab bag of latest and greatest apis, many of which are not appropriate to the task, and managing them all becomes a problem, so you get apis to manage the apis... ad nauseam.

When the revolution comes, the book authors and gurus should be right behind the architects in the line of people that need shooting.

murphee
Offline
Joined: 2003-06-10
Points: 0

> The compile/debug cycle complaint is just wrong.
> Javac and Jar are actually really really fast.

That's not the point; Eclipse has basically removed the compile cycle by pushing it in the background (I haven't called javac & friends for years).
A problem is that Hotswap (code replacement) is very limited and will stop working even for trivial changes (just edit an anonymous class to access some local var... it'll need changes in the containing class to add accessors, thus changing class signature).

> using some automated tool - and we don't have to poke
> around much to see that the problem is actually Ant,
> not Java.

Well... there's a great build tool for Ruby called rake... and it doesn't actually need XML or anything: it's a DSL in Ruby. See: http://www.martinfowler.com/articles/rake.html

Combine that with Rails tools like Switchtower (which facilitates updating of a Rails app, including rollback in the case of failures).

> thing. However an alternative way of looking at them
> is that they are an optimisation of the things that
> programmers do most.

Yes, but they're not necessary anymore. Primitives that fit inside CPU registers can be handled with Tagged Types (Immediate Types, or however they are called) which have basically the same performance as primitives, and won't have to be heap allocated. All of this can be done with modern VMs and dynamic compilers (Smalltalk has always used immediate types).

The problem with Java: if you want to have proper performance, you use primitives... but you can't keep that up if you want to handle them with container classes. So Sun brought up Autoboxing/AutoUnboxing... which added further little complexity to the language (subtle ones... like the fact that Autoboxing some values (-128 -- +127) causes no allocation, whereas the rest *does* cause heap allocation).

Now: if all types had been reference types, optimizations could have been added in transparently, ie. speeding up code; with the rift between primitives and wrappers, this isn't possible.
And let's not start talking about the mess that is BigInteger & Co; the issues with those would be non existant in a primitive-less world. We're constantly bumping into size limits in IT... and it's the same with bit widhts of types; thing is: it wouldn't be necessary.

Don't get me wrong: I know why primitives happened (first VMs with the very simple interpreter plus simple GC), but that doesn't mean that we should have to live with that nonsense longer than necessary.

> For strong static typing, I think that is a matter of
> taste. But... perhaps in the interest of introducing
|...|
> In terms of productivity - strong typing is king.
> Strong typing has (in those competitions),
> convincingly laid the smack down.
[...]
>This is not a 'ring out', this is not a victory because > someone interferred by throwing a chair into the ring

Sorry... but do you actually have any specific arguments for static typing? All your paragraphs just contained empty victory metaphors and chest beating... but no content.

> As for the choices that people make, you cannot
> legislate against stupidity.

Indeed.......

> When the revolution comes, the book authors and gurus
> should be right behind the architects in the line of
> people that need shooting.

It's funny to read statements like this... it shows that the Java world is *really* scared shitless over competition like Ruby, Python, and other dynamic languages....

Hey, I'm a Java developer... but how about this: let's use the dynamic languages to improve the Java platform... move the crufty old Java language to write the nasty stuff... and then write the interesting bits of the software with dynamically type languages on top.
How about this: instead of slagging of static typeing and blatherin about "static typing is king"... how about doing something productive? Like: thinking how the *benefits* of static typing could be added to dynamic languages? (How about a extension library for Ruby that allows you to write protocols/interfaces, or enforce certain class signatures).

olsonje
Offline
Joined: 2005-08-10
Points: 0

> It's funny to read statements like this... it shows
> that the Java world is *really* scared shitless over
> competition like Ruby, Python, and other dynamic
> languages....

Personally I don't think this is true, history has shown people are afraid of change, in some fashion, regardless of what that change is. Just because someone doesn't agree with anothers assumption doesn't mean that they are anymore correct or incorrect then the other view(s).

Personally in my day to day life, I use Python, C, C++, Java, and occasionally others. I have no fear of learning a new langauge or wanting to try something completely random, yet my day job revolves mostly around java related things. Have I seen people in the java world be afraid of change? Yep. But the same can be said for those who live and breath C or C++ or any other language.

Tom

I do find it interesting that the closest we have in Java to an object literal is XML. Especially interesting in that XML and Java objects are so different from each other (as evidenced by the diversity of mapping tools available). Maybe Java should pick up native support for JSON or something similar but more Java-like. (Rather than the horror-show XML literals they've mused about for Dolphin.)

dleuck
Offline
Joined: 2005-04-22
Points: 0

Agreed. I wrote SDL (http://sdl.ikayzo.org) to allow easy creation of XML like datastructures, but it would be nice to have something in the language. At least with 1.5's varargs you can statically import a list method to construct lists:

List ints = list(1,2,3,4,5);

Daniel Leuck
http://www.ikayzo.com

Message was edited by: dleuck

jasonrberry
Offline
Joined: 2004-04-25
Points: 0

I am tired of this. How many books does he need to sell for us to stop hearing about it.

I am going to run to the train station because I don't want to over-rely on my complex car.