back to article Gosling gets closure on Java

James Gosling, the Father of Java, today gave his blessing to the latest attempt to simplify the programming language. In his blog today, the Sun Microsystems vice president said he "absolutely" backs the proposal for putting closures into Java Developer Kit 7.0, the next version of Java. Closures are the brainchild of Neal …

COMMENTS

This topic is closed for new posts.
  1. John Vaudin
    Thumb Down

    Simplifying?

    "James Gosling, the Father of Java, today gave his blessing to the latest attempt to simplify the programming language"

    Er. How can adding MORE stuff to a language simplify it? It's not like they can throw away anonymous inner classes.

    No - Java is doomed to go the same way as C++ - with armies of academics, who are too clever to any proper work, adding more and more features to it, all in the name of making it 'more expressive', until eventuall it gets replaced by a new, cleaner, simpler language, and the whole process starts all over again.

    Plus ca change...

  2. Chris Rimmer

    @John Vaudin

    Yes, that does seem to be the cycle. I think the problem is that approaching a mature language is very difficult, and requires a lot of patience and dedication to learn. I've been writing C++ for over 10 years, and for most of that time, everything I've learned has demonstrated to me that there are several more things that I hadn't realised that I didn't understand. Now that I'm writing a C++ language support library to make GCC work with our platform, I feel that I've finally reached a tipping point, understanding multiple inheritance, RTTI and exception handling in some depth.

    When a developer doesn't understand a complex feature of a language, and can get by with a simpler approach, it is very easy for them to believe that the complex feature is just clutter. (And vendors exploit this perception to promote their proprietary languages, which allow you to write impressive demo code very quickly, but aren't up to the job of fleshing out and maintaining a full application).

    As programmers set out with a new, simple programming language, they start to understand the problems which the complex feature addressed, and start demanding that the feature be added to their simple language. Eventually the simple language evolves into something that the next generation of programmers turn away from in horror.

    So what's the solution?

    Well a good start would be if programmers spent more time learning, particularly learning about programming in general, rather than programming with a particular language. I find it saddening when some developers criticise C++ saying that Java and C# are "more object-oriented than C++", demonstrating that they don't understand (i) the difference between supporting a design and programming paradigm on the one hand, and forcing programmers to put all data and functions into syntactic structures labelled "class" on the other, and (ii) that object orientation is only one paradigm which is eminently suitable for many problems, but is not ideal or is even irrelevant to others.

    Another would be if skilled developers were given the ability to choose the technology suitable to the problem to be solved, rather than being forced by managers to use whatever whizzy product some vendor has just convinced them will magically create a solution to all their business problems just with a few mouse clicks performed by people with no knowledge of software development.

    I've seen software development work well and work badly over the years. Where it's gone well, it's been due to a good team of skilled developers, where the most experienced ones mentor the less experienced; and where the immediate management have prevented higher management from interfering with day-to-day activities, but have made sure that the development team are focussing on solving the business goals (without trying to force them to do so in any particular way).

  3. Anonymous Coward
    Boffin

    How languages evolve, unfortunately

    Quoting Tony Hoare (aka C.A.R. Hoare, google if you must):

    "There are two ways of constructing a software design.

    One is to make it so simple there are obviously no deficiencies;

    the other is to make it so complicated that there are no obvious

    deficiencies. The first method is far more difficult."

    Several languages went down the second path: Algol68, ADA, C++.

    Java seems to be heading in that direction, despite a promising

    beginning.

    Each time a language crosses a 'tipping point' of complexity, a

    new clean and lean language emerges trying to follow the first method,

    but eventually grows cruft (sorry, features) - especially if it falls

    into the clutches of a committee - until it is firmly on that second path.

    I agree with the original comment, c'est la vie.

  4. Chris Rimmer

    @Anonymous Coward

    From my reading of "The Design and Evolution of C++" by Bjarne Stroustrup, I don't think that's really the way that C++ has evolved. The last major features to be added to the C++ language were templates, exception handling and run-time type information, and the essence of the design was already in place 20 years ago, before standardisation began. From what I've read recently, there will be some minor tidying of the language in the updated C++ standard next year, but no major language features. Stroustrup makes it clear that he is determined not to add language features where there are already alternative ways to express the idea in the existing language, or where libraries can be used instead.

    Again in the D&E book, Stroustrup shows where the various language features come from. Templates came from a desire to create container classes in which type errors could be detected at compile time. Exceptions are an important part of allowing applications to be composed of independently-written components, in which the code which detects an error condition is unlikely to be in a position to know how to respond, and vice-versa. C++ features were generally introduced in response to needs of a wide section of the C++ programming community, and ideas were discussed and refined for years before being accepted as part of the language, considering the experiences of experimental C++ implementations and of other programming languages. Features which were unlikely to be of use to a wide cross-section of C++ programmers were consistently rejected.

    It's interesting that you point to Java as being a promising clean language. The major features of C++ not present in Java were basically multiple inheritance and templates, and I suppose operator overloading if you consider that major. However, right from the beginning the Java language introduced several new features, including a form of run-time type information with a much greater scope than C++'s minimal version, garbage collection as standard, interfaces, serialisation, and multi-threading and synchronisation support. That was soon followed with inner classes.

    The question I'd like to ask you is: what is the minimal set of features for an effective general-purpose programming language? I take it you'd want a variety of data types, control flow and function calls. Is floating-point support necessary? Would you consider it excessive to have classes? Should there be language support for polymorphism, or are function pointers or references sufficient? What about support for type-safe collection classes? What about exceptions, or is it good enough to have return values which have to be checked on every function call, so that the likely control flow is hard to see because of all the inline error-handling code? Is it necessary to have built-in constants for pi and e? What about complex number support, or should that be expressed through structures with two members, and if so, what types should those members have? What about closures? What about run-time type identification? What about the ability to create objects by the name of their type? Garbage collection? Support for multiple threads? Should it be able to call functions written in other programming languages? Should it allow unchecked access to arrays? If not, what should it do in response to an access violation?

    More tellingly, how would you decide what was the appropriate set of features for a programming language? Would you decide for yourself, and tell people to take it or leave it?

  5. Anonymous Coward
    Happy

    Re: Simplifying?

    Since the JVMs are to my knowledge largely written in C++. It is hard for me to understand how anyone can expect C++ to disappear just yet.

This topic is closed for new posts.