You need to sit back and look at your language, and what it says about what you're trying to do.

You have a team that's trusted by customers, and you want to *empower* *them* to think like salespeople? When your corporate culture has produced salespeople so lacking in integrity that your own customer base has come to the conclusion that those salespeople are only interested in "alleviating them of their money"?

Your technical team is working *fine*. Don't break it.

Your sales team sounds dysfunctional and broken. Fix it.

As a general rule, fix what's broken before you mess with what works. This is counter to most corporate cultures (which has a tendency to kill the goose laying the golden eggs by trying to 'fix' the goose to lay larger eggs), so don't try to ape others without some analysis.

In the end, the best sales technique is to make it trivially easy for someone to give you money, and to make something that someone would want to give you money for. In this world, making it easy for the technical staff to say "oh, we have a product that'll solve that problem, let me give you a single-user ninety-day license for that." would go a long way towards exposing your products to your customers without spoiling your technical team's reputation.

(And WTF is this 'service orientated' crap? I doubt the technical team would describe themselves that way, although they might say 'service oriented'.)

And while the easy-bake oven is almost a decent analogy, the existence of relatively more open Android devices kills it. You can't say an Android phone isn't intended for the same things -- both Android and iOS are targeting the exact same users, use cases, etc. It's much more like the difference between two otherwise-identical toasters, one of which can have the temperature and cooking-time adjusted, and the other always produces toast of precisely the shade of brown Steve Jobs favors.

I carry both an Android phone and an iPhone.

I prefer the iPhone.

The Android does *more*, but I find it less pleasant to use overall. The iPhone is a toaster with three settings, while the Android is a toaster-oven with seventeen dials and a bling switch.

And after six months of equivalent use, you'd be sad that you couldn't make pizza in your iPhone toaster, and that the three settings wasn't ideal for toasting your cinnamon bagel. But the Android toaster-oven has burned you at least once a week, has turned itself on for no apparent reason five times, has turned itself off while in use fourteen times, and unplugged itself from the wall three times. Further, despite all the settings, you've never actually managed to get anything toasted exactly the way that you want -- the color might be right, but the texture isn't, or the color is right and the texture is right, but the crusts have been cut off.

So.

I think Android wins on the flexibility front. And I think the iPhone wins on the usability front.

(And this bothers me, since I've long been an advocate for flexibility -- but in practice, it's just not working for me.)

I can do less with the iPhone, but what I *can* do is pretty damn good. I can do more with the Android, but the WTF? rate is much higher, and quite a lot higher in the common usage cases.

How much of these differences are between the hardware or the carrier, I don't know. And as an end-user, I don't care. I want a reliable, predictable, *consistent* experience, and the Android isn't giving me that, for all that it lets me do five gazillion things *more*.

