I suppose this question would seem very different if the students were required to use emacs/vi, gcc, make, etc. on a unix shell
I was waiting for someone to say that. Yes, it would be different. First of all, lets focus on the key issue: it's the compiler/build environment, not the editor/ide. People should use whatever editor they want, but to have objective grading, there must be one known build environment. So the comparison should be "mandating gcc" versus "mandating $commercial_compiler". Given this choice, gcc on unix is preferable because:
It's network-friendly and automation-friendly. The TA's can set up a test-compile email address to which students can mail source code and have the compile results / stdout mailed back. This enables students to test their programs on the definitive platform regardless of which compiler they used during development. Presumably this could be done with $visual_shinything also, but I doubt it's as easy.
It's beerishly free. Students are always poor, and it's senseless to make them buy something when they could get the equivalent for free.
It's the future. Microsoft's star is falling, and a few years after the breakup any proprietary language variants they've invented will be as relevant as COBOL. GCC, in contrast, will be at the center of future compiler development. When Intel makes a new chip, one of their first priorities is to port GCC. As Vinod Villopillil pointed out in the Halloween Documents, open source software has long term credibility.
It's vendor-neutral. Academics usually strive for indepdence from commercial pressure, both for themselves and for their students. I don't think History professors would require a textbook written by the Tobacco industry to spin recent history in their direction. The CS academics need to struggle for this integrity in the face of a University administration that wants to make 'strategic partnerships' with commercial entities.
I don't accept the "moral equivalence" which you seem to imply between GCC and $shinything. Everyone, including Microsoft is welcome to steer the future development of GCC by submitting patches, and by forking the code if their patches are rejected. Proprietary compilers from Microsoft will be steered solely by Microsoft's wishes. To avoid Godwination, I will not extend this analogy to its logical consequences. Thanks for giving me the opportunity.
When you do load balancing and you have Microsoft's wallet, you use real stuff. Big-IP, Webserver Director, stuff like that.... You are supposing that the load balancer is running an OS like Win2000 or BSD? AHHHHH!!!!!. I would be damn if they dare to do that.
Actually, the Big-IP runs BSDI. The only thing that makes an 'appliance' magical and special is that you don't know what's in it. Once you get to explore its guts, it's just another computer. I still like the BigIP, though, because F5 did a great job putting together all the pieces that would take several weeks to get 'just right'.
I think that the spread of proprietary software on Linux will lead to an increased number of compromised and damaged systems. In the Windows world, the installation of a new package is a substantial risk and can seriously affect the security and uptime of the system. In the UNIX world, this is usually not the case. We frequently assume that this is due to UNIX's better security model, but this is not really true. What really protects us is the consensus among software authors and packagers that installation scripts and Makefiles should not perform unexpected actions, such as modifying files in/etc. In practice, most applications installation has to be done as root, so the author of the install program has unlimited capacity to harm the system. I recently installed a proprietary binary application on a Linux box. The install script wanted to be run by UID 0, or it would bail with an error message. Fortunately, it was a shell script, not a compiled program, so I was able to draw its fangs. I also created a new user just for this package, so it wouldn't mess with anyone's home directory. Then I successfully ran the script. The script tried to modify some files in/etc, and to chgrp sys most of the files it installed. (There is no group 'sys' on that machine.) A newbie would accept the script's demand to be run as root, and would not have noticed the changes in/etc. Multiply this by the number of commercial packages on the machine (say 10) and you might approach Windows Syndrome - each new application add mysterious bugs to the system.
Windows systems are haunted by elusive and destructive spirits. Soon Linux systems will be also.
And even if we solve the install problem, you have to wonder if it's worth creating a new user for each proprietary package. To get the most use out of software, I want to run it under my normal UID. But if this means having my.mailcap,.bashrc,.Xdefaults, etc modified on the random whim of some Windows programmer who never quite understood the UNIX environment, then the annoyance outweighs any benefits the software could offer.
The influx of commercial freeware means that we will be dealing more and more with software conceived in the Windows world and only reluctantly ported to UNIX. The consequences of this shift will be far-reaching and unpleasant. Windows programs install on the assumption that nobody is adminning the box; it's just a free-for-all between competing applications which modify anything in the filesystem to suit their immediate needs. This concept is readily transplanted to the UNIX environment with the mandate that 'this script must be run by root.'
I'm responding to the AC who feels ICANN should not be blamed for their "accident".
no way to prevent all accidents... that's why they're accidental!
I disagree. Preventing accidents is a large part of what airlines do, what shipping companies do, and less obviously, what ISP's do. ICANN has vomited profusely on itself in public, and deserves contempt, not excuses. An incident like this doesn't proceed from a single minor mistake; rather it indicates a deeply flawed organization. Which of the following is more likely?
ICANN's seasoned, gray-bearded mail admin, who has been working with mail since UUCP days, was setting up a list server for the ten thousandth time, a task he can perform standing on his head, when a wild cosmic ray entered his skull, causing a neuron to misfire, whereupon the admin configured the list server wide open.
ICANN's trained MCSE monkey clicked on a pretty icon and said "Look boss! Instead of pasting all 12000 addresses into Outlock, we can automagically send them with Visual Active SpamBlaster++!" whereupon he was given a bannana.
In the absence of decisive information, I think the latter is more likely. Which brings me to my point: organizations that undervalue technical people will embarass themselves technically; a fate which they richly deserve. Sooner or later, investors must get the message that when some suit decides "120K is way to much to pay a sysadmin, whatever that is. I can get a MCSE for half that!", he is steering the organization towards financial ruin.
I am not claiming that good sysadmins don't make mistakes. I am claiming that good sysadmins have a sense of fear which is proportional to the magnitude of the disaster with which they are flirting. They also have a tendency to watch newly activated things for signs of impending doom. A lack of that sense and that tendency ought to disqualify one from being a sysadmin. A lack of good sysadmins ought to disqualify one from having a decisive effect on the internet.
The proof of the above paragraph is simply the computer you are sitting in front of. Your operating system is not a tangled mass of spaghetti code because oop provides encapsulation (or individual ants) to prevent that.
My operating system is mostly written in plain old procedural C. Is any production OS actually written in OO code? How many years does it take to `ls`?
I think you are presenting a false dichotomy of 'spaghetti code' vs. 'OO'. The majority of code is neither - it is relatively clean, structured procedural code. In other words, large tasks are decomposed into smaller tasks (recursively) until small, understandable functions are reached. No encapsulation needed.
Spaghetti code is code that uses a lot of GOTO's (or jumps) - typically written in BASIC or assembler. Structured code can be viewed as a hierarchy of black boxes with defined inputs and outputs; spaghetti code cannot. The transition to structured code took place (mostly) long before OO.
This (bashing of Randal) is almost certainly a troll, but I'll reply for the benefit of those who don't already know. Randal was convicted of three felony counts for performing tasks that essentially fell within his professional scope as sysadmin. Read the whole story. It's worth learning about, because many people who work with computers are in danger of similar prosecution if they piss off the wrong person. So before you condemn Randal, answer this: have you ever accessed a corporate information resource without explicit authorization? If you say no, and you work in a large, heterogeneous corporate environment, I can rest assured that you don't get much accomplished. If you say yes, you are confessing to the crux of the charges against Randal. The real problem here is that the average person (judge, juror) has so little understanding of how computers work that many innocent actions can be portrayed as criminal. Ever grepped a password file? Now picture how that could sound in court. Anyway, if someone has a serious reason to disbelieve Randal's side of the story, please post it or a link to it. In the 4+ years since the conviction, I haven't seen any.
A methodology is the principology and practicology concernified with the analysification of the methodologies appropriationalized to the field of studification...
Couldn't resist. I remember having a miserable battle with a high school teacher who wanted me to 'centerize' the title on an essay.
Pirsig is fairly mystical. But I think Guy Kawasaki had a good idea of what makes software good. Good software, according to Kawasaki, is Deep, Indulgent, Complete and Elegant.
Apache is deep. When you type `make install` and `apachectl start` for the first time, you have a functioning web server for static pages. So Apache works great for the beginner. But Apache has great depth - you can customize many aspects of the server's behavior, and ultimately chain in your own handlers to provide any imaginable behavior. That's depth. As Larry Wall said, simple things should be simple and hard things should be possible.
Xearth is indulgent. Type 'man xearth'. That's a lot of options. It gives a sense of luxurious plenitude, like a table laden with three courses and five kinds of wine. More than you could possibly want.
It's harder to think of something complete. The feeling of completion is that the creator has filled in all the cracks, addressed all the situations logically implied by the existing rules, and covered all the bases in the relevant specs and RFC's, no matter how obscure. And he's done it so decisively that as a user applying the software to a new situation, you're never in any doubt that the (previously untested) capabilities exist. Maybe sendmail is the example?
vi is elegant. When you type 'd3w' to delete three words, it feels like cutting with an exquisitely sharp knife. Elegant tools almost make dull tasks fun.
Of course, none of this addresses freedom from bugs, which is certainly an important part of quality. But if we're aiming for Pirsigian quality, freedom from bugs is not enough.
That was really good. I just wish the Qualitarians had chosen some other word than Quality to describe what they're doing. Quality is a deep and connotative word and shouldn't be reduced to a label for a checklist wielded by an impostor.
I think that a fax is worth 100 emails, and a printed, FedExed letter is worth 10 faxes. Unfortunately, high-ranking executives don't read email. This ties in to the problem of addressing - whining to 'complaints@spamazon.com' will cause your carefully crafted communication to bounce off an illiterate and uncaring support droid. You need to research the name, title, and address/fax number of the responsible manager who is enforcing the undesirable policy. In any event, I can't honestly participate in such a boycott. I dislike spamazon for numerous reasons, and no single change in their actions would induce me to buy from them.
I don't know about you, but a.equals(b) seems more intuitive to me then strcmp(a, b). Again, cleaner.
And I think that $a eq $b is even cleaner and more symmetrical. Seems like Java is still approaching strings as some weird exception to be handled with HazMat gloves instead of recognizing them for the meat and potatoes of most programming.
What else can you say about a language whose hook is 'platform-independence' and which runs on so few platforms? I can think of few modern languages which are less portable than Java.
I hope Java teaches everyone some painful lessons about what to avoid. A language born as a pimple on the butt of a moribund set-top box and thrust into the limelight artificially by corporate/marketing imperatives was doomed to failure from the outset. The only question is how long the decaying corpse will be left out on the street.
The main sucker for Java is the corporate manager riding herd on a bunch of keyboard monkeys he doesn't quite trust and hoping that a bondage-and-discipline language will limit the amount of feces they can throw. I've talked to a couple of these, and they pale with horror at the idea of unleashing their monkeys with Perl.
I think a secondary and less acknowledged motivation for the sucker choosing java is that it reduces the dynamic range between smart and dumb programmers, thus protecting his fragile ego. If Abigail coded Java, it would probably look just like Mike Monkey's Java. So the sucker manager could be spared the realization that he is an order of magnitude less intelligent than some of his programmers.
Oh, about that 'memory management' issue:
You have to worry about memory management in every language and tool. Even if that doesn't mean malloc'ing and free'ing memory yourself. Most Java programmers I know have no problem doing stupid memory stunts like redeclaring objects inside loops, etc.
Try this: % perl -e'for(0..10) {for(0..1000) {my $x=7;} print `ps u $$`;}' and notice that the memory consumption doesn't increase.
The point is that in 1999 there is no reason for an application programmer to have to worry about that. It seems like Java has stuck the application programmer with responsibility for memory management while attempting to hide the details, a predictably disastrous combination.
Anyway, this whole mess illustrates the perils of a proprietary programming language. A world that has C, Perl, Python and TCL should laugh Java off the planet.
A small KVM switch is handy for configuring a new machine, but surely once the machine is up you'll access it with telnet or ssh. The whole KVM idea seems ugly, kludgey, and unscalable. It also seems like pandering to the weaknesses of the network-impaired OS's.
Ugly: Three extra cables per box?
Kludgey: Extending an analog video further than it's meant to go until it looks like a TV in a cheap motel?
Unscalable: How do you add a third console to your 2XN switch? How do you connect from the workstation across the hall, across the campus, or across the country?
Those who do not understand X are condemned to reinvent it, poorly. (Not that you really need X for administrative tasks.) (And not that I really understand X.)
I wish that corporate statements of support translated into reality a little more quickly. When I look at (Compaq|HP|IBM)'s web pages for servers, I can rarely tell what degree of linux support they have on a particular product. I'd like to see a table listing each hardware feature and explaining how, and how well it is supported. The best example is RAID arrays. If the vendor claims that the RAID is linux-compatible, does this mean:
They provide a binary, closed-source kernel module?
They provide a kernel patch?
Someone else has written a kernel patch?
I can write a script which takes some action when a drive dies?
I can take drives offline/online with a command-line utility (for hot swap)?
The number one thing Compaq could do to show that they're serious about linux on servers is eliminate keyboard, video and mouse. These are relics of the "PC wannabe server" days. Sun's Netra realizes this. I want the BIOS fully accessible through the serial port. And if the machine locks up hard, I want to reboot it through the serial port (with adequate authentication.) And obviously, the RAID must be fully configurable/controllable through the serial port. Although I'm not sure what would be the best way to install Linux on a headless box.
In reality, it's easier and cheaper to build from scratch than to get satisfaction from these corporate giants. They talk the Linux talk, but they walk the Microsoft walk.
I think ASP's can be divided into two categories: "wholesale" and "retail."
Wholesale: Products which offer a client/server interface to customer programs. Products like Oracle encourage ASP hosting because:
They are hard to admin correctly, encouraging amortization of the admin cost across a broad user base.
Licensing fees are frequently related to total processor power, which penalizes small users who want headroom to handle spikes. The big ASP could load average many small users, delivering consistent service with a small proportional headroom.
The ASP will be more able to get Oracle's (or other vendor's) attention when problems arise, due the volume of business.
Retail:Desktop applications for consumers or employees. They make sense because:
Consumers and small businesses don't want to take sysadmin responsibility for a complicated system.
Consumers shouldn't have to invest in a technology (software) which they'll never have time to research adequately. The ASP is in a perfect position to invest wisely in software acquisition/development.
Sophisticated web apps will allow the small business owner/manager to define the roles and permissions of each employee relative to company data. This is not a good fit with the PC-centric model.
Employees will be more able to use their normal work environment while at home or travelling.
ASP's can use their logs to determine what parts of an app are buggy or frustrating to users and rapidly upgrade them. Boxware vendors like MSFT are forced to rely on the user's anecdotal and distorted account of what went wrong on the "PC". Understandably, they tend to discount consumer complaints - witness Gates' famous comment that people complain about bugs in Windows in order to look cool.
Other Stuff:
Stop thinking of this from a geek's standpoint. These services are mostly not for geeks. They will be created and maintained by geeks, but their main beneficiaries will be the ordinary people who are currently forced to admin their own Windows boxes.
Backups and disk mirroring will be a major strong point. Most people never back up their PC's data and everyone has heard heart-rending stories of major projects lost.
If you hate the ASP model, please never use the phone again. Switch over to ham radio. Every criticism leveled at the ASP idea goes double for telephony.
The real problem will be differentiating the free/low-cost ASPs, which will be under-provisioned and burdened with animated GIF's, from the serious and expensive ASP's which will invest in bandwidth, disk, backup, sysadmins, and development.
The bottom line is that consumers never wanted to be sysadmins any more than they wanted to run nuclear power plants or global communication networks. They just want power, phone, and data conveniently on tap.
The 'development loop' = type ':w' in vi; click reload in browser.
Power and expressiveness - once you've had a car with power windows, it's hard to go back to manual cranked windows. Grep (the function, not the program), Map, and regexps eliminate much of what I would have coded in C.
CPAN: everything you need under one roof. And in my experience, the quality is uniformly high.
These are the anti-perl arguments which keep popping up:
"It's a mere scripting language." Interpreted languages have generally been less powerful. People tend to imagine a correlation between the pain/complexity of the development cycle and the value of the resulting code. Microsoft especially seems to encourage this thinking with their glittery IDE. Richard Stallman first pointed out the problem of the "mere scripting language" mentality in his essay describing the genesis of EMACS.
"Compiled code is faster" As many have pointed out, bandwidth usually chokes a web server. But assuming you've eliminated the CGI process creation hurdle via mod_perl or equivalent, and that you're accessing a database to generate the pages, I think you're more likely to bottleneck in the database.
"Perl is OK for small things, but comes up short for big, object-oriented team-built apps." On my web server, the heavy lifting is done by Apache, mod_perl, and MySQL. The DBMS stores the data, which is why the Perl code is fairly small and doesn't have complex data types (other than those from used modules). When someone talks about object-oriented programming for the web, I tend to wonder if he understands the power of the DBMS.
Just my 2c worth. Perl is like abortion, gun control, and vi vs emacs. People will love or hate it for very personal reasons, and not switch because of something they read on/.
The only real problem with lynx is lack of support for tables. Currently, I'm using w3m, a text based browser with table support. It works great for ebay, streetprices, etc. I still use lynx for slashdot because the tables on slashdot don't really contribute anything.
And what makes them qualified to educate anyone? Check out http://www.itaa.org. They don't seem to have discovered the alt tag yet. Maybe the kids will educate them. Also, the page starts with - there is no DTD mentioned. Now, I do this myself from time to time, but then again, I don't run around calling myself the "Information Technology Association of America". But this is mere quibbling. If we dig deeper, to http://www.itaa.org/news/pr/pr19990930a.htm (what happened to the 'l' by the way?) we find the following:
ITAA also supported the workforce provisions of the bill, which establish a fellowship program for graduate and undergraduate students studying computer security...
Now, in trying to imagine these kids 'studying computer security', I visualized two scenarios:
Students sitting in neat rows in a big classroom, listening to a grave lecturer prate on about 'infosec' and 'trusted information systems'. They never touch a computer (except to write a paper in MS Word.) Needless to say, they'll be prey for the 12-year old script kiddies.
Students attacking and defending a huge menagerie of old and new hardware, running every conceivable OS. This would work. But wait - isn't there some dissonance between this option and the 'Just Say No' campaign?
Oh, in case you didn't read the press release, ITAA is DOJ's partner in this venture.
Slashdot Mirror
Given this choice, gcc on unix is preferable because:
- It's network-friendly and automation-friendly. The TA's can set up a test-compile email address to which students can mail source code and have the compile results / stdout mailed back. This enables students to test their programs on the definitive platform regardless of which compiler they used during development. Presumably this could be done with $visual_shinything also, but I doubt it's as easy.
- It's beerishly free. Students are always poor, and it's senseless to make them buy something when they could get the equivalent for free.
- It's the future. Microsoft's star is falling, and a few years after the breakup any proprietary language variants they've invented will be as relevant as COBOL. GCC, in contrast, will be at the center of future compiler development. When Intel makes a new chip, one of their first priorities is to port GCC. As Vinod Villopillil pointed out in the Halloween Documents, open source software has long term credibility.
- It's vendor-neutral. Academics usually strive for indepdence from commercial pressure, both for themselves and for their students. I don't think History professors would require a textbook written by the Tobacco industry to spin recent history in their direction. The CS academics need to struggle for this integrity in the face of a University administration that wants to make 'strategic partnerships' with commercial entities.
I don't accept the "moral equivalence" which you seem to imply between GCC and $shinything. Everyone, including Microsoft is welcome to steer the future development of GCC by submitting patches, and by forking the code if their patches are rejected. Proprietary compilers from Microsoft will be steered solely by Microsoft's wishes. To avoid Godwination, I will not extend this analogy to its logical consequences.Thanks for giving me the opportunity.
Windows systems are haunted by elusive and destructive spirits. Soon Linux systems will be also.
And even if we solve the install problem, you have to wonder if it's worth creating a new user for each proprietary package. To get the most use out of software, I want to run it under my normal UID. But if this means having my .mailcap, .bashrc, .Xdefaults, etc modified on the random whim of some Windows programmer who never quite understood the UNIX environment, then the annoyance outweighs any benefits the software could offer.
The influx of commercial freeware means that we will be dealing more and more with software conceived in the Windows world and only reluctantly ported to UNIX. The consequences of this shift will be far-reaching and unpleasant. Windows programs install on the assumption that nobody is adminning the box; it's just a free-for-all between competing applications which modify anything in the filesystem to suit their immediate needs. This concept is readily transplanted to the UNIX environment with the mandate that 'this script must be run by root.'
- ICANN's seasoned, gray-bearded mail admin, who has been working with mail since UUCP days, was setting up a list server for the ten thousandth time, a task he can perform standing on his head, when a wild cosmic ray entered his skull, causing a neuron to misfire, whereupon the admin configured the list server wide open.
- ICANN's trained MCSE monkey clicked on a pretty icon and said "Look boss! Instead of pasting all 12000 addresses into Outlock, we can automagically send them with Visual Active SpamBlaster++!" whereupon he was given a bannana.
In the absence of decisive information, I think the latter is more likely. Which brings me to my point: organizations that undervalue technical people will embarass themselves technically; a fate which they richly deserve. Sooner or later, investors must get the message that when some suit decides "120K is way to much to pay a sysadmin, whatever that is. I can get a MCSE for half that!", he is steering the organization towards financial ruin.I am not claiming that good sysadmins don't make mistakes. I am claiming that good sysadmins have a sense of fear which is proportional to the magnitude of the disaster with which they are flirting. They also have a tendency to watch newly activated things for signs of impending doom. A lack of that sense and that tendency ought to disqualify one from being a sysadmin. A lack of good sysadmins ought to disqualify one from having a decisive effect on the internet.
I think you are presenting a false dichotomy of 'spaghetti code' vs. 'OO'. The majority of code is neither - it is relatively clean, structured procedural code. In other words, large tasks are decomposed into smaller tasks (recursively) until small, understandable functions are reached. No encapsulation needed.
Spaghetti code is code that uses a lot of GOTO's (or jumps) - typically written in BASIC or assembler. Structured code can be viewed as a hierarchy of black boxes with defined inputs and outputs; spaghetti code cannot. The transition to structured code took place (mostly) long before OO.
This (bashing of Randal) is almost certainly a troll, but I'll reply for the benefit of those who don't already know. Randal was convicted of three felony counts for performing tasks that essentially fell within his professional scope as sysadmin. Read the whole story. It's worth learning about, because many people who work with computers are in danger of similar prosecution if they piss off the wrong person. So before you condemn Randal, answer this: have you ever accessed a corporate information resource without explicit authorization? If you say no, and you work in a large, heterogeneous corporate environment, I can rest assured that you don't get much accomplished. If you say yes, you are confessing to the crux of the charges against Randal. The real problem here is that the average person (judge, juror) has so little understanding of how computers work that many innocent actions can be portrayed as criminal. Ever grepped a password file? Now picture how that could sound in court. Anyway, if someone has a serious reason to disbelieve Randal's side of the story, please post it or a link to it. In the 4+ years since the conviction, I haven't seen any.
Of course resistance to change is a survival characteristic, and a learned behavior to boot.
Couldn't resist. I remember having a miserable battle with a high school teacher who wanted me to 'centerize' the title on an essay.
Of course, none of this addresses freedom from bugs, which is certainly an important part of quality. But if we're aiming for Pirsigian quality, freedom from bugs is not enough.
That was really good. I just wish the Qualitarians had chosen some other word than Quality to describe what they're doing. Quality is a deep and connotative word and shouldn't be reduced to a label for a checklist wielded by an impostor.
I think that a fax is worth 100 emails, and a printed, FedExed letter is worth 10 faxes. Unfortunately, high-ranking executives don't read email. This ties in to the problem of addressing - whining to 'complaints@spamazon.com' will cause your carefully crafted communication to bounce off an illiterate and uncaring support droid. You need to research the name, title, and address/fax number of the responsible manager who is enforcing the undesirable policy.
In any event, I can't honestly participate in such a boycott. I dislike spamazon for numerous reasons, and no single change in their actions would induce me to buy from them.
I hope Java teaches everyone some painful lessons about what to avoid. A language born as a pimple on the butt of a moribund set-top box and thrust into the limelight artificially by corporate/marketing imperatives was doomed to failure from the outset. The only question is how long the decaying corpse will be left out on the street.
The main sucker for Java is the corporate manager riding herd on a bunch of keyboard monkeys he doesn't quite trust and hoping that a bondage-and-discipline language will limit the amount of feces they can throw. I've talked to a couple of these, and they pale with horror at the idea of unleashing their monkeys with Perl.
I think a secondary and less acknowledged motivation for the sucker choosing java is that it reduces the dynamic range between smart and dumb programmers, thus protecting his fragile ego. If Abigail coded Java, it would probably look just like Mike Monkey's Java. So the sucker manager could be spared the realization that he is an order of magnitude less intelligent than some of his programmers.
Oh, about that 'memory management' issue:
Try this: % perl -e'for(0..10) {for(0..1000) {my $x=7;} print `ps u $$`;}' and notice that the memory consumption doesn't increase.The point is that in 1999 there is no reason for an application programmer to have to worry about that. It seems like Java has stuck the application programmer with responsibility for memory management while attempting to hide the details, a predictably disastrous combination.
Anyway, this whole mess illustrates the perils of a proprietary programming language. A world that has C, Perl, Python and TCL should laugh Java off the planet.
Those who do not understand X are condemned to reinvent it, poorly.
(Not that you really need X for administrative tasks.)
(And not that I really understand X.)
The number one thing Compaq could do to show that they're serious about linux on servers is eliminate keyboard, video and mouse. These are relics of the "PC wannabe server" days. Sun's Netra realizes this. I want the BIOS fully accessible through the serial port. And if the machine locks up hard, I want to reboot it through the serial port (with adequate authentication.) And obviously, the RAID must be fully configurable/controllable through the serial port. Although I'm not sure what would be the best way to install Linux on a headless box.
In reality, it's easier and cheaper to build from scratch than to get satisfaction from these corporate giants. They talk the Linux talk, but they walk the Microsoft walk.
Wholesale: Products which offer a client/server interface to customer programs. Products like Oracle encourage ASP hosting because:
Retail:Desktop applications for consumers or employees. They make sense because:
Other Stuff:
The bottom line is that consumers never wanted to be sysadmins any more than they wanted to run nuclear power plants or global communication networks. They just want power, phone, and data conveniently on tap.
- The 'development loop' = type ':w' in vi; click reload in browser.
- Power and expressiveness - once you've had a car with power windows, it's hard to go back to manual cranked windows. Grep (the function, not the program), Map, and regexps eliminate much of what I would have coded in C.
- CPAN: everything you need under one roof. And in my experience, the quality is uniformly high.
These are the anti-perl arguments which keep popping up:- "It's a mere scripting language."
- "Compiled code is faster"
- "Perl is OK for small things, but comes up short for big, object-oriented team-built apps."
Just my 2c worth. Perl is like abortion, gun control, and vi vs emacs. People will love or hate it for very personal reasons, and not switch because of something they read onInterpreted languages have generally been less powerful. People tend to imagine a correlation between the pain/complexity of the development cycle and the value of the resulting code. Microsoft especially seems to encourage this thinking with their glittery IDE. Richard Stallman first pointed out the problem of the "mere scripting language" mentality in his essay describing the genesis of EMACS.
As many have pointed out, bandwidth usually chokes a web server. But assuming you've eliminated the CGI process creation hurdle via mod_perl or equivalent, and that you're accessing a database to generate the pages, I think you're more likely to bottleneck in the database.
On my web server, the heavy lifting is done by Apache, mod_perl, and MySQL. The DBMS stores the data, which is why the Perl code is fairly small and doesn't have complex data types (other than those from used modules). When someone talks about object-oriented programming for the web, I tend to wonder if he understands the power of the DBMS.
The only real problem with lynx is lack of support for tables. Currently, I'm using w3m, a text based browser with table support. It works great for ebay, streetprices, etc. I still use lynx for slashdot because the tables on slashdot don't really contribute anything.
That was much funnier than the original article. It sounds as if it's rooted in bitter reality.
Oh, in case you didn't read the press release, ITAA is DOJ's partner in this venture.