Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

A voice of reason. It is refreshing to see a diffrent viewpoint in this time of Java craze.
In my own experience (and I work for a web development house) you can cut down time of development by factor 5-10 using a weakly typed scripting language such as PHP.

Why is J2EE always forgotten about when it comes to Java? I dont know of anything that comes close to J2EE.Try to have transactional management across different operations on Solaris, Linux, Windows, etc., with Oracle, IBM Mainframes, etc. Now add a new database vendor, switch a few Windows boxes to Linux boxes, etc. J2EE makes all this much easier to manage and cope with.Seeing these elements run in 'containers' the objects are already started up and waiting to service...wrecking your 'java is slow' arguement.

True story: I was working for a startup in 1992 that needed to get a product to market in record time with minimal resources. The product was not a piece of software, but a simple Windows utility was needed to control it.

The utility was not very large and manipulated only very small amounts of data, but it needed to be easy to use, reliable, and look and feel like a good "commercial-quality" Windows application. The total number of hoped-for installations was to be in the low two digits.

I chose VB as the development system, which at that time was almost brand-new, to implement the software. I got it done in time--about nine months. It was a beautiful candidate for rapid application development. During the development, we added many features and change the UI many times in response to user testing and management requests.

It worked well. I am not aware of any problems with it, with respect to performance or UI, other than a rather slow startup time (about 30 seconds on the hardware of the day--which was an 80386SX running at, IIRC, 33 MHz).

I left the company, the company was bought by a new set of VC's, they hired a new software developer (who was absolutely first-rate).

The VC's insisted that the software be rewritten in C++.

There's no real punchline, because after two years of work the new developer succeeded in converting the program, and adding some new features (relating to minor changes in hardware capabilities). Neither I, nor the programmer, nor anyone at the company was aware of any real gains from the recoding, other than the ego satisfaction of knowing that they were using a "professional" programming language.

In my next few job searches, the hiring manager looking at the part of the resume where I described this work experience skipped over the "successfully completed on time" part and focussed on the "Visual Basic" part. It seemed as if the appearance of VB on a resume practically erased all my experience with other languages.

Of course, PERL and friends, being associated with the academic and UNIX communities, don't have quite the same aroma to them.

Nevertheless, I was very struck with the amount of damage to one's career that one can do by doing topnotch work, but using the "wrong" programming language in which to do it.

I think you miss the point. Before you go back and re-read the article put aside your obvious bias. The problem he was mentioning was that Java is not the right language for every situation. He was stating that you need to understand what you need to perform the job and use the right system. In cases of web-side solutions he is saying perhaps Java is over-kill.

I've written software in C that has been ported with little effort from one hardware platform to another with less effort than I have seen of many Java applications. I might suggest C is the language of choice for programmers.

OK, I guess I need a programming lesson then. For a database driven application, how do you propose not to have hardcoded SQL statements? Have the SQL statements looked up in the database or something? And how would you do that without hardcoding statements?

I've never seen anything as bloated as Java apps like NetBeans, Forte or WebSphere Studio. I've seen NetBeans use 200-300 MB of RAM and WebSphere Studio use over 600 MB of RAM on my machine. They had to upgrade all the machines in our group from 833 MHz with 512 MB to 2.4 GHz with 1 GB and WebSphere is still the slowest launching app and biggest memory hog I've ever seen.

I would use an automatic SQL statement generator. Why? Because:1) It would prevent people from decompiling my code and just "seeing" exactly how the database is set up. Yes, you could still figure it out, but it would be less obvious.2) More importantly, as things change, the queries could easily change with the system without having to go through and change every single instance in hard-coded strings.There are easy and hard ways to make an automatic SQL generator: the easy way, as it most always does, would yield a larger, more obfuscated generator, while spending more time in design should yield a more optimized and quick generator. If you want source, hire me.:)

