Bruce Eckel Talk: Java Issues & Directions

Home

News: Bruce Eckel Talk: Java Issues & Directions

  1. Bruce Eckel Talk: Java Issues & Directions (26 messages)

    On June 25, 2004 at the UC Berkeley Haas School of Business, Bruce Eckel (Thinking in Java) gave a talk on issues and directions for the Java language. He looks at the new features in JDK 1.5/J2SE 5.0 and is very honest. He criticizes Java, "but in the spirit of understanding the limitations of the language".

    Bruce mentions the fact that people have "interesting" things to say here on TheServerSide.com when he blogs about something such as Checked Exceptions.

    Let's check out the video, and show him that we have good thoughtful comments! :)

    View the video: Bruce Eckel on the direction of Java

    View his blog: 7-9-04 Java Issues & Directions

    Threaded Messages (26)

  2. Transcript[ Go to top ]

    Does anyone know if a text transcript of the video?
  3. Transcript[ Go to top ]

    +1
  4. Transcript[ Go to top ]

    Well, I doubt the existence of text script of the video. It's over 2 hours.
  5. Transcript[ Go to top ]

    Couldn't someone watch it and transcribe it? I know this sounds like work, but it would be worth it.
  6. Transcript[ Go to top ]

    Part of it can be found in the following links
    http://mindview.net/WebLog/log-0050
    http://mindview.net/WebLog/log-0051
    http://mindview.net/WebLog/log-0052
    http://mindview.net/WebLog/log-0054
    http://mindview.net/WebLog/log-0055
  7. Too bad it's in rm format.
  8. Great[ Go to top ]

    Great talk. Clears up the mind on some things about being a programmer and Java community as a phenomena. My guess is that Sun made a good marketing move by creating a community which we all required but at the same time it had to ensure Sun itself and the language implementation through JCP gets community feedback considered appropriately. That's of course, my vote for "open sourcing" Java. Thanks to Bruce, I was looking to try Python earlier, but now I think I will get some Python book today.
  9. It's a great talk. I agree with most of the arguments Bruce provided, especially with the criticism of the checked exceptions. The subject of "strong typing versus readability and maintanability of code" was also very interesting.

    Just recently I had to work with an existing Struts/JSP-based application where the standard was to use Java string constants everywhere, including JSP pages. Now, this certainly provides compile-time checking (even though JSPs are compiled at runtime) but it makes the code absolutely unreadable.

    One topic I didn't agree with was the "problem of multiple classpaths/classloaders" as Bruce described. It can be difficult to setup and debug at times but I just do not see how this feature can be implemented in a simpler way.
  10. I second that[ Go to top ]

    It's a great talk. I agree with most of the arguments Bruce provided, especially with the criticism of the checked exceptions. The subject of "strong typing versus readability and maintanability of code" was also very interesting.Just recently I had to work with an existing Struts/JSP-based application where the standard was to use Java string constants everywhere, including JSP pages. Now, this certainly provides compile-time checking (even though JSPs are compiled at runtime) but it makes the code absolutely unreadable.One topic I didn't agree with was the "problem of multiple classpaths/classloaders" as Bruce described. It can be difficult to setup and debug at times but I just do not see how this feature can be implemented in a simpler way.
    Having dealth with classpaths and DLL's, I take classpaths everyday and twice on sundays. Atleast with classpaths I have more control and can provide dynamic behavior. Comparing classpaths to .NET 1.0 and 2.0, I find classpaths easier. Having to create separate app domains to dynamically load and unload domain objects and apps, feels less flexible to me. That's my own bias. I'm sure others will disgree and find DLL's easier. I like to think everyone thinks differently, therefore there is no one right way to do things. Humans are not static and the "best" language, platform and technique changes over time.
  11. I second that also[ Go to top ]

    Having dealth with classpaths and DLL's, I take classpaths everyday and twice on sundays. Atleast with classpaths I have more control and can provide dynamic behavior. Comparing classpaths to .NET 1.0 and 2.0, I find classpaths easier.
    Am a veteran of a decade of fighting the DLL/COM hell wars. Fought them on different fronts in different situations at different companies. After working with Java for a few years, I've actually come to regard classpath and the class loader capabilities as one of my favorite things about the language. Simply because I've encountered so much pain elsewhere by comparison. I absolutely prefer it over the COM machine-global registry and I too prefer it to .NET dynamic loading features as it's more straightforward (and I believe more ammendable to customizing for interesting and unique class loading situations).

    It also irks me that .NET has two executables that it distinguishes - .exe and .dll vs. the universal .class file that Java has. Circular references between .exe and .dll are overtly prevented by Visual Studio (for dependent .dll assemblies, restricts adding references to .exe assemblies). Whereas circular references between two java .class files is dealt with by the Java compiler. So there are still some edges of .NET that have a sort of C/C++ archaic feel to them whereas Java seems a more definitive departure from the old ways.
  12. Code Readability[ Go to top ]

    It's a great talk. I agree with most of the arguments Bruce provided, especially with the criticism of the checked exceptions. The subject of "strong typing versus readability and maintanability of code" was also very interesting.

    Just recently I had to work with an existing Struts/JSP-based application where the standard was to use Java string constants everywhere, including JSP pages. Now, this certainly provides compile-time checking (even though JSPs are compiled at runtime) but it makes the code absolutely unreadable.
    I find that type information being in the source code is essential for my ability to read the code. Especially if I didn't write it.

    And I'm not sure how string constants make code unreadable, but I suspect it probably had more to do with the unreadability of JSP.
  13. Just recently I had to work with an existing Struts/JSP-based application where the standard was to use Java string constants everywhere, including JSP pages. Now, this certainly provides compile-time checking (even though JSPs are compiled at runtime) but it makes the code absolutely unreadable.
    Exactly. Better example (ignoring reflection, as it is too verbose to do extensive work with it) of untyped programming in Java would be if you worked with objects where the only (or the most important) method was something like object.do(String actionName, Object[] parameters). I bet there is a web app framework with something like this somewhere...
  14. I bet there is a web app framework with something like this somewhere...
    You're so right. There is one. We are using Tapestry for our new application and we are immensely happy with this choice. The only problem -- it is so much harder to look at the JSP sources now. It is like going from C back to assembler coding ...
  15. Like Bruce, I wish that Java Generics were more than automatic casting for Collections. That's nice enough, I suppose, but not what I expected when I first heard about Generics (I come from a strong C++ background, so I was expecting something similar to C++ templates).

    When he was talking about XUL and next-generation GUIs he mentioned Avalon (Microsoft) and Flex (Macromedia), but didn't mention any of the Java-based XUL frameworks. I suppose none of the Java frameworks have the backing of a major player or standard, but they are available. Personally, I like Thinlets. Thinlets make an applet a viable client.

    I like the new enum capabilities (Josh Bloch will need to re-write that entire section of Effective Java). I'm less certain about autoboxing. There's a big dicussion of autoboxing pitfalls on Javalobby.

    Anyway, I thought the talk was interesting and worth watching.
  16. Generics = Specifics[ Go to top ]

    Like Bruce, I wish that Java Generics were more than automatic casting for Collections. That's nice enough, I suppose, but not what I expected when I first heard about Generics (I come from a strong C++ background, so I was expecting something similar to C++ templates).
    Java Generics suffers from a bad misnaming, I think. Rather than let you take something that's typed and make it untyped, it let's you take something that's untyped, and make it typed. It's actually increasing the strength of compile time type checking. I think it's a good thing, as it lets me do something like write a Closure Class that's typed. But, the marketing was wrong, and the name is wrong.
  17. Generics = Specifics[ Go to top ]

    If you've seen the video, Bruce talks about specifics of Java generics and how it's implemented inside the JVM. Backwards compatibility makes generics "erased" so the type information is lost and the only thing you get is compile time type checking. That's good of course, but at the same time it creates some issues at the runtime, especialy then you have mechanisms as reflection.
  18. Generics = Specifics[ Go to top ]

    I can not see this video, but it was article about this "JAVA generics flaw".
    As I understand this flaw does not exist and Bruce is wrong (or I missunderstand this problem), see javadoc for java.lang.reflect.ParameterizedType
  19. I have been a long time fan of Bruce Eckel, actually since the first "Thinking in C++" edition and I agree with a lot of what he says in his talk there. However, there's this static vs. dynamic typing issue that he has been going on for quite a long time and again in this talk I fail to understand what his argument really is. I mean he says that it doesn't scale, that static typing is useful for some time because it provides a kind of testing but that it eventually gets in your way. But he doesn't say how that is. It stays rather fluffy. There has to be a verbally expressable reason why it doesn't scale but he doesn't give one.

    In my experience, it's exactly the other way around. As long as a code base is reasonably small, I don't need static type checking because I can remember where and how objects are used. I don't need a tool that can infer inconsistencies in the code based on the types of variables because I know how things work and what I have to change when I change something else. However when a system gets big, my brain doesn't scale. I don't know all the consequences of what I'm doing anymore and I can use any help that tools and compilers can possibly give me.

    Then there's the testing argument. He (as most proponents of dynamic typing) says that you have to write tests anyway so why is it important that one part of that testing is performed at compile time by the compiler? One answer is that we have to deal with two fundamentally different kinds of errors: (a) errors that are inconsistencies _within_ the code and (b) errors that depend on the state of the system at a particular point in time and thus are non-deterministic. The first kind of error can be found automatically by an algorithm that can be proved to be correct and complete. The second kind of error can never be proved to not exist. The only thing we can do write a heuristic that gradually reduces the chance of an error. Now, if I can get formal proof of something, why in the world would I want to write lots of test code to try it out? I mean would anyone write a program that adds 1 to millions of even numbers to make sure that the result is always an odd number? That'd be kind of foolish IMHO. However, a question that is not foolish is if the kind the kind of statically typed variables that we have in Java or C# are really the best way of enabling the compiler to do the static checks we want. I'm not sufficiently familiar with all the modern compiler science to say anything about that. What is this type inference thing for example?

    The other issue I take with his argument is concerned with the readability question. Someone in the audience asks about Perl and Bruce says it doesn't scale because it's too succinct to be readable wheras at various other points he emphasises the importance of the amount of finger typing that is necessary to achieve something. Now, that again is something I don't find very helpful. There needs to be a way to express the concept of readability a little better and in a less subjective way.

    First of all I would prefer to separate two aspects: What information is actually there and how is this information expressed syntactically. Sure, the line List list = new ArrayList(); needs less finger typing than List<Person> list = new ArrayList<Person>(); and the first is easier to read as well. But this is because it contains less information. Dynamic typing fans simply say I never need this kind of information. But that's clearly an over simplification. Sometimes you need it and sometimes you don't. You probably don't need it a lot while you are in the process of writing green field code. When I write code, most of the time, I'm working on just a few methods of a few classes. On average, I believe I have about 10 files open in my editor. And in the beginning I change them a lot and all the types get in my way because I change base classes and interfaces and I remove and add a lot of methods and quite often objects are simply passed on from method to method so their type is completely irrelevant but the compiler still wants me to keep it up to date. Now with generics I have even more of this 'useless' type information all over the place. I have to say Map<String,Person> over and over again although I know already what this map I have been staring at for hours and hours contains. So this situation that you have in the first phase of software production is clearly the source of the "I don't need no stinkin types" sentiment.

    But later, when I read my own old code or even someone elses code, types are a life saver. Code without types reads like a story without general terms: "Yesterday I got on a ? to go to a ? called Toxteth. On the ? I met a ? who asked me if I knew about a ? where we could have ?." Pretty ambiguous, don't you think? :-) So when I read code, I have to find out what types of things I'm dealing with. I might know some context that helps me to infer some of the missing types and of course a proper naming strategy can help a lot but if I still cannot infer (or guess) the types and have to find out, that becomes a really messy thing because I need to hunt down the points where objects are created which may be in some completely different part of the system that I never wanted to learn about in the first place.

    My conclusion is that dynamic typing makes sense within the confines of modules that a single person can easily understand. For example I wouldn't have a problem if static typing was used only in the public parts of classes but not in the private parts.
  20. I am developing with Java almost 5 years and the notion of static typing was always a good thing for me. Yes, it makes code more readable, but a motivation behind dynamic typing, as much as I can say now (I've never used dynamic typed language, but I'm looking at the Python now to get a feeling how it works), is that you define a type of an object by virtue of using it the way you except it would be useful. I mean, if you have a method to pass a parameter to, you surely will know how to use it whithin that method, so you define the type and you don't care explicitly marking the type as we do in Java. This is almost like TDD, you test the object using it whithin a method, you define it's behaviour. But that's just my thoughts at the moment after seeing the video, I really don't have much experience with dynamic typed languages (but I will:)).
  21. I think it is very trivial to decide and there is no problems with both ways,
    if you write shell script or some utility for text processing or to copy blobs aka files then you do not need any types and any scripting language is better for you than JAVA or C in this case.
    But if you work with typed data aka database, then you need types and JAVA or C is more usefull in this case. Readability is the mater of taste and it is not a good motivation to choose programming language.
  22. I agree about the fluff[ Go to top ]

    I agree about the fluff and I can vouch that it comes from Eckel being infected by the Python-virus.

    Python really is something else and the general philosophy of the language is that types are not really necessary if you have really clear code and correct separation. This, though natural for the Pythonista, is quite a hard sell to people used to static typing. I have experienced it myself trying it on the Java folks we have here. I got the same objections as are given here.

    I was hoping that Eckel could back up the dynamic advantages with the clear writing and examples I am used to getting from him. But for now he doesn't. I really hope he writes something like Thinking In Python book where delivers on this.

    I can say that reading other people's Python code it is very easy understanding what goes on. Easier in my experienc than in similarly functioning Java code because there are much fewer levels of indirection and interfacing and much less verbosity.
    The fact remains that the only big application I know of that is written in Python is Zope. Granted Zope is big and complex and it does seem to work pretty good. But I haven't seen much other Enterprise grade material.
  23. Python-virus infection[ Go to top ]

    I agree about the fluff and I can vouch that it comes from Eckel being infected by the Python-virus.
    .
    Correct-me if I'm wrong but He uses python late binding and C++ templates to compare with Java generics.

    He didn't say don't use java go for python. Python-virus infection is very bold for a presentation of strenghts and weakness of a language. Something that is very trivial.


    Regads,

    Geraldo Lopes de Souza

    (Sorry for my english)
  24. Python infection[ Go to top ]

    Correct-me if I'm wrong but He uses python late binding and C++ templates to compare with Java generics.
    Generics aside he also went into some more discussion and controversy about the dynamic (late binding) vs. statically typed languages.
    He didn't say don't use java go for python. Python-virus infection is very bold for a presentation of strenghts and weakness of a language. Something that is very trivial.
    His advocacy (or wasn't he?) of dynamicity is pretty symptomatic for someone (just) converted to Python. If you have been stuck with languages like C++ and Java the freedom of Python's dynamic typing can come very refreshing (I had the same experience). I don't want to turn this into a Java/Python debate, I'm just mentioning my observations.
  25. Python infection[ Go to top ]

    And what about Groovy? ;-)
  26. Python use case[ Go to top ]

    Python is not for Enterprise and there's no doubt in that. It's control language, integration tool, quick and dirty, there's no intention to swallow Java with Python.
  27. Now that I have taken a look at the generics for the first time, I have to agree with Bruce. The Java generics are really just an automatic type casting mechanism and have nothing to do with true 'templates' like they are called in C++.

    The fact that you lose your type information after compilation is just too bad, and in fact, might cause more trouble than breaking the byte code backwards compatibility itself. I am especially concerned about the 'excuse syntax' introduced to generics only to to get around the lack of type information at runtime. In other words generics try to be like C++ templates but in process introduce really cumbersome and kludgy workarounds that make the whole generics idea less than the sum of its parts. Quite honestly, I do not need automatic type casting at the expense of all these kludges.