So, you have tried to explain to other intelligent, competent techies why programming is so much more complex than what they do, but you can't seem to convince them, eh?
Have you considered that maybe, just maybe, you are wrong? Maybe programming isn't harder than hardware design, or mechanical design, or mathematics, or physics? I mean, if it were, it would be a really convenient excuse, wouldn't it? "Your OS crashes so much because software is really complex." "You got infected by this virus because security is software, and software is really complex." "I missed this deadline because programming is really complex." Personally, as a professional, I am leary of ideologies which promise to exculpate me of professional responsibilities.
Brooks writes, "software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound." This is certainly true. However, you have to ask yourself if it is necessarily true or only accidentally true; that is, is it the only way software development can be or is it merely the current state of software development, perhaps because we don't yet understand programming well enough? For example, better programming languages let you abstract out more complex and varied patterns in software than worse ones; the result is simpler, more regular programs. As our understanding of how programs operate and are structured improves, we can expect to make them smaller and more regular with such tools.
The proper response to, "Programming is hard!" is not, "Therefore I am not responsible for bad programs," but rather, "How can we make it easier to meet our responsibilities?"
Religion never reviews its own practices, views, and procedures, and changes them. That's why Catholic masses are still spoken in Latin,...
The grandparent did not claim that religion doesn't change; he claimed that, if it changes, it does not tend to change in the "right" direction. (Please save your flames and note that this is not logically equivalent to saying that it tends to change in the "wrong" direction.)
In science, unlike religion, there is an objective standard of correctness given by the real world. To say that science is self-correcting is to say that it tends toward more accurately describing the real world.
In religion, there is no objective standard of correctness. It may change, but you cannot say whether it is getting "better" or "worse" with respect to that standard. At best, religions have a subjective notion of correctness, or truth, but none of the examples you gave even have anything to do with that. (Using a non-Latin language in Catholic masses, for example, has nothing to do with theological issues; if anything, a fundamentalist would argue that not using Latin is "less correct".)
Some religions may be becoming more liberal or tolerant (though some are going in the opposite direction). But that is a political trend, not an objective one.
How about an essay on the plot? A review? A synopsis? Anything? Bueller?
"He's sick. My best friend's sister's boyfriend's brother's girlfriend heard from this guy who knows this kid who's going with a girl who saw Ferris pass out at 31 Flavors last night. I guess it's pretty serious."
I saw the ilovebees site mentioned as an alternate reality game a few days ago at the cloudmakers Yahoo! group. Also see ARGN.
Proposal: Language and language-filter settings
on
Language Tempest At Orkut
·
· Score: 2, Interesting
I am on Orkut, and I don't care if members there speak Portuguese, English, Korean or Swahili. I speak several languages, and I don't believe everyone in the world needs to speak English.
What I do care about is the fact that every day my Orkut mailbox is filled with mass-mailed messages addressed to "Communities" and "Friends of friends" which are written in Portuguese, and therefore of no interest to me. More than half the messages in my box fit this description now. I find it extremely irritating; it's a step away from spam.
What Orkut needs is:
a language ID attached to each message/mail,
a "default language" setting for each user which gets attached to each message they post, and
a user setting which allows to filter out messages and mail posted in languages which a user cannot understand.
This would solve the problem, and, I imagine, greatly reduce bandwidth (or, rather, increase useful bandwidth) since it can be done server-side.
From the article: First, I wanna tell you what I usually do to make a computer easy and consistent to use for a newbie...
The Grim Reaper replies: Shut up, you American! You Americans, all you do is talk and talk, and say "let me tell you something," and "I just wanna say..." Well, you're dead now, so shut up!
Small machines require small amounts of energy. Why would they be unable to complete a krebs cycle and liberate ATP for energy? Where there are living creatures, there is a source for energy.
And yet, living creatures do not multiply out of control in an organic grey goo scenario. If there is a reason for this which applies to organic machines, which are honed to efficiency over millions of years of natural selection, who's to say this reason won't also apply to human-designed nanomachines?
Perhaps the same principles which limit the populations of organisms apply to populations of nanomachines? Rabbits multiply exponentially, yet the world is not overrun by them. The same holds of insects. Even people kill each other off when they overpopulate.
Syntax matters. It may not matter in the way naive programmers think it matters, but it matters.
I did not say syntax does not matter; I said it does not matter as much as semantics. If program meanings were determined by a polynomial, syntax would be the lowest-order subterm, a constant factor, and one which is easy to modify simply by preprocessing compiler inputs or replacing the front-end.
In contrast semantics comprise all the higher-order subterms, and are tightly coupled. In general, one cannot change the semantics of a language and attempt to preserve the behavior of existing program by automatically translating to compensate.
Really, this should be obvious. By and large, programming language syntax is limited to context-free languages, or something slightly less restrictive. In contrast, a programming language by definition has a Turing-complete semantics, which corresponds as a parsing problem to type 0 languages. Type 0 does not reduce to CFL. So semantic issues subsume and dominate syntactic ones.
Even if looks didn't tell you a lot aobut a candidate, they would simply matter because they matter to many voters.
Your argument is obviously circular because you decided to define "matters" as "matters to voters". When I said that a candidate's looks don't matter, I was of course talking about their decision-making skills, policies, platform, etc. Now, why would you misread my argument in such a bizarre fashion?
Welcome to the real world, where people with limited knowledge and information make important decisions, often irrational decisions. And to help improve such decisions and the effects they have, we have discussions, about syntax, semantics, and everything else.
Unfortunately, your discussions hardly ever lead anywhere, not in small part, I think, because you are more concerned about parroting aphorisms and platitudes than applying rational methods to the problem, or building on established work.
You are welcome to stick your head in the sand, I prefer to participate.
You are not a participant; you are a spectator at a football game, yelling slogans because everyone else around you is yelling the same thing; someone who thinks that, because they go to all the games and know all the cheers, that they are on the team.
The people on the field are people like me, who read peer-reviewed literature, publish papers in scientific fora, prove results and, when they argue, can argue logically and support their points with relevant evidence based on the existing literature. You, on the other hand, seem to be unwilling even to respond to arguments in an intellectually honest manner.
I love O'CAML, but its syntax is too tricky for mainstream programmers
Really, the world is better off without the programs these people might write. A person who cannot grasp a context-free grammar is a person who cannot write a useful, working, non-trivial application.
Furthermore, the people who complain endlessly about syntax are in large part also the people who have not clue one about what really distinguishes one programming language from another, or, indeed, even what a programming language is. Hence all the ignorant remarks that language A is better than language B because it has a bigger library (a library is not part of a language), or because A is dynamically typed (static typing subsumes dynamic typing), or because A is interpreted or not (interpretation is a property of an implementation, not a specification).
Such people do not deserve a say in what syntax---much less language---they use, because they aren't informed enough to make a good choice.
Now, I am an informed programmer, and I do think I deserve a say. But I will tell you that, though I am not a big fan of OCaml's syntax, C-like syntax or LISP-like syntax, I will gladly use any of them if I need to, because I know that the importance of semantics dominates that of syntax, and because I know that learning a new syntax is the easiest part of learning a new language.
Arguing about syntax is like picking a political candidate because he looks attractive: irrelevant. Do you want an ignoramus like that to decide who governs you? Do they even deserve voting rights? There really is no point: you might just as well just thrown some random noise into the poll records, or automatically pick a candidate for these people based on whether they prefer Britney Spears over Avril Lavigne. Different method, same result.
Neuburg has said "My approach is not to rely on documentation,... but to bang away at the language itself, testing and experimenting, trying to deduce the underlying rules" and this approach has certainly borne fruit in this volume.
This sounds reassuring, but is not the correct way to approach a programming language or a program. Such things are defined by specifications, not implementations. (If they're not, avoid them.) Besides the fact that implementations are frequently buggy, a particular implementation may well fix certain behavior which is left undefined by the specification.
For example, evaluation order of procedure arguments is often left undefined by a programming language standards; experimentation obviously cannot reveal this fact and will give misleading results. If you rely on empirically observed behavior like this you'll end up writing programs which only work with a specific version, on a specific platform or in a certain situation, and you'll never know until it's too late.
These facts are so fundamental to programming that it really pains me that they must even be mentioned in a forum like this. That the author of a book on a programming language would be ignorant of something like this is almost unforgivable.
WILL: Say I'm working at N.S.A. Somebody puts a code on my desk, something
nobody else can break. So I take a shot at it and maybe I break it. And I'm
real happy with myself, 'cause I did my job well. But maybe that code was the
location of some rebel army in North Africa or the Middle East. Once they have
that location, they bomb the village where the rebels were hiding and fifteen
hundred people I never had a problem with get killed.
(rapid fire)
Now the politicians are sayin' "send in the Marines to secure the area"
'cause they don't give a shit. It won't be their kid over there, gettin'
shot. Just like it wasn't them when their number got called, 'cause they were
pullin' a tour in the National Guard. It'll be some guy from Southie takin'
shrapnel in the ass. And he comes home to find that the plant he used to work
at got exported to the country he just got back from. And the guy who put the
shrapnel in his ass got his old job, 'cause he'll work for fifteen cents a day
and no bathroom breaks. Meanwhile my buddy from Southie realizes the only
reason he was over there was so we could install a government that would sell
us oil at a good price. And of course the oil companies used the skirmish to
scare up oil prices so they could turn a quick buck. A cute, little ancillary
benefit for them but it ain't helping my buddy at two-fifty a gallon. And
naturally they're takin' their sweet time bringin' the oil back and maybe even
took the liberty of hiring an alcoholic skipper who likes to drink seven and
sevens and play slalom with the icebergs and it ain't too long 'til he hits
one, spills the oil, and kills all the sea-life in the North Atlantic. So my
buddy's out of work and he can't afford to drive so he's got to walk to the job
interviews which sucks 'cause the shrapnel in his ass is givin' him chronic
hemorrhoids. And meanwhile he's starvin' 'cause every time he tries to get a
bite to eat the only blue-plate special they're servin' is North Atlantic scrod
with Quaker State.
(A beat.)
WILL (cont'd): So what'd I think? I'm holdin' out for somethin' better. I
figure I'll eliminate the middle man. Why not just shoot my buddy, take his job
and give it to his sworn enemy, hike up gas prices, bomb a village, club a baby
seal, hit the hash pipe and join the National Guard? Christ, I could be elected
President.
Wrong: there are a dozen programming languages which eliminate the possibility to exploit bugs such as buffer overruns, and programs like lsh are a perfect candidate for them. Such languages also improve code reuse, thus bolstering reliability, localizing errors and assigning blame where it belongs.
Furthermore, it's not necessary to provide a 100% guarantee of correctness to improve software quality. A familiarity with modern formal methods such as those used to specify programming languages will improve the quality of any software you write.
As for costliness, if the figure that 80-90% of development time is spent debugging is true, then you have a lot of leeway before increased time spent in specification and verification starts to exceed your overall budget. Add to that the expected decrease in support costs, and the value proposition is pretty good. Add to that the fact the network effect that you will actually be able to rely on external libraries, and development time decreases even further.
The fact is, people who write buggy software are bad citizens in the programming community. They hurt users, they hurt other programmers and they hurt themselves.
The idea that reliability cannot be addressed is a self-fulfilling prophecy and a cop-out. You have to bite the bullet sometime.
Well, that's part of the problem, isn't? Nobody ever claims anything about their software anymore because, shockingly, they might be held accountable by someone.
This is translating into bigger and bigger headaches for everyone else, because nowadays we all depend on some software, and it's never right. Never. Only maybe in the next version. But there's always a next version, right?
Maybe we should all start heading our programs with the comment:
/* IANAP(rogrammer), but I believe this may work... */
The more people say that the new BG bears no resemblance to the original, the more I have to wonder why the hell they are so upset about it. People are talking about boycotting the new show's sponsors in protest. If it's a completely different show, why? Did you also protest Law & Order because it's not X-Files, or Farscape because it's not Quantum Leap?
So the show has the same name as a show you like. Big deal, it's happened before. So the premise of the show is the same as an earlier SF show. Big deal, there are only about four or five premises in the space opera genre anyway. So some of the art style will be reused. Big deal, who cares.
Maybe you should judge the new show on its own merits. A show can be good without being Battlestar Galactica. Anyway, BG was not exactly Shakespeare in the first place.
Geez, you would think that people who believe in open source and the right to reuse things would not make such a furor when someone decides to do something new with existing material.
We ought to use them to teach children those languages that are immensely powerful yet, judged by our standards, too inefficient to be practical.
Functional languages are not inefficient. Haskell programs in particular are much faster than equivalents written in scripting languages like Python or Perl, which are widely deployed in industry, because they can be compiled in an efficient way. With Haskell, space usage can be a problem for naive users, but in call-by-value languages like SML and Ocaml that problem disappears as well.
Wright has been toying with traditional linear entertainment during the past year, creating several five-minute episodes of "M.Y. Robot" that were written by Lew Morton of "The Simpsons" and "Futurama."
Strange. I've heard that `Lew Morton' is a fake name which writers use to sign material which is so bad that they don't want to take credit for it.
Is this wrong? Or do those with power get to do whatever they want?
Gee, could you state this in a more biased, loaded and patronizing manner? Hell, why not just make up my mind for me, and relieve me of the burden of thinking.
I notice your examples don't address the issue of porting FROM the integrated language/OS TO another platform - say the same language running on a foreign platform and thus WITHOUT the OS integration.
If the language ensures that programs are safe, then it doesn't hurt to run them on an OS which performs redundant dynamic checks. They will run a bit slower, of course, but no slower than programs of an unsafe language.
In my view, OS integration with a language should not restrict portability of programs; it should only take advantage of the guarantees provided by language compiler.
You also don't address integration with legacy code - in other languages or binary-only - within a single application. (See my story about the death of MAD near the end of this posting.)
Yes, I agree this is a hairy issue.
Looks to me like using foreign-language inclusions would require turning on the protection even for the compiler-vetted object code and thus sacrificing much of the advantage.
One can imagine the compiler marking calls to unsafe procedures which enable an OS mode which performs dynamic checks for the duration of the procedure call, but that is only a partial solution since it doesn't address many subtler issues such as the integrity of data passed between safe and unsafe portions of the code.
To be honest, I doubt there is a good solution.
But, I think it is worth rewriting some legacy code in better languages:
When you do so, you are not just translating or reinventing the wheel, because you are writing what amounts to a constructive proof that the program fulfills certain desirable properties, such as safety from crashes. For the original program there are no such guarantees.
Of course, better languages should also reduce the time needed to write code, so it is less of a burden the second time around.
Better languages have better facilities for abstraction, so you can expect the new code to be more modular and more reusable.
As I pointed out, the code will run faster on our hypothetical OS.
Finally, the trend these days is away from monolithic applications and towards components, so the need for statically linking unsafe code with safe code is decreasing.
Integrating the language and the OS kills portability, robustness, and security.
If the language is well designed, it will have just the opposite effect. A good language can enforce program portability by abstracting away from low-level architectural details; it can increase robustness and security by statically detecting and rejecting programs that may crash or clobber each other's stores. OS performance can be expected to improve as well, since the OS need not dynamically check for (trap) such error conditions, so figures like context-switch frequency will plummet.
All the languages you mentioned (except Fortran, which afaik was never integrated with an OS, and mad, which I've never heard of) are dynamically typed languages which perform only trivial static analyses, so there is not much advantage in integrating them with the OS.
Unsafe languages like C can still be run on such an OS simply by executing them in a runtime environment which performs exactly the sort of trapping and fault-checking that a conventional OS does. Certainly their programs would run slower than those of the native language, which, by design, require less monitoring by the system, but there is no reason to expect they would run any slower than they would on a conventional OS.
I haven't seen the film yet, but I think this issue could be addressed by claiming that the precogs can only witness future situations wherein the killer has already made his decision to commit murder. So, the order of events would always be: Joe decides to kill Jane, precog sees Joe kill Jane, Joe kills Jane.
Now you will say, "But Cruise's character is accused of murdering a man he's never met, so, if precognition works the way you suggest, his agency's claim that he will murder that person would be unsupportable." OK, but consider that the sort of "decision" I have in mind might be made very indirectly.
For example, maybe Jane is black and Joe decided consciously 5 years ago to become a skinhead, and its in his nature that if he goes that far, that he will always end up killing Jane or someone sufficiently like Jane in a sufficiently similar situation, if he ever encounters it. By this logic, Joe does possess free will, the precog's precognition ability doesn't interfere with it, and the critical decision points could be many years past, giving the precog plenty of time to predict typical murders.
You might claim that Joe doesn't have free choice after he's made his decision, and part of having free choice is the ability to always change your mind. I can't argue against that, except to say that if every person can always change their mind at any point after a decision, then there seems to be no role for people's nature or nurture in their decision-making process, and so individuality disappears.
You might also argue that if Joe doesn't have free choice after he makes his initial decision, then convicting him for murder would be unjust. But I could counter that by claiming that Joe should have been more self-aware when he decided to become a skinhead, and realized what the consequences would be, that he might be unable to stop himself from killing Jane (or someone like her) in the future. Then, perhaps, the court is convicting him for being stupid or ignorant, which is a bit unsavory, but probably not unjust by many standards. "Ignorance of the law is no excuse", etc. I think there are limits to how much leeway a judge will give for stupidity; the important issue is knowing the difference between right and wrong, and Joe can probably know that, both when he makes his decision and when he kills Jane.
Slashdot Mirror
So, you have tried to explain to other intelligent, competent techies why programming is so much more complex than what they do, but you can't seem to convince them, eh?
Have you considered that maybe, just maybe, you are wrong? Maybe programming isn't harder than hardware design, or mechanical design, or mathematics, or physics? I mean, if it were, it would be a really convenient excuse, wouldn't it? "Your OS crashes so much because software is really complex." "You got infected by this virus because security is software, and software is really complex." "I missed this deadline because programming is really complex." Personally, as a professional, I am leary of ideologies which promise to exculpate me of professional responsibilities.
Brooks writes, "software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound." This is certainly true. However, you have to ask yourself if it is necessarily true or only accidentally true; that is, is it the only way software development can be or is it merely the current state of software development, perhaps because we don't yet understand programming well enough? For example, better programming languages let you abstract out more complex and varied patterns in software than worse ones; the result is simpler, more regular programs. As our understanding of how programs operate and are structured improves, we can expect to make them smaller and more regular with such tools.
The proper response to, "Programming is hard!" is not, "Therefore I am not responsible for bad programs," but rather, "How can we make it easier to meet our responsibilities?"
That is Dan Schmidt's game, "For A Change".
Religion never reviews its own practices, views, and procedures, and changes them. That's why Catholic masses are still spoken in Latin, ...
The grandparent did not claim that religion doesn't change; he claimed that, if it changes, it does not tend to change in the "right" direction. (Please save your flames and note that this is not logically equivalent to saying that it tends to change in the "wrong" direction.)
In science, unlike religion, there is an objective standard of correctness given by the real world. To say that science is self-correcting is to say that it tends toward more accurately describing the real world.
In religion, there is no objective standard of correctness. It may change, but you cannot say whether it is getting "better" or "worse" with respect to that standard. At best, religions have a subjective notion of correctness, or truth, but none of the examples you gave even have anything to do with that. (Using a non-Latin language in Catholic masses, for example, has nothing to do with theological issues; if anything, a fundamentalist would argue that not using Latin is "less correct".)
Some religions may be becoming more liberal or tolerant (though some are going in the opposite direction). But that is a political trend, not an objective one.
"He's sick. My best friend's sister's boyfriend's brother's girlfriend heard from this guy who knows this kid who's going with a girl who saw Ferris pass out at 31 Flavors last night. I guess it's pretty serious."
I saw the ilovebees site mentioned as an alternate reality game a few days ago at the cloudmakers Yahoo! group. Also see ARGN.
I am on Orkut, and I don't care if members there speak Portuguese, English, Korean or Swahili. I speak several languages, and I don't believe everyone in the world needs to speak English.
What I do care about is the fact that every day my Orkut mailbox is filled with mass-mailed messages addressed to "Communities" and "Friends of friends" which are written in Portuguese, and therefore of no interest to me. More than half the messages in my box fit this description now. I find it extremely irritating; it's a step away from spam.
What Orkut needs is:
This would solve the problem, and, I imagine, greatly reduce bandwidth (or, rather, increase useful bandwidth) since it can be done server-side.
Oops, I see now Christian is a fellow German; pardon my knee-jerk reaction.
He still writes like a stereotypical American, though. ;)
From the article: First, I wanna tell you what I usually do to make a computer easy and consistent to use for a newbie...
The Grim Reaper replies: Shut up, you American! You Americans, all you do is talk and talk, and say "let me tell you something," and "I just wanna say..." Well, you're dead now, so shut up!
Ahhh, I feel better now. :)
Small machines require small amounts of energy. Why would they be unable to complete a krebs cycle and liberate ATP for energy? Where there are living creatures, there is a source for energy.
And yet, living creatures do not multiply out of control in an organic grey goo scenario. If there is a reason for this which applies to organic machines, which are honed to efficiency over millions of years of natural selection, who's to say this reason won't also apply to human-designed nanomachines?
Perhaps the same principles which limit the populations of organisms apply to populations of nanomachines? Rabbits multiply exponentially, yet the world is not overrun by them. The same holds of insects. Even people kill each other off when they overpopulate.
Syntax matters. It may not matter in the way naive programmers think it matters, but it matters.
I did not say syntax does not matter; I said it does not matter as much as semantics. If program meanings were determined by a polynomial, syntax would be the lowest-order subterm, a constant factor, and one which is easy to modify simply by preprocessing compiler inputs or replacing the front-end.
In contrast semantics comprise all the higher-order subterms, and are tightly coupled. In general, one cannot change the semantics of a language and attempt to preserve the behavior of existing program by automatically translating to compensate.
Really, this should be obvious. By and large, programming language syntax is limited to context-free languages, or something slightly less restrictive. In contrast, a programming language by definition has a Turing-complete semantics, which corresponds as a parsing problem to type 0 languages. Type 0 does not reduce to CFL. So semantic issues subsume and dominate syntactic ones.
Even if looks didn't tell you a lot aobut a candidate, they would simply matter because they matter to many voters.
Your argument is obviously circular because you decided to define "matters" as "matters to voters". When I said that a candidate's looks don't matter, I was of course talking about their decision-making skills, policies, platform, etc. Now, why would you misread my argument in such a bizarre fashion?
Welcome to the real world, where people with limited knowledge and information make important decisions, often irrational decisions. And to help improve such decisions and the effects they have, we have discussions, about syntax, semantics, and everything else.
Unfortunately, your discussions hardly ever lead anywhere, not in small part, I think, because you are more concerned about parroting aphorisms and platitudes than applying rational methods to the problem, or building on established work.
You are welcome to stick your head in the sand, I prefer to participate.
You are not a participant; you are a spectator at a football game, yelling slogans because everyone else around you is yelling the same thing; someone who thinks that, because they go to all the games and know all the cheers, that they are on the team.
The people on the field are people like me, who read peer-reviewed literature, publish papers in scientific fora, prove results and, when they argue, can argue logically and support their points with relevant evidence based on the existing literature. You, on the other hand, seem to be unwilling even to respond to arguments in an intellectually honest manner.
I love O'CAML, but its syntax is too tricky for mainstream programmers
Really, the world is better off without the programs these people might write. A person who cannot grasp a context-free grammar is a person who cannot write a useful, working, non-trivial application.
Furthermore, the people who complain endlessly about syntax are in large part also the people who have not clue one about what really distinguishes one programming language from another, or, indeed, even what a programming language is. Hence all the ignorant remarks that language A is better than language B because it has a bigger library (a library is not part of a language), or because A is dynamically typed (static typing subsumes dynamic typing), or because A is interpreted or not (interpretation is a property of an implementation, not a specification).
Such people do not deserve a say in what syntax---much less language---they use, because they aren't informed enough to make a good choice.
Now, I am an informed programmer, and I do think I deserve a say. But I will tell you that, though I am not a big fan of OCaml's syntax, C-like syntax or LISP-like syntax, I will gladly use any of them if I need to, because I know that the importance of semantics dominates that of syntax, and because I know that learning a new syntax is the easiest part of learning a new language.
Arguing about syntax is like picking a political candidate because he looks attractive: irrelevant. Do you want an ignoramus like that to decide who governs you? Do they even deserve voting rights? There really is no point: you might just as well just thrown some random noise into the poll records, or automatically pick a candidate for these people based on whether they prefer Britney Spears over Avril Lavigne. Different method, same result.
This sounds reassuring, but is not the correct way to approach a programming language or a program. Such things are defined by specifications, not implementations. (If they're not, avoid them.) Besides the fact that implementations are frequently buggy, a particular implementation may well fix certain behavior which is left undefined by the specification.
For example, evaluation order of procedure arguments is often left undefined by a programming language standards; experimentation obviously cannot reveal this fact and will give misleading results. If you rely on empirically observed behavior like this you'll end up writing programs which only work with a specific version, on a specific platform or in a certain situation, and you'll never know until it's too late.
These facts are so fundamental to programming that it really pains me that they must even be mentioned in a forum like this. That the author of a book on a programming language would be ignorant of something like this is almost unforgivable.
But hey, worse is better, right?
WILL: Say I'm working at N.S.A. Somebody puts a code on my desk, something nobody else can break. So I take a shot at it and maybe I break it. And I'm real happy with myself, 'cause I did my job well. But maybe that code was the location of some rebel army in North Africa or the Middle East. Once they have that location, they bomb the village where the rebels were hiding and fifteen hundred people I never had a problem with get killed.
(rapid fire)
Now the politicians are sayin' "send in the Marines to secure the area" 'cause they don't give a shit. It won't be their kid over there, gettin' shot. Just like it wasn't them when their number got called, 'cause they were pullin' a tour in the National Guard. It'll be some guy from Southie takin' shrapnel in the ass. And he comes home to find that the plant he used to work at got exported to the country he just got back from. And the guy who put the shrapnel in his ass got his old job, 'cause he'll work for fifteen cents a day and no bathroom breaks. Meanwhile my buddy from Southie realizes the only reason he was over there was so we could install a government that would sell us oil at a good price. And of course the oil companies used the skirmish to scare up oil prices so they could turn a quick buck. A cute, little ancillary benefit for them but it ain't helping my buddy at two-fifty a gallon. And naturally they're takin' their sweet time bringin' the oil back and maybe even took the liberty of hiring an alcoholic skipper who likes to drink seven and sevens and play slalom with the icebergs and it ain't too long 'til he hits one, spills the oil, and kills all the sea-life in the North Atlantic. So my buddy's out of work and he can't afford to drive so he's got to walk to the job interviews which sucks 'cause the shrapnel in his ass is givin' him chronic hemorrhoids. And meanwhile he's starvin' 'cause every time he tries to get a bite to eat the only blue-plate special they're servin' is North Atlantic scrod with Quaker State.
(A beat.)
WILL (cont'd): So what'd I think? I'm holdin' out for somethin' better. I figure I'll eliminate the middle man. Why not just shoot my buddy, take his job and give it to his sworn enemy, hike up gas prices, bomb a village, club a baby seal, hit the hash pipe and join the National Guard? Christ, I could be elected President.
Wrong: there are a dozen programming languages which eliminate the possibility to exploit bugs such as buffer overruns, and programs like lsh are a perfect candidate for them. Such languages also improve code reuse, thus bolstering reliability, localizing errors and assigning blame where it belongs.
Furthermore, it's not necessary to provide a 100% guarantee of correctness to improve software quality. A familiarity with modern formal methods such as those used to specify programming languages will improve the quality of any software you write.
As for costliness, if the figure that 80-90% of development time is spent debugging is true, then you have a lot of leeway before increased time spent in specification and verification starts to exceed your overall budget. Add to that the expected decrease in support costs, and the value proposition is pretty good. Add to that the fact the network effect that you will actually be able to rely on external libraries, and development time decreases even further.
The fact is, people who write buggy software are bad citizens in the programming community. They hurt users, they hurt other programmers and they hurt themselves.
The idea that reliability cannot be addressed is a self-fulfilling prophecy and a cop-out. You have to bite the bullet sometime.
chihowa, you seem like the most level-headed and down-to-earth person I've seen here on Slashdot in years.
Good luck to you!
Grandparent wrote: nothing is flawless
Parent replied: Nobody ever claimed it would be.
Well, that's part of the problem, isn't? Nobody ever claims anything about their software anymore because, shockingly, they might be held accountable by someone.
This is translating into bigger and bigger headaches for everyone else, because nowadays we all depend on some software, and it's never right. Never. Only maybe in the next version. But there's always a next version, right?
Maybe we should all start heading our programs with the comment:
because that would be pretty damn accurate.
So the show has the same name as a show you like. Big deal, it's happened before. So the premise of the show is the same as an earlier SF show. Big deal, there are only about four or five premises in the space opera genre anyway. So some of the art style will be reused. Big deal, who cares.
Maybe you should judge the new show on its own merits. A show can be good without being Battlestar Galactica. Anyway, BG was not exactly Shakespeare in the first place.
Geez, you would think that people who believe in open source and the right to reuse things would not make such a furor when someone decides to do something new with existing material.
We ought to use them to teach children those languages that are immensely powerful yet, judged by our standards, too inefficient to be practical.
Functional languages are not inefficient. Haskell programs in particular are much faster than equivalents written in scripting languages like Python or Perl, which are widely deployed in industry, because they can be compiled in an efficient way. With Haskell, space usage can be a problem for naive users, but in call-by-value languages like SML and Ocaml that problem disappears as well.
Strange. I've heard that `Lew Morton' is a fake name which writers use to sign material which is so bad that they don't want to take credit for it.
Come on, guys, it's all ball bearings these days!
Gee, could you state this in a more biased, loaded and patronizing manner? Hell, why not just make up my mind for me, and relieve me of the burden of thinking.
If the language ensures that programs are safe, then it doesn't hurt to run them on an OS which performs redundant dynamic checks. They will run a bit slower, of course, but no slower than programs of an unsafe language.
In my view, OS integration with a language should not restrict portability of programs; it should only take advantage of the guarantees provided by language compiler.
You also don't address integration with legacy code - in other languages or binary-only - within a single application. (See my story about the death of MAD near the end of this posting.)
Yes, I agree this is a hairy issue.
Looks to me like using foreign-language inclusions would require turning on the protection even for the compiler-vetted object code and thus sacrificing much of the advantage.
One can imagine the compiler marking calls to unsafe procedures which enable an OS mode which performs dynamic checks for the duration of the procedure call, but that is only a partial solution since it doesn't address many subtler issues such as the integrity of data passed between safe and unsafe portions of the code. To be honest, I doubt there is a good solution.
But, I think it is worth rewriting some legacy code in better languages:
If the language is well designed, it will have just the opposite effect. A good language can enforce program portability by abstracting away from low-level architectural details; it can increase robustness and security by statically detecting and rejecting programs that may crash or clobber each other's stores. OS performance can be expected to improve as well, since the OS need not dynamically check for (trap) such error conditions, so figures like context-switch frequency will plummet.
All the languages you mentioned (except Fortran, which afaik was never integrated with an OS, and mad, which I've never heard of) are dynamically typed languages which perform only trivial static analyses, so there is not much advantage in integrating them with the OS.
Unsafe languages like C can still be run on such an OS simply by executing them in a runtime environment which performs exactly the sort of trapping and fault-checking that a conventional OS does. Certainly their programs would run slower than those of the native language, which, by design, require less monitoring by the system, but there is no reason to expect they would run any slower than they would on a conventional OS.
Coincidence? I think not! :)
Nonono. Pick one:
Now you will say, "But Cruise's character is accused of murdering a man he's never met, so, if precognition works the way you suggest, his agency's claim that he will murder that person would be unsupportable." OK, but consider that the sort of "decision" I have in mind might be made very indirectly.
For example, maybe Jane is black and Joe decided consciously 5 years ago to become a skinhead, and its in his nature that if he goes that far, that he will always end up killing Jane or someone sufficiently like Jane in a sufficiently similar situation, if he ever encounters it. By this logic, Joe does possess free will, the precog's precognition ability doesn't interfere with it, and the critical decision points could be many years past, giving the precog plenty of time to predict typical murders.
You might claim that Joe doesn't have free choice after he's made his decision, and part of having free choice is the ability to always change your mind. I can't argue against that, except to say that if every person can always change their mind at any point after a decision, then there seems to be no role for people's nature or nurture in their decision-making process, and so individuality disappears.
You might also argue that if Joe doesn't have free choice after he makes his initial decision, then convicting him for murder would be unjust. But I could counter that by claiming that Joe should have been more self-aware when he decided to become a skinhead, and realized what the consequences would be, that he might be unable to stop himself from killing Jane (or someone like her) in the future. Then, perhaps, the court is convicting him for being stupid or ignorant, which is a bit unsavory, but probably not unjust by many standards. "Ignorance of the law is no excuse", etc. I think there are limits to how much leeway a judge will give for stupidity; the important issue is knowing the difference between right and wrong, and Joe can probably know that, both when he makes his decision and when he kills Jane.