Skip to main content

Chapter 5: Rules of the Game

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

Chapter 5's intro says: "If you think about it, you instinctively know that some programming languages will definitely not be the next big one. Lisp is productive, but the average Joe can't understand it. Perl is rich and powerful, but it's subtly inconsistent, and is prone to produce unmaintainable code. With a little vision and experience, you can apply a similar kind of reasoning to understand the types of languages that might follow Java. I suggest that we define success loosely: the language should be recognized widely and adopted broadly among developers who now use Java. This chapter, then, suggests the characteristics that the language should have to have broad commercial success."

Briefly put, the traits evaluated by "Beyond Java" in potential successors to Java are:

* Portability
* Internet Focus
* Interoperability
* Database Integration
* Transactions and Security
* Open Source
* Economics [i.e., there needs to be a compelling economic reason to try something new]
* Approachability
* The Killer App
* Dynamic Typing
* Code Blocks and Continuations
* Rapid Feedback Loop
* User Interface Focus
* Dynamic Class Model
* Sound Foundations

What do you think of this list? Are the right things on it?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rickcarson
Offline
Joined: 2004-03-04
Points: 0

> Sounds like a lot of work compared to OCaml where you
> have do nothing to achieve the same goal.

Rank Language Projects
[b]39 OCaml (Objective Caml) 54[/b]

> > Oh wait. Generics don't play nicely with
> primitives.
> > I *still* have to write a wrapper class (either a
> > a subclass that isA ArrayList, or if I want to
> > strictly enforce the putters and poppers, wrap it
> up
> > in something that hasA ArrayList).
>
> Again, not a problem in OCaml, where you don't have
> to do anything extra for generics and primitive
> types.

You know, when I looked at OCaml, there was something that made me spit my lunch.

And that was that you have separate operators for arithmetic depending on whether the numbers are whole numbers or decimals.

So maybe you don't have strongly typed variables, but you have strongly typed operators instead (and that is how the language infers the types).

I don't really think that they've gained anything there.

> The principle I see here is that language matters
> tremendously when you want additional features.
> Java's early design decisions make it difficult to
> o retrofit new features like generics or
> aspect-oriented programming onto the language.

At the time I felt that Java was reasonably complete. Having looked at Python I now think that the language does indeed have some cruft, but it is things like semi-colons and curly braces, not the absence of features of dubious worth (whether generics (for Ghu's sake - just use Object - how much more generic can you get than that :D ), or closures, or anti-hole pantyhose).

> Such features can't be made by within the language
> due to limitations, so you have to modify the
> compiler to add them, and even then they're clunky
> and difficult to use. In a more dynamic language,
> you can add such features on your own and they're
> simple and easy to use.

So what is the problem with Groovy? It has closures and all that other guff.

Message was edited by: rickcarson

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

> > Sounds like a lot of work compared to OCaml where
> you
> > have do nothing to achieve the same goal.
>
> Rank Language Projects
> [b]39 OCaml (Objective Caml) 54[/b]

What's your point? I haven't claimed that OCaml is widely used, but it's a good example of how type inferencing is used. However, C# is widely used and Microsoft has announced type inferencing as a feature of C# 3.0.

> You know, when I looked at OCaml, there was something
> that made me spit my lunch.
>
> And that was that you have separate operators for
> arithmetic depending on whether the numbers are whole
> numbers or decimals.
>
> So maybe you don't have strongly typed variables, but
> you have strongly typed operators instead (and that
> is how the language infers the types).

Variables [b]are[/b] strongly typed in OCaml, but operator overloading is not supported, even for primitive types. It seems odd at first, but it's a superficial oddness and I grew to like it after a while. If you don't like it, try one of the other type inferencing languages that does support operator overloading, like OCaml's older cousin, SML. Or wait for C# 3.0, as I don't think Microsoft is going to eliminate operator overloading when they add type inferencing.

> So what is the problem with Groovy? It has closures
> and all that other guff.

It's been a while since I looked at Groovy, but I don't recall it supporting anything that older dynamic languages didn't already have. Given your focus on project numbers, I think you'd support one of the older dynamic languages, in which far more development is being done, over Groovy.

robilad
Offline
Joined: 2004-05-05
Points: 0

> > So what is the problem with Groovy? It has
> closures
> > and all that other guff.
>
> It's been a while since I looked at Groovy, but I
> don't recall it supporting anything that older
> dynamic languages didn't already have. Given your
> focus on project numbers, I think you'd support one
> of the older dynamic languages, in which far more
> development is being done, over Groovy.

Yes, but Groovy runs on a JVM! ;)

Of course, that's a pretty pointless argument for a programming language. It is a useful argument in marketing to an audience of Java developers, though, which is why you'll see JRuby mentioned a lot to the would-be converts to Ruby. ;)