The point is that most programmers use Java because of its premise of programmatic power. While the metaphor may not stretch to every use of Java, Greenspun talks particularly about WebApps in general, and JSPs in particular. His only point was that while Java *is* powerful, for a low or mid-end Web application system, most of the engineering has to do with designing the database correctly, and integrating everything tightly. Perl and PHP are widely used because they're not as verbose in such situations, and a more powerful language is NOT needed at the presentation layer, and Java _is_ infamous for its boiler plate requirements.

This, and this alone, is why he likens Java to SUVs, because of the metaphorical holier-than-thou driver, who buys into a $100k Hummer because supposedly it can handle hardcore 4x4ing, but in reality knows it's only driving to Bed, Bath, and Beyond and back. Personally, I'm not often a detractor of Java, but I have worked a good deal with Perl for such things, and in this respect: I agree with him.

I don't want to start a holy war here, but what IS up with you java fanatics. I have been waiting here on my Spark Station Ultra 5000 for 20 minutes as my java database attempts to replicate a 17 million row table. 20 minutes! At home, on my AMD athlon 2000+ running Mandrake linux with postsql the same operation would take 2 minutes, if that.

Also, while this is happening, Oracle won't work, and evertyhing else screeches to a halt. Even jmacs (JavaEmacs) is struggling to keep up as I type this.

I won't go on into the laundry basket of other problems with this machine. My packard bell 450 running slackware and Mysql lite runs faster than this machine at times.

Java Addicts, flame me if you like, but I'd rather hear some intelligent reasons why I should use Java over faster, cheaper databases.

However, I currently am working to migrate our PHP web application to Java and it is going well. I am using Servlets + FreeMarker templates. Using a template system allows me to change some of the presentation details without recompiling and Servlets prevent me from killing myself because of the giant nasty hack that is JSP...

Yes, I might seem bitter but I can see no real reason to use JSP. The only argument I can get from anyone on for it is "You don't have to recompile and deploy it". That was a good point before application servers accepted changes on the fly to the code. Now I just recompile the one servlet and Tomcat reloads it. Simple...

we developped a SQLRepository object which stores sql code and definitions in an xml file...
This file can be packaged together with the jar or an external url... It could be possible to transfert it via secured https to prevent the user to see db structure...

He's obviously never had to maintain large perl programs. Given the potential for pitfalls (synonyms are shite, scoping is just pure bollocks wrt $_, I've met precious few people who know what local means, even if it is written in the book - having two mechanisms for scope - just how does that work then?), I wouldn't use Perl for anything bigger than a 100 lines, even then it would have to be "throwaway".

$_ doesn't matter on a small level like that but $_ with a couple thousand functions and various programmers meddling at intervals, not at all entirely contiguous and it'a recipe for disaster. Been there, done that. Never again.

If someone were to say to you "I'll just write this little script, it won't take me long" I'd advise that you either (a) fire them or (b) run for the hills. They have no idea what they're doing. In the long run, all you get is grief.

Well, I worked at a project with no hardcoded SQL. It was a bitch. It happened because the client would NOT provide ODBC link to the DB. Therefore, we needed a middle server that got "request for X service with Y parameters", looked up in it's own service table what query that was, made it to the DB server, and returned the results in XML.

The biggest drawback is the fact that the queries are stored in varchar fields in a table. All the queries used by the system (a nationwide chain of gas station managers). So, when you where inserting or modifying a service, you where doing things like "insert into services values... 'select blah from blah where blah=''... " and you had to start escaping characters like mad. And a missescaped quote would leave LIVE SQL in the SQL command... I saw a case where somebody had a bad escaped ", so the "where" clause was included into the string... he wiped out ALL the functions:o

Graham's article is a load of crap. Not having any factual information to say, his arguments against it are:

1) It's bad because it's energetically hyped. Unlike Lisp, where no one uses it because everyone is too busy posting on comp.lang.lisp about how wondeful a language it is?

2) It's aimed low. Gosling has already called bullshit [java.net] on this argument.

3) It has ulterior motives. So what?

4) No one loves it? Well, those of us who used to use C++ appreciate it a hell of a lot.