The major flaw *I* find with Java is the incredible mess it makes of I/O (but some people seem to like it). A less basic flaw is the mess it made of generics. I understand that this was to maintain compatibility with older code, but it's not worth it. A different answer should have been found. I guess it's a matter of taste, but I really dislike the classes wrapped around classes wrapped around classes kind of syntax that Java promotes. (It's not inherent in the language, but in the esthetics of the library designers.) I can see the utility, but it's really ugly, and a different approach should have been found. But that might have required either multiple inheritance or mixins.

The wide-char stuff in Java is the messiest part, in my opinion, while the multitude of stream classes were the nicest. What *part* of I/O bothers you the most?

Generics are indeed a mess. All I wanted was covariant return types, but instead the language got screwed up by the type-theory weenies. Of all the problems I had seen in Java code by that time, getting the wrong type out of a container instance resulting in a class cast exception was *not* a common problem. It was a clever solution looking for a problem, which is a recipe for disaster.

Which, really, is the key lesson that isn't being learned by most of the folks who want to improve on Java: clever is a bad idea unless it solves an actual problems encountered by real programmers, as opposed to solving concocted problems by theory-minded boffins.

You're the one who brought up assembler, and expanded the topic beyond just objects in Java. So, no, that's not just what we're talking about -- we're talking about the *concept* of pass-by-reference, and then applying that to Java. You've expanded the scope of the discussion, so it's ingenuous for you to try to narrow it back down again.

Your "fix" to the provided code merely demonstrates that you are unfamiliar with the concept of pass-by-reference, and thus are not qualified to hold an opinion on the subject. Please go and take an introduction to programming course from a reputable institution. This is a concept any second-year computer-science student should have been exposed to.

You keep getting hung up on where the objects are created, instead of paying attention to variables and parameters.

Seriously, did you even bother to run the code? And then contrast that with a language that is acknowledged to have pass-by-reference semantics?

It doesn't look that way to me. :(

The fact that Java's primitive types are all immutable makes this even easier -- immutable objects are very well-behaved.

Um... what?

Are you sure you meant to write "immutable" here?

Objects are never placed on the stack - which is where parameter "passing" takes place. It's always been like that, even back in the days of assembler..

Um, there are conventions where no stack is used to pass parameters. An when you get to the level of writing assembler, a stack is purely optional. So, no, even back in the days of assembler, parameter passing was not necessarily done with a stack. Even now, passing parameters in registers is an acceptable convention on register-rich hardware.

At this level, it's best to think of Java as having nine primitive types: boolean, character, byte, short integer, integer, long integer, float, double, and object pointer (or object reference, but that just leads to confusion when talking about pass-by-reference). When you "pass an object" to a method in Java, you actually pass the _value_ of the object pointer to the method.

When you use a language with "actual" pass-by-reference semantics, there are certain behaviors you expect to see, such as the one I described. We do not see those behaviors in Java.

Just because the object reference is automatically dereferenced in Java doesn't mean that we can get away with saying that "Everything is passed by value", since object never are passed by value.

Actually, we can.

If the language didn't actually allocate an object pointer variable distinct from the object itself, I'd concede your point. In that case, the memory location aliased by a variable would be the actual object, and that would arguably be a pass-by-reference language. It would also be a noticeably different language.

Seriously, show me how to write a method in Java that sets the parameters in the calling scope to null, and I'll agree with you.

e.g.,

      Object s = "can't touch this";
      Object t = new Object();
      foo( s , t ); /* at this point, s and t should both be null */

I've never been able to figure out a way to do this in Java.

And that's why I call Java a pass-by-value language.

I think perhaps there is a misunderstanding the benefits of homework.

For children, it's a means of allowing for parents to be involved. Parents who care about their children's education tend to have children who do well, and learn. Parents who view homework as something to keep the children busy in the evenings so they can watch TV tend to have children who do not do well.

Rather than putting the whole burden of education on the schools, we should get the parents engaged. How to accomplish that is the truly difficult problem.

I favor having parents attend school with their kids for an hour a day per kid.

Anyone who does not appreciate what JEE brings to the table is not a serious enterprise developer.

I *appreciate* what J2EE brings to the table.

That doesn't mean I _like_ it.

I generally agree with your list (with AJAX and WSDL being a notable exception; those are flaws, not a features, but the evils of AJAX and WSDL are another discussion entirely), but feel that it misses an important point: J2EE is just nasty.

It's like C++ -- the *list* of features does not mitigate the sheer soul-draining /wrongness/. And like C++, it's a reasonable "early effort", and we're now at the point of needing someone to look at J2EE with a critical and analytical eye, and to devise for J2EE what Java was to C++: something, while perhaps not perfect, is a few orders of magnitude *better*.

Your list is an important place to start, if not in actual features, then in issues addressed by those features that any successor *must* address just to get a seat at the table.

Very true.

In C++, when you overload an operator, you change the order of precedence for that operator. This can result in some very annoying bugs.

Before I ever jump on the "operator overloading is a good thing" bandwagon, I'd like to see it done right in a language, somewhere. Until that time, the preponderance of the evidence, to me, is that unrestricted operator overloading isn't worth the trouble it brings with.

I have a sneaking suspicion that to do operator overloading "right", you'll have to implement a field.

Everything in Java is passed by value. And every object variable is a reference.

Those two statements are mutually exclusive :-)

Objects are passed by reference, which means that NOT everything is passed by value. Only the reference to the object is passed by value :-)

This is what happens when you don't start students with Pascal and give them proper training in what lexical scope really means. :)

Let's cover the basics, shall we?

Variables are aliases for memory locations.

When we say "pass by value", I mean that the _value_ of a variable is passed to the subroutine.

When we say "pass by reference", I mean that the _location_ of a variable is passed to the subroutine.

