I thought the savior mentioned on your home page taught tolerance? Or is that "trollerance"?
Re:Robert Steel- A Great Speaker?
on
H2K2 Wrapup
·
· Score: 2
I haven't seen Steele speak, but I've seen the phenomenon you describe: an enthusiastic speaker who does things like "throw out details that excite the audience" gets reviewed as an excellent speaker, although any reasonably object analysis concludes otherwise. Many people tend to judge a speaker based on how he makes them feel, rather than on a dispassionate analysis of his delivery and material. I've seen people be wowed by transparent two-bit conmen with passionate delivery. I think it has to do with our desire to find leaders to look up to, or something.
You'd be amazed the amount of programming theory you can soak up reading through the perl6 mailing lists.:-)
I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP, for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).
If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory in general, and much, much more follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.
BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.
The quick hack you mentioned isn't the sort of thing I was thinking of, and in fact is possible without requiring special syntax in any language that supports closures, e.g. the Scheme for it would be (map (lambda (s) (display s)) foo). A lambda-lifting compiler can optimize that nicely. Nothing wrong with code like that, although it's perhaps a bit messier and less general in Perl:)
If Perl were restricted to its OO bits, with some of the legacy eliminated, and the documentation were changed so that newbies aren't encouraged in bad habits, it could become a somewhat more well-suited language for serious development. You'd probably end up with something more like Python or Ruby (btw, why am I discussing Perl with someone named "PythonOrRuby", anyway?)
I suspect with or without projects like Parrot, the major scripting languages will tend to converge, since they already primarily differ in terms of syntax and convenience features, and not that much in semantics.
The typing scheme you suggest for Perl 6 looks similar to "friend" classes in C++ - although in C++ it is enforced statically, which is an advantage for this sort of thing.
Actually, public/private/protected scoping is rather simplistic and old-fashioned, but perhaps convenient. Strictly speaking, you're better off using types properly, a.k.a. interfaces. A class can have a private interface (set of methods), a protected interface, and a public interface. Each of these interfaces is actually a distinct type, and thus can benefit from the usual type-checking and inference rules, i.e. you don't have to have special logic to deal with public/private/protected. Each client simply uses the interface which it has access to, and you aren't restricted to three different kinds of interface.
In general, type issues in programming languages have been very well researched, so if you're interested in that sort of thing, I suggest you pick up some books on functional programming and type theory. Haskell, ML, or OCaml are good languages to learn in this area. Learning programming language theory by watching Larry Wall is as ill-advised as learning to program by reading the Perl docs...
The problem is that natural selection should apply on these scales like it doesn on a planetary scale. Only the life forms that breed from planet to planet are likely to survive in the long run. Where are they?
It's a problem that may be too tough for natural selection to solve. In this comment, I explain why humans aren't likely to expand beyond their planet. Similar logic applies to any species. For a species to expand beyond its planet, it would need the ability to direct a substantial fraction of the resources available to it towards interstellar colonization. That's likely to require a great deal of cooperation. (Imagine a debate about this in, say, the US Congress!)
Natural selection favors competition, and only favors cooperation when there's an overall competitive benefit to the organism's direct reproductive success - often measured in terms of how many grandchildren it has. Natural selection doesn't apply here because the motivation to take actions with goals measured in centuries is non-existent, except possibility amongst very highly evolved intelligent creatures of a certain kind. There certainly aren't enough such creatures on Earth.
The overall logic of natural selection still applies, of course - you're correct when you say "Only the life forms that breed from planet to planet are likely to survive in the long run". But you can't assume that it's possible for life forms to reach this level of success. Intelligent life may be quite common in the universe, but they're all too busy dealing with their own petty day-to-day concerns and survival to fund credible interstellar colonization attempts.
Before any interstellar exploration or colonization attempts can take place, the initiating species has to agree to devote massive resources to the attempt. Taking Earth as an example: we haven't colonized a single planet in our solar system, in fact we haven't put a human on any other planets. It's hardly certain that we ever will get any further than Mars. The probes we've sent out aren't designed to return information from interstellar distances, and aren't likely to intersect with any other star systems in any case, except possibly when their orbit around the galactic core decays sufficiently.
Before any of this changes, a lot of taxpayers somewhere have to be convinced of the need to commit the resources in question. That'll make for an interesting societal debate - NOT! There's so little interest in this kind of thing in the general population of Earth, that an interstellar exploratory mission is effectively impossible - let alone a colonization mission. Committing funds today with a miniscule chance of receiving a return hundreds or thousands of years from now is just not a concept that any politician who wants to get re-elected is likely to support.
I'm not arguing that this is right, but it's realistic. The only way interstellar travel is likely to happen is if the necessary technologies reach price points where an group of mega-billionaires can get together and do it privately. Maybe that could happen in a few hundred years time, but I wouldn't count on it.
Certainly, you can write bad code in any language. But I've seen more bad code in Perl than any other single language. I attribute this to a few things, and one of them is the baby-talk issue raised by the original poster.
As for encouraging good practices, a couple of things that can help are strict object-oriented languages, and static typing - which is exactly why you think Eiffel is a candidate. If Ada weren't so unnecessarily bloated, it might come close, but it fails because it doesn't have proper OO.
By "strict", I mean languages that aren't procedural with OO tacked on, that don't allow "backsliding" into pure procedural coding. Not that procedural coding is necessarily bad, but when it gets out of hand - big and without proper structure - it can be. Better to force people to use classes - any organization is better than no organization.
Static typing helps in team environments where multiple programmers have to work on the same body of code. It provides a kind of self-documenting of the code that's guaranteed to be accurate (enforced by the compiler). It also helps tools understand the code, and can actually help point out deficiencies in the design (which is part of why "refactoring" has become such a big deal in the Java world).
It isn't the job of a language syntax to make someone a good programmer.
Syntax isn't even remotely the issue. Semantics is. It's when you get to the semantics that the issue of how you're encouraged to write code comes into play. This is an issue that can affect newbies as well as experts, because humans tend to be lazy, and it's easy to fall into bad habits. Perl is a language that encourages bad habits - it actively rewards them. This can be a good thing if you're trying to get some fairly small thing done quickly, where elegance and long-term maintainability are not big issues - the hacky shortcuts can be useful. But hacky shortcuts don't usually scale.
I'm fully aware that Perl "allows for" that kind of code. The words I used were "helps you write". Perhaps I should have said "encourages you to write". I responded to the poster about the "baby talk" because I've seen this phenomenon repeatedly: people who've developed bad code because the language doesn't discourage them from doing so.
Have you ever been asked to clean-up really bad perl? Many times "clean-up" is a total re-write.
Yes, more than once. In each case, a rewrite into a more appropriate language was the answer. I'm a professional developer, and I can write decent Perl, but what I use it for are admin scripts and text processing (I first began using Perl as a more powerful replacement for Awk).
The Perl systems I've been asked to look at have been entire applications where the coder started small and grew without any architecture. Once you hit about 4,000 lines of code or so, the problems start to appear. By the time you reach about 10,000 lines of code, the seams are creaking. Systems that need much more than this should not be written in Perl.
Perl is a kick-ass scripting language with incredibly powerful features and an enormous set of really useful libraries, but in any application large enough to need an "architecture", it's not appropriate.
Yes, you can use discipline and write well-structured Perl, but that's like writing object-oriented code in C - the language isn't helping you. For serious software development, use a language that helps you write clean, modular, readable, self-documenting code.
CVS is the tool I've used most often to crack the Windows monopoly at client companies. CVS is so ubiquitous and has so many advantages over VSS that it's not difficult to convince people to try it out. In some cases, I've even managed to get companies to set up a Linux box to do it.
I've never come across a single case of anyone who switched saying "I prefer VSS" or even "I miss such-and-such feature from VSS".
VSS is a hangover from the bad old days of PC computing, when everything was file-based and local-network oriented and the Internet was a mysterious thing best ignored. It doesn't seem to have managed to shake that legacy in the slightest.
What kind of support for refactoring do you have in mind? I do Java development with plenty of refactoring (using Eclipse), and most of the time a simple commit of the tree picks up all the changes. The only exceptions are new files, and renamed/deleted files. However, that's not always an issue, and when it is, it's usually not on a lot of files.
BTW, one thing that can help is to use a GUI interface to CVS. Eclipse integrates with CVS, and on Windows, WinCVS does a good job.
"An" preceeds a word that begins with a consonant. "A" preceeds a word beginning with a vowel.
Then how come you said "a word", "a consonant", and "a vowel"? Shouldn't that be "an word", "an consonant", and "an vowel"??
As an AC pointed out elsewhere, "Use of "a utility" is favored over "an utility" because, despite the spelling, the word begins with a consonant sound". To see this in action, compare e.g. "a utility" to "an understanding".
However, the problem I was talking about is actually a human one, not a technical one. Even if Simpleface delivers the ultimate usable user interface, as long as the people who implement end interfaces do things because of self-perceived technical coolness rather than usability, we'll continue to have bad interfaces. Although perhaps over time, the existence of good interfaces will eventually drive bad interfaces out of existence...
I'm not an expert, but I think you want StarOffice, which is kinda/sorta the commercial version of OpenOffice. Someone who knows more can clarify the difference...
maybe this is one reason open source companies fail?
<mini-rant>
I think you're right that not only open source companies, but all dot-coms and other businesses with an online presence, often do badly on the web because of sucky web sites. Industry knowledge of web site user interfaces is still in its infancy, apparently, and many many sites simply don't provide an easy way to fulfil obvious and simple customer needs. A big part of this may be because there's such a disconnect between the business side and the technical site-designing side - as long as website designers think that Flash is the way to enhance customer experience, websites are going to suck (not because of Flash specifically, but because of the attitude, in which "coolness" wins out over usefulness).
But, if you need to be able to rely on the application or system, it might be a Really Good Idea(TM) to use only the documented features. You might miss out on some helpful features, but you might also save your butt.
Darn! You mean I shouldn't be using the hidden "overclocking" option I found on my pacemaker? But I feel so alive with my heart going at a steady 180bpm all the time!
That might be the earliest example in the "PC"
industry, but IBM was much earlier - they used to (perhaps still do) charge big bucks to perform "upgrades" on customer mainframes by enabling hardware that was already in the machine.
Mainframes would ship with various disabled features. Remember these were room-size devices (well, multiple large cabinets which would fill up a big room). When the customer wanted an upgrade, an IBM technician would be sent out, he would rearrange some jumpers, enabling a feature, and the customer would receive a bill for e.g. $100,000 for a memory upgrade.
IBM made no apology for this: you were charged for the functionality you received, and the fact that the "upgrades" already existed inside the boxes in your computer room was irrelevant.
So perhaps one can blame IBM for having started the ball rolling on the idea of strong control of "intellectual property" by the vendor... I wonder if anyone back then "hacked" their own mainframes?
Thanks for the detailed response. All I've been trying to figure out is what real evidence you had for your hypothesis about corn. As you said, "It's really annoying when a profession that claims to be based on scientific principles ignores scientific principles". Substitute "person" for "profession", and that's where I was coming from.
Although I'll grant that I had to beat an anecdote out of you, I was after any kind of evidence at all.
Here's my "claim", based on evidence presented so far: corn is one of a number of high glycemic foods. Perhaps there are other factors along the lines of the glycemic index which also bear on weight gain in humans, which haven't yet been clearly identified, and perhaps corn is particularly high on this as-yet undiscovered metric. However, in the absence of any information about that, I'm more inclined to think - based on the evidence - that you might get similar results to those you've experienced by replacing some other high-glycemic index food in your diet. The "control" I referred to could be as simple as going back to eating corn, but cutting out all that bread. But I was rather disappointed to discover that you're not a nationally recognized research facility - why am I even bothering to talk to you??:oP
I don't have figures about the proportion of food products in American's diets. If all you're saying is that corn is the biggest proportion high-glycemic food in people's diets, and that this explains the effect, that's fine. Here in the northeast, I don't see a lot of evidence of corn being such a huge factor - you're not writing from Iowa, are you?;) I don't count high fructose corn syrup as part of the corn effect. Although I agree the consumption of it in soda etc. is a big factor, there's really no basis for claiming that it is somehow worse than other pure sugars, i.e. corn fructose is no better or worse than cane sugar fructose.
"It's a complex business, and humans don't seem to be good at intuitively analyzing situations that involve multiple interacting variables."
You are hanging out with the wrong humans; you need to hang out with engineers.
I hang out with quite a few engineers and academics, who are not at all exempt from the effect I'm talking about - in fact, they tend to overestimate the laser-like clarity of their own thought processes, and believe that their brains are much more like completely logical computing machines than is really the case.
I was making an "absolute" statement about human mental capacity: our brains evolved to deal with various problems related to things like social interaction and food-gathering, and they aren't in fact optimized to be general purpose computing devices. Tests like the Wason test (google for it if you're interested and not already familiar) demonstrate these limitations quite effectively. Although the smarter among us are capable of being trained to be pretty decent problem-solvers, that's the reason I said "intuitively" - because such training doesn't completely overcome our intuitive flaws.
I don't really share your cynicism about the medical profession - your average doctor is just trying to do what he can to earn a living while providing patients with some kind of results. People get bad results from doctors because many don't have the ability to distinguish the good ones from the bad ones, and because they rely too much on the doctors, and have too many prejudices and taboos which doctors can't overcome. I think you'd find that if you looked for a doctor who shared some of your perspectives on what constitutes effective treatment, you might find one, and you might be quite happy with the results. I've done that myself. I've also walked out on doctors who were morons. Try asking a doctor your question about high blood pressure treatment - you might find they'll tell you that in 85% of cases, the problem could be significantly reduced if the patient just exercised or dieted, but since that's often not a realistic expectation, the drugs are an easy way out just as much for the patient as the doctor. The same goes for a host of other ills, ranging from depression to diabetes. I suspect you'd find that many doctors are quite receptive to patients who want to help take responsibility for their own health, but unfortunately most people aren't really in a position to do this, since it requires a lot of work, including honest self-assessment, another thing people aren't good at.
As for drug companies, they're like any companies - profit-driven. It took decades for the simple cure for most stomach ulcers - i.e. antibiotics - to become accepted, and the discoverer had to swallow bacteria to do it. But Zantac etc. were very profitable, and the drug companies didn't want to hear about a solution that was already available in generic form. Evil, hypocritical? Nah, just business.
Perhaps I was wrong to say I don't share your cynicism - perhaps I have a different sort of cynicism. I don't expect anyone else to have my interests at heart, and I've found that to be quite a reasonable working hypothesis. And that way, I'm not disappointed when I find that someone's trying to screw me.;o)
With open source, the existence of a user community for a particular version is far more likely to produce people who are willing to maintain that version than in the commercial case. Companies will drop products even when there's a thriving user community, if the sales of the product in question are no longer commercially viable. (I've done this myself, with a software package I used to sell.) All products eventually become the responsibility of their user communities, but with open source, at least you have some options, up to and including paying someone to make enhancements and fix bugs for you. If all you have are binaries, you're SOL.
I experienced a similar thing when taking a helicopter ride in Hawaii - the helicopter operators there had recently had a rash of accidents, some of them fatal, which had been in the news. My g/f and I called up some of the companies, and asked them about their accident record, before picking which company to fly with. Luckily we had some outside info, otherwise we'd never have been able to tell anything at all about their safety records. One company, which had had multiple fatal accidents, would only acknowledge that "yes, they had had some 'incidents'". Further questioning resulted in evasive answers about things like the safety improvements that had been made since then.
So I agree: flyer beware! Don't expect that a company which is about to launch you into the air in a highly unstable and potentially very dangerous vehicle is going to be honest with you about the risks...
Stateful packet filters only check the first packet, and then only for the source, some flags, and then pass it through. Then it will make sure that following pieces of the conversation are limited to the same source, destination, and ports.
You're correct that a firewall which exclusively perform OSI layer-3&4 stateful inspection works like this. I was speaking loosely, since commercial firewalls tend to be less focused than this. Perhaps I should have said "stateful multi-layer inspection firewalls", which is a more accurate description of the hybrid nature of many "stateful" commercial firewalls. These firewalls perform inspection at multiple OSI layers, in many cases right up to layer 7, the application layer. Firewalls like this are quite capable of protecting against the HTTP attacks of Nimda and Code Red.
When I said "monitors the actual content of the connection", I again spoke too loosely: I was talking about the protocol content at the application layer, which is what layer-7 firewalls monitor.
So, properly configured, a stateful firewall still can NOT prevent you from being exploited.
Some of the layer-7 firewalls can prevent certain application exploits. Even something like this SSH hole could potentially be blocked by such a firewall, but it would depend on the specifics of the exploit and on what the firewall was checking for. But everything I said was intended to emphasize that firewalls do not provide a complete security solution, no matter how stateful they are or what network layer they operate at.
Yes, you read my reply wrong. I was replying to someone who suggested that this article indicated the need for firewalls, and pointing out that firewalls don't necessarily protect you from attacks like these.
I agree that a lot can be done with stateful firewalls. My point was really to dispel the notion that many people have that any old firewall will protect you from attacks like these. Although in the end, it's kinda futile, since just the word "firewall" conjures up visions of shiny magic boxes in people's heads, and overcoming the marketing is tough.
As for Nimda, IIRC it spread through HTTP attacks as well as email, so it was more of a worm than a virus. Regardless, it is related to firewalls in the way implied by the previous paragraph. There are people out there who believe that their firewall protects them from exploits like Nimda. In fact, Nimda is a great case in point, since even if you had a stateful firewall which prevent the Nimda HTTP hack, your workstations could still become infected via email, potentially ultimately infecting your servers, and once again proving that admins shouldn't believe everything the slick salesman told them about the $18,000 Checkpoint Firewall-1 they just bought.
Slashdot Mirror
I thought the savior mentioned on your home page taught tolerance? Or is that "trollerance"?
I haven't seen Steele speak, but I've seen the phenomenon you describe: an enthusiastic speaker who does things like "throw out details that excite the audience" gets reviewed as an excellent speaker, although any reasonably object analysis concludes otherwise. Many people tend to judge a speaker based on how he makes them feel, rather than on a dispassionate analysis of his delivery and material. I've seen people be wowed by transparent two-bit conmen with passionate delivery. I think it has to do with our desire to find leaders to look up to, or something.
I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP, for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).
If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory in general, and much, much more follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.
BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.
You've probably come across this before, but here's a nice piece about ML's type system from a partly Perl perspective.
If Perl were restricted to its OO bits, with some of the legacy eliminated, and the documentation were changed so that newbies aren't encouraged in bad habits, it could become a somewhat more well-suited language for serious development. You'd probably end up with something more like Python or Ruby (btw, why am I discussing Perl with someone named "PythonOrRuby", anyway?)
I suspect with or without projects like Parrot, the major scripting languages will tend to converge, since they already primarily differ in terms of syntax and convenience features, and not that much in semantics.
The typing scheme you suggest for Perl 6 looks similar to "friend" classes in C++ - although in C++ it is enforced statically, which is an advantage for this sort of thing.
Actually, public/private/protected scoping is rather simplistic and old-fashioned, but perhaps convenient. Strictly speaking, you're better off using types properly, a.k.a. interfaces. A class can have a private interface (set of methods), a protected interface, and a public interface. Each of these interfaces is actually a distinct type, and thus can benefit from the usual type-checking and inference rules, i.e. you don't have to have special logic to deal with public/private/protected. Each client simply uses the interface which it has access to, and you aren't restricted to three different kinds of interface.
In general, type issues in programming languages have been very well researched, so if you're interested in that sort of thing, I suggest you pick up some books on functional programming and type theory. Haskell, ML, or OCaml are good languages to learn in this area. Learning programming language theory by watching Larry Wall is as ill-advised as learning to program by reading the Perl docs...
It's a problem that may be too tough for natural selection to solve. In this comment, I explain why humans aren't likely to expand beyond their planet. Similar logic applies to any species. For a species to expand beyond its planet, it would need the ability to direct a substantial fraction of the resources available to it towards interstellar colonization. That's likely to require a great deal of cooperation. (Imagine a debate about this in, say, the US Congress!)
Natural selection favors competition, and only favors cooperation when there's an overall competitive benefit to the organism's direct reproductive success - often measured in terms of how many grandchildren it has. Natural selection doesn't apply here because the motivation to take actions with goals measured in centuries is non-existent, except possibility amongst very highly evolved intelligent creatures of a certain kind. There certainly aren't enough such creatures on Earth.
The overall logic of natural selection still applies, of course - you're correct when you say "Only the life forms that breed from planet to planet are likely to survive in the long run". But you can't assume that it's possible for life forms to reach this level of success. Intelligent life may be quite common in the universe, but they're all too busy dealing with their own petty day-to-day concerns and survival to fund credible interstellar colonization attempts.
Before any of this changes, a lot of taxpayers somewhere have to be convinced of the need to commit the resources in question. That'll make for an interesting societal debate - NOT! There's so little interest in this kind of thing in the general population of Earth, that an interstellar exploratory mission is effectively impossible - let alone a colonization mission. Committing funds today with a miniscule chance of receiving a return hundreds or thousands of years from now is just not a concept that any politician who wants to get re-elected is likely to support.
I'm not arguing that this is right, but it's realistic. The only way interstellar travel is likely to happen is if the necessary technologies reach price points where an group of mega-billionaires can get together and do it privately. Maybe that could happen in a few hundred years time, but I wouldn't count on it.
As for encouraging good practices, a couple of things that can help are strict object-oriented languages, and static typing - which is exactly why you think Eiffel is a candidate. If Ada weren't so unnecessarily bloated, it might come close, but it fails because it doesn't have proper OO.
By "strict", I mean languages that aren't procedural with OO tacked on, that don't allow "backsliding" into pure procedural coding. Not that procedural coding is necessarily bad, but when it gets out of hand - big and without proper structure - it can be. Better to force people to use classes - any organization is better than no organization.
Static typing helps in team environments where multiple programmers have to work on the same body of code. It provides a kind of self-documenting of the code that's guaranteed to be accurate (enforced by the compiler). It also helps tools understand the code, and can actually help point out deficiencies in the design (which is part of why "refactoring" has become such a big deal in the Java world).
It isn't the job of a language syntax to make someone a good programmer.
Syntax isn't even remotely the issue. Semantics is. It's when you get to the semantics that the issue of how you're encouraged to write code comes into play. This is an issue that can affect newbies as well as experts, because humans tend to be lazy, and it's easy to fall into bad habits. Perl is a language that encourages bad habits - it actively rewards them. This can be a good thing if you're trying to get some fairly small thing done quickly, where elegance and long-term maintainability are not big issues - the hacky shortcuts can be useful. But hacky shortcuts don't usually scale.
That's easy, it's 1.6 arseloads. A little more in Texas.
For more information, I suggest the All-Purpose *load Unit Conversion Calculator.
Yes, more than once. In each case, a rewrite into a more appropriate language was the answer. I'm a professional developer, and I can write decent Perl, but what I use it for are admin scripts and text processing (I first began using Perl as a more powerful replacement for Awk).
The Perl systems I've been asked to look at have been entire applications where the coder started small and grew without any architecture. Once you hit about 4,000 lines of code or so, the problems start to appear. By the time you reach about 10,000 lines of code, the seams are creaking. Systems that need much more than this should not be written in Perl.
Perl is a kick-ass scripting language with incredibly powerful features and an enormous set of really useful libraries, but in any application large enough to need an "architecture", it's not appropriate.
Yes, you can use discipline and write well-structured Perl, but that's like writing object-oriented code in C - the language isn't helping you. For serious software development, use a language that helps you write clean, modular, readable, self-documenting code.
Damn, I'm going to have to buy a whole assload of chalk now!!
CVS is the tool I've used most often to crack the Windows monopoly at client companies. CVS is so ubiquitous and has so many advantages over VSS that it's not difficult to convince people to try it out. In some cases, I've even managed to get companies to set up a Linux box to do it.
I've never come across a single case of anyone who switched saying "I prefer VSS" or even "I miss such-and-such feature from VSS".
VSS is a hangover from the bad old days of PC computing, when everything was file-based and local-network oriented and the Internet was a mysterious thing best ignored. It doesn't seem to have managed to shake that legacy in the slightest.
BTW, one thing that can help is to use a GUI interface to CVS. Eclipse integrates with CVS, and on Windows, WinCVS does a good job.
"A" preceeds a word beginning with a vowel.
Then how come you said "a word", "a consonant", and "a vowel"? Shouldn't that be "an word", "an consonant", and "an vowel"??
As an AC pointed out elsewhere, "Use of "a utility" is favored over "an utility" because, despite the spelling, the word begins with a consonant sound". To see this in action, compare e.g. "a utility" to "an understanding".
However, the problem I was talking about is actually a human one, not a technical one. Even if Simpleface delivers the ultimate usable user interface, as long as the people who implement end interfaces do things because of self-perceived technical coolness rather than usability, we'll continue to have bad interfaces. Although perhaps over time, the existence of good interfaces will eventually drive bad interfaces out of existence...
maybe this is one reason open source companies fail?
<mini-rant> I think you're right that not only open source companies, but all dot-coms and other businesses with an online presence, often do badly on the web because of sucky web sites. Industry knowledge of web site user interfaces is still in its infancy, apparently, and many many sites simply don't provide an easy way to fulfil obvious and simple customer needs. A big part of this may be because there's such a disconnect between the business side and the technical site-designing side - as long as website designers think that Flash is the way to enhance customer experience, websites are going to suck (not because of Flash specifically, but because of the attitude, in which "coolness" wins out over usefulness).
'nuff said. :)
Not quite - how the heck do you get out of emacs once you're done playing? I'm sending this darn Linux PC back to Walmart right away!
Darn! You mean I shouldn't be using the hidden "overclocking" option I found on my pacemaker? But I feel so alive with my heart going at a steady 180bpm all the time!
Mainframes would ship with various disabled features. Remember these were room-size devices (well, multiple large cabinets which would fill up a big room). When the customer wanted an upgrade, an IBM technician would be sent out, he would rearrange some jumpers, enabling a feature, and the customer would receive a bill for e.g. $100,000 for a memory upgrade.
IBM made no apology for this: you were charged for the functionality you received, and the fact that the "upgrades" already existed inside the boxes in your computer room was irrelevant.
So perhaps one can blame IBM for having started the ball rolling on the idea of strong control of "intellectual property" by the vendor... I wonder if anyone back then "hacked" their own mainframes?
Based on the foolproof new EU diagnostic medical procedures, I am sorry to inform you that you have terminal chlamydia, and have 6 weeks to live.
Oh yes, and you're color blind...
Although I'll grant that I had to beat an anecdote out of you, I was after any kind of evidence at all.
Here's my "claim", based on evidence presented so far: corn is one of a number of high glycemic foods. Perhaps there are other factors along the lines of the glycemic index which also bear on weight gain in humans, which haven't yet been clearly identified, and perhaps corn is particularly high on this as-yet undiscovered metric. However, in the absence of any information about that, I'm more inclined to think - based on the evidence - that you might get similar results to those you've experienced by replacing some other high-glycemic index food in your diet. The "control" I referred to could be as simple as going back to eating corn, but cutting out all that bread. But I was rather disappointed to discover that you're not a nationally recognized research facility - why am I even bothering to talk to you?? :oP
I don't have figures about the proportion of food products in American's diets. If all you're saying is that corn is the biggest proportion high-glycemic food in people's diets, and that this explains the effect, that's fine. Here in the northeast, I don't see a lot of evidence of corn being such a huge factor - you're not writing from Iowa, are you? ;) I don't count high fructose corn syrup as part of the corn effect. Although I agree the consumption of it in soda etc. is a big factor, there's really no basis for claiming that it is somehow worse than other pure sugars, i.e. corn fructose is no better or worse than cane sugar fructose.
I hang out with quite a few engineers and academics, who are not at all exempt from the effect I'm talking about - in fact, they tend to overestimate the laser-like clarity of their own thought processes, and believe that their brains are much more like completely logical computing machines than is really the case.
I was making an "absolute" statement about human mental capacity: our brains evolved to deal with various problems related to things like social interaction and food-gathering, and they aren't in fact optimized to be general purpose computing devices. Tests like the Wason test (google for it if you're interested and not already familiar) demonstrate these limitations quite effectively. Although the smarter among us are capable of being trained to be pretty decent problem-solvers, that's the reason I said "intuitively" - because such training doesn't completely overcome our intuitive flaws.
I don't really share your cynicism about the medical profession - your average doctor is just trying to do what he can to earn a living while providing patients with some kind of results. People get bad results from doctors because many don't have the ability to distinguish the good ones from the bad ones, and because they rely too much on the doctors, and have too many prejudices and taboos which doctors can't overcome. I think you'd find that if you looked for a doctor who shared some of your perspectives on what constitutes effective treatment, you might find one, and you might be quite happy with the results. I've done that myself. I've also walked out on doctors who were morons. Try asking a doctor your question about high blood pressure treatment - you might find they'll tell you that in 85% of cases, the problem could be significantly reduced if the patient just exercised or dieted, but since that's often not a realistic expectation, the drugs are an easy way out just as much for the patient as the doctor. The same goes for a host of other ills, ranging from depression to diabetes. I suspect you'd find that many doctors are quite receptive to patients who want to help take responsibility for their own health, but unfortunately most people aren't really in a position to do this, since it requires a lot of work, including honest self-assessment, another thing people aren't good at.
As for drug companies, they're like any companies - profit-driven. It took decades for the simple cure for most stomach ulcers - i.e. antibiotics - to become accepted, and the discoverer had to swallow bacteria to do it. But Zantac etc. were very profitable, and the drug companies didn't want to hear about a solution that was already available in generic form. Evil, hypocritical? Nah, just business.
Perhaps I was wrong to say I don't share your cynicism - perhaps I have a different sort of cynicism. I don't expect anyone else to have my interests at heart, and I've found that to be quite a reasonable working hypothesis. And that way, I'm not disappointed when I find that someone's trying to screw me. ;o)
With open source, the existence of a user community for a particular version is far more likely to produce people who are willing to maintain that version than in the commercial case. Companies will drop products even when there's a thriving user community, if the sales of the product in question are no longer commercially viable. (I've done this myself, with a software package I used to sell.) All products eventually become the responsibility of their user communities, but with open source, at least you have some options, up to and including paying someone to make enhancements and fix bugs for you. If all you have are binaries, you're SOL.
So I agree: flyer beware! Don't expect that a company which is about to launch you into the air in a highly unstable and potentially very dangerous vehicle is going to be honest with you about the risks...
You're correct that a firewall which exclusively perform OSI layer-3&4 stateful inspection works like this. I was speaking loosely, since commercial firewalls tend to be less focused than this. Perhaps I should have said "stateful multi-layer inspection firewalls", which is a more accurate description of the hybrid nature of many "stateful" commercial firewalls. These firewalls perform inspection at multiple OSI layers, in many cases right up to layer 7, the application layer. Firewalls like this are quite capable of protecting against the HTTP attacks of Nimda and Code Red.
When I said "monitors the actual content of the connection", I again spoke too loosely: I was talking about the protocol content at the application layer, which is what layer-7 firewalls monitor.
So, properly configured, a stateful firewall still can NOT prevent you from being exploited.
Some of the layer-7 firewalls can prevent certain application exploits. Even something like this SSH hole could potentially be blocked by such a firewall, but it would depend on the specifics of the exploit and on what the firewall was checking for. But everything I said was intended to emphasize that firewalls do not provide a complete security solution, no matter how stateful they are or what network layer they operate at.
I agree that a lot can be done with stateful firewalls. My point was really to dispel the notion that many people have that any old firewall will protect you from attacks like these. Although in the end, it's kinda futile, since just the word "firewall" conjures up visions of shiny magic boxes in people's heads, and overcoming the marketing is tough.
As for Nimda, IIRC it spread through HTTP attacks as well as email, so it was more of a worm than a virus. Regardless, it is related to firewalls in the way implied by the previous paragraph. There are people out there who believe that their firewall protects them from exploits like Nimda. In fact, Nimda is a great case in point, since even if you had a stateful firewall which prevent the Nimda HTTP hack, your workstations could still become infected via email, potentially ultimately infecting your servers, and once again proving that admins shouldn't believe everything the slick salesman told them about the $18,000 Checkpoint Firewall-1 they just bought.