5) People are forced to use it. Wrong. Countless companies choose it because it is an appropriate technology.

6) It has too many cooks. I find this a huge advantage to Java. It means their API's very well thought out. It's why Java is nicely internationalizable, for one.

7) It's bureaucratic. Their API's are no more verbose than many languages. Any "bureacracy" that exists is to promote flexibilty.

8) It's pseudo-hip. Like quoting Paul Graham.

9) It's designed for large organizations. True, because large organizations have to do somethign more complicated then the typical perl script can handle. His arguments here are debunked by Gosling in my previous link.

10) The wrong people like it. That is, Paul Graham's friends don't like it, people Paul Graham doesn't know like it! What an argument!

11) Its daddy is in a pinch. I fail to see how this is relevant.

12) The DoD likes it. The DoD also likes the internet, they were one of the first government agencies to really take to it. Does that say something bad about the internet now?

Comparing Java to Lisp or (ugh) Perl is a joke. Well, I think perl is very ugly and counter-intuitive, so let's take Python as an example. If I were to make a simple website, i'd use Python instead of Java. If I were to do a hacker type of activity, something that may not be around 3 years from now, I'd use Python. Or even Lisp if it was something just for me. They'd be wise choices. However, for an enterprise app? Java is an excellent choice.

I know with Java I can write an application with DB connectivity and a GUI and have it run on AIX, Windows, and Linux. Without having to change a line of code.

Now I know it's possible to do this with C (Actually, is it? Is GTK available on AIX? Is GTK any less horrible on Windows than it used to be), but it'd take much more time, and I'd end up with all sorts of conditional code based on OS.

I might suggest Java is the language of choice for programmers who have jobs to do, need to write tight code, and don't have all the time in the world.

We're using PHP to connect to different sort of backend databases and other services. We used mostly Oracle in the past, but have made a move to Postgres mostly due to the cost. We're still using Oracle for clients who are willing to pay for it.

My most recent assignment was using DB2 on an IBM iSeries machine (formerly known as AS/400).

PHP can and is used to develop "enterprise" size web applications. It doesn't have to be Java. And I can been the cost of any Java shop around here.