Java is a pass-by-value language, with one of the types being an "object-reference". When I pass such a type to a subroutine (method), the *value* of the variable is passed, and /not/ the location of the variable.

If Java were a pass-by-reference language, then the output of:

public class IfJavaWereAPassByReferenceLanguage {
      public static void main( String [] args ) {
            String s = "Hello ";
            System.out.print( s );
            foo( s );
            System.out.println( s );
      }

      public static void foo( String reference ) {
            reference = "World";
      }
}

would be "Hello World".

But it isn't, so Java isn't a pass-by-reference language. It helps to draw a picture. It can take a bit of effort to understand what's going on for some people, but drawing a picture of what's actually going on helps a lot.

You're passing in a "type" flag in an object-oriented language and you consider that to be a "clean" design? Your aesthetic is *vastly* different from mine.

When I'm programming in an OO language, I strive to eliminate type flags (you have a means of type-selection -- the object system. use it!), switches, or nested conditionals.

I guess that's why there's so much noise and fury about desirable or undesirable features in languages -- some of the idioms used by one group are anti-patterns to another group, and, arguably, vice-versa. Presumably, the goals of OO are different as well -- is it to be used primarily to organize the code for clarity and maintainability, or is it to be used to maximize code reuse?

Many of the "improvements" to Java were done without the thought necessary to make them work right, such as the Generics capability.

However, I disagree about the problem of abstract static methods. I have come to dislike static methods and would prefer to see their use limited *further*, since much of the absolutely terrible code I've had to deal with over the years has been a result of the (ab)use of static methods.

Many colleges teach Java as a good first language, as the perceived alternative is C++, which is a terrible first language for anyone. Java's not a good first language, but it's by no means the worst.

Java Generics are indeed a total hack, which is a result of trying to cram features into a language without thinking through the consequences. Generics were the cool thing, therefore, to remain relevant, Java must have Generics... and thus we get this festering sore on the language.

I do not agree with the analysis for abstract static methods. In the Java object model, the concept makes no sense (unlike, say, Smalltalk), and, indeed, is arguably worse than useless. A great deal of the terrible code that I've run across over the years has been a direct result of programmers favoring static methods with only the shakiest of justifications.

It's true that meta-programming is awkward, but in the languages where it isn't, and is heavily used, I fail to see a significant improvement in code readability or maintainability. It allows for clever techniques that can be extremely difficult to debug, much less understand from reading the source code. Awkwardness in this domain is a disincentive, which is arguably a good thing.

Exception handling is awkward... and arguably more informative than in any other language in common use. Some languages allow the exception handler to "fix" the problem and resume, which is amazing and powerful and wonderful... until you discover a programmer who uses this capability for mixins and flow control, making the code virtually impossible to follow.

But then, I'm one of those throwbacks who consider having to use a debugger to develop or read code to be a bad thing. Code is a form of literature, not a performance art.

Multiple inheritance is an abomination.

Not all types being object is a wart, and not a significant one. Autoboxing is a hack that's worse than the flaw it attempts to hide.

Java is a language full of flaws, but when one tries to envision a replacement language, one needs to consider not its flaws, but what it did *right*, and /why/ that design decision was right for the language. (I assert that what's "right" may be different in the context of a different language; "these are my favorite things" is a poor way to assert what's right.)

In my opinion, some of the things Java did that was right was:

1) It ran on several platforms. MSWindows was the dominant desktop environment, and it sucked, and sucked hard. The more useful systems (Solaris and Linux at first) were far nicer for developers, but those systems weren't what the users and managers were using. Java could be developed on the hippie's Linux box, tested on the corporate Solaris server, and demonstrated to the manager on his MSWindows desktop.

That's a huge win. Nobody feels that the language chosen is being used to force someone else's environment on everyone else.

2) It supported concurrent programming out of the box. Most of the time, in most of the code, there's not a need to handle threaded or concurrent code. But in that window where it is useful to separate tasks into concurrent threads of execution -- such as keeping the database-access code out of the GUI drawing thread -- it's made vastly simpler in Java.

And given that MSWindows at the time had a laughable concurrency model, Java's ability to bring this sort of concurrency to Java was *very* attractive. You didn't have to rewrite the algorithms developed on a UNIX-type machine to handle the broken MSWindows environment, which ties into point #1.

