Re: Setting up a Java development environment the debian way.
Le mercredi 22 juin 2005 à 16:05 +0100, Alan Chandler a écrit :
> On Wednesday 22 June 2005 14:48, Aurélien Campéas wrote:
> > Le mercredi 22 juin 2005 à 08:01 +0100, Alan Chandler a écrit :
> > > I am a complete newbie as far as java is concerned.
> > Then, allow me to question your choice of Java as a web development
> > language & platform.
> > Are you a newbie wrt Java the language ? or Java the web dev tools ?
> I am a newbie for both
I would be interested, then, in having some feedback from your progress.
Do you intend to take notes along your way in this project ? (sure,
debian-user is not an adequate place, but some blog can be sufficient) -
but off course don't feel obliged to do that :)
> > If so (if either ...), and if this is for a pet project and not mandated
> > by the corporate drones, why not have a look at some excellent, 100%
> > free, alternative languages & platforms ? I can cite a few :
> > python / zope, quixote, ...
> > ruby / ruby-on-rails ...
> I did take a long close look at ruby-on-rails. See below for why I convinced
> myself not to take that route.
> > Guess what, for a good part these frameworks (and the choice of their
> > mplementation language) have been made by people disgusted by the Java /
> > J2EE / whatever way of doing things. They are more lightweight and
> > pleasant to use. Do yourself a favor, don't go the Java way ;-).
> Let me give you my reasoning for thinking about going down the java route.
> First. I have worked for the same system development company for the past 33
> years. However the last time I programmed commercially (ie I was paid to
> write software) was in about 1978 (in PDP 11 assembler). I was probably
> still very technically involved with software development during the 1980's
> when I was head of a product development unit in my company and and remained
> responsible for the strategic technical vision for the product. In mid
> 1990's I started moving over to becoming a business expert (in Electricity
> Competion), and although I did some data and process modelling as a way of
> understanding requriements, I have not done any technical work since.
> Two. Because I do no technical work at work - although with a technology
> company - I play with the technology at home. It has become my hobby
This goes against Java for sure ... (I'm sure everyone there understand
it's only my opinion : flame disclaimer).
> Three: I am very much at the front end sales and bidding process. We
> frequently bid applications requiring web front ends to a database, the core
> software which we use and then enhance is almost always a java servlet/JSP
> implementation, which I don't properly understand the issues of. I would
> like to understand better the technical nuances of what is being bid - and
> understand what is hard and what is easy to do.
Good. Then indeed, go ahead and try the Java way. But don't forget that
while you will be able to discover the problems with the Java way on
your own for sure, you will see more of them when you will have tried
some of the branches of the alternative.
But you can obviously only do one thing at a time.
> I have heard the arguments (specifically the ones suggesting using ruby on
> rails) which I only partially buy into (ruby terseness seems partially to be
> lack of type checking - does this really work in industrial strength
> application development?) but I have no frame of reference for the the other
> side of the argument.
Can you define "industrial strength application development" ? It would
help a lot frame an answer on this.
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).
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
> So I have two reasons to go java. One to understand what technical people at
> work are telling me, the other to really understand the other side of the "my
> programming language is best" arguments.
> But I will go the Ruby route if this doesn't work out. But I have to try Java
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"
* 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
* 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.
Sorry for the little rant, and have a good trip through whatever you
(oh yes, one more : when you investigate ruby/python ... remember that
these languages are only the shadow of something more vast, like a
continent ... named Common Lisp. Have a look at
http://www.gigamonkeys.com/book/ which has been written by a former Java
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.