cheers,
dalibor topic

tobega
Offline
Joined: 2004-06-20
Points: 0

> > In that light, I would say that "Explicitness"
> would
> > be a very desirable property for this type of
> > programming, to increase maintainability and avoid
> > the need of having a subtle understanding of the
> > application.
>
> As always, it depends on what you want to do. A
> number of posters have expressed disapointment with
> generics, and the complexity of generics in Java and
> templates in C++ arises from the explicit typing
> systems of those languages. This complexity is not
> inherent in generics, though, as it's simple to write
> and read generic code in a type inferencing language
> like OCaml or Haskell, where the compiler determines
> types using the Hindley-Milner algorithm without
> requiring user type declarations (of course, the
> programmer can declare types when explictness is
> desirable.)

I haven't tried out the generics stuff in Java (so far I think the 1.5 javadocs just look messy), but in theory I support the use of generics.

I recently had to do battle with an interface that returns an Iterator. So far so good, but what the heck can I get out of it???? It wasn't documented, so I had to spend a while finding that out first...

To me, the main thing is how easy it is for someone else a few years after the fact to understand the code quickly. How easily is that done with type inferencing? I guess a good IDE can do it, but you can't always count on one being available at that time.

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

Alas, these sorts of discussion all too quickly devolve into this war over the (proposed) definition of a single, "perfect" language. That's just a fantasy. Even general purpose programming languages exist in a context and are created/biased to better match specific purposes.