It might be helpful (for those who don't know) to learn a bit about the ArsDigita experience with Java. aD was philg's old company and developed a toolkit (the ACS) based on Tcl and Oracle. The software was a bit kludgy in many ways but had the advantage of being fairly scalable and written close to the database, so you could tune the queries and generally figure out what was going on. The lack of typechecking in Tcl didn't matter too much because SQL queries and stored procedure calls are checked at compilation - and besides, if you keep the edit-test cycle down to under a second you can quickly find bugs.

The rewrite of the system in Java, based on using database abstractions and (would you believe) HTML abstractions was a complete crock [membled.com] and ended up being not only slower than the Tcl/SQL version, but less maintainable and much more buggy. I think they got something out of it in the end, after dropping 90% of the extra complexity and object-oriented-itis, but there's no way Java plus an object-relational mapping layer was the right implementation language.

OpenACS and Java [openacs.org] makes a similar argument to philg's, but more coherently and less trollishly. I agree with his essential points however. And what he writes is based on experience, both with managing a web development company and with teaching students.

Depends on the application. Check out JDO (Java Data Objects), Hibernate, and Castor. They are all OO->DB frameworks. Your app works with objects, and all the various things objects have, properties that return scalars, properties that return other objects (relationships), properties that return lists of other objects. They map those onto DB statements, which may be generated at application start in a fraction of a second. Usually you build your object model, and then an XML file or two describing the relationships between your objects, and it Just Works. The XML can be autogenerated from the classes themselves if needed.

You would be suprised how many "robust and power applications" do not in fact require much out of SQL at all. Hence the various pushes/ideas with object databases.

Now, if your app is a large reporting app, doing massive SUMs and GROUPings, sure. This doesn't cut it. But it's amazing how the majority of apps just manipulate a set object model.

In about 1997, Phil Greenspun wrote in his How to be a Web Whore Just like Me [greenspun.com] book in Chapter 8 [greenspun.com]:"You should learn Java. I predict that it will gradually supplant C over the next ten years. Java is going to be big. You heard it here first."

In this particular post, he is not saying that Java is not ever useful or practical. He merely states that people who develop in Java are often using a tool that is not especially suited to the task -- that it's not always the right tool for the job. This is exactly like a single guy who does nothing with his SUV except do a one hour commute to work and home -- it works, but there are more practical solutions.

I guess I shouldn't have been so zealous in my hatred of JSP. I am by no means a purist. Hell, I was primarily a PHP programmer. My hatred for JSP comes from seeing the horrible nasty code that the so called "java experts" in another programming group at my company write. I guess I should remeber that even evil things (JSP,.NET, Broccoli) can be used for good.

While I think Phil exagerrates the cost of a Java solution over a scripting based solution, he does hit the nail on the head with Java's dearth of support for named bind-variables and flexible SQL support.

This is more cultural than technological. SQLJ has been available for years and handles bind variables in the same way that C does. But nobody uses it.

There's a tremendous distaste for SQL databases in the Java community. A major component of the Java community seems to have evolved out of the OO purist / Smalltalk view of things that view relational databases as an abomination to be avoided, or at least wrapped and hidden with an object-relational mapping layer. This is due to many varied reasons: dealing with objects alone is very empowering, and becoming an expert at SQL and relations is a discipline unto itself that many Java developers choose not to undertake.

If one DID actually try to learn the technology behind SQL and databases like Oracle, they'd discover a tremendously powerful engine for storing and retrieving data, that doesn't necessarily require elaborate model-view-controller architectures for good maintainability.

Simple web applications can be written with packages of stored procedures and a minimal data binding framework to JSP pages in a snap. In fact, this seems to be the approach ASP.NET and ADO.NET has been taking. Apple's WebObjects took this approach too, though with an object/relational mapper underneath (and "Fetch Specifications" instead of , or in support of, stored procedures).

Struts was the first real stab at a good data binding framework for JSP and is wonderful, but generally wasn't dynamic enough until the introduction of the DynaBean.

In summary, I think Java can definitely achieve the productivity levels of PHP and Perl, but the default recommendations from Sun are not the approaches that lead to these levels of productivity. I would suggest that the learning curve in Java might be higher to achieve this productivity, but it certainly is possible.

But I also think that the Java-based techniques do tend to favour a certain level of modularity that PHP and Perl and traditional VB/ASP based approaches do not favour out of the box, thus leading to a very unmaintainable approach. I think the Java community over compensated with "too much" modularity, but there are signs this is calming down.

" AMD also uses GNU Common Lisp and ACL2 internally, though they can't reveal any specifics - this is of course the problem with a language that's suited well for the research and development part of the product phase. Who wants to give away what they're doing just to advertise that they're using Lisp?"

ACL2 is a theorem prover written in LISP. They're using it for processor correctness verification [google.com]. They approached J Moore about that when the notorious Pentium bug blew up in Intel's face, and they didn't want to repeat the episode themselves.

Wow, somebody's still using that thing. 20 years ago I headed a group to develop a proof-of-correctness system that used the original Boyer-Moore theorem prover, along with a Nelson-Oppen type prover. (See "Practical Program Verification" in POPL '83) "ACL" stands for "A Computational Logic". Boyer and Moore went to considerable trouble to formalize mathematics in a completely constructive form, with a theorem prover to prove the theorems.
It can build up number theory from something close to the Peano axioms in a few minutes.

It's a very elegant formalization. There's no "forall" or "exists", which eliminates many philosophical tangles. Induction is done by recursion, and you have to prove that the recursion terminates by showing that a nonnegative integer metric decreases on each recursion.

Years later, after object oriented programming came out, it became clear to me how to merge Boyer-Moore theory with object theory. Boyer-Moore theory doesn't have "hiding", and it needs it. Shells should have private and public functions, and if an object cannot be distinguished via the public functions, it should be considered equal for proofs that use only the public functions. This allows fixing up the mess with constructive set theory without adding more axioms.

