Registered: Sep, 2005
Re: The Positive Legacy of C++ and Java
Posted: Apr 20, 2009 7:48 AM
> > You keep invoking the "Java is for dumb programmers"
> fallacy. Why?
> I don't think Java is for dumb programmers, or at least I
> wouldn't want this to be the case. I just think that
> anybody arguing against adding more advanced features to
> Java tends to make it a language for stupid programmers -
> not even so much stupid as lower-skilled.
I think you are right that this is why *some* people don't want these features but for a lot of other people, it's really about managing complexity. Each new feature adds more complexity to the language. If the feature doesn't offer significant specific (and new) advantages, then the Java philosophy is that it's not worth the extra complexity. Again, I'm not sure that operator overloading is correctly excluded. I'm talking about this in general.
> 1) Yes and no. Surely a next big thing in programming
> languages will come some day, but enterprises, as they get
> more mature regarding IT stuff, heavily support evolution
> instead of revolution. Any revolution means high costs,
> whereas evolution is much cheaper. So the process of
> moving away from Java will be a slow one, unless for
> instance MS offers to pay for migrating all Java apps to
> .Net, and makes .Net open source and available cross
> platform, which is already SciFi.
I'm actually envisioning a world where a new language that runs on the JVM and integrates cleanly with Java becomes the next thing. Instead of rewriting all the Java code, the new language would be used to build onto existing Java apps and eventually the Java parts would be rewritten in the newer language. This isn't my idea, obviously. Scala was developed with this vision. Personally, I can't see Scala gaining wide acceptance in IT. The design seems to concerned with pointy-headed concepts and not enough with real day-to-day programmer concerns, although it does offer some real benefits in that area.
> 2) Unfortunately, it isn't IT shops that decide upon
> technology. And non-IT shops, i.e. customers, don't make
> decisions based on language issues alone - what they use
> is the TCO. The sheer numbers of Java programmers on the
> market, plus availability of tools, libraries, application
> servers and overall infrastructure components, many of
> them free, make Java an attractive technology for
> enterprise applications, in spite of Java having its
> quirks. The only alternative is .Net, which is however
> limited to Windows as an OS, which brings significant HW
> and SW limitations with it (if we don't consider
> virtualization), and which still isn't that well covered
> with server-side technologies, thus being a less
> attractive technology for an enterprise infrastructure,
> IMO. Essentially, I think it's the robusntess of the
> ecosystem around a language that makes it succeed or
> vanish. The ecosystem around the JVM and Java is quite
> large and stable, I think.
I agree. I work in a shop with a lot of COBOL and RPG programmers. Management doesn't really want to continue to use COBOL but we have a lot of COBOL code and developers are easy to come by (for now.) What makes it very difficult to get away from COBOL is how poorly it integrates with other languages and tools. Java, IMO, doesn't have this same problem.
> > A little off-topic but if the only reason to support
> Java is for your
> > customers, have you considered pre-processors or IDE
> Yes. I've not yet come across something smart enough, on
> one hand, and on the other hand it gets too complicated to
> be feasible the moment programmers outside your team get
> their hands on code you delivered - remember, the code
> belongs to the customer, so whoever is hired by the
> customer can change it in any way he/she wants. Also,
> customers sometimes (we try to avoid it if possible)
> sometimes give you existing code for maintenance projects,
> and in such cases such tools are a lot less useful, if at
> On the other hand, IMO something requiring tools to be
> used is not a smart technology choice. Every additional
> component in the process is an additional potential point
> of failure. If the ppl providing the tools fail to keep up
> with development of the language or of the platform,
> switching tools can be complicated or impossible, or at
> least extremely expensive.
I was thinking that a tool that allowed you to see a specific method as '+' or '-' in your IDE would be a good fit. The resulting code would look like any other code. The customers would be none the wiser, if it were done well.
> Third, why would a small SW dev shop support a language
> other than for providing services based on it to
I don't know. Why are you asking?
> > Even if you don't have to use a feature, it affects you.
> If gotos were
> > allowed, you would have to understand how they are being
> used in any
> > code that you had to deal with that used them.
> 1) I'd rather learn to understand goto, even if I wouldn't
> use it, than give up operator overloading, if I had the
> choice. It's the lack of choice that bothers me. Besides,
> there's a difference of effort needed to learn to
> understand what goto does in code you didn't write and to
> understand how to use goto efficiently (you can replace
> goto with operator overloading or generics, the meaning of
> what I want to say is the same).
But you are missing that the use of these features by others affects you in that it forces you to change how you do things. It's not just about reading their code. You may be forced to use the feature to interact with their APIs.
> 2) It seems to me you think standards cannot and are not
> ever enforced. If you have a coding standard which bluntly
> states that goto should never be used, the size of the
> team is IMO irrelevant for enforcing the standard.
Coming to agreement on what the standards should be is definitely affected by the size of the team. The only solution is to have a dictator and you are in the same situation then that you are in with the JCP (unless you are the dictator.)
> Although also IMO having such a rigid standard is stupid,
> and code reviews should be used to allow or reject a goto
> on a case by case basis.
On a large team, the review teams are not always the same group of people. If you make it up to the review team you end up with highly inconsistent code and frustrated developers because one team approves something one week and the next team rejects the same approach the next week. The uncertainty creates low morale and other problems.
> It's also a bit off topic, but I
> remember a Linus Torvalds quote: "Dijkstra probably hates
> me" - related to the use of goto in the Linux kernel code
> ver. 1.4.something. I just looked, gotos are still used in
> the same file, although the comment is no longer there.
I don't know anything about kernel development so it might be perfectly reasonable in that circumstance. But I know for sure that goto never needs to be used in business logic. There are ways to use goto that are not problematic. They are essentially what the standard structures like loops and methods we use in languages like Java came from. But that's the point, they offer no advantages over these approaches. The only thing they add is the ability to cause confusion and other problems. You lose nothing by excluding them (in a business app.) Personally I don't like having big red buttons that say "don't push" around. If I have to choose between a railing that prevents people from accidentally falling to their death and a sign that says "careful, don't fall", I'll do with the railing every time.
The upshot is that I agree with the Java philosophy in general. Don't add features that don't provide significant and new (and good) abilities. Having lots of different ways of doing the same things just creates inefficiencies. In the case of operator overloading, it probably would have been OK if added in the beginning but would be problematic to add now.