In terms of languages, check out: DSLs ( http://weblogs.java.net/blog/johnm/archive/2005/11/dsls_feelin_gro.html ), ITLS! ( http://www.artima.com/weblogs/viewpost.jsp?thread=81574 ), and Conversational Programming Languages ( http://www.artima.com/weblogs/viewpost.jsp?thread=106031 ).

In terms of productivity and what not, check out: Why Software Sucks ( http://www.artima.com/forums/threaded.jsp?forum=106&thread=128462 ), the Anatomy of Insanity ( http://www.artima.com/forums/threaded.jsp?forum=106&thread=69024 ), and the java.net bookclub forum on The Mythical Man-Month ( http://today.java.net/cs/user/forum/cs_disc/1158 ).

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

> In that light, I would say that "Explicitness" would
> be a very desirable property for this type of
> programming, to increase maintainability and avoid
> the need of having a subtle understanding of the
> application.

As always, it depends on what you want to do. A number of posters have expressed disapointment with generics, and the complexity of generics in Java and templates in C++ arises from the explicit typing systems of those languages. This complexity is not inherent in generics, though, as it's simple to write and read generic code in a type inferencing language like OCaml or Haskell, where the compiler determines types using the Hindley-Milner algorithm without requiring user type declarations (of course, the programmer can declare types when explictness is desirable.)

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

> As always, it depends on what you want to do. A
> number of posters have expressed disapointment with
> generics, and the complexity of generics in Java and
> templates in C++ arises from the explicit typing
> systems of those languages. This complexity is not
> inherent in generics, though, as it's simple to write
> and read generic code in a type inferencing language
> like OCaml or Haskell, where the compiler determines
> types using the Hindley-Milner algorithm without
> requiring user type declarations (of course, the
> programmer can declare types when explictness is
> desirable.)

Just one of the many real problem with generics is that it does not solve anything truly compelling. Oh wow, I want an ArrayList that only takes ints - okay, I'll just subclass it and provide putter and popper methods for whichever of the methods I actually want to use.

Not that you even need to do that if you use a little coding discipline, and make sure you only put the proper types in the list. It's not that hard. Really.

Oh wait. Generics don't play nicely with primitives. I *still* have to write a wrapper class (either a subclass that isA ArrayList, or if I want to strictly enforce the putters and poppers, wrap it up in something that hasA ArrayList).

But the principle is the same. It is like Aspects - their best example (logging) is not particularly compelling, since it is trivial to do yourself.

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

> Just one of the many real problem with generics is
> that it does not solve anything truly compelling. Oh
> wow, I want an ArrayList that only takes ints - okay,
> I'll just subclass it and provide putter and popper
> methods for whichever of the methods I actually want
> to use.

Sounds like a lot of work compared to OCaml where you have do nothing to achieve the same goal.

> Not that you even need to do that if you use a little
> coding discipline, and make sure you only put the
> proper types in the list. It's not that hard.
> Really.

True, and this is essentially the argument that dynamic typing proponents advance against static typing. It's not hard to do these things on your own.

> Oh wait. Generics don't play nicely with primitives.
> I *still* have to write a wrapper class (either a
> a subclass that isA ArrayList, or if I want to
> strictly enforce the putters and poppers, wrap it up
> in something that hasA ArrayList).

Again, not a problem in OCaml, where you don't have to do anything extra for generics and primitive types.

> But the principle is the same. It is like Aspects -
> their best example (logging) is not particularly
> compelling, since it is trivial to do yourself.

The principle I see here is that language matters tremendously when you want additional features. Java's early design decisions make it difficult to retrofit new features like generics or aspect-oriented programming onto the language.

Such features can't be made by within the language due to limitations, so you have to modify the compiler to add them, and even then they're clunky and difficult to use. In a more dynamic language, you can add such features on your own and they're simple and easy to use.

tackline
Offline
Joined: 2003-06-19
Points: 0

> The principle I see here is that language matters
> tremendously when you want additional features.
> Java's early design decisions make it difficult to
> o retrofit new features like generics or
> aspect-oriented programming onto the language.

Which particular decisions do you think particularly made it difficult for generics? My understanding is that generics were high on the wishlist from day zero. It seems unlikely that the smart people involved would deliberately lay traps for themselves.

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

> > The principle I see here is that language matters
> > tremendously when you want additional features.
> > Java's early design decisions make it difficult to
> > o retrofit new features like generics or
> > aspect-oriented programming onto the language.
>
> Which particular decisions do you think particularly
> made it difficult for generics? My understanding is
> that generics were high on the wishlist from day
> zero. It seems unlikely that the smart people
> involved would deliberately lay traps for themselves.

I suspect that explicit typing is the problem with generics, as generics are a pain in every explicitly typed language I've used with them, but not really an issue in type inferencing languages.

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

> need semi-colons, and VB shows us that you don't need
> case sensitive names. The VB IDE's ability to recase

If you fix your locale to Locale.US case insensitivity works well and seems the friendly approach. Then you get a client from Turkey and discover that 'I' is no longer the uppercase of 'i'. The case mapping done by the Windows NTFS file system is unique, it doesn't match any locale (although Americans are unlikely to notice any of its surprises).

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

> > need semi-colons, and VB shows us that you don't
> need
> > case sensitive names. The VB IDE's ability to
> recase
>
> If you fix your locale to Locale.US case
> insensitivity works well and seems the friendly
> approach. Then you get a client from Turkey and
> discover that 'I' is no longer the uppercase of 'i'.
> The case mapping done by the Windows NTFS file system
> is unique, it doesn't match any locale (although
> Americans are unlikely to notice any of its
> surprises).

Remember, we're not talking about Locale stuff in general, but specificalyl about Variable Names In Code. What that has to do with the NT File System is left as an exercise for the reader.

In the case of (sic) Turkey - perhaps it would be relevant to know what VB does if you've got a Turkish version of VB - and how the locals feel about it's case handling.

We can just assume that it does the wrong thing, but that is a bit arrogant on our part, wouldn't it be better to know what the Turkish programmers actually want in that case?

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

Interestingly enough, I think that one of the biggest benefits to either Python or Ruby is much better readability, and applications with a cleaner, more object-oriented structure.

I mention Perl and PHP as examples of a combination of language/community that get short term productivity right at the expense of long-term productivity.

Also, I read a number of studies that compared lines of code to productivity. Most pointed to a pretty clear correlation. Less was better.

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

The debate about productivity is interesting.

Some people measure productivity as 'number of key strokes'.

Personally, I find that the number one thing that gets me to the 'finish line' first (on non trivial projects) is not to sit down at thye keyboard and start bashing out code - but to get a pen and paper (or whiteboard) and start working out the high level design. This saves an enormous amount of 'refactoring' later on. Also - an important point (since I can hear the wailing and gnashing of the XP fans already), the design is not set in stone but is flexible - it is flexible in a way that is not possible *unless* you have the big picture. When requirements change you can pick the best place in the design to make the change, rather than just bolting it on as a special case and hoping for the best.

Now - in the long run, where I define long run as any project that will be around for two months or more (anything less than that and you could just do a sprint for the finish line and darn the torpedoes... since you can just rewrite it from scratch later anyway), the most important thing for productivity is not number of keystrokes or lines of code - but *readability*.

Readability is crucial, it trumps all other considerations when it comes to productivity. For the people who write terse 'self documenting' code (Res ipsa loquitur, sed quid in infernos dicit?), so long as they can read their own code years later, then fine.

Otherwise, or especially if you work on a project with more than one person, then readability is crucial. Much more time will be lost pondering the finer points of other peoples use of syntax and debugging obscure code than will ever be saved by a few keystrokes.*

So in this context, where we are talking about 'the next big thing' after Java, I think it is important for the language to be productive, and the largest component of that will be clarity and readability.

*Now on this topic, I am aware that there are studies which show Lisp programmers writing some code in half the size of C style languages, and having fewer bugs etc. And we should not ignore that perhaps some problems can be expressed more clearly *and* more succinctly in certain languages. All Turing complete languages are equivalent of course, but some are more suitable than others for various tasks (Java for instance is much better for applications which use the network than C or C++, but those languages might be better choices for writing the networking layer which Java sits on top of) As a counter-example to prove the point - there is no program whatsoever that is easily expressed in BrainFark for instance.

So perhaps we can all agree that the next big language will allow us to do those things we consider important (though everyone seems to have a different list for that), such as relational database persistence, transactions over the network etc, both tersely, and clearly. In other words, it will be a better fit for those things we do all the time right now and that we struggle with right now.

On the other hand, a lot of the 'problems' that the various current Java frameworks 'solve' are things that are simple to do, but repetitive.

When I wrote earlier about the forces of complexity vs the forces of simplicity, what I am not sure is clear is what I think the motivation is for the people making simple things more complex. In most cases, I think it is to avoid repetition or 'the boring bits'. For instance - reading and writing to a database is actually fairly easy in Java. After doing it for a couple of months your average programmer should be able to just 'bang out' CRUD (create, read, update, delete) code without hardly needing to think about it. But it gets 'boring' pretty quickly....

tobega
Offline
Joined: 2004-06-20
Points: 0

rickcarson,

I am with you all the way, really like your thinking.

> Personally, I find that the number one thing that
> gets me to the 'finish line' first (on non trivial
> projects) is not to sit down at thye keyboard and
> start bashing out code - but to get a pen and paper
> (or whiteboard) and start working out the high level
> design. This saves an enormous amount of
> 'refactoring' later on. Also - an important point
> (since I can hear the wailing and gnashing of the XP
> fans already), the design is not set in stone but is
> flexible - it is flexible in a way that is not
> possible *unless* you have the big picture. When
> requirements change you can pick the best place in
> the design to make the change, rather than just
> bolting it on as a special case and hoping for the
> best.

Indeed, and just for the record, that is not at all contrary to XP or any other agile "method", which I think all recommend short informal design sessions on every task. The mismatch would come if you spent weeks or months designing before testing the design with code, or if the design was set in stone.

>
> Now - in the long run, where I define long run as any
> project that will be around for two months or more
> (anything less than that and you could just do a
> sprint for the finish line and darn the torpedoes...
> since you can just rewrite it from scratch later
> anyway), the most important thing for productivity is
> not number of keystrokes or lines of code - but
> *readability*.

Amen. Easily provable, too. Maintenance costs are about 60% of total application costs, and almost all that is code-related (understanding the code). Of the 40% cost for initial implementation, only about 30% is code-related (the rest is requirements gathering, design, testing and just general heat-production getting everything organized). So readability will benefit you for at least 80% of code-related activities, actually even more because you will need to go back and read code even during initial development.

[snip]
> On the other hand, a lot of the 'problems' that the
> various current Java frameworks 'solve' are things
> that are simple to do, but repetitive.
>
> When I wrote earlier about the forces of complexity
> vs the forces of simplicity, what I am not sure is
> clear is what I think the motivation is for the
> people making simple things more complex. In most
> cases, I think it is to avoid repetition or 'the
> boring bits'. For instance - reading and writing to
> a database is actually fairly easy in Java. After
> doing it for a couple of months your average
> programmer should be able to just 'bang out' CRUD
> (create, read, update, delete) code without hardly
> needing to think about it. But it gets 'boring'
> pretty quickly....

I think the intentions are usually "good", in a misguided belief that it will be simpler to learn the framework than the underlying concepts, and, why not, less of the boring stuff to do. But using the same framework stuff over and over again is also boring. You can never get away from the fact that most programming is just boring data-shuffling. And learning a framework is almost never simple...

While this kind of "complexity hiding framework" usually does give a small benefit, so far, every experience I have had with this kind of "obscurity" has come back to bite us in the end.

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

> I think the intentions are usually "good", in a
> misguided belief that it will be simpler to learn the
> framework than the underlying concepts, and, why not,
> less of the boring stuff to do. But using the same
> framework stuff over and over again is also boring.
> You can never get away from the fact that most
> programming is just boring data-shuffling. And
> learning a framework is almost never simple...

Very few people deliberately set out to be evil, or write evil code. You are right in that the framework to save us from the boring bits can then itself become boring.

> While this kind of "complexity hiding framework"
> usually does give a small benefit, so far, every
> experience I have had with this kind of "obscurity"
> has come back to bite us in the end.

There are some really good frameworks out there.
Consider Applets and what they do - trying to 'roll your own' would be enormously difficult, and yet they are relatively simple to use.

(Contrast with CRUD - which is relatively easy to roll your own, and typically the frameworks are harder to fiddle with than rolling your own - but probably writing your own CRUD framework is really interesting)

Consider Sockets. I don't know if you ever had to use C sockets, but let me tell you with Java not having to worry about 'endianness' makes life a lot easier.

Consider RMI. It takes Java sockets, which are already dead easy, and makes them even easier!

(Contrast with CORBA - which is horrible)

Consider Servlets. They don't particularly hide much in the way of complexity (eg you still have to understand the difference between stateful and stateless programming), but they do save you an awful lot of work if you had to 'roll your own' and they allow you to boil down the essence of a dynamic web app to just slapping strings together - and it doesn't get much more basic than that.

NB this is one of the things which most 'scripting' languages focus on - string (and regex) manipulation. Indeed it would be surprising if a well done scripting cgi implementation didn't make it dead easy to do a dynamic web site.

Still, when choosing between 'dead easy' and 'on death's doorstep easy' (Java poso (plain old servlet objects)), there's not much in it from the programmers point of view, so considerations like performance and scalability are likely to be deciding factors.

tobega
Offline
Joined: 2004-06-20
Points: 0

> Consider Sockets. I don't know if you ever had to
> use C sockets, but let me tell you with Java not
> having to worry about 'endianness' makes life a lot
> easier.

And all your other examples, too.

I suppose the difficulty lies in finding the distinction between what is really "higher level" thinking and what is "obscurity".

Your examples are all great examples of "higher level", it is still recognizable what you are doing and as far as I get it, they don't really restrict you in any way, don't obscure things.

The type of example I had in mind was when someone here in the past thought that "make" was too hard for everybody to learn, so they made their own language and used make below that. Problem is that there are a lot of built-in assumptions needed to make it work. I suppose it has served fairly well, as such, but there have also been difficulties, and the general knowledge-level of the ordinary developer is not raised when they learn the specifics. And anyone new suddenly has a higher threshold.

Contrast that to my previous place of employment where they made the same preliminary analysis, but the reaction was instead to generate a general make-script for each "application" and specify the assumptions (file placement and such) under which the auto-generated make-script would work. Which then left a natural extension point (editing the make-script) when something out of the ordinary needed to be done, and anyone doing it would gain generally useful knowledge.

I would classify my first example as "obscurity" rather than "higher level", while the second may or may not be classified as "higher level", but it sure avoids "obscurity".

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

@tobega

It is a tough question, how to spot the bad frameworks from the good. I have two very basic rules of thumb:
(1) Does it try to replace Java
(2) Does it require large amounts of configuration

JSPs are an absolute classic for #1 - they are trying to replace something which is not actually all that difficult to do in Java (slap some strings together) - and their justification is that Java is 'too hard'. So they replace it with something else. Now the poor Java programmer has to learn two languages...

Particularly bad is when the thing they replace Java with is so similar in appearance to Java that you keep tripping up over the gotchas where they are different. Replacing X with X' which is just subtly different enough to violate your intuition is a bad thing.

I'm sure everyone is sick of me harping on about how Struts is the root of all evil, so for #2 I will use EJBs instead as my example of what not to do (though there are certainly for worse frameworks out there). Some months ago I had to fiddle around with the configuration for one of our EJBs (I forget why). Lets say that the xml configuration for that particular bean had 23 different parameters that required twiddling. Lets also say that each of those parameters is basically a boolean (plus null), so takes one of three values: yes no or maybe.

That makes for 3^23, or 94,143,178,827 (94 billion plus change) different combinations.

But really, probably out of those 94 billion, only about a dozen combinations are actually valid. The documentation is unhelpful, and the toolset is primitive. Your odds of picking the right one by accident are not good (if you're feeling that lucky, just go and buy a powerball ticket).

A schema will check for stuffed up syntax, but you really need a tool that says "oh hey, I see you've twiddled parameter Z - did you know that if you set Z to true, you need to set W to false, and Q to null?"

Or better yet, where there is a limited subset of the gazillions of possible combinations, to have those standard options able to be instantiated, and then persisted into the configuration file, so that you could effectively choose from a combo box or something in a nice little gui tool.

Yeah yeah, real men don't use GUIs, they fiddle with all 94 billion till they get the right one. Whatever. (Actually, I know there are people who actually enjoy that kind of thing - my opinion is that they are all (a) insane and (b) grossly underpaid)

Compare the amount of fiddling required to get RMI working with the amount of fiddling required to get hibernate working - it is orders of magnitude difference (and hibernate while bad is not the worst offender out there).

The third basic rule of thumb would be:
(3) Amount of documentation - and there are two dangerous extremes, too much, and too little.

An example of this would be the "Struts in Action" book, weighing in at over 600 pages... and it acknowledges that there are large swathes of the framework that it only touches on lightly in passing.

Struts in Action though was better than the Hibernate documentation, which suffers from the same problem that RMI did (haven't looked at RMI recently). Which is different, mutually exclusive versions. The way the RMI documentation should have been written would have been like this:
Step 1 - choose your version (pre and post skeletons)
Step 2 - here's the 5 pages that tells you what to do
Instead you got a 30 odd page document which was continually tripping itself up by at each point having to point out the differences between the two versions.

tobega
Offline
Joined: 2004-06-20
Points: 0

rickcarson,

Right on the nose!

I got completely frustrated with EJB configuration when it complained about the order I was putting things in the configuration file!

But I blame that on DTDs and XMLSchemas being wrongly focused. Nobody would ever dream of thinking that the order of the properties of a Java object was an important aspect, so why should the order of child elements in XML have any magic significance other than that assigned by the author of the particular document?

tobega
Offline
Joined: 2004-06-20
Points: 0

I don't think it is possible to make a list for one killer language, since it probably depends on what type of code you need to create.

The stuff I work on normally needs to be maintainable for the next 10-20 years.

In that light, I would say that "Explicitness" would be a very desirable property for this type of programming, to increase maintainability and avoid the need of having a subtle understanding of the application.

archangel
Offline
Joined: 2003-07-01
Points: 0

> The stuff I work on normally needs to be maintainable
> for the next 10-20 years.
>
> In that light, I would say that "Explicitness" would
> be a very desirable property for this type of
> programming, to increase maintainability and avoid
> the need of having a subtle understanding of the
> application.

Is that really so?

* The more explicit you have to be with a language, the more code you have to write.

* The more code you have to produce, the more opportunity for bugs.

* The more bugs AND the more code you have to maintain leads to harder maintainability.

tobega
Offline
Joined: 2004-06-20
Points: 0

Hey, you're just baiting me, aren't you? ;-)

But I'll bite for now.

> > The stuff I work on normally needs to be
> maintainable
> > for the next 10-20 years.
> >
> > In that light, I would say that "Explicitness"
> would
> > be a very desirable property for this type of
> > programming, to increase maintainability and avoid
> > the need of having a subtle understanding of the
> > application.
>
> Is that really so?
>
> * The more explicit you have to be with a language,
> the more code you have to write.

Not necessarily, depending on how well the language lets you show your intentions.

>
> * The more code you have to produce, the more
> opportunity for bugs.

Not if it is more code because it explicitly expresses your intentions and the contract of your methods and objects. Then the next programmer along will understand it better and the compiler will catch things that you otherwise have to read docs or test cases to know (if you're lucky enough to have all aspects documented or tested).

>
> * The more bugs AND the more code you have to
> maintain leads to harder maintainability.

LOL, nice try.

If you explicitly have to specify whether a parameter or return value can be null or not, that would lead to less bugs and more maintainable code.

If you explicitly have to specify when an object passed as a parameter may be modified by the method call, that would lead to less bugs and more maintainable code.

And so on.

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

Are these things really important?

* Portability for instance was something that I liked initially about Java. It also allowed me to switch to a mac and all my (heavy i/o intensive) own apps ran without recompile.

Mostly these days though (at work etc) the portability that is the most useful is being able to work across multiple versions of windows. Microsoft is still the 800 pound gorilla.

* Internet focus. The intraweb is indeed becoming more important. As I pointed out in a previous flamewar the key here is bridging the gap between client and server, and the major stumbling block there is... none other than our beloved company in Redmond and their stranglehold on OEMs and hence browsers.

Even if Firefox became the dominant browser on the web, you still wouldn't be able to get a new language out there, unless you developed a plugin for it, and convinced everyone to download that plugin and/or keep their browsers up to date.

... so with FF you'd need not one, but two massive shifts of the global market ...

* Interoperability not sure what is meant by this that makes it different from portability.

* Database Integration: good luck with that one, let me know how it works out for you! Many other languages have tried and failed. Arguably the best would be COBOL. The problem is that there is a fundamental disconnect between relational databases and object oriented or imperative programming. At one point I think someone asked James Gosling what was the one thing he most regretted not putting into Java, and he said something like 'set operations'. Which is interesting, because SQL is basically just set manipulation.

* Transactions - personally I think that any language which includes this will categorically fail to be the next big thing. Transactions (particularly once you start talking about this in the context of networks) are so complex that it will kill the language before it gets out of the gates.

* Security - more is better of course. And as our friends at redmond demonstrate it needs to be in there from day one. I think the trick here would be security that:
(a) works
(b) doesn't make life difficult for the user
(c) doesn't make life difficult for the programmer
So it would need to be fundamental to the language and transparent (or nearly so) - and would probably be the DRM proponents wet dream come true.
Maybe something with IPv6 - we each get our own IP address? Issues of being able to confidently assert your identity (ie, yes, I am the one who won the bid / purchased this CD legally) while still preserving anonymity will make this similar in difficulty to the transaction thing.

* Open source. Meh. I don't think this is a big deal. Open source languages tend to gather about themselves a small cult following. Openness in a language is a lot more important. Java is open because you can peek under the hood.

* Economics. This is wrong. The reason that programmers will ditch one language for another is if it solves their pain. The reason I haven't switched to Python or Ruby for instance is that not only do they not solve any pains for me, but they cause new ones. Show me Ruby without warting, and Python without magic underscores, and I may become more interested. When I switched from VB/C++ to Java it was because it alleviated a huge pain. No such massive pain exists in the Java world (except Struts and XP weenies).

* Approachability - this may be what I label as Openness, but may also incorporate readbaility and other things that make a language easy to learn and work with over time. Arguably Java is less approachable now than when it started, due to new features being bolted on. Perhaps a 'neat trick' would be if you could start out with a complete easy language, and then scale up as you became more confident. Here I think an IDE could be critical, if for instance you could take Java's new for loop, and switch to a 'simple' or 'expanded' view, which would simply 'unroll the syntactic sugar' - the same with things like auto boxing and un boxing, and also closures (which I assume is what code blocks and continuations is about).

* The killer app: personally I think this would be "Ajax done right - end to end". Some people seem to think that their favourite IDE (eg Eclipse) is 'the killer app'. But while Eclipse might be 'the killer app' for swt, there doesn't seem to be any mass exodus away from swing to swt. Java seems to have done well - and yet I cannot think off the top of my head what the killer app would be. If anything, maybe it was Applets. Where you could as a programmer, show off to the world your coding prowess on your homepage?

* Dynamic Typing
* Code Blocks and Continuations
* Dynamic Class Model
These just reflect Bruce's current language bias. If someone who loves Perl tells me that 'the next big thing' in languages is going to have top notch regex support I will just nod my head and say 'yeah, whatever'.
But who knows? As they say, every dog has his day - maybe the day of functional languages has finally come?

Whereas in languages like Javascript functions are first class objects, I don't see people using that part of the language very much. Would it really be that much of a change to Java to pass methods as parameters and the return values of methods?

Would it really revolutionise my life to be able to give an object a method which it stores and then later on executes?

No, in fact, what it would probably be is just a syntactic sugar wrapping for what already exists using reflection. There is a Method object in Java. Noone uses it, because it is not convenient to use, and in many cases I could just define an Interface with that method and hand over an instance of the Interface - and I get all the yummy type safety and early warnings from the compiler...

* Rapid Feedback Loop - this is why I love my compiler. I find out about problems up front. It doesn't catch everything, but it saves me a lot of time and effort. Arguably, a lot of the things that it catches (ie forgetting a semi-colon, wrong case in a name) are cruft. Python shows us that you don't need semi-colons, and VB shows us that you don't need case sensitive names. The VB IDE's ability to recase your names (to what they are originally declared as) is a nice touch. On the other hand, although it spits the dummy if I type in a line wrongly, sometimes I spot something further up the page and I want to jump to that line, fix it, and then come back to the current line. Having to wrestle your way through the popup boxes whining at you is annoying. Better would be if the wrong lines just 'looked horrible' ie set the font background to red, or the text to flashing or something equally offensive.

* User Interface Focus - here again we perhaps could learn a lot more from VB than from Java. VB makes life really easy for the UI designer (rather, the UI slapper - the one that slaps together a quick and dirty GUI front end). But it hides too much, sometimes (not often) you want to pop the hood and tinker around under the bonnet. Whereas with Java, it is practically all tinkering around under the bonnet (until you start trying to fiddle with combo boxes). In particular, the ability to double click on your control and get taken to its default method is a huge productivity win. Sadly, it still takes a lot of work to make it look non-ugly, but at least the bulk of the plumbing is done for you (and sometimes it is even a good thing that all the plumbing is hidden).

Though the real master of this is Cocoa (project builder), it is almost as easy to slap something together as it is in VB, and Project Builder provides all sorts of visual cues to help you line controls up and so forth (the tedious disadvantage of not using hierarchical layout managers).

archangel
Offline
Joined: 2003-07-01
Points: 0

This is quite a long list, so I'll just make a few points:

* Portability.
It's great to develope with little thought about compatibility issues and it's great to share sourcecode with people who work on other systems (e.g. Windows or Linux).

* Internet focus.
Definitely. The first "wow" moment I had with Java was when I wrote a little app that looked up a book title from an ISBN number from a webpage. I agree that this still needs to be continually developed and improved.

* Interoperability.
This is the communication between different systems. This has certainly been one of the Java's strengths on the server-side - talking with legacy systems through connectors etc. This doesn't have to be in the language, but the libraries have to make this simple. Could we have native-ish integration like we're seeing in JDIC?

* Database Integration.
I'm not sure how deep this has to be in the language, but I've really liked what I've seen in Groovy.

* Transactions.
Again, I'm not sure how deep this has to be in the language. However, a language that supports meta-tags and meta-programming would be well placed to suppor this.

* Security.
It's always been one of Java's strengths, but as Rick points out it shouldn't make life difficult for the programmer, which Java has a bit of a habit of doing (need to get better at this programming melarky...)

* Open Source.
Ah...that flamewar... I'm not sure if the *language* has to be OS, but it certainly should have a strong OS community. Again, this was one of Java's strengths.

* Economics.
I have to disagree with Rick here. He must work in quite a wonderful company if Economics doesn't have a strong impact on what technologies he uses. Economics is tied into everything. For me to sell a new technology to my company I have to show increased productivity, higher quality and suitable integration with what we're currently using (there's Interoperability again).

Will post the rest at my next tea-break.

Christian Schlichtherle

To me, productivity is the name of the game. Yesterday I had an eye-opening experience: I was looking at a small application which I've wrote almost 13 years ago. It is a 2D/3D GUI to play with Rubik's cube (anyone remembers this kid's toy from the eighties?) and have it solved automatically. This program I wrote in Prolog and it consumed less than 60 KB source, including the GUI and documentation! It is still part of the official SWI-Prolog distribution as a contribution.

If I had to do this in Java today I'ld bet after 60KB of source code I would have just completed the main application frame...

About 15 years ago, I started playing around with C++ and Postgres. When I looked at my Rubik app yesterday I realized that 15 years later we are still working on the same problems with only slightly enhanced tools and workarounds (called "frameworks", which sounds much nicer of course): We are still working hard to persist and visualize data.

Thus, if I were to design the next generation business programming language, productivity would be clearly the name of the game. It would be a mixture of object oriented programming and programming in predicate logic. While the former clearly helps to extend on a sound API basis, the power of the latter allows you to store and retrieve any data from a persistent store way beyond the features of old SQL. Here are some ideas:

* Direct syntax support for components as a sort of extended class. This means no more writing of property change support code, getters and setters and so on.

* Any component could be optionally persisted without the need to think how its been represented in the storage layer. A low level API would be provided to allow providers to implement the functionality (like with JCE).

* Components could be looked up using predicate logic syntax similar to Prolog. Compared to the power of predicate logic, looking up data using SQL is a poor man's choice.

* Any class is also an interface. This would allow anybody to reimplement the behaviour of any existing class! Yes, I suppose this might cause some security issues, but it's just too tempting.

* Removal of package private and protected access modifiers. Though they are useful, they are way too often incorrectly used (anyone ever tried to extend JFileChooser and its companion classes to remove their dependancy on the hidden ShellFolder class?).

* Operator overloading, especially '=' would be the comparison operator, whereas ':=' would be the assignment operator (similar to Pascal, only that you could overload '=', but not ':=').

* No generics. Though they are useful when writing Collections, they just make life too complicated for most use cases and especially the compiler writers (anyone stumbled over "bridge" methods when trying to write classes that work with both Java 1.4 and 5.0?).

My 2p. Regards, Christian

jmoore
Offline
Joined: 2004-08-27
Points: 0

I want to give a strong second to the "No generics" bullet. As a long-time Java developer with extensive experience in C++ and Ada, I was so disappointed when the decision was made to add generics. Generics seem nice on the surface, but they complicate the language in strange and subtle ways, and they did not solve a problem that I had using Java. I think now that most Java programmers are beginning to realize that the addition of generics was a mistake. Unfortunately, it will be almost impossible to go back.

indukumar

You forgot one important aspect: Module versioning. Without it, complicated deployments are definitely a pain.