Skip to main content

Chapter 14: The Dream Language

7 replies [Last post]
jonathansimon
Offline
Joined: 2003-06-07
Points: 0

Graham lays out his criteria for a dream language in this chapter. He has some interesting things to say, but a couple of points made me reflect on my experiences with Java.

First is hackability -- Java is only mildly hackable. Swing components, while extremely flexible, have a lot of private, and package protected variables, and code is split sometimes arbitrarily between the UI and the View classes. I usually end up copying the src of some class or another and hacking (in the bad context) my own copy of it. I don't really consider that a hackable (in the good context) language.

I code Swing most of the time, but this holds for the rest of the language. For example, I hear a lot of C++ programmers complain that they don't have the same low level access to pointers and such in Java. It would be cool if the language itself was build in layers so that if you were one of the people who likes to dig into things like classloaders and JavaCC, you can, otherwise you can just run with the standard stuff.

We can chat about all of the other attributes as well, but I just want to add one thought from earlier in the discussion regarding multiple languages. The topics in this chapter are all sort of overarching, global heuristics -- I agree with the earlier discussion and don't believe there is a single, best language. On the other hand, I could see an optimal unified platform -- a group of languages that all work together, each with a specific purpose and intent.

-jonathan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
javakiddy
Offline
Joined: 2004-01-23
Points: 0

There is a downside to hackability. The more hackable a system is, the harder it is to upgrade it while keeping it backwards compatible. Access modifiers aren't intended to annoy the hell out of programmers (although they do). They define the boundary between the API developer and the API user. By restricting access to something the developer is saying "this is implementation detail, and my responsibility - keep off".

If you want to know the pitfalls of hackability, take a look at the history of the Amiga vs. the PC when it came to graphics. The Amiga had a fairly nice (for its time) OS with lots of nice graphics features - it also had very powerful (again, for its time) A/V hardware. Many developers, particularly games developers, bypassed the OS and bashed the hardware directly. "I don't want to be confined by someone else's code", they claimed. When it came to upgrade the Amiga hardware this created enormous problems, and resulted in a substantial effort (some say the majority) being wasted not on developing new features but on trying to keep the new hardware backwards compatible. The PC, on the other hand, never had the luxury of a single standardised set of A/V hardware - just competing hardware from different manufacturers conforming to a few standards. As such the idea of a software abstraction layer (ie. DirectX) became the norm. The side effect being it was much easier to upgrade hardware on a PC. The downside is you loose your 'hackability'.

So there in lies the dilemma - the more control you get over a system the harder it is to upgrade. Either you (as the user) end up porting your code from version to version each time, or they (as the developers) end up doing backflips to try to keep within an ever-tightening straight-jacket of backwards compatibility.

And with regard to your points on 'a dream language'. There never will be a single be-all-and-end-all language, nor should there ever be. Languages are tools, and the more generic/bloated a tool gets, the less useful. (Jack of all trades, master of none.)

The idea of a set of languages which can cover all eventualities is appealing, if it wasn't for the fact that the environment in which they are being used is ever-changing and evolving. The tools you choose today may not up to the job tomorrow. Trying to define such a set of languages would therefore be like shooting at a moving target.

jonathansimon
Offline
Joined: 2003-06-07
Points: 0

Dig what you're saying about hackability -- but I think its important to make distinctions between technology decisions and social ones.

This is a social decision. If there is a way to get it across to people that hacking in the implementation layer is unsafe, and will not be supported between releases, then all is well. It would encourage people only to hack when necessary.

But there is also the question of designing for extension. If packages were really optimized for extension, some of these problems go away. Not all, but some. But as Josh Bloch points out -- really designing for extension is hard.

Now, whether or not people could handle this is an entirely separate discussion...

javakiddy
Offline
Joined: 2004-01-23
Points: 0

> This is a social decision. If there is a way to get
> it across to people that hacking in the
> implementation layer is unsafe, and will not be
> supported between releases, then all is well. It
> would encourage people only to hack when necessary.

What I forgot to stress in my original posting was that the Amiga people did just that: in the developers documentation they made a big deal about not bashing the hardware. Some programmers did it anyway - which encouraged others to do the same (because after all you want your software to be as cool as the next guy's, right?) Before long it was commonplace.

Some Amiga fanatic can correct me if I'm wrong, but I think when they upgraded the hardware (to 'AGA'?) they actually went as far as to withhold the hardware programming specs, unlike with the originals.

Its very hard to say "using X, Y and Z you can do some really great stuff... but please don't use them". That is definitely a social issue. As is the bad reputation the Java brand will get with the public at large when 'hacked' applications have compatibility problems.

ndario
Offline
Joined: 2003-07-14
Points: 0

exactly what i had to do to change the way user moves through jtable from vertical to horizontal. i needed to add/change few lines and it ended with copying bunch of code from BasicTableUI to my custom class, renaming it and adding my code.

definitely not the way swing should work.

billksun
Offline
Joined: 2004-06-30
Points: 0

"It would be cool if the language itself was build in layers..."

Dead on!!! That's what I was thinking! It's nice that Java has all these encapsulated codes and that it's easy to use. But it would be even better if Java allows access to the fine grains of Java. I think layering is the best answer to this. High-level or low-level, your choice. And that's a powerful choice.

matt_meyer
Offline
Joined: 2004-04-20
Points: 0

That is the coolest thing about Java as a platform vs Java as a language. Java as a language(please don't hurt me) is a little clunky and redundant, but Java as a language has been easy to sell to enterprises and has become quite ubiquitous.
Now it's time for Java as a platform. Groovy is a pretty cool scripting language. Jython is already very active and established. Heck, go all the way down and program on the bytecode if you like.
If you can live with the abstraction of the VM the Java platform is pretty awesome. It's hackable, layered, relatively portable, and it has a very large community of COOL opensource hackers providing limitless innovative solutions.
Graham is a brilliant individual, but he should stop judging Java by it’s cover.

johnm
Offline
Joined: 2003-06-06
Points: 0

> On the other hand, I could see an optimal
> unified platform -- a group of languages that all
> work together, each with a specific purpose and
> intent.

Have you checked out the Parrot VM work that is being spearheaded by the Perl folks? It's at: http://www.parrotcode.org/