I suppose you meant that programmers do not bound-check properly. Obviously this is the cause of the failures. However, safe languages solve this problem by guaranteeing this can't happen.
Sure, they do. But it is a non-issue. The reason we see a lot of buffer overflows is simply because most popular software gets written in languages that allow buffer overflows. Not because this is some Really Big Problem that we should be sacrificing two-thirds of our CPU cycles and 110% of RAM to.
Before you reply saying that it is in fact a big problem, your task is to figure out why that software is so popular.
Tell me, how are the unsafe languages such as C or C++ more suitable for daemon coding than Python, Lisp, Scheme, etc?
Funny, I was thinking the same, only different. Why don't you tell me why the most popular daemons are written in C and not in <your favorite interpreter>?
Reliability, and portability issues are both voting against C and C++.
Ah yes, reliability such as Perl's or Java's, which just keep eating memory until you reboot the machine, or portability such as Lisp's, with it's one, no um two, no sorry three, well actually four, or was it five, competing dialects.
As for C's portability: do you even know on what hardware C was first implemented?
As for speed, safe languages prove to be at least fast enough for I/O-bound applications. Some safe languages (Common Lisp, OCaml) even prove to compile to much more efficient code than C\C++ in many cases.
Ah yes, the miracle cases, I've heard of those. Wonderful those, even though they never seem to actually materialize. So that's like, what, running a marathon with a jerrycan of water on your back, saving you 10 seconds in case you get thirsty?
Python, along with Twisted Matrix, for example, allows for easy, safe, and very fast network daemons. Medusa is an example of a very fast Python webserver, written in much less code than equivalent C\C++, and executing at least as fast.
Again, wonderful. What leverage does any of this have on the success of something like, say, Apache?
If Python allows performance, ease of development, reliability and guarantee of security (from such volunerabilities), how is it less suitable than C or C++ for the development of network daemons?
Well, if it would actually offer all that, then it would not be less suitable. However, it doesn't.
That's bull.
Very articulate, thanks.
All programmers make mistakes. What you are talking about here is the ability to make 0 mistakes as far as array indexing, pointer management, and other low-level issues are concerned. Firstly, there are always potential mistakes in any part of a program. Secondly, pointer management (killing dangling pointers correctly, managing complex pointing graphs, etc) is not trivial at all.
Wow. Programming is hard? News at eleven I suppose. "Solving a differential equation is not trivial at all, so we're going to use this new math..."
Therefore, a language that makes you a guarantee of safety in those regards, and handles all those low-level issues automatically and correctly, is a huge benefit.
Again, wonderful. Too bad, then, that it's not here yet.
You're not going to prove it, but debugging a single, finite code base (A compiler) is a hell of a lot easier than debugging and correcting infinite amounts of code written all the time. To claim it is as hard to maintain correctness of the compiler as it is of EVERY program out there is absurd.
Right, right, you don't even bother to read your code, because whatever the compiler spits out must be perfect. Whatever.
As for Visual Basic and Javascript, my experience is that they are safe in those regards. They are obviously (at least Visual Basic) not examples of stable well-tested platforms, as many of the Lisp, Python, and other compilers/VM's are (especially when considering the reputation of the creators).
Your experience is that they're safe? So much for your experience then.
Seriously, how did you expect me to respond? Are Outlook worms the cause of buffer overruns or dangling pointers?
Assuming the goals of your language are to ease development and provide the best platform for developing software, a language that does not provide a guarantee of safety is far inferior to one that does, in terms of fulfilling those goals.
Our goals are to deliver fast and useful software with few bugs. Not to waste time "easing development" for contingencies that never actually occur. Sorry.
Buffer overruns do not occur because programmers do not know how to do bounds checking. We see a lot of buffer overruns occur however, because the only languages truly suitable for most problem domains are the languages that allow these things to happen. Completeness has nothing to do with that by the way. Reliability, memory usage, speed and portability issues have.
Besides, if programmers can't get something simple like array indexing right, then how are they going to get the much, much, much more complicated domain-specific safety issues right? And how are you going to prove that your favorite Common LISP implementation actually does not violate any of the requirements? Look at how "safe" a language like Javascript is. Or Visual Basic.
You see where I am coming from, when your C code malfunctions, that is not a flaw with C -- it's a flaw in your code.
OK, this troll is over. Let's examine it in a bit more detail.
Am I the only one who has noticed that the remit of consoles increases year on year?
Nice touch: remit. Note also the "lonely voice in the desert" approach (/. crowd loves the "nobody cares to look at my research" angle).
At first they were simple gaming machines, now they focus on email, broadband, DVD playing, web browsing, etc etc.
A bit disappointing. Would have expected mention of <insert controversial technology>. On second thought I figure might have diluted the nostalgy for a "simpler past" that's working here.
With MS's.NET initiative,
There it is, the controversial technology.
one can't help but wonder if the concept of a 'home computer' will become entirely redundant.
Nice red herring. Troll establishes emotional bond with the grizzled hackers of yore through the use of the quaint 'home computer'.
After all, the fact is that.NET will enable traditional tasks performed by applications such as MS Word, Excel etc to be done entirely over the web.
Provocation: "the fact is", "will enable".
With the rise of consoles, this will render the home computer redundant in time.
Troll alienates grizzled hackers.
Another advantage is that consoles are so easy.
Cue pointless remark by FlightSimFan about how some games will never move to the console. Also set up the atmosphere for confrontation with the anti-ease-of-use crowd.
I mean, I find Windows and Mac OS X very complicated and difficult to use
Cue anti-ease-of-use crowd.
I am from a pre-computer generation, and have watched with a little bemusement as these glorified typewriters conquer all.
Knowful wink at the humanist and "digital citizen" crowds.
They are dividing society into two classes, the Digirati
Cue the Katz/Wired crowd.
who can understand Computers running super complicated, unintuitive OS's like OS X and Windows, and the disposessed, who just don't understand and never will.
A clever provocation: no mention of Linux at all! Doesn't seem to be very effective in its apparent goal to ignite a UI war though.
Consoles, by extending their grasp, may remove this knowledge gap by providing a wonderfully simple, hermetically sealed system that can be easily used by everyone, including your granny, and me!
"Hermetically sealed" makes a nice appearance. Otherwise not very convincing.
I will welcome the day, I think, I don't like the idea of supercomplex computers running increasingly difficult OS's taking over all simple tasks and dispossessing those with better things to do than understand the impossible complexities of Internet Explorer and Microsoft Word.
Boilerplate common sense.
I look to Sony, MS and Nintendo to provide a democratic and egalitarean new computing future for all, in which everyone can share.
Disappointing. Too flippant for there to be any venom in this tail. Several loose ends left hanging. Rather pathetic attempt to ensnare the FSF zealots with the "share" there as well.
The problem with this kind of argument, though, is that you are presupposing that even the most skillful and most dedicated of programmers are careless and/or incompetent, in which case switching to a language that eliminates buffer overflows helps only very marginally.
The point is that for any real world task, the problem-specific requirements dwarf all other considerations. The hard part is not some abstract "checking your input" -- the hard part is knowing what to check for.
Programming is just hard. It's a complete fallacy to suggest that you can make it easier by shielding programmers from the implementation detail. Because it's exactly the implementation detail that we are being paid to get right.
Dude. They wrecked the WTC. And you are impressed by the "motivation and resources of IB, NSA, FBI or CIA"? Why can't you cope with the reality that, in all probable likelyhood, most of their software looks, well, pretty much like everyone else's software?
People'll just get this like they credit cards or cell phones I suppose. Useless if only one person has one, but opens up a whole can of goodies|worms if everyone has one. It'll be optional though and even if most people have one there will still be people doing without.
Yeah, I know. My radio starts buzzin' when somebody calls my neighbours cellphone. Probably his mum, because she calls really often, and she must be deaf, because he talks really loud. The perfect room would have to be EM shielded, sound proofed, backlit and 30M water resistant.
Look, flat files won. Sure you can spruce up many things when your files have meta data. But this is on the order of saying that 16 bit ASCII would have been nice.
Couldn't print? Not much to offer? BeOS may not have the best printing scheme, but it does work.
Okay, sure, but people are not going to dump their Macs for it.
the attribute based file system offers many features for many users;
So does MacOS HFS. As the Mac users will attest, one of the great features of not having a flat-file file system is that you have to be really careful transferring your files onto other systems, or they'll break.
Let's also not forget that BeOS has the best SMP implementation out of any O/S I've seen out there.
As operating systems have come and gone, one trend has been impossible to avoid. Driver support is next to nonexistent for anything other than Windows, and increasingly Linux on the x86 platform.
Are you talking about Windows 3.11 drivers? DOS drivers? Win95 drivers? Win98 drivers? WinNT drivers? WinXP drivers? And what about Netware drivers? OS/2 drivers? Arguably success has less to do with driver availability than with being a monopolist.
This doesn't have anything to do with the ethos of open source, nor does it have anything to do with the quality of the operating system. BeOS absolutely kicked ass, it was an incredible attempt at exactly what the industry needs - a clean OS designed for today's desktop needs.
Designed for today's desktop needs? BeOS? The OS that couldn't print? Perhaps there was a window between 1995 and 1998 where BeOS might have fit in. But compared to NT4 and Linux it simply did not have that much to offer.
Unfortunately, this isn't what hardware manufacturers want to support. They want to support Windows and maybe Linux. From a conspiratorial standpoint, you could always think about it as the hardware manufacturers simply sticking to Windows because the power curve keeps increasing so often, new parts are always in vogue. From a more realistic standpoint, it's likely because the manufacturers are broke due to economic conditions, or simply too inexperienced to handle multiplatform development. Can open source volunteers make good drivers? Sure, we've seen this with xfree86, but look at what's happened to X. It's huge, considerably bloated, and with the exception of a very few window managers, ugly and unwieldy.
So what are you saying? That X is considerably bloated, ugly and unwieldy because of the efforts of open source volunteers? And compared to what? Can you name any real-world OS that isn't "bloated" in this sense? I mean in the next paragraph you go on about how "[unwieldy] the BSD/Mach codebase" of OS X is and that the GUI sucks up too much RAM. So that leaves, what? Are you saying Windows is not bloated?
What's "bloated" mean to you, anyway? I mean you throw off all these non-starters and ramble yourselves a +3 Interesting, so it's just because I'm jealous that I'm asking.
Will I use Linux and X11? Yes, of course. But I'm not the average home user, and that's where the battle for vendor support for an OS lies. I hope someday open source will come around and realize this.
Open source is all about you coming around and realizing something, pal.
Thanks to all at Mozilla, Asa, Brendan, Seth, Steve, Dave, Boris, Navin, Brian, Peter, Mike, Simon, timeless... Etcetera. We know who you are. We can see the ruthless triage and the late nights, the cross platform blues. X font handling. Sorry for doubting you in the past guys. Maybe ultracapitalism, anarchy and Internet Explorer will not rule after all. And the beast shall multiply a thousandforth, eh? And the followers of Mammon shall tremble? I better find a new job
Slashdot Mirror
Bah, if you're worried about developer efficiency, then Linux is not for you. Stop using it. It will never do what you want it to.
He was? Good! First sensible thing they did since they abolished slavery!
Twenty-first, you idi... Oh wait... I see...
Before you reply saying that it is in fact a big problem, your task is to figure out why that software is so popular.
Funny, I was thinking the same, only different. Why don't you tell me why the most popular daemons are written in C and not in <your favorite interpreter>? Ah yes, reliability such as Perl's or Java's, which just keep eating memory until you reboot the machine, or portability such as Lisp's, with it's one, no um two, no sorry three, well actually four, or was it five, competing dialects.As for C's portability: do you even know on what hardware C was first implemented?
Ah yes, the miracle cases, I've heard of those. Wonderful those, even though they never seem to actually materialize. So that's like, what, running a marathon with a jerrycan of water on your back, saving you 10 seconds in case you get thirsty? Again, wonderful. What leverage does any of this have on the success of something like, say, Apache? Well, if it would actually offer all that, then it would not be less suitable. However, it doesn't. Very articulate, thanks. Wow. Programming is hard? News at eleven I suppose. "Solving a differential equation is not trivial at all, so we're going to use this new math..." Again, wonderful. Too bad, then, that it's not here yet. Right, right, you don't even bother to read your code, because whatever the compiler spits out must be perfect. Whatever. Your experience is that they're safe? So much for your experience then.Seriously, how did you expect me to respond? Are Outlook worms the cause of buffer overruns or dangling pointers?
Our goals are to deliver fast and useful software with few bugs. Not to waste time "easing development" for contingencies that never actually occur. Sorry.Besides, if programmers can't get something simple like array indexing right, then how are they going to get the much, much, much more complicated domain-specific safety issues right? And how are you going to prove that your favorite Common LISP implementation actually does not violate any of the requirements? Look at how "safe" a language like Javascript is. Or Visual Basic.
You see where I am coming from, when your C code malfunctions, that is not a flaw with C -- it's a flaw in your code.
Okay, but that's putting the computer into a video tape. I think what I meant was putting the video tape into a computer.
I hope that in the 21th century, we don't let apesnots like Wesley Crusher run things on the bridge.
Well, I don't know how it will end up, but I do know what it was like, for to my knowledge it was never possible to put a videotape into a computer.
Safe languages? Would those be languages in which you can only solve safe problems?
Nice touch: remit. Note also the "lonely voice in the desert" approach (/. crowd loves the "nobody cares to look at my research" angle).
A bit disappointing. Would have expected mention of <insert controversial technology>. On second thought I figure might have diluted the nostalgy for a "simpler past" that's working here. There it is, the controversial technology. Nice red herring. Troll establishes emotional bond with the grizzled hackers of yore through the use of the quaint 'home computer'. Provocation: "the fact is", "will enable". Troll alienates grizzled hackers. Cue pointless remark by FlightSimFan about how some games will never move to the console. Also set up the atmosphere for confrontation with the anti-ease-of-use crowd. Cue anti-ease-of-use crowd. Knowful wink at the humanist and "digital citizen" crowds. Cue the Katz/Wired crowd. A clever provocation: no mention of Linux at all! Doesn't seem to be very effective in its apparent goal to ignite a UI war though. "Hermetically sealed" makes a nice appearance. Otherwise not very convincing. Boilerplate common sense. Disappointing. Too flippant for there to be any venom in this tail. Several loose ends left hanging. Rather pathetic attempt to ensnare the FSF zealots with the "share" there as well.The point is that for any real world task, the problem-specific requirements dwarf all other considerations. The hard part is not some abstract "checking your input" -- the hard part is knowing what to check for.
Programming is just hard. It's a complete fallacy to suggest that you can make it easier by shielding programmers from the implementation detail. Because it's exactly the implementation detail that we are being paid to get right.
Hook, line, sinker, rod + reel, buddy.
A: You don't.
Vigilantes: amateurs trying to look like professionals.
Right, right.
Dude. They wrecked the WTC. And you are impressed by the "motivation and resources of IB, NSA, FBI or CIA"? Why can't you cope with the reality that, in all probable likelyhood, most of their software looks, well, pretty much like everyone else's software?
People'll just get this like they credit cards or cell phones I suppose. Useless if only one person has one, but opens up a whole can of goodies|worms if everyone has one. It'll be optional though and even if most people have one there will still be people doing without.
Great story. Post followups. Get him to put up a web page.
2) Right, right. So lets go all the way and just forgo BFS completely.
Yeah, I know. My radio starts buzzin' when somebody calls my neighbours cellphone. Probably his mum, because she calls really often, and she must be deaf, because he talks really loud. The perfect room would have to be EM shielded, sound proofed, backlit and 30M water resistant.
2) Ah. And BeFS is not "oddball"?
What's "bloated" mean to you, anyway? I mean you throw off all these non-starters and ramble yourselves a +3 Interesting, so it's just because I'm jealous that I'm asking.
Open source is all about you coming around and realizing something, pal.Thanks to all at Mozilla, Asa, Brendan, Seth, Steve, Dave, Boris, Navin, Brian, Peter, Mike, Simon, timeless... Etcetera. We know who you are. We can see the ruthless triage and the late nights, the cross platform blues. X font handling. Sorry for doubting you in the past guys. Maybe ultracapitalism, anarchy and Internet Explorer will not rule after all. And the beast shall multiply a thousandforth, eh? And the followers of Mammon shall tremble? I better find a new job