Yes, I read somewhere that 'native' graphics acceleration for JDKs 1.4+ is much more advanced
on Windows (that is, there is such a thing). I think it may have even been mentioned in release notes... But even HotSpot used to be much faster (closer to "native speed") earlier. I hope this is not the case any more, that optimizers are on par on different x86/Sparc platforms (haven't done much testing recently on performance).
Not that there's anything bad in Java being nicely optimized on Windows, but it sucks if/when same is not true on unix platforms (ie. "only" on Windows... apparently Apple has fortunately created a decent JVM for MacOSX from what I've heard). Esp. since Sun is finally getting serious about supporting Linux (their own distribution, selling multi-AMD-CPU [blade] servers).
this is completely off topic, but du you know a vt220 emulation with user definable fonts (softfonts?) implemented?
Nope; that's one of few things from 220 I did not implement (should have said 90+% vt-220, half of vt-320... didn't implement sessions either). I did implement double-width/double-size fonts, blinking, and default "gfx" character set, plus also switchable speed throttle (9600 bps etc); just for fun so that most vt-animations would work.:-)
I probably didn't see decent description of user defineable fonts on web back then (plus, I'm not old enough to have
extensively used real vt-220 emulators except during my first college year for playing muds, before getting into x-work stations... so I wasn't aware of such a feature). Could have been nice to try to implement it.
In case you want to have a look at what I implemented (which after rewrite a year ago is not 100% as compliant as it used to be, but is much cleaner source now), you can find it via Google; search for "jiveterm home page". I always thought one of these days I'd finish it, since it's kind of cool thing to have done. =)
Java isn't and never will be as fast as C/C++, people who say "but oh it's compiled it runs just as fast" haven't a clue what they're talking about.
Ok; due to your insightful explanation and supporting evidence, I now understand the situation completely. Apologies for spreading FUD about Java's acceptable performance.
ps. Can you point me to the section(s) in kernel documentation that explain performance problems of Java compared to C or C++? I seem to have trouble finding it.
Don't forget that it is also percieved as slow since just about any application anyone has seen for a desktop environment written in Java has a sluggish GUI.
It's in many ways unfortunate that with JDK 1.2 (Swing) and onwards, Sun pretty much dumped fast native support for GUI rendering. It has its benefits -- full control, easier portability -- but the fact is that simple GUI apps felt faster with 1.1 than they have done ever since (or even more). This is, alas, especially noticeable on X-windows, perhaps since often the whole window is rendered as one big component as opposed to normal x app components (in latter case, x-windows can optimize clipping better).
Years ago (in late 90s, 97 or 98), I wrote a full VT-52/100/102/220 terminal emulator with telnet handling (plus for fun plugged in a 3rd party then-open SSH implementation). After optimizing display buffer handling, it was pretty much on par with regular xterm, on P100 (Red hat whatever, 5.2?), as in felt about as fast, and had as extensive vt-emulation (checked with vttest).
Back then I wrote the thing mostly to show it can be done, as all telnet clients written in Java back then were horribly naive, doing full screen redraw and other flicker-inducing stupidities... and contributed to the perception that Java is and will be slow. I thought it had more to do with programmers not optimizing things that need to be optimized.
It's been a while since then; last I tried it on JDK 1.4.2... and it still doesn't FEEL as fast, even though technically speaking all java code parts ARE much faster (1.1 didn't have any JIT compiler; HotSpot, as tests show, is rather impressive in optimizing). It's getting closer, but then again, mu machine has almost an order of magnitude more computing power now, as probably does gfx card.
To top off problems, in general Linux implementation has been left with much less attention than windows version (or Solaris, but Solaris is at least done by same company).:-/
Fact of the matter is, your high-tech "skill" of database design is not much different that the skill of an autoworker installing the drivetrain on a Buick. These days, it's easy to learn, and repetative.
How easy it's to make fun of those "code monkeys" "writing silly VB", or in your case, that simpleton data modeler... and be pretty much mistaken.
While comparatively speaking there are certainly more challenging tasks in software development, it's by no means low-level monkey work you think anyone can do. To you it is (I hope) easy thing to do. But when most people can't even use their VCRs, you are seriously overestimating competency of general work force in quite specialized field.
Now, obviously there doesn't need to be MUCH innovation in there. But I would claim that designing new standards or protocols or especially specifications is often not significantly more demanding, for example. Implementing this is more likely to include innovations.
Committees and working groups are full of mediocrities, who just follow up footsteps of others.
Having said that, I wouldn't really care employing someone whose only job was data modelling either... I do prefer wider skilled individuals; one task of which may be data modelling, but certainly not the only one.
BTW, no regular call approaches 64 Kbs data rates. That's ISDN territory.
Nope. Analog calls do consume full 64 kbps channels (although in US, one out of 64 bits is snatched for signalling, to form a virtual signalling channel from 24 real ones; this leaves 56 kbps for ISDN; in Europe full 64 kbps is the norm); it's just that only ISDN modems can reliably transfer at full speed (since they don't do D/A conversions); analog ones can not get it all (but do pretty darn well with bit of help of probability theory with signal processing). It is possible to compress that on trunk network, but I don't know if that's done (didn't use to be necessary, with T1/E1 it just complicates call routing?). So, at least for last copper mile 64k is used for each call.
Still, better way to go about voice quality would be to use compression on that 64k channel... I'd love to get that done; 64k uncompressed isn't too good, even for speech.
As for overhead, I'm in agreement there: the overhead of TCP/IP is definitely minimal compared to the cost of marshalling RPC data to begin with. TCP/IP can be tuned anyway, and it'll almost certainly be faster and more robust than something that tries to reinvent it over UDP.
Perhaps I misread original points, but it seemed like he wasn't so much worried about overhead, but about time-sensitivity aspect. TCP tries really hard to get all the data get through (with re-sends etc), without worrying at all about delays. It's good for bulk transfers, and things that simply have to get through, but for real-time (or in general time sensitive) data it's pretty useless to get anything that is late. And worse,
since there's no way to really know what's going on (from TCP POV, "app shouldn't care"), it's
difficult for the app to try to failover or
other sensible action to resolve the (likely transient) problem.
Trying to figure out information about why and how data just isn't getting back, via socket (or whatever) API is next to impossible... thus, protocols such as RTP were developed. It's been a while since I followed what was happening there, but there was definite need for something that would give better control over timing information; at the very least for apps to be able to find out if there are timing problems, and do the right thing whatever it is (mark server as likely being down, find alternatives etc).
As to overhead, I'd agree; esp. due to HTTP being so ubiquitous, all stacks are ridiculously optimized, and handle "non-optimal" usage of TCP (simple request-reply) rather fine, all things considered.
Ok, this is off-topic, but how is Jazilla doing? I probably need to have a look at home page... I'd be very interested in having a look, perhaps even helping if there's something interesting I might have expertise on. Back in the day I did write a simple HTML rendering component (JDK 1.1, before swing), and nowadays am interested in implementing efficient data structures. Plus it'd be fun to get to do some actual app development (not just server-side) for a change.:-)
"They don't build them things like they used to..."
Thing is, computer systems are pretty disposable thingies these days; and even if they weren't, it doesn't take more than a decade for current crop of electronics to eventually break. Basically it's just matter of time before any server breaks; which components fail first may vary, but ALL components will eventually die.
I guess this sort of put a limit to the amount of expansion, collaboration, and open effort that can be handled without big money support.
Interesting thought. Fortunately, CPU power, storage capacity and networking bandwidth all still keep getting more affordable... so there
can still be growth, eventually.
Additionally, perhaps it could also force rethinking of some parts of architecture (I don't know how sophisticated system wikipedia nowadays is... original wiki was pretty straight-forward scripted quick-n-useful app), which in the end would probably be a Good Thing.
persians are indoeuropeans not semites, which means theye're ethnicly closer to us then say finns or hungarians.
I think you meant to say "linguistically", since from language perspective you are correct. Germanic languages are somewhat related to persian (amongst other languages), more so that fenno-ugric (finnish, hungarian, estonian) ones. But ethnicity implies much wider range of things, from cultural to genetic attributes... in which case fenno-ugrians and persians both are fairly distinct from anglo-saxons.
IMHO, java still has too much overhead. We havent got the efficiency and equality that has been promised yet, but I assume we will get there someday.
I think this really depends on what one is doing. On server-side web app (and similar) processing, Java (with 1.4 JDK) seems to be pretty low overhead, considering what it's doing (as in fully standards compliant with unicode encodings etc). Most overhead comes (IMO) from various (often unnecessary complicated, for what they do) frameworks, and from people who have no experience in considering performance impacts on designs or
implementations.
There are areas where Java is closer to optimal, low overhead alternatives, and then there are others (byte-handling still has overhead, for one; scientific calcs can not be optimized nearly to degree other native compiled languages can etc. etc).
And even with low overhead areas, there are still occasional issues with most demanding loads... But all in all, to me it seems to finally be decent tradeoff, between robustness of runtime environment (obtaining 24/7 uptimes is restricted not by JVM but by architecture of implemented system, and potentially hardware), and moderate
overhead due to runtime VM; as compared
to having even less overhead but more challenging
development (making 110% sure memory handling in C/C++ is foolproof... in Java you can much more gracefully handle unexpected failures, NPEs etc).
This means that for every file delivered, more than one node is labored with the uploading of this file, and given that, for most people, upstream bandwidth is a rather limited resource, the ultimate consequence will be that the system will be slow as compared to one where the files are sent directly, e.g., FastTrack or gnutella.
Not necessarily, in theory (in practice, probably). If routing is done in a way similar to wireless ad hoc routing is supposed to be done, it could just mean that routing decisions are not done end-to-end, but by independent routing (and encrypting) nodes. Thus, there need not necessarily be additional unnecessary nodes; theoretically it could even reach better routing decisions, since it's not (just) your ISPs router trying to optimize based on financial reasons ("we have deal with MCI and thus we'll go from NY to LA and then back to Boston, instead of using direct route"). Your other point (asymmetric connections) is still valid though...
In practice it is likely that optimal behaviour won't be achieved, esp. in cases where endpoints are reasonably close to each other (in which case guaranteeing anonymity prevents best shortcuts). However, it really comes down to how well implementation works, not that specification dictates bad performance; and also in your usage patterns. If you want to swap files with your neighbour, this would be pretty suboptimal; but that's probably not very common use case. Inter-continental transfer, on the other hand, may not be much less efficient than "direct" connections.
They come with a SuSE derivitve distro. I couldn't tell if its real SuSE or a SuSE Sun optimized.
It's probably Sun's own distro, "Java Enterprise Linux" (and "Java Desktop Linux", or something along those lines), formerly known as Mad Hatter? It is based on SuSE, don't know if it's a spin-off (like Mandrake started from Red Hat), or if they'll stay related.
But some people claim he was/is a frankenstein, and it would make lots of sense he came from a test tube or something! Yeah, I'd assume he was made same way all other humans are actually.
And yes, I agree in that it'd be reasonable to require proof of existence, rather than proof of non-existence; especially since latter is in general impossible to really prove... if you find it, it exists, if not, you may still have doubts.
Sure, hiding a vial of almost anything, or canister of something else is easy. But for weapon-grade stuff, that's not the way it can be done. You don't fire vials with missiles or howitzers, nor do you get much results with small amounts of nerve gas. Plus, even evil crooked
scientists and military lunatics prefer not to
get harmed by the dangerous stuff, so packaging
generally adds lots of overhead on otherwise
potentially small volume.
I mean, although I know that "even if I'm paranoid, it doesn't mean they aren't after me" is sometimes valid counter argument, is it so hard to believe that perhaps Saddam eventually thought
that WMDs were NOT worth all the hassle?
(after losing to Iran, getting chastised,
eventually, for killing kurds with mustard
gas, getting kicked out of Kuwait by coalition
etc. etc.)
Have people
just been so well indoctrinated with scare d'jour; after red scare it's all these pesky
terrorists and dictators taken out of b-class
Hollywood movies, lumped together, every one
of them being wild-eyed raving lunatics whose
main mission is to destroy the earth along with western way of life. From that perspective it
may be unthinkable that perhaps bloody dictators
too can occasionally use their judgment, do
some cost/benefit analysis of their own.
If you keep that in mind, how hard do you suppose it will be to WMDs?
As long as they can be camouflaged as bum-looking middle-aged dude, living in a hole, pretty easy?
On the other hand, there is also possibility that it's comparing apples and oranges, and that hiding WMDs efficiently, securely, and in a way they can be reused, yet still not detected easily by radioactivity, or chemical leakage, is significantly more challenging task than hiding
an ex-dictator.
Given a few years, I wouldn't be surprised to see a program like that be the basis of the next big thing in programming languages.
Why is that? I generally believe in using right tool for the job... and controlled or non-controlled, human languages that I'm familiar with do not seem to have much benefits over existing programming languages?
Of course, the quality of the software would be much better if you had the time to do everything yourself, or if the team consisted only of highly skilled, very intelligent, experienced programmers. The problem is, this description fits only a minority of all programmers out there, and there are big companies that require hundreds or even thousands of programmers. They won't hire idiots, but they have to hire programmers that are just good enough, and have more experienced ones to be their bosses and tell them what to do. Heck, I often _wished_, when doing small projects, that I _had_ someone who gives me advice, instead of just a PHB who wants me to implement by yesterday the feature request he'll send me tomorrow...
Amen. Additionally, I have noticed that having mix of various skill levels has also its benefits. Having just experts sometimes leads to more conflicts; it's more challenging to gain consensus, and having to use authority sometimes has bad consequences. When there's some existing "natural" seniority level difference, it is easier to have mentor-like relationships; leaders are followed not because of title, but because of their longer experience and stronger skills.
And then more junior co-workers also get benefit
of learning, more senior people get better
at teaching others (plus see improvements via
mentoring others).
I have also noticed that sometimes people forget too soon that they too used to be inexperienced, and their learning ability (or willingness) decreases... and then it may well be that enthusiastic and quickly learning novice can quite soon surpass old timers, as optimal team members.
Ok, you're over generalizing... java and "www" are not synonymous. Yes, in the very beginning, java was a toy for playing inside a web browser. Today, entire applications are written in java far, far removed from any browser.
Um, I must have misphrased something, as I never meant to imply otherwise. I have 6 years of Java experience (and its currently my main implementation language), so I definitely know "java == applets" hasn't been true for years now.
By mentioning both Java and WWW I just meant to use analogy regarding their significance in making many things easier, thus enabling less skilled people to do things formerly only possible by professionals.
Other than that I certainly agree with your points. About the only additional point I have, though, is that I know some decent programmers, who have taken alternate routes to learning the craft, although most of good ones have gotten at least some decent education. So basically there are more than one way to get there; but what one definitely needs is interest and enthusiasm, not greed.
Coding is not about writing high-quality software, it's about hacking together stuff like GUI frontends for simple...
Careful here. Your definition of coding might not really what many people here consider it to be (but more importantly, whether article did is... well I need to RTFA too, heh).
In casual conversation, I might consider to be roughly equivalent of programming; but I also know some people have more traditional water fallish image of architecture, design, coding separation.
Nowadays what you describe as coding is something only suitable for machines, or as part of job for person who does "more", ie. does not just act as medium between someone with brains and keyboard. There's no need or place for that kind of "coder".
In same time as I can describe architecture and design of a component to someone who couldn't have done that, I can usually just implement and test component, and generally get higher quality end results (apologies if I'm preaching to the choir here... but it's one of my pet peeves with PMs and PHBs).
On the other hand... I certainly recognize group of low-skilled/inexperienced (often both) individuals working at companies that do fit your description of coders.:-/
It's frustrating how difficult it is to get through the idea that there is huge productivity difference between good and barely sufficient programmers. Personally I use estimate of 10:1 (including all aspects of productivity, from wider range of task better pgorammers are capable of tackling to higher quality, maintainibility etc. of end results); and I doubt that's exaggeration.
Things like java have poluted the world by making everything think they can program.
Umm.... so it's Java's fault that it made things
much easier? Like WWW sucks as now everyone thinks they have ideas worth publishing (-> home pages, blogs), or that they can find information themselves, by-passing publishers (googling, mailing lists, newsgroups)? Or cars that are easy to operate, without having to even have full understanding of internal combustion engine? (and so on and on).
Now, the way I see it, average low-level skill set of people who work as programmers may have decreased, but it has more to do with huge increase in number of people in question.
Previously it took dedication, experience, interest... nowadays there are many more people for whom it's "just a job". For better or worse, not everyone HAS to know as much about basics as they used to have. In a way it's sad, in a way it really doesn't matter. I have my 20+ years of programming experience (starting at fresh age of 9 with commodore basic); in some ways it's neat to know so much more than fresh graduates do, about fundamentals, about different ways things can be done, about history of how things have changed. Perspective is nice thing to have. Especially with changing economic conditions; it's much easier to weather the downturns.
But even with the influx of less seasoned practisioners of the art, I would claim that number of competent programmers has still grown. Their relative size of the whole probably has decreased... but not absolute size. And with recent implosion of the job market, I'd venture a guess even relative ratio has slightly grown past year or two.
What you're left with is the prospect that maybe one out of every million page hits is going to a Slashdot developer who's debugging that the rendered properly, though if it's XHTML transitional then a XML editor would be a great choice and would again make it irrelevant if it's clogged full of waste whitespace.
And even without XHTML, one can just use HTML Tidy to XML'ize it, then use XML indenter or editor.
No need for production source to be prettified.
because a text-mode installer will work through one, and a bitmapped GUI one won't.
There are 2 separate issues: whether installer is built to use (logical) text output display or not, and secondly, how such device is implemented: in hardware (as is the case for PC gfx cards, as legacy baggage), or in firm/software.
I'm
only arguing about second part; that physically there's no need to have hardware implementation of character output device. I'm NOT arguing that all installers should be graphical "just because"; just that such text display could be implemented by BIOS (or equivalent), if necessary. Or alternatively, by reasonably light-weight part of graphics lib. Installer
definitely shouldn't implement graphics
primitives either way.
About serial port connection; there still has to be serial driver that connects to shell (either full or minimal one on which installer runs), which is used to give input and enable output... so while simplish to implement, it's not completely free. But I definitely agree it's a useful thing to have, and wouldn't claim it's imperative that should be removed.
Slashdot Mirror
Not that there's anything bad in Java being nicely optimized on Windows, but it sucks if/when same is not true on unix platforms (ie. "only" on Windows... apparently Apple has fortunately created a decent JVM for MacOSX from what I've heard). Esp. since Sun is finally getting serious about supporting Linux (their own distribution, selling multi-AMD-CPU [blade] servers).
Thanks, that's pretty interesting. Should make it much easier to use dbvis at work, since I'm remotely displaying it!
Nope; that's one of few things from 220 I did not implement (should have said 90+% vt-220, half of vt-320... didn't implement sessions either). I did implement double-width/double-size fonts, blinking, and default "gfx" character set, plus also switchable speed throttle (9600 bps etc); just for fun so that most vt-animations would work. :-)
I probably didn't see decent description of user defineable fonts on web back then (plus, I'm not old enough to have extensively used real vt-220 emulators except during my first college year for playing muds, before getting into x-work stations... so I wasn't aware of such a feature). Could have been nice to try to implement it.
In case you want to have a look at what I implemented (which after rewrite a year ago is not 100% as compliant as it used to be, but is much cleaner source now), you can find it via Google; search for "jiveterm home page". I always thought one of these days I'd finish it, since it's kind of cool thing to have done. =)
Ok; due to your insightful explanation and supporting evidence, I now understand the situation completely. Apologies for spreading FUD about Java's acceptable performance.
ps. Can you point me to the section(s) in kernel documentation that explain performance problems of Java compared to C or C++? I seem to have trouble finding it.
It's in many ways unfortunate that with JDK 1.2 (Swing) and onwards, Sun pretty much dumped fast native support for GUI rendering. It has its benefits -- full control, easier portability -- but the fact is that simple GUI apps felt faster with 1.1 than they have done ever since (or even more). This is, alas, especially noticeable on X-windows, perhaps since often the whole window is rendered as one big component as opposed to normal x app components (in latter case, x-windows can optimize clipping better).
Years ago (in late 90s, 97 or 98), I wrote a full VT-52/100/102/220 terminal emulator with telnet handling (plus for fun plugged in a 3rd party then-open SSH implementation). After optimizing display buffer handling, it was pretty much on par with regular xterm, on P100 (Red hat whatever, 5.2?), as in felt about as fast, and had as extensive vt-emulation (checked with vttest). Back then I wrote the thing mostly to show it can be done, as all telnet clients written in Java back then were horribly naive, doing full screen redraw and other flicker-inducing stupidities... and contributed to the perception that Java is and will be slow. I thought it had more to do with programmers not optimizing things that need to be optimized.
It's been a while since then; last I tried it on JDK 1.4.2... and it still doesn't FEEL as fast, even though technically speaking all java code parts ARE much faster (1.1 didn't have any JIT compiler; HotSpot, as tests show, is rather impressive in optimizing). It's getting closer, but then again, mu machine has almost an order of magnitude more computing power now, as probably does gfx card.
To top off problems, in general Linux implementation has been left with much less attention than windows version (or Solaris, but Solaris is at least done by same company). :-/
How easy it's to make fun of those "code monkeys" "writing silly VB", or in your case, that simpleton data modeler... and be pretty much mistaken. While comparatively speaking there are certainly more challenging tasks in software development, it's by no means low-level monkey work you think anyone can do. To you it is (I hope) easy thing to do. But when most people can't even use their VCRs, you are seriously overestimating competency of general work force in quite specialized field.
Now, obviously there doesn't need to be MUCH innovation in there. But I would claim that designing new standards or protocols or especially specifications is often not significantly more demanding, for example. Implementing this is more likely to include innovations. Committees and working groups are full of mediocrities, who just follow up footsteps of others.
Having said that, I wouldn't really care employing someone whose only job was data modelling either... I do prefer wider skilled individuals; one task of which may be data modelling, but certainly not the only one.
Nope. Analog calls do consume full 64 kbps channels (although in US, one out of 64 bits is snatched for signalling, to form a virtual signalling channel from 24 real ones; this leaves 56 kbps for ISDN; in Europe full 64 kbps is the norm); it's just that only ISDN modems can reliably transfer at full speed (since they don't do D/A conversions); analog ones can not get it all (but do pretty darn well with bit of help of probability theory with signal processing). It is possible to compress that on trunk network, but I don't know if that's done (didn't use to be necessary, with T1/E1 it just complicates call routing?). So, at least for last copper mile 64k is used for each call.
Still, better way to go about voice quality would be to use compression on that 64k channel... I'd love to get that done; 64k uncompressed isn't too good, even for speech.
Perhaps I misread original points, but it seemed like he wasn't so much worried about overhead, but about time-sensitivity aspect. TCP tries really hard to get all the data get through (with re-sends etc), without worrying at all about delays. It's good for bulk transfers, and things that simply have to get through, but for real-time (or in general time sensitive) data it's pretty useless to get anything that is late. And worse, since there's no way to really know what's going on (from TCP POV, "app shouldn't care"), it's difficult for the app to try to failover or other sensible action to resolve the (likely transient) problem.
Trying to figure out information about why and how data just isn't getting back, via socket (or whatever) API is next to impossible... thus, protocols such as RTP were developed. It's been a while since I followed what was happening there, but there was definite need for something that would give better control over timing information; at the very least for apps to be able to find out if there are timing problems, and do the right thing whatever it is (mark server as likely being down, find alternatives etc).
As to overhead, I'd agree; esp. due to HTTP being so ubiquitous, all stacks are ridiculously optimized, and handle "non-optimal" usage of TCP (simple request-reply) rather fine, all things considered.
Ok, this is off-topic, but how is Jazilla doing? I probably need to have a look at home page... I'd be very interested in having a look, perhaps even helping if there's something interesting I might have expertise on. Back in the day I did write a simple HTML rendering component (JDK 1.1, before swing), and nowadays am interested in implementing efficient data structures. Plus it'd be fun to get to do some actual app development (not just server-side) for a change. :-)
"They don't build them things like they used to..."
Thing is, computer systems are pretty disposable thingies these days; and even if they weren't, it doesn't take more than a decade for current crop of electronics to eventually break. Basically it's just matter of time before any server breaks; which components fail first may vary, but ALL components will eventually die.
Interesting thought. Fortunately, CPU power, storage capacity and networking bandwidth all still keep getting more affordable... so there can still be growth, eventually.
Additionally, perhaps it could also force rethinking of some parts of architecture (I don't know how sophisticated system wikipedia nowadays is... original wiki was pretty straight-forward scripted quick-n-useful app), which in the end would probably be a Good Thing.
I think you meant to say "linguistically", since from language perspective you are correct. Germanic languages are somewhat related to persian (amongst other languages), more so that fenno-ugric (finnish, hungarian, estonian) ones. But ethnicity implies much wider range of things, from cultural to genetic attributes... in which case fenno-ugrians and persians both are fairly distinct from anglo-saxons.
I think this really depends on what one is doing. On server-side web app (and similar) processing, Java (with 1.4 JDK) seems to be pretty low overhead, considering what it's doing (as in fully standards compliant with unicode encodings etc). Most overhead comes (IMO) from various (often unnecessary complicated, for what they do) frameworks, and from people who have no experience in considering performance impacts on designs or implementations.
There are areas where Java is closer to optimal, low overhead alternatives, and then there are others (byte-handling still has overhead, for one; scientific calcs can not be optimized nearly to degree other native compiled languages can etc. etc). And even with low overhead areas, there are still occasional issues with most demanding loads... But all in all, to me it seems to finally be decent tradeoff, between robustness of runtime environment (obtaining 24/7 uptimes is restricted not by JVM but by architecture of implemented system, and potentially hardware), and moderate overhead due to runtime VM; as compared to having even less overhead but more challenging development (making 110% sure memory handling in C/C++ is foolproof... in Java you can much more gracefully handle unexpected failures, NPEs etc).
Not necessarily, in theory (in practice, probably). If routing is done in a way similar to wireless ad hoc routing is supposed to be done, it could just mean that routing decisions are not done end-to-end, but by independent routing (and encrypting) nodes. Thus, there need not necessarily be additional unnecessary nodes; theoretically it could even reach better routing decisions, since it's not (just) your ISPs router trying to optimize based on financial reasons ("we have deal with MCI and thus we'll go from NY to LA and then back to Boston, instead of using direct route"). Your other point (asymmetric connections) is still valid though...
In practice it is likely that optimal behaviour won't be achieved, esp. in cases where endpoints are reasonably close to each other (in which case guaranteeing anonymity prevents best shortcuts). However, it really comes down to how well implementation works, not that specification dictates bad performance; and also in your usage patterns. If you want to swap files with your neighbour, this would be pretty suboptimal; but that's probably not very common use case. Inter-continental transfer, on the other hand, may not be much less efficient than "direct" connections.
It's probably Sun's own distro, "Java Enterprise Linux" (and "Java Desktop Linux", or something along those lines), formerly known as Mad Hatter? It is based on SuSE, don't know if it's a spin-off (like Mandrake started from Red Hat), or if they'll stay related.
But some people claim he was/is a frankenstein, and it would make lots of sense he came from a test tube or something! Yeah, I'd assume he was made same way all other humans are actually.
And yes, I agree in that it'd be reasonable to require proof of existence, rather than proof of non-existence; especially since latter is in general impossible to really prove... if you find it, it exists, if not, you may still have doubts.
I mean, although I know that "even if I'm paranoid, it doesn't mean they aren't after me" is sometimes valid counter argument, is it so hard to believe that perhaps Saddam eventually thought that WMDs were NOT worth all the hassle? (after losing to Iran, getting chastised, eventually, for killing kurds with mustard gas, getting kicked out of Kuwait by coalition etc. etc.)
Have people just been so well indoctrinated with scare d'jour; after red scare it's all these pesky terrorists and dictators taken out of b-class Hollywood movies, lumped together, every one of them being wild-eyed raving lunatics whose main mission is to destroy the earth along with western way of life. From that perspective it may be unthinkable that perhaps bloody dictators too can occasionally use their judgment, do some cost/benefit analysis of their own.
As long as they can be camouflaged as bum-looking middle-aged dude, living in a hole, pretty easy?
On the other hand, there is also possibility that it's comparing apples and oranges, and that hiding WMDs efficiently, securely, and in a way they can be reused, yet still not detected easily by radioactivity, or chemical leakage, is significantly more challenging task than hiding an ex-dictator.
Why is that? I generally believe in using right tool for the job... and controlled or non-controlled, human languages that I'm familiar with do not seem to have much benefits over existing programming languages?
Amen. Additionally, I have noticed that having mix of various skill levels has also its benefits. Having just experts sometimes leads to more conflicts; it's more challenging to gain consensus, and having to use authority sometimes has bad consequences. When there's some existing "natural" seniority level difference, it is easier to have mentor-like relationships; leaders are followed not because of title, but because of their longer experience and stronger skills. And then more junior co-workers also get benefit of learning, more senior people get better at teaching others (plus see improvements via mentoring others).
I have also noticed that sometimes people forget too soon that they too used to be inexperienced, and their learning ability (or willingness) decreases... and then it may well be that enthusiastic and quickly learning novice can quite soon surpass old timers, as optimal team members.
Um, I must have misphrased something, as I never meant to imply otherwise. I have 6 years of Java experience (and its currently my main implementation language), so I definitely know "java == applets" hasn't been true for years now. By mentioning both Java and WWW I just meant to use analogy regarding their significance in making many things easier, thus enabling less skilled people to do things formerly only possible by professionals.
Other than that I certainly agree with your points. About the only additional point I have, though, is that I know some decent programmers, who have taken alternate routes to learning the craft, although most of good ones have gotten at least some decent education. So basically there are more than one way to get there; but what one definitely needs is interest and enthusiasm, not greed.
Careful here. Your definition of coding might not really what many people here consider it to be (but more importantly, whether article did is... well I need to RTFA too, heh). In casual conversation, I might consider to be roughly equivalent of programming; but I also know some people have more traditional water fallish image of architecture, design, coding separation.
Nowadays what you describe as coding is something only suitable for machines, or as part of job for person who does "more", ie. does not just act as medium between someone with brains and keyboard. There's no need or place for that kind of "coder". In same time as I can describe architecture and design of a component to someone who couldn't have done that, I can usually just implement and test component, and generally get higher quality end results (apologies if I'm preaching to the choir here... but it's one of my pet peeves with PMs and PHBs).
On the other hand... I certainly recognize group of low-skilled/inexperienced (often both) individuals working at companies that do fit your description of coders. :-/
It's frustrating how difficult it is to get through the idea that there is huge productivity difference between good and barely sufficient programmers. Personally I use estimate of 10:1 (including all aspects of productivity, from wider range of task better pgorammers are capable of tackling to higher quality, maintainibility etc. of end results); and I doubt that's exaggeration.
Umm.... so it's Java's fault that it made things much easier? Like WWW sucks as now everyone thinks they have ideas worth publishing (-> home pages, blogs), or that they can find information themselves, by-passing publishers (googling, mailing lists, newsgroups)? Or cars that are easy to operate, without having to even have full understanding of internal combustion engine? (and so on and on).
Now, the way I see it, average low-level skill set of people who work as programmers may have decreased, but it has more to do with huge increase in number of people in question. Previously it took dedication, experience, interest... nowadays there are many more people for whom it's "just a job". For better or worse, not everyone HAS to know as much about basics as they used to have. In a way it's sad, in a way it really doesn't matter. I have my 20+ years of programming experience (starting at fresh age of 9 with commodore basic); in some ways it's neat to know so much more than fresh graduates do, about fundamentals, about different ways things can be done, about history of how things have changed. Perspective is nice thing to have. Especially with changing economic conditions; it's much easier to weather the downturns.
But even with the influx of less seasoned practisioners of the art, I would claim that number of competent programmers has still grown. Their relative size of the whole probably has decreased... but not absolute size. And with recent implosion of the job market, I'd venture a guess even relative ratio has slightly grown past year or two.
And even without XHTML, one can just use HTML Tidy to XML'ize it, then use XML indenter or editor. No need for production source to be prettified.
There are 2 separate issues: whether installer is built to use (logical) text output display or not, and secondly, how such device is implemented: in hardware (as is the case for PC gfx cards, as legacy baggage), or in firm/software.
I'm only arguing about second part; that physically there's no need to have hardware implementation of character output device. I'm NOT arguing that all installers should be graphical "just because"; just that such text display could be implemented by BIOS (or equivalent), if necessary. Or alternatively, by reasonably light-weight part of graphics lib. Installer definitely shouldn't implement graphics primitives either way.
About serial port connection; there still has to be serial driver that connects to shell (either full or minimal one on which installer runs), which is used to give input and enable output... so while simplish to implement, it's not completely free. But I definitely agree it's a useful thing to have, and wouldn't claim it's imperative that should be removed.