On Wed, 2005-06-22 at 18:21 +0200, Aurélien Campéas wrote: > Le mercredi 22 juin 2005 à 16:05 +0100, Alan Chandler a écrit : > > > > For the record, the static typing in Java is acknowledged as one of the > worst imaginable (in short : it is mandatory but you have to go through > its backdoor (read : defeat it) all the time to make working programs).
It still provides more static type support than completely dynamically-typed languages like Ruby and Python. And if you use "generics" as provided in Java 1.5+ then this problem is resolved. > > OTOH, Working programs have been written in dynamically typed languages > for ages. Yes, industrial strength programs (whetever that means). > > And I don't know any serious study about this topic. All we have is > anecdotal developper experience/opinions. But you will be able to judge > how important is static typing by yourself, again, when trying > ruby/python/lisp ... This mail list isn't really the proper venue for this discussion so I'll just make one reply then shut up. All the following is of course just my opinion. Ruby/Python are excellent languages where the developers on the project are experienced and talented. However this isn't usually the case with any "industrial scale" development; the normal corporate IT department has people with a wide range of abilities, and in that situation the support of a statically typed language can be very useful (IMO). And anyway it is *extremely* difficult to sell non-technical management on development in Ruby/Python. Java's marketing has, however, raised its awareness level to a point where the senior suits will actually consider it. So from a purely practical point of view, if you are interested in learning tools that will be of use in a commercial environment then Java is much more useful to know than Ruby/Python. > > There is an aspect of Java that is quite misunderstood : it is a good > language / platform not because of some technical merits (it is really a > rehash of 60's technology) but because of the division of labor it > allows in the industry (and some other "social" or "political" > properties) : > * separation from the designers (or so-called software architects) that > draw UML pictures and the coders (so-called code-monkeys that do the > supposedly unintelligent translation from high-level pictures to PL > level) > * mass availability of Java programmers (thus supposed > interchangeability of those) > * good marketing pressure from Sun and other big players to make Java > the new COBOL > > All the hype about Java being an OO-language (a very poor one indeed) > and bringing encapsulation to programming in the large masks the fact > that the big organizations that use Java need to encapsulate, indeed, > the many mediocre (read : insufficiently trained on theoretical and > practical levels, thus cheaper) programmers that make their huge dev. > teams. I pretty much agree with this. Java is a middle-of-the-road compromise language. I don't think it's "a very poor" OO language, it's an average one. The only revolutionary thing about Java is the fact that it compiles to portable bytecode (well, it isn't actually the first to do that either). But, in a twist of fate, in Java's "server" niche that is almost irrelevant. And J2EE was horribly over-complicated, a fine example of design-by-committee. However under pressure from alternative nicely-designed frameworks like Spring and Hibernate, J2EE is becoming more streamlined and easier to use. J2EE 1.5 should be a significant improvement over the past. The servlet spec was always a nicer beast, simple and focussed, and hasn't changed much since its first release. And the Java language underlies all of these. Re Tomcat/JBoss: applications should always be separated into "presentation" and "business logic" parts. This allows experts on the "business logic" to work on parts without being concerned about how exactly the information is presented to the user. And it means that the presentation can be updated/modified without any concerns about breaking the critical business logic. In large industrial systems, "business logic" is implemented as a set of "Enterprise Java Beans" (EJBs). And the presentation is implemented as servlets/jsp-pages. Sun have published separate specifications for these two parts: the servlet spec and the ejb spec. And the two combined is called "j2ee". Tomcat implements only the "servlet" spec. JBoss implements the EJB support stuff itself, and incorporates Tomcat to deal with the servlet part (or Jetty which also is a project that just implements the servlet spec). However where there is little/no critical business logic in an application it is possible to use just the servlet level functionality to implement the application. So Tomcat (or Jetty or other) can be used on its own. And that is probably where you want to start - servlets are not trivial, but EJBs can be very complex to use. Anyway, you should probably start by buying a book on servlet development which will discuss all of this. Other sites you may wish to investigate: http://myfaces.apache.org/ http://struts.apache.org/ http://jakarta.apache.org/tapestry/ http://incubator.apache.org/beehive/ NB: the large number of frameworks that exist to "simplify" servlets and EJBs may be taken as an indication that the original specs weren't entirely up-to-scratch... Regards, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
