> the new ASUS motherboads have COP : CPU Overheating Protection, which switches off the machine when temp goes baloony.
I have an ASUS board a bit over a year old. I do intensive number crunching on my home machines, with some jobs running over a week of continual 100% CPU time. Being AMDs, they tend to run kind of hot, too, so sometimes I put a room fan blowing along the wall behind the boxes' exhausts.
At any rate, one warm day I had the A/C set kind of high and the room fan aimed elsewhere, and one of the boxes overheated while I was out to lunch. But the board halted it for me. When I came home it was making a horrible alarm sound, and unfortunately I had to reboot because I couldn't figure out how to make it restart after the alarm, but at least I didn't get a fire, nor even any overheat damage to the CPU.
BTW, Linuxers/BSDers who have temperature sensors on their motherboards may want to run lm_sensors and a display such as gkrellm in order to keep an eye on your system temperatures when you are around.
> I just don't get why the state that has most of the Mojave Desert can't set up a decent solar energy system, at least for the bottom half of the state.
I don't understand why they don't just hook generators up to all the exercise machines in gymns all over the state,
> Despite the truth that only the informed few know, the ignorant masses will much sooner believe Microsoft because **money talks** (trough PR).
"Trough PR" - I like that. (I suppose you meant "through PR", but if so the slip was felicitous.)
At any rate, with citizens' distrust of big corporations at an all time high, this is probably the best time for anti-MS PR to kick into high gear. Eggs won't help, but let your voices be heard.
> Palladium : was originally the name of the statue of Pallas-Athenas, which was supposed to protect the city of Troie. Which was later invaded by greeks which used a subterfuge which will be known for centuries as trojan horses.
Funnier yet when you find out that some people think the Palladium was actually a gigantic dildo.
No, stop, don't mod this up as 'funny' - I'm serious.
On ABC's "World News Now" late-night news program they did a nice tribute to John, and a surprisingly long one for a mainstream media outlet. (I'd estimate about two minutes in a thirty-minus-commercials program.) They showed and played clips of the Who while they talked about his life.
Also, right after their tribute came their weather segment, where they traditionally play music and show zoo clips while listing world-wide temperatures. This morning they played "Boris the Spider" during the clip, announcing it as one of John's songs before they started. (Also, amusingly, the zoo clip was of a small flock of penquins wandering through a town.)
I love the irony of having that post moderated down as "troll".
Re:What does this mean for the industry as a whole
on
Salon in Dire Straits
·
· Score: 1, Troll
> Mod me flamebait if you will, but you must admit that it is a big sin here to admit that you believe in Capitalism and suppor those who try to make a living selling anything that has to do with intellectual property.
In my experience, the only time I get moderated down to Hell predictably is when I make too vigorous a critique of exactly those things that you think are a "sin" to espouse on Slashdot.
I had a real good example 2-3 weeks ago, but unfortunately it has already scrolled off my posting history
> How much money do MY bugs cost? Do fatal bugs in my code actually RETURN productivity to the workforce? Do bugs in my code actually make money for the US economy?
No, because when your game blows up right when I kick down the door to beat Werdna's 455, I have to generate a new character and start over at Level 1.
What was supposed to merely while away a slow morning becomes a day-long project, and that is what hurts the economy.
> Developers operate in an environment driven almost completely by market forces.
Of course, this report is just one of many symptoms that the public is getting sick of cr4ppy software. Development may always be driven by market forces, but the nature of those forces seems to be changing. Hopefully in a few years the dominant market force will be "get it right or get out of the business".
> One things for sure: there are a few more timebombs ticking away out there. Enron may have been just the first of many.
After following the news, watching the PBS special, and reflecting on human nature, I've come to the conclusion that this is the norm rather than the exception.
Our whole economy (and indeed, most of our government) is focused on keeping share prices high at all costs. For companies, this means optimize the quarterly report at all costs. (Or even more frequently than quarterly, for an increasing number of companies.) So they are re-wiring themselves to be all marketing on the front side and all creative bookkeeping on the back, with a big gaping hole in the middle where the genuine power of the economy lies^w used to lie.
This does not bode well for the long-term health of our economy. The metaphor "house of cards" comes to mind.
> But recently someone on a local usenet newsgroup made this same claim you are making, and in the same note tried to imply that the US health care system is perfectly fine because of it's capitalist nature. (as opposed to the evil of socialism) So I was curious and started looking for some facts. What I found is that life expectancy in the US is less than other G8 nations which have socialized health care... Furthermore the infant mortality rate is also higher in the US compared to the other G8 nations... On top of that, the amount spent on health care in the US per capita is much greater...
Ah, but you're evaluating it on the wrong basis. The US healthcare system is optimized for its benefit to shareholders, not for its benefit to patients.
> "It could be used, for example, if there was threat of a detonation of some type of a remote-controlled device. We could jam the frequencies to make sure nobody could send a signal to that bomb."
And since they were courteous enough to announce this in advance, the (hypothetical) bombers will simply design their remote controls to use fire and police frequencies, which you can bet will not be jammed.
I suspect type-checking a program that way would be an NP-complete problem, if not outright EXP.
Also, I used to work in a shop where all the code was VAX BASIC and I ended up becoming the Debug Guru. Disgustingly, about 2/3 of the bugs were a result of automatic variable declarations like Tablizer seems to be advocating. Not so much type problems as variable name mismatches:
Alpha=x+2 ... Alph=Alph+1 ... print Alpha
kind of thing.
People who want bug-free code use languages that require variable definitions.
[FWIW, the second most common source of bugs was stashing something in a global variable and expecting the value to be the same the next time the subprogram that assigned the value was called. A cut-n-paste mentality meant that they had hundreds of functions using the same global variable.]
BTW, since he mentions that his programs aren't full of type-checking code, I'm starting to wonder whether he even knows what we mean by "dynamic type checking", or at least whether he's ever written a non-trivial program in a DTCing language.
> But how will the GPL license of the software affect their works?
This seems to be a growing issue. E.g., there has been a recent discussion on the Freeciv mailing list, where they are actively trying to get their hands on improved graphics but want to be rigorous about licensing issues. (And alas, they had to reject some nice tilesets that various people have submitted because of dubious licensing status.)
It seems to me that this would be worth writing the FSF about and seeing whether they are interested in providing a "content" license. They recently produced their GNU Free Documentation License in recognition that the GPL doesn't cover everything, but that does not seem to be completely apt for game artwork (and other game content) either.
They do link to another Design Science License for data, which you may want to evaluate. But IMO it would be great if you could get the FSF to produce and defend a free content license (GCL?) that was explicitly defined to work like and with the GPL.
The reason I think the FSF might take an interest is because so much new GPL'd software is GUI-oriented and requires graphics of one sort or another, and a basic corpus of free/licensed graphics might help free software take off in new areas like it has in infrastructure.
> A book about Algorithms and Data Structures in general
Other than the business-oriented stuff, this is probably the most important pair of items on the list, not something to be lumped together with the odds-and-ends at the bottom.
This is the stuff that takes programmers from an intuitive approach to the extremes of well-informed effectiveness.
Also, it's not specific to any particular language, OS, or other technology that will be out of the limelight before you finish reading your booklist.
> Because the problem isn't one of compilers, or ironically of technology. Its an attitude and approach problem. Its the lack of peer review of architecture and design that is the problem.
I would agree with your middle sentence, though I would generalize it to "humans are the weakest link in software production".
So all I'm suggesting with the language bit is to use languages that make the computer do some low-level tedious checking that computers are so good at and humans are so prone to errors at, especially when done in large quantities.
And as far as I'm concerned, poor language choice is just an instance of your "attitude and approach problem". There are good reasons to use one language over another, but those are hardly ever the reasons you hear people use to justify their choices.
In other branches of this thread the discussion has focused on static type checking. I wish programmers would learn that rigorous type definitions aren't an unrewarding chore but rather an opportunity. Think of them as constraints embedded in your code. Sure, I'd rather have a general constraint that told the compiler "no bugs, please", but since that appears to be impossible I'm happy to have whatever lesser constraints that are possible.
In my experience the time spent in type definitions pays off many-fold over the long haul, and better yet they mean I can spend more time thinking about what my program is doing rather than getting bogged down in the details of how it does it. I offload the most tedious details by doing the declarations up front, and then concentrate almost exclusively on the abstract logic of the program. And my bugs are almost always errors in my algorithmic logic; I don't waste a minute tracking down the truly stupid stuff.
> Let me put it in a form that even you could understand: Take the smartest, best programmer in a room. Let me come up with a solution to a non-trivial set of requirements using whatever language you think "helps".
Heh. I see you freudianly substituted "me" for "him". Let's leave it as an empirical question whether you would be the smartest, best programmer in the room.
> I guaran-g*ddamn-tee it that the program will suck. It may suck obviously, it may suck subtley, but it will suck. That's because one person isn't smart enough.
This conforms to our ideals -- most particularly to our anti-elitist democratic ideals -- but is it true in practice? If we were talking about highly qualified rocket scientists designing a rocket I would agree that your claim was (usually) right.
But in the realities of the IT industry, I would guess that for a team of five or more developers the best one is probably an order of magnitude better than the group average, and for larger groups that might extend to 2-3 orders of magnitude. (The SEI only finds about a single order of magnitude between the best and the worst that they test, but remember that they are testing people in SE classes approximately equivalent to graduate level study, hardly a random selection of IT employees. I've worked on projects with people who couldn't be relied on for such trivia as changing the backup tape every day or logging out of their terminal when they went home, and yet they were expected to participate as peers in the development of complex software.)
At any rate, I seriously doubt that your claim holds in practice in the IT industry. It's a fortunate project that has a team where all, or even half, of the members can contribute to the design instead of distracting the more qualified individuals with idiotic suggestions and writing crap code that ultimately has to be debugged by the gurus because the people who wrote it don't even understand it.
Also, your claim is a really odd response to my post. I don't think anyone, anywhere, has ever suggested that compilers should (or even could) replace the human creativity that goes into a program. What some of us are suggesting instead is that the compiler should have to do all the 5417-shoveling, freeing humans up to focus on the creative aspects almost exclusively. (Would you rather use a 417-shoveling language, or shovel it yourself?)
> These aren't little things - they're ways of fundamentally changing the way programming is done.
IMO the single most important thing we need to do is to quit thinking of ourselves as programmers and start thinking of ourselves as problem solvers.
Once you've solved the problem, writing the code is a straightforward (albeit tedious) task. Unfortunately, there's a myriad books and classes teaching "how to program", but not nearly so many about "how to think out a problem".
I have previously worked as a TA for CS classes, and it always amazed me how many people would bring in three pages of code intended to solve a five- or ten-line problem, and even though their code might compile perfectly they obviously didn't have the slighest idea about how to go about actually solving the problem. (Indeed, as often as not they didn't even understand the question yet.)
And though it's easy to dismiss this by saying that those people shouldn't have been in CS and probably never finished, I'm sad to say that the same problem is rampant in industry as well, except there the same kind of people are put in responsible positions on very large and complex projects.
At any rate, back to what you said, once you know the solution to the problem you can easily pick the language -- and algorithm -- most suitable for telling a CPU how to carry out that solution. If people would learn to think of their jobs in those terms, I suspect software would immediately start getting better.
> In my experience there is a tradeoff. Languages that tend to do more "static typing" do catch stuff that interpreted (dynamic) languages may not or not as early, but dynamically languages are often (potentially) easier to read because there is less code devoted to formalities and conversions. IOW, they reduce bugs by making the code smaller and easier to review by eye IMO.
Let me start by saying that I don't have any particular grudge against dynamic type checking: when given a free choice of language of implementation, my second most common choice is a DTCing language.
But there are a couple of points that need to be made about DTCing languages.
First, DTCing languages depend on the programmer to remember to do the type checks wherever they are needed, and programmers are the weakest link in programming projects (well, excluding managers and customers). I would guess that forgetting a check is essentially random, depending only on the individual programmer and the day of the week. So for a given programming team the rate of forgets is going to be essentially constant on timescales greater than a week. The result is that the number of forgets is going to be proportional to the size of your project. And unless your test suite is guaranteed to trace out every path through the code, the number of type errors that ship to your customer is going to be proportional to the size of the project. Compare this to a language that demands strict type definitions and static type checking, where the number of type errors that ship to your customer is zero.
Second, re this -
> IOW, they reduce bugs by making the code smaller and easier to review by eye IMO.
I disagree with both those assertions, and thus with the conclusion that DTCing languages reduce bugs. Re the first assertion, sure, you get to leave out the type definitions, but you have to sprinkle your code liberally with dynamic checks instead -- probably resulting in more code when you have a big program that uses lots of types. Re the second assertion, I find that rigorous type definitions actually make code easier to read, because all the complex type definitions and variables' types are declared exactly once each, after which you can think of them as abstractions when you are reading the rest of the code.
So what I find is that I only use the DTCing language for small one-off tasks such as doing a quick but non-trivial calculation, rarely more than a page of code, few data types, and data entry by myself. For big, or even medium-sized projects, I feel like I come out hours ahead by using a strait-jacket language that busts me at compile time when I neglect to say what I mean and mean what I say.
> It is like chosing between a thick helmet that blocks your view of some dangers, but protects you from bonking, or wear no helmet so that you can see and move more nimbly to avoid the dangers.
IMO it's more like deciding whether or not to take along a mine detector when you know you're entering a minefield.
> What I would like to see is pre-processors for dynamic languages that flag "suspicious" stuff, but don't outright prevent running.
Yeah, that would be nice, but I don't see how it would be possible. What's "suspicious" if you don't tell the compiler/interpreter what to expect? And if you do tell it what to expect, you're doing exactly what STCing languages require.
Slashdot Mirror
> the new ASUS motherboads have COP : CPU Overheating Protection, which switches off the machine when temp goes baloony.
I have an ASUS board a bit over a year old. I do intensive number crunching on my home machines, with some jobs running over a week of continual 100% CPU time. Being AMDs, they tend to run kind of hot, too, so sometimes I put a room fan blowing along the wall behind the boxes' exhausts.
At any rate, one warm day I had the A/C set kind of high and the room fan aimed elsewhere, and one of the boxes overheated while I was out to lunch. But the board halted it for me. When I came home it was making a horrible alarm sound, and unfortunately I had to reboot because I couldn't figure out how to make it restart after the alarm, but at least I didn't get a fire, nor even any overheat damage to the CPU.
BTW, Linuxers/BSDers who have temperature sensors on their motherboards may want to run lm_sensors and a display such as gkrellm in order to keep an eye on your system temperatures when you are around.
> I just don't get why the state that has most of the Mojave Desert can't set up a decent solar energy system, at least for the bottom half of the state.
I don't understand why they don't just hook generators up to all the exercise machines in gymns all over the state,
> Despite the truth that only the informed few know, the ignorant masses will much sooner believe Microsoft because **money talks** (trough PR).
"Trough PR" - I like that. (I suppose you meant "through PR", but if so the slip was felicitous.)
At any rate, with citizens' distrust of big corporations at an all time high, this is probably the best time for anti-MS PR to kick into high gear. Eggs won't help, but let your voices be heard.
> Scares me and intrigues me at the same time...
And you thought those lungs were fake. They're the result of exercise, I'm telling you!
> Palladium : was originally the name of the statue of Pallas-Athenas, which was supposed to protect the city of Troie. Which was later invaded by greeks which used a subterfuge which will be known for centuries as trojan horses.
Funnier yet when you find out that some people think the Palladium was actually a gigantic dildo.
No, stop, don't mod this up as 'funny' - I'm serious.
What did they do, charge us the price for four tenors?
> Good news guys, if we manage to trigger a nuclear winter, it will only take 1.4 millions years to have forests back instead of 10 !
>
Cool! With the saved space and reduced food requirements I can now plan on taking four girls instead of three!
On ABC's "World News Now" late-night news program they did a nice tribute to John, and a surprisingly long one for a mainstream media outlet. (I'd estimate about two minutes in a thirty-minus-commercials program.) They showed and played clips of the Who while they talked about his life.
Also, right after their tribute came their weather segment, where they traditionally play music and show zoo clips while listing world-wide temperatures. This morning they played "Boris the Spider" during the clip, announcing it as one of John's songs before they started. (Also, amusingly, the zoo clip was of a small flock of penquins wandering through a town.)
That physically hurt when I read it.
I love the irony of having that post moderated down as "troll".
> Mod me flamebait if you will, but you must admit that it is a big sin here to admit that you believe in Capitalism and suppor those who try to make a living selling anything that has to do with intellectual property.
In my experience, the only time I get moderated down to Hell predictably is when I make too vigorous a critique of exactly those things that you think are a "sin" to espouse on Slashdot.
I had a real good example 2-3 weeks ago, but unfortunately it has already scrolled off my posting history
> How much money do MY bugs cost? Do fatal bugs in my code actually RETURN productivity to the workforce? Do bugs in my code actually make money for the US economy?
No, because when your game blows up right when I kick down the door to beat Werdna's 455, I have to generate a new character and start over at Level 1.
What was supposed to merely while away a slow morning becomes a day-long project, and that is what hurts the economy.
> Developers operate in an environment driven almost completely by market forces.
Of course, this report is just one of many symptoms that the public is getting sick of cr4ppy software. Development may always be driven by market forces, but the nature of those forces seems to be changing. Hopefully in a few years the dominant market force will be "get it right or get out of the business".
> One things for sure: there are a few more timebombs ticking away out there. Enron may have been just the first of many.
After following the news, watching the PBS special, and reflecting on human nature, I've come to the conclusion that this is the norm rather than the exception.
Our whole economy (and indeed, most of our government) is focused on keeping share prices high at all costs. For companies, this means optimize the quarterly report at all costs. (Or even more frequently than quarterly, for an increasing number of companies.) So they are re-wiring themselves to be all marketing on the front side and all creative bookkeeping on the back, with a big gaping hole in the middle where the genuine power of the economy lies^w used to lie.
This does not bode well for the long-term health of our economy. The metaphor "house of cards" comes to mind.
> But recently someone on a local usenet newsgroup made this same claim you are making, and in the same note tried to imply that the US health care system is perfectly fine because of it's capitalist nature. (as opposed to the evil of socialism) So I was curious and started looking for some facts. What I found is that life expectancy in the US is less than other G8 nations which have socialized health care... Furthermore the infant mortality rate is also higher in the US compared to the other G8 nations... On top of that, the amount spent on health care in the US per capita is much greater...
Ah, but you're evaluating it on the wrong basis. The US healthcare system is optimized for its benefit to shareholders, not for its benefit to patients.
> "It could be used, for example, if there was threat of a detonation of some type of a remote-controlled device. We could jam the frequencies to make sure nobody could send a signal to that bomb."
And since they were courteous enough to announce this in advance, the (hypothetical) bombers will simply design their remote controls to use fire and police frequencies, which you can bet will not be jammed.
kind of thing.> In which case, you have no idea what x is.
I suspect type-checking a program that way would be an NP-complete problem, if not outright EXP.
Also, I used to work in a shop where all the code was VAX BASIC and I ended up becoming the Debug Guru. Disgustingly, about 2/3 of the bugs were a result of automatic variable declarations like Tablizer seems to be advocating. Not so much type problems as variable name mismatches:
People who want bug-free code use languages that require variable definitions.
[FWIW, the second most common source of bugs was stashing something in a global variable and expecting the value to be the same the next time the subprogram that assigned the value was called. A cut-n-paste mentality meant that they had hundreds of functions using the same global variable.]
BTW, since he mentions that his programs aren't full of type-checking code, I'm starting to wonder whether he even knows what we mean by "dynamic type checking", or at least whether he's ever written a non-trivial program in a DTCing language.
> I'm really looking forward to Parrot as a way to bind Perl and Python together, and to do some of the things that Java was supposed to do.
I really appreciate the vote of confidence, but I simply don't have time to do all that right now.
> Is it so far-fetched that Microsoft is actually trying to provide it's users with the features that they want?
Not if "they" refers to "Microsoft".
> But how will the GPL license of the software affect their works?
This seems to be a growing issue. E.g., there has been a recent discussion on the Freeciv mailing list, where they are actively trying to get their hands on improved graphics but want to be rigorous about licensing issues. (And alas, they had to reject some nice tilesets that various people have submitted because of dubious licensing status.)
It seems to me that this would be worth writing the FSF about and seeing whether they are interested in providing a "content" license. They recently produced their GNU Free Documentation License in recognition that the GPL doesn't cover everything, but that does not seem to be completely apt for game artwork (and other game content) either.
They do link to another Design Science License for data, which you may want to evaluate. But IMO it would be great if you could get the FSF to produce and defend a free content license (GCL?) that was explicitly defined to work like and with the GPL.
The reason I think the FSF might take an interest is because so much new GPL'd software is GUI-oriented and requires graphics of one sort or another, and a basic corpus of free/licensed graphics might help free software take off in new areas like it has in infrastructure.
= programs.
Wirth, IIRC.
> A book about Algorithms and Data Structures in general
Other than the business-oriented stuff, this is probably the most important pair of items on the list, not something to be lumped together with the odds-and-ends at the bottom.
This is the stuff that takes programmers from an intuitive approach to the extremes of well-informed effectiveness.
Also, it's not specific to any particular language, OS, or other technology that will be out of the limelight before you finish reading your booklist.
> Because the problem isn't one of compilers, or ironically of technology. Its an attitude and approach problem. Its the lack of peer review of architecture and design that is the problem.
I would agree with your middle sentence, though I would generalize it to "humans are the weakest link in software production".
So all I'm suggesting with the language bit is to use languages that make the computer do some low-level tedious checking that computers are so good at and humans are so prone to errors at, especially when done in large quantities.
And as far as I'm concerned, poor language choice is just an instance of your "attitude and approach problem". There are good reasons to use one language over another, but those are hardly ever the reasons you hear people use to justify their choices.
In other branches of this thread the discussion has focused on static type checking. I wish programmers would learn that rigorous type definitions aren't an unrewarding chore but rather an opportunity. Think of them as constraints embedded in your code. Sure, I'd rather have a general constraint that told the compiler "no bugs, please", but since that appears to be impossible I'm happy to have whatever lesser constraints that are possible.
In my experience the time spent in type definitions pays off many-fold over the long haul, and better yet they mean I can spend more time thinking about what my program is doing rather than getting bogged down in the details of how it does it. I offload the most tedious details by doing the declarations up front, and then concentrate almost exclusively on the abstract logic of the program. And my bugs are almost always errors in my algorithmic logic; I don't waste a minute tracking down the truly stupid stuff.
> Let me put it in a form that even you could understand: Take the smartest, best programmer in a room. Let me come up with a solution to a non-trivial set of requirements using whatever language you think "helps".
Heh. I see you freudianly substituted "me" for "him". Let's leave it as an empirical question whether you would be the smartest, best programmer in the room.
> I guaran-g*ddamn-tee it that the program will suck. It may suck obviously, it may suck subtley, but it will suck. That's because one person isn't smart enough.
This conforms to our ideals -- most particularly to our anti-elitist democratic ideals -- but is it true in practice? If we were talking about highly qualified rocket scientists designing a rocket I would agree that your claim was (usually) right.
But in the realities of the IT industry, I would guess that for a team of five or more developers the best one is probably an order of magnitude better than the group average, and for larger groups that might extend to 2-3 orders of magnitude. (The SEI only finds about a single order of magnitude between the best and the worst that they test, but remember that they are testing people in SE classes approximately equivalent to graduate level study, hardly a random selection of IT employees. I've worked on projects with people who couldn't be relied on for such trivia as changing the backup tape every day or logging out of their terminal when they went home, and yet they were expected to participate as peers in the development of complex software.)
At any rate, I seriously doubt that your claim holds in practice in the IT industry. It's a fortunate project that has a team where all, or even half, of the members can contribute to the design instead of distracting the more qualified individuals with idiotic suggestions and writing crap code that ultimately has to be debugged by the gurus because the people who wrote it don't even understand it.
Also, your claim is a really odd response to my post. I don't think anyone, anywhere, has ever suggested that compilers should (or even could) replace the human creativity that goes into a program. What some of us are suggesting instead is that the compiler should have to do all the 5417-shoveling, freeing humans up to focus on the creative aspects almost exclusively. (Would you rather use a 417-shoveling language, or shovel it yourself?)
> Maybe the corporate empire is evil, or at least an argument could be made... But did you really think the animators were evil?
Yeah, that's why the villians in Disney movies always come across as cheesy would-be villians, as nice guys pretending to be villians.
Now if they would hire some truly evil animators, this problem would surely go away.
> These aren't little things - they're ways of fundamentally changing the way programming is done.
IMO the single most important thing we need to do is to quit thinking of ourselves as programmers and start thinking of ourselves as problem solvers.
Once you've solved the problem, writing the code is a straightforward (albeit tedious) task. Unfortunately, there's a myriad books and classes teaching "how to program", but not nearly so many about "how to think out a problem".
I have previously worked as a TA for CS classes, and it always amazed me how many people would bring in three pages of code intended to solve a five- or ten-line problem, and even though their code might compile perfectly they obviously didn't have the slighest idea about how to go about actually solving the problem. (Indeed, as often as not they didn't even understand the question yet.)
And though it's easy to dismiss this by saying that those people shouldn't have been in CS and probably never finished, I'm sad to say that the same problem is rampant in industry as well, except there the same kind of people are put in responsible positions on very large and complex projects.
At any rate, back to what you said, once you know the solution to the problem you can easily pick the language -- and algorithm -- most suitable for telling a CPU how to carry out that solution. If people would learn to think of their jobs in those terms, I suspect software would immediately start getting better.
> In my experience there is a tradeoff. Languages that tend to do more "static typing" do catch stuff that interpreted (dynamic) languages may not or not as early, but dynamically languages are often (potentially) easier to read because there is less code devoted to formalities and conversions. IOW, they reduce bugs by making the code smaller and easier to review by eye IMO.
Let me start by saying that I don't have any particular grudge against dynamic type checking: when given a free choice of language of implementation, my second most common choice is a DTCing language.
But there are a couple of points that need to be made about DTCing languages.
First, DTCing languages depend on the programmer to remember to do the type checks wherever they are needed, and programmers are the weakest link in programming projects (well, excluding managers and customers). I would guess that forgetting a check is essentially random, depending only on the individual programmer and the day of the week. So for a given programming team the rate of forgets is going to be essentially constant on timescales greater than a week. The result is that the number of forgets is going to be proportional to the size of your project. And unless your test suite is guaranteed to trace out every path through the code, the number of type errors that ship to your customer is going to be proportional to the size of the project. Compare this to a language that demands strict type definitions and static type checking, where the number of type errors that ship to your customer is zero.
Second, re this -
> IOW, they reduce bugs by making the code smaller and easier to review by eye IMO.
I disagree with both those assertions, and thus with the conclusion that DTCing languages reduce bugs. Re the first assertion, sure, you get to leave out the type definitions, but you have to sprinkle your code liberally with dynamic checks instead -- probably resulting in more code when you have a big program that uses lots of types. Re the second assertion, I find that rigorous type definitions actually make code easier to read, because all the complex type definitions and variables' types are declared exactly once each, after which you can think of them as abstractions when you are reading the rest of the code.
So what I find is that I only use the DTCing language for small one-off tasks such as doing a quick but non-trivial calculation, rarely more than a page of code, few data types, and data entry by myself. For big, or even medium-sized projects, I feel like I come out hours ahead by using a strait-jacket language that busts me at compile time when I neglect to say what I mean and mean what I say.
> It is like chosing between a thick helmet that blocks your view of some dangers, but protects you from bonking, or wear no helmet so that you can see and move more nimbly to avoid the dangers.
IMO it's more like deciding whether or not to take along a mine detector when you know you're entering a minefield.
> What I would like to see is pre-processors for dynamic languages that flag "suspicious" stuff, but don't outright prevent running.
Yeah, that would be nice, but I don't see how it would be possible. What's "suspicious" if you don't tell the compiler/interpreter what to expect? And if you do tell it what to expect, you're doing exactly what STCing languages require.