3) It eliminated many programmer problems. The lack of pointer arithmetic and built-in garbage collection (in contrast to C++) was another major factor in why Java became a big thing. Thought was put in to what the /actual/ problems were (as opposed to what pundits *thought* were the problems), and solutions devised accordingly. (Once the development path started down the road of adding features that were _neat_ instead of solving a real problem, we started getting broken crap like Generics.)

This is really where the designers of new languages should concentrate their efforts. Look at the problems that are actually cropping up, and devise solutions for those problems, in the context of all the other problems and solutions devised for the proposed language.

4) It had a large and diverse library. The scope of this sort of effort is difficult to accomplish, as growing this much support code is time-consuming and expensive. There's a /lot/ of code that ships with the Java SDK, making a great many of the mundane-but-frequent tasks not just easier, but *easy*. From basic data structures to network servers, only a few lines of code were needed, using the well-documented libraries.

Which brings us to documentation...

5) It came with a built-in documentation system. The Javadoc system is, frankly, amazing. It made it easy to create usable, cross-linked, accurate documentation about a codebase, so that even mediocre developers could generate useful documentation. With a minimum of effort, a developer unacquainted with the code could easily start using a codebase just from the documentation generated with a tool.

The large and diverse library was documented with the same tool that developers could use on their own code. The library documentation served both as a reference for how to use the code, it also served as a reference for how to write documentation. Programmers who had no idea how to write decent documentation now had a ready reference to crib from, which made their managers (and, presumably, fellow developers) happy.

6) It scaled with the size of the development team. From Object-Oriented language features, to interfaces, to JAR files, the language supports large teams of developers. One of the most useful features (not original to Java, but certainly popularized by it) is the "interface". Also called a 'public abstract virtual class', often dismissively, its usefulness lies in the ability to clearly document what a class will look like without having to implement the class.

This lets teams of developers define the points of coupling between their respective modules, without at that time having to mandate how that module will work. With just an abstract class, behavior tends to leak across this boundary, leading to hidden coupling, which makes the overall system more fragile, and requires more manpower to manage the interactions between modules as the size of the team grows.

These sort of scaling issues should be a paramount concern of anyone devising a language to supersede Java. These sorts of language issues should be at the forefront of any language designer's mind -- what are the REAL problems, and how does any particular feature solve that problem?

I don't get that sense from this new language. It seems to be more of a hodgepodge of "cool features from C# we would like to see in a language but won't fit in Java".

Personally, I don't like the idea of having Just One Language to be used everywhere. I *liked* Pascal as an introductory language, and found its limitations useful in pushing the student into other languages once the pedagogical goals have been reached. I *like* the idea of having at least one language for systems programming, and a different set of languages for applications, and a different set for scripting, and so on and so forth.

Cite, please, Gosling admitting that interfaces were (probably) a mistake. They're one of my favorite features of the language, especially when the time comes to work with other developers. In my experience, a well-defined interface reduces integration time and coupling, while multiple inheritance increases 'em.

(To be fair, the increased integration time and coupling problems might have been due to other features of C++.)

I emphatically *don't* want a C++ style macro compiler or include system. That leads to incomprehensible and unmaintainable code. Been there, done that, got burned. Java's biggest selling point was that it wasn't C++. Java's biggest failings are when it tries to ape C++.

driving is fun when you're driving for fun.

I disagree. Driving is *always* fun. Well, at least when it's more than just a couple of minutes, or you have a sprained ankle, etc. :)

but most of what people have to use cars for is serious and boring. sitting in rush hour traffic isn't fun, driving to and from the same place every day for a decade isn't fun.

I dunno.

Serious, maybe. boring? Only if you're not having fun.

(To be clear, I'm not thinking of "fun" as "playful", but as "enjoyable" or "satisfying".)

Granted, on rush hours. I don't like rush hours, so I adjust my schedule and route to avoid them.

And driving to and from the same place every day *is* fun. You need to pick a route (or routes) that avoids things you /don't/ enjoy.

some of us just want them as tools which do something useful.

I just don't understand this thinking. I want my tools to be enjoyable to use, appropriate to the task, reliable, *and* useful. I don't have one hammer in my toolbox, I have six hanging on the pegboard on the wall.

I can't afford six cars, nor do I have a garage big enough if I could.