Why Java would still stink even if it weren't security swiss cheese Java is horrible and I hate it. Good, now there's a strong intro: attention grabbing, and it gets the natives all riled up. Sadly, the extremist sentiment of my statement is not that far from the truth. Hating or loving a logical construction such as a programming language is irrational, illogical and otherwise nonsensical. As …
"I wrote a few crappy programs in Java that could do some basic things. After a year or so of this I then decided that I'd much rather do anything else other than be a developer for a living."
Yeah, so is Trevor even writing about this?
Next article: "I hate X not because there's anything inherently wrong with the X, but because of a decade's worth of people who still haven't figured out how to use it as designed."
Ok, so you hate Java. That's fine, but you don't then tell us what it is that you love. FAIL.
The problem isn't the language, it's the people doing the programming and deployment. Worrying about library/runtime versions is just part of the business and happens with every programming language I've worked with. I have to say that Java was no better or worse than the others in that respect.
I never said Python was the best; I lack the diversity of experience to reliably choose a "best" language. Of the dozen or so that I, personally code in - including Java - Python is the one I enjoy coding in. Mostly because I enjoy the diversity of use cases for the code. It compiles - so I don't need an interpreter - and yet I can also use it as web scripts, shell scripts, etc.
It is a simple language that is easy to learn, code in a maintainable fashion and addresses all of the use cases I run across on a regular basis.
It isn't "the best," but it is my favourite.
"Whitespace as syntax? "
I really like python as a language and given that its done a good job of taking over perls former niche of general purpose unix scripting language I'm not alone.
However.... I must agree that the forced indentation is a REALLY poor design decision. I know why Guido did it - to force a common format on everyones code. But what it has resulted in is people accidentally deleting some whitespace (easy if some idiot has only used 1 or 2 spaces) moving an end of block line outside of the block it was in but leaving a program that still apparently runs but now has a potentially serious bug. Also it makes it harder to spot the ends of intermediate blocks when looking at code.
Its not just Makefiles - Occam suffered from it to. Some lessons are never learnt.
However.... I must agree that the forced indentation is a REALLY poor design decision. I know why Guido did it - to force a common format on everyones code. But what it has resulted in is people accidentally deleting some whitespace (easy if some idiot has only used 1 or 2 spaces) moving an end of block line outside of the block it was in but leaving a program that still apparently runs but now has a potentially serious bug.
But it's just as easy to make mistakes with curly brackets or the dangling "else" in C or similar languages! And worse, you don't know where you should be looking for the bug. The curly brackets may not be where you expect them in your coding style. If it's an editor flub, they may not be where anyone expects them in any widely used coding style.
I didn't like Python indentation-as-syntax when I first met it. The dislike lasted for a few hours, acceptance lasted the next couple of days, and then it blossomed into love.
"But it's just as easy to make mistakes with curly brackets "
No it isn't. You delete a curly bracket from a C/C++ program and it won't compile (unless you've accidentaly inserted another elsewhere - and how likely is that?). With python you can accidentaly delete whitespace and quite often the script will still run. Except now it has a bug you don't know about and wasn't there before.
I'm sorry , but indentation as block qualifiers is a VERY bad idea.
One of the nicest things about curly braces for control in your code is that you can pretty print it automatically. Python is virtually impossible to refactor without extreme pain. For example, if I have a block of similar code at a couple of different places in a function and want to extract it in to another function, when I move the code I have to painstakingly make sure I get the indentation right. In C++ I can move the code and ask the editor to fix it (eg ctrl+meta+\ in emacs). If I've made a mistake in the process, the indentation will look off.
Personally, if I wanted to make whitespace a requirement in a language I would have whitespace AND control characters. I would be totally fine with a C++ or C compiler having a strict mode that failed on a syntax error if your indentation was inconsistent with the curly braces. That would have been the way I would have enforced whitespace requirements in Python.
On the other hand, as a rapid prototyping language it can be excellent. And I hate Python less than I hate Java (for all the reasons the article author said). For me, Java has failed the write once run anywhere maxim, but in trying to allow that it has crippled itself everywhere. I totally understand the reason why a lot of companies want to use a garbage collected language for general compute. Personally, I love C++ and if I'm going to write in a garbage collected language, I would probably pick C# ahead of Java. Unfortunately, I find both C# and Java limit me so much in the space of generic programming that I get frustrated with them.
The way python wants indentation done these days is just fine. The requirement in python is that your indentation is consistent. That is all. Originally python had a mandatory indentation style, but that is no longer true. And if you don't think consistent indentation of your code blocks should be mandatory, then you shouldn't be programming at all. Pick anything you want for indentation, but always use that within a given file.
If you want scary use of whitespace as syntax, have a look at perl. That's scary. <$foo> is not the same as <$foo >
If I had a penny for every time a Python fanboi criticized Perl when the conversation did not even involve it, I could retire :-)
In your example, the Perl scalar variable $foo is the same in both places, buy you just added an empty space after the second instance. What was your point actually?
I enjoy coding in Python too. Just wish it made it feasible to ship desktop apps built with it. WxPython was close to good enough for the GUI but the wrapping process was intensely painful (caveat, I haven't bothered looking for improvement in the last few years).
Exactly and I'll get hate for saying this but this reminds of all the hate VB 6 got. If you kept VB 6 targeted at its main purpose, writing front ends to local DBs then it was a perfect tool, in fact I've yet to see anything that ran as fast and used as little memory in that role.
The problem with it (and Java) is too many that didn't know what they were doing tried to use it for everything and made these big sprawling messes.
So its not the tool, its the programmer. I mean if you use a hammer wisely you can use it as part of a toolkit that will help you build a lovely home. if on the other hand you hand it to a chimp and let him loose in a bomb factory, should you blame the hammer when the whole place goes up?
the problem is the language, it's grown to be huge and far to complex with far far far to many bits to it. to a non java person it's practically impossible to trouble shoot. Yes runtime versions can be an issue but it seems to be a particular problem with java. I rarely have these sorts of problems with C and to a lesser effect in python
'Nothing more to say, just, "Thank you".'
I have to agree.
'Write once, run anywhere' was a ridiculous idea from the start. Instead of being all things to all platforms at all times as intended, it ended up as the software analogue of the adjustable spanner.
The only thing they're any good for is bashing people over the head with and even then there are other blunt instruments which are far better suited to the task.
I've see Python mentioned as an alternative but that suffers from the same disease. They both aim for universal portability without changes and there are a plethora of versions all in use concurrently.
In addition, Python also has another significant problem - the use of indentation level for block demarcation.
God only knows what the hell Guido van Rossum was smoking when he came up with *that* idea...
I certainly don't buy 'readability' for an instant. That sounds like an after the fact excuse rather than a conscious design decision.
There's a very good reason why C/C++ are so ubiquitous - A 'native' compiler suite and standard library specifically tailored to the target platform.
" 'Write once, run anywhere' was a ridiculous idea from the start. "
Indeed, I think these sorts of claims are one of the great myths of our times. I got bitten with the "portability" of C and learned quickly that not all ints are alike, and anything remotely OS-involving (which, let's face it, is pretty much anything beyond the remit of the standard libraries) is going to be "interesting" to program in such a way as to remain portable. It isn't impossible, but you have to be careful not to make too many system-specific assumptions.
Likewise, set your user agent string on Firefox to fake being the Android browser, and watch heaps of stuff fail (Google Maps, Google Groups, Flickr, Facebook, etc etc). Too many differences in the scripting.
You see, universal languages... there's the shiny theory and there's the dingy reality, the two are very much different.
I cannot see why indentation is harder to deal with than f.ex. squiggly-braces or ';'?
To me, C++ code looks like that pair of used knickers my dog ate and shat out three days later under great duress! Not something one wants to get involved with, even from a safe distance downwind.
Totally agree. Spring 3 three makes developing web applications a breeze. Innovations like Spring and Hibernate are starting to catch in in the .net world too. If you want to avoid reinventing the wheel, build your java projects with maven, it allows you to download thousands of free to use libraries to provide whatever functionality you can think of, including Spring and Hibernate. When combined with artifactory (a maven proxy) you can also create a library of your own reusable components. Using these tools can also encourage you to write code in a more reusable fashion. There have been some attempts to create a .net equivalent to maven, but I don't think that these have taken off, probably due to a lack of content. I can't think of another language that is so well provided for in terms of tools and libraries for avoiding reinventing the wheel!
Agree, but only about Applets, and the quality of your average graduate.
Disagree with AC above "Reinventing the wheel". Actually, that's C and C++ devs who are paranoid of using APIs (rightly so, no-one wants to core).
Disagree with the sentiment in general about Java. It's mature, it's fast, it has excellent APIs and I've worked on many a scalable, stable, ultra low-latency and high throughput algo trading system built on it.
Of course the admins don't agree. They have to guess which version of java needs to be installed to run the piece of crap, and try to make sure it doesn't conflict with the version of java needed by another piece of crap they already had to deploy. After all java developers don't ever tell you what environment they developed it for.
<rant> Lennart, Yes, yes, Yes!!! Have run 4 different versions of Java per server for each of the 4 security zones and all of them were memory hogs. The only fix for the regular crash, burn, recover and restart ? Shell scripts to monitor and restart when the crap died. Sure Java can run well and lightly, except the dumbing down of coding training means it never happens in the real world.
The idea of write once, run anywhere is complete fantasy, as M$ will find find out with Windows 8. On a super computer the OS is merely a way to run fortran/C code in parallel to solve a problem. User interface is nearly irrelevant. A consumer device is nearly the opposite. Any attempt to make make the code portable to a phone or tablet reeks of facist non-thinking. The nearest I have seen to write once, run anywhere that worked, was Cobol P compilers. This is a small defined space but it met a need and worked well. </rant>
The sooner the fantasy of one size fits all is dumped for a pragmatic approach applied to classes of machines' main use the better. Anything which increases security risks should be evaluated very caustically, like java. Disabling it on my browser because of crappy 3G network increased browsing speed significantly. In return security improved and annoying hanging applets vanished.
Well said, Trevor.
"...The idea of write once, run anywhere is complete fantasy,.."
I disagree. I'm a sysadmin, working for a softhouse. I remember a good case of "write once, run everywhere":
We (the company) were developing a system. The programmers were using (at the time, it's ancient history) W2K 32 bits. Some computers were 32 bits, another ones 64 - but the OS was always 32bit, with one exception: one programmer was using a 64bit Linux.
The test server was a 64 bit Linux. All of the machines above were x86.
The production hardware was a Sun machine, with a SPARC processor and running Solaris 64bits.
The code would run, without modification, in all machines. Yes, we compiled the code for the specific java version (even using 1.5 we made Eclipse compile to 1.4). And it worked, and worked well.
Now, I don't claim this code would run on a mobile - I'm not THAT insane. But it would run on Windows, Linux, Solaris...
"Write once, run anywhere" can indeed work. Assuming your programmers are hot shit and either A) restrict themselves to a very limited subset of the language or B) "Write once, debug everywhere."
It is possible to achieve the holy zen of “write once, run anywhere.” It is however enough work that you’re better of being a monk on a mountain for 40+ years. It’s more satisfying and less effort.
"""After all java developers don't ever tell you what environment they developed it for."""
The most commonly used Java programming idioms are:
#include <everything on developers machine>
#include <the internet>
Combined with run-time linking and automagick updates this diversity of libraries gives Java its "flavour"; The BOFH of course learns to sidesteps the issue by slapping the whole mess in a private VM and never touching it again once it runs.
At last a soul mate that shares my dread, not especially of the language, but of the write once run anywhere concept. It sounds fine on the face of it to say that we can write the app once and it will run just dandy on any platform but that has never worked in reality.
I love the move towards web based apps. It is almost done now, very seldom to we see job adds for desktop apps. However what is holding us back is that you cannot simply write a standard web app. Every web developer knows that the majority of his or her time is actually spent making sure it works on IE6 to the latest Chrome. So why do people imagine they can write one Java app and it will just work?
In all fairness, Java got closer to it (write once..) than many. Web based apps are just a whole world of pain, getting worse with the arrival of variously capable mobile devices.
Very rarely these days do I work for a client who has any illusions about '..run anywhere' - they have a list of target machines (usually wrong) and operating systems (outdated) and they'll fail to test across those combinations.
"Every web developer knows that the majority of his or her time is actually spent making sure it works on IE6 to the latest Chrome. So why do people imagine they can write one Java app and it will just work?"
To be fair, the cross browser problem has nothing to do with java in true web applictions (i.e. not applets), which generate HTML server side that is sent to the browser, but more due to the fact that browsers render HTML and CSS differently. Web applications developed in .net, perl, PHP etc will have exactly the same issue.
My experience of developing web applications, which I mainly deploy on Apache Tomcat, is that for the most part they do just work when deployed on JBoss or Glassfish, or indeed on Tomcat deployed on different OSes.
My exposure to write once run anywhere was relatively limited, but I did write a data distribution server using RMI and windows, and had no problems running it on Sun/Solaris without have to do *any* porting. Sure, I *tested* it, but only a complete tool wouldn't. Not only that, but the code worked across a mix of Solaris and Windows machines which could be updated from a single repository.
Frankly, if your developers don't adequately test their applications and do their version management, then perhaps you ought to be looking for better programmers...
Better programmers will cost more money, testing will cost more time - which is money! This is bad in a world where everything is transient and made after a competitive bidding process.
The users will not see any difference between the really good and the barely adequate code, it is generally an integrated part of the luser-experience for people to have web-thingies crash on them after spending 30 minutes entering the information. People do it again when they have to, or move on if they don't, new people come in to replace them. The web is evolving into one big drive-by business, you just have to capture enough of the "plankton" drifting past to survive, the artistic impression is irrelevant ;-)
How does one motivate management to spend from the $bonus$-cash coffer on better developers when a decent BOFH can hack around most issues using the free tools: Bash, VM's and an Apache load-balancer?
I would estimate that one decent BOFH can carry the can for a team of about 20 poor Java developers, the BOFH-pay is about the same salary as one developer, so the math is easy.
"The users will not see any difference between the really good and the barely adequate code"
Depends when it goes tits up. Just today I plugged my mobile into a photo-print booth. I had a couple of hundred digicam pictures (and associated thumbnails). What I forgot was the large pile of manga scans and the timed JPEGs for recording travel (a photo every few seconds with embedded GPS info). The machine tried to cope with ~8500 images, and after I selected about ten, the booth promptly crashed. The monitor program noticed and rebooted (was running XP!) and that took around ten minutes (my God, what ancient hardware takes that long?).
With it getting harder and harder to find 2Gb cards, and most worthy digital cameras being SDHC compatible, I suspect photos numbering thousands are going to be increasingly common. The software will need to be better than "barely adequate" for it can't crash just because it has too many thumbnails, and it sucks hard to be expected to navigate twenty photos at a time (that it insists on redrawing before it will permit you to tap on the 'next' button).
Which means ultimately this company will have to get somebody in to mod the software to do what it might have done in the first place had they had a better class of programmer from the start.
...that said, a regular feature on my blog is "nice hardware ruined by lame/crap/terrible firmware". It seems that all many manufacturers are interested in these days is the barest minimum that will fulfil the promises made on the packaging (um...mostly). Why make an awesome product when a mediocre one in half the time will do?
@Iggle Piggle: Surely you jest? Having done both (lots over years) Java Swing and (recently) Web App development (Tomcat/JSP with jQuery) I will take Swing anyday. Proper encapsulated, re-usable components, usable/simple layout containers, rich controls (tree's, tabs, data-grids anyone?). Commercially available components. Web-Apps don't come close.
As to Write Once, Run Anywhere? For client-side app's Swing mostly do the trick. If you delve into JNI then that's your own lookout, otherwise it pretty much does do what it says. I agree it has deployment and security issues though. But Web Apps? a complete PITA, you'll spend all your time getting it "just so" on the required list of browsers and platforms. Argghhh. jQuery, etc make it better but they are nowhere near perfect.
However, saying all that, Web App's are the future, for better or worse. The nascent Web Components work from Google (http://www.youtube.com/watch?v=2txPYQOWBtg) will, finally, allow grown up components (such as a tree - gasp) be a drop-in bit of markup not some cobbled together pile of junk.
Java Swing is on the way out, banks use it, but that's hardly bleeding edge. Shame. JavaFX (v2) also looks cool, but is probably too late.
I remember the good old days at Uni working on a Java applet game for my final year project. Back then (~1999) Microsoft were busy trying to sabotage Java by including their own Virtual Machine with Windows. Their Win 98 VM was an interesting beast in that it was much faster than the Sun VM but also much less compatible (for example Sun's VM would run the midi music in the game, the MS VM could only manage to play wav files IIRC).
Even better was Microsoft's VM on Win NT, which would randomly stop the for loops in my code whenever it felt like it, causing all sorts of odd bugs. Of course Microsoft's piece de resistance was J++. It allowed you to use all sorts of proprietary Windows components in your apps and applets to ensure they wouldn't run on anything other than Windows. An epic piece of evilness by MS. They just aren't as devious these days...
First off, I too detest Java. Anyone that says it is fast simply doesn't know how to write good C code. It does scale - the downloads of each patch or update are prime bloatware of even the sizes M$ would blush at. But, having said that, I do have some sympathy for Java coders as write-once-run-anywhere has never really worked, even back in the days of supposedly standard ANSI C.
what are the alternatives? There's a fairly clear need for a strong, static, explicitly typed manged-memory language with Algol-flavoured syntax, because you can be reasonably assured of finding some moderately priced coders to write in it and moderately competent managers who won't be horrified by it.
Stuff like Scala doesn't avoid all of the underlying JVM and Java library issues you mentioned. C# under Windows is nice enough, and even makes pretences to be multiplatform given the existence of Mono... but if you're not using the Windows version, Mono seems very much like a second class citizen.
And all you're left with after that is C++ (which I like, but it is too easy to do write unstable software full of security issues if you have to trust people to manage their own memory) and a plethora of rather nice dynamic languages which don't seem to have much business cachet because it is too easy to write dog slow unreadable code and you have to trust your devs to write test cases.
So Java may be awful, but is anything else really that much less awful?
Lazarus. Write once, compile anywhere ;) Just released version 1.0, too.
Runs on Windows, Linux, OSX, FreeBSD, perhaps even Solaris if you can persuade it to. I think it can create apps for Android, could be IOS as well.
Uses Qt, GTK2, Carbon or Win32... and switching between them could be just a recompile.
In my hobbyist eyes, reading/writing Object Pascal (more or less the dialect Delphi uses - there's even a Delphi compatibility mode in Lazarus) is much easier than C++.
I had to learn programming with Modula 2 while some courses inflicted the lecturer's pet language on top - Miranda, occam, Z notation, Dbase IV... It was a breath of fresh air when we were finally taught C which was actually useful for something.
If I were teaching a course on programming these days I would absolutely not use Javascript though. It's far too easy to abuse and doesn't impose any sort of discipline on new programmers. Python would be a far more suitable choice, though failing that maybe Java and definitely Java and C++ when they mastered the basics.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