What?
I love Java. There I said it. Of course script kiddies love their languages. What else do they know? I think Paul Graham should try building an enterprise app in java before hes starts spouting mostly foundles criticisms. Most of the people who have nothing good to say about Java know fsck all about it. This holds true for most people's views on languages/technology. Ignorance is bliss, write an article!

Java has lots of type-checking, etc. that's usually unnecessary for my simple reporting/collection of database data.

Thanks, I needed a good chuckle. I look forward to reading about your projects in future issues of RISKS digest.

Plus imho Tomcat is a pain in the ass to configure, and you gotta keep javac'ing, and so on.

Yes, Tomcat sucks. Use JBoss. (Or even JBoss with tomcat pre-embedded.) Also, learn how to use Ant. I type three letters and hit return and the system works out all the dependencies, compiles any files necessary, syntax-checks XML descriptors, bundles everything into jar, war and ear files as appropriate (building the jar descriptors for me), and deploys the final single archive file onto my web server. Then it prints out the URL to click to test the result, in case I've forgotten it.

Don't assume from my posting that I'm in any personal hurry to learn VB and PHP! But having so many bright young people in 6.171 gives one a fun opportunity to take a high-level look at the programming tools of the moment.

What would I personally prefer to use? The same thing that I would have wanted to use 10 years ago: Common Lisp, CLOS, plus an ML-like type inferencing compiler/error checker. I find this preference, shameful, however, and try to keep it concealed from young people.

Just yesterday I ran into a friend. She's a 23-year-old graduate student in computer science at Harvard. Conversation rolled around to programming tools. Unprompted she said "What I think would be best is Common Lisp Object Systemw with a modern type system". I was stunned. I thought it was only dinosaurs like me that clung to Lisp.

I had a second ephiphany for the week... Believing that Lisp circa 1982 plus some mid-1980s ML tricks thrown in is better than all of the new programming tools (C#, Java) that have been built since then is sort of like being a Holocaust denier.

I have been running a multi server site with resin for a few years now. I haven't seen any of the versioning issues that you mention, even when I converted from Apache/JServ jdk1.1 to resin jdk 1.3.

I do think that the full 3 tier setup is probably a pain in the ass. Maybe a lot of people are resorting to this complexity without reason.

Moving to a war deployment was the best thing we ever did. We have an ant script that checks out the entire web app from cvs, tags the tree, compiles the app, tests and deploys the war to our staging server.

I have found that Java web apps can be more fragile than say perl/CGI so you have to take care , but the advantages for complex sites outweigh the problems.

Or various other ways. The idea is to map the logical functions into the object model so that the code does not have to be concerned with the underlying data model.

getOrders() returns an object that implements List. size() runs a COUNT query..get() runs a select. This can be lazily cached very very easily (most object persistance frameworks support caching and lazy objects).

This instantly allows the object model to fit into your existing programming methods. This means that getOrder() returns a real Java list, just one that happens to transparent run SQL queries on access. It would have all the common functions a List does, size(), iterator(), etc. Depending on the type of relationship.

Yes, this is overhead. However, it's amazing how fast it actually does perform, thanks to intellegent caching which you do not get for free writing raw SQL statements. Caching of course depends on your implemention. Would be hard to cache if you were running a cluster of boxes. You get the point.

Part of your mapping defination is weither or not the getOrders() list should fill on creation of the category, or weither it should fill on access, or weither it should fill in blocks of 10 or 20.

We developed a multiplatform system (originally Linux, now Solaris) that is the equivalent of having a c backend and a php frontend that has no hardcoded SQL queries in its scripting or core levels and handles server high server load on a single machine. This system was written in under 4 weeks, and supports LDAP, JDBC (Any Database). It has connection pools, content management / access control, reporting, threaded handling, caching of data (the list continues)... We did it!