> In contrast, most of Java's oft-cited "advantages" are simply features that are missing, and which you're at liberty to > ignore in C++ as well.
It's true that Java is lacking some features that C++ has (parametric polymorphism through templates comes to mind, maybe operator overloading if you like that sort of thing). But not all of its "features" are really features (to me). For instance, some might say that C++ has a feature of "letting me" manage my memory myself. I don't think of this as a feature, because it often leads to memory leaks or heap corruption (double deletes!). I like to have my memory managed automatically. Some might say that being able to cast someone's abstract data structure to a concrete type so I can use my special knowledge of how it's actually implemented is a "feature", but I think that it's precisely the library developer's ability to control how his library is used that's a feature. I would say that Java's nice and portable libraries are a direct result of this language support for abstraction. (And, to an extent, the politics of its development..)
I don't have any problem with languages that let you get at the details (Java does, through its native method interface) when appropriate; I just think that C++ tempts programmers too much by having things like unsafe arrays, pointer arithmetic, unchecked casts, and new/delete right there in in front of you in the core language.
Java is getting generics soon, so that will close a gap in its abstraction capabilities. And, of course the languages I actually like to program in (Java is not one of them) like SML and O'Caml have had polymorphism for a long time, as well as some of the other keen features you mention like higher-order nested functions, algebraic datatypes, pattern matching, fancy module systems, etc.
Springer-Verlag actually requires you to sign over the copyright. The copyright! You're not licensing the work to them to publish, but actually giving it away. (In return, you get the "privilege" to purchase a copy at 30% off.) Back in the day when publishers were really the only way to get others to see the work, maybe this was reasonable. With the internet, where I can easily share papers with other researchers at no cost to me, I think this situation is pretty fucked up. I definitely see a revolt in the near future...
I'm not saying that *nobody* should understand how things work, but the understanding that a compiler or runtime writer needs is different than the understanding that an application developer should need. Most application developers do not need to know which way it is faster to traverse an array, because that level of efficiency simply isn't important for most applications. To tell you the truth, there's no reason why the 2d array abstraction couldn't include a map or fold function (an iterator to Object-Oriented folks) that traverses it in the more efficient manner, abstracting away that detail from the programmer as well.
In a language that supports abstractions well, and under well designed abstractions, these kinds of breakdowns ("leaks") are rare. Though more knowledge seldom hurt anyone, if we were going to either spend time teaching students how compilers work so that they can debug strange compiler errors (these happen, of course, but are pretty rare) or teaching students how to create good abstractions and use them appropriately (these kinds of problems are much more common!!), I favor the latter!
OK, fine: All programming languages have an implementation, and a host operating system. But switching from Java to C++ certainly won't save you from these kinds of problems. (In fact, there is only ONE C++ compiler that I know of that actually claims to be compliant with the C++ language definition; ie., every C++ compiler that people use to build programs is filled with bugs concerning the language's many insane idiosyncrasies!)
I only mean to point out Java as a *language* that has better abstraction properties than C++. (Personally, I prefer other less popular languages like SML, but Java serves the point as well. Just be careful not to take Java as the best example of a high-level language, because high-level languages can have better features and be more efficient than Java is.) Software written in a correct implementation of Java on a correct OS can not have buffer overflows. Programs written in C, even in a correct compiler (few exist) on a correct OS, can and frequently do have buffer overflows. I am reluctant to call this a programmer problem, because such bugs are so common, even among extremely good programmers. (Are the authors of Quake III Arena, Apache, MySQL, the Linux Kernel, ssh, BIND, Wu_ftpd just all bad programmers for having buffer overflows in their software? I personally don't think so...)
Some people are reading this article and using it as evidence to support low-level languages like C. ("Abstractions are leaky, so programmers need to have access to low-level details in order to work around leaky abstractions." or "Abstractions are leaky, so there's no point in using abstraction.") I think that's exactly backwards! Essentially, what I'm claiming is that C++ is a poor language for large software precisely because it does not allow programmers to create "tight" abstractions. Some languages do! These languages are much more pleasant to program in, and to build large software in! And in those languages, we can indeed make tight abstractions without the kinds of leaks he's described.
I guess you are a troll (I hope you don't really believe what you're saying!!), but you're missing an important point: FreeBSD has security holes frequently found in it (ie, buffer overflows, heap overflows, format string attacks); bugs that would be impossible to make in a language like (say) Java. Security holes are the most salient example, but there are many perils to trying to do things "manually" and by programmer brute-force in a language like C.
Java's not my favorite language, but programs written in it tend to be more robust than their C counterparts.
Is this a "copyright" bit? (Like the bit set when you make a digital copy of a minidisc?) If so, be careful if you release this program, or you might run into problems similar to my own bit-flipping software!
Are you crazy? Use a network filesystem hosted on one machine, or network storage. Sharing the same physical drive between two concurrently-running operating systems will require special drivers and extra communication between the two (at best), and be totally unreliable at worst.
Yes, it would be pretty boring. I've done it a little bit for a class I took a few years ago, and it was really not very fun. My feeling is that we have enough corporate-looking fonts already, and that it's much more fun and interesting to push the envelope on new font looks, as well as extend the corporate fonts to cover more of the Unicode charset. I would be interested in a push to create free (as in freedom) corporate fonts to replace existing ones, but it really is a pain in the ass so there'd need to be a good chance of the project producing something worthwhile...
I do like to make usable bitmap fonts, though, and I've done some of that.
You really shouldn't judge a professor by his New York Times article. It's not a technical article, and it's not intended for the tech-savvy Slashdot audience. It's supposed to 'wow' your average computer user or perhaps drum up some buzz so that he can get better funding. Just because he's a dreamer doesn't mean he doesn't have any idea what he's talking about.
Also, your sarcastic comment about Yale being "CS central" is way off mark. It's not a top-tier school (I think they're ranked in the 20s or so for graduate school), but it is a strong program and they have several really good people there.
I don't agree with what he's saying, either, but that doesn't make him an ass. If you want to make a fair analysis of his research, you should maybe check out one of his research papers at citeseer.
bug 178,326... "There are not 200,000 bugs in Bugzilla" bug 178,327... "There are not 200,000 bugs in Bugzilla" (closed - DUP bug 178326) bug 178,328... "There are not 200,000 bugs in Bugzilla" (closed - DUP bug 178326)
No, regulation is not the answer. There are loads of technological solutions of varying complexity: hash cash, authentication, etc. If we care a lot about Spam, we should be working to decide on a technology and implement it in our mail readers. (There are some, already, like S/MIME, that have a fair amount of deployment.)
Think about what you're saying: Legislate to try to extend the life of a legacy system? We should not be encouranging the government to do this kind of thing. How much do we hate the DMCA? How much will we hate the anti-anonymous e-mail law? Don't we *want* authenticated and encrypted communication anyway? Why do we use ssh for typing commands at our shell (pretty boring to read, except for passwords) but SMTP for our english messages (often much more sensitive!)?
Maybe I'm just naive, but can someone explain a believable situation where four slower CPUs (say, 100mhz) would beat two faster ones (200mhz)? There's loads of overhead in an SMP system, so I find it hard to imagine that having more chips would be better. (I don't know about the special weird requirements of a big SQL system, though).
Well, the academic programming language community doesn't agree with you. We still publish papers and do research and develop new programming languages and new programming language ideas. You might say, "computer programmers are very slow to adopt new programming languages and ideas," and that would be true. But that doesn't mean that computer scientists aren't still working on more abstract, more expressive languages!
This is not a technical whitepaper. This is a dream that a college kid had about a supervirus that controlled the whole internet. It would be much more interesting if he had also dreamed up an implementation, since there are loads of difficult issues that come up when you're forced to detail this kind of idea in the way that's needed to actually write a program. Not even worrying about the obvious scaling issues (especially with regard to failure recovery), there are a bunch of assertions made in the text that are simply wrong, or at least completely unproven. Take, for instance, the statement, "The only way to protect against Curious Yellow is to inoculate every computer with an anti-worm, Curious Blue, which uses similar technology to instantly distribute security patches." (???)
Another example is the "Security, Cryptography..." section, which is essentially just a rambling narrative of a hypothetical situation based on some messed up assumptions:
"Due to the large size of private keys, they cannot be easily remembered and so much be stored electronically somewhere."
Sure, but it's easy to store them encrypted with some memorizable key. That's what PGP does, for instance, and stealing the encrypted private key is pretty useless!
Vague statements like "Using statistical analysis of the propagation of code updates, the source of updates can eventually be traced," are equally underexplained and undermotivated. It's pretty easy to get data anonymously onto the internet -- there are anonymous remailers, web proxies, usenet servers (groups.google.com), etc. I recall a worm whose creator anonymously posted cryptographically signed updates to sci.crypt (or something like that), for instance. Using an internet kiosk or setting up a free AOL account from a payphone and then using one of these would be pretty damn hard to track.
Basically, this is nothing more than wild speculation of the sort, "Wouldn't it be cool if...!", except without the if. Give us technical details and analysis, not a barely believeable science fiction story!
Slashdot Mirror
> In contrast, most of Java's oft-cited "advantages" are simply features that are missing, and which you're at liberty to
> ignore in C++ as well.
It's true that Java is lacking some features that C++ has (parametric polymorphism through templates comes to mind, maybe operator overloading if you like that sort of thing). But not all of its "features" are really features (to me). For instance, some might say that C++ has a feature of "letting me" manage my memory myself. I don't think of this as a feature, because it often leads to memory leaks or heap corruption (double deletes!). I like to have my memory managed automatically. Some might say that being able to cast someone's abstract data structure to a concrete type so I can use my special knowledge of how it's actually implemented is a "feature", but I think that it's precisely the library developer's ability to control how his library is used that's a feature. I would say that Java's nice and portable libraries are a direct result of this language support for abstraction. (And, to an extent, the politics of its development..)
I don't have any problem with languages that let you get at the details (Java does, through its native method interface) when appropriate; I just think that C++ tempts programmers too much by having things like unsafe arrays, pointer arithmetic, unchecked casts, and new/delete right there in in front of you in the core language.
Java is getting generics soon, so that will close a gap in its abstraction capabilities. And, of course the languages I actually like to program in (Java is not one of them) like SML and O'Caml have had polymorphism for a long time, as well as some of the other keen features you mention like higher-order nested functions, algebraic datatypes, pattern matching, fancy module systems, etc.
Springer-Verlag actually requires you to sign over the copyright. The copyright! You're not licensing the work to them to publish, but actually giving it away. (In return, you get the "privilege" to purchase a copy at 30% off.) Back in the day when publishers were really the only way to get others to see the work, maybe this was reasonable. With the internet, where I can easily share papers with other researchers at no cost to me, I think this situation is pretty fucked up. I definitely see a revolt in the near future...
I'm not saying that *nobody* should understand how things work, but the understanding that a compiler or runtime writer needs is different than the understanding that an application developer should need. Most application developers do not need to know which way it is faster to traverse an array, because that level of efficiency simply isn't important for most applications. To tell you the truth, there's no reason why the 2d array abstraction couldn't include a map or fold function (an iterator to Object-Oriented folks) that traverses it in the more efficient manner, abstracting away that detail from the programmer as well.
In a language that supports abstractions well, and under well designed abstractions, these kinds of breakdowns ("leaks") are rare. Though more knowledge seldom hurt anyone, if we were going to either spend time teaching students how compilers work so that they can debug strange compiler errors (these happen, of course, but are pretty rare) or teaching students how to create good abstractions and use them appropriately (these kinds of problems are much more common!!), I favor the latter!
OK, fine: All programming languages have an implementation, and a host operating system. But switching from Java to C++ certainly won't save you from these kinds of problems. (In fact, there is only ONE C++ compiler that I know of that actually claims to be compliant with the C++ language definition; ie., every C++ compiler that people use to build programs is filled with bugs concerning the language's many insane idiosyncrasies!)
I only mean to point out Java as a *language* that has better abstraction properties than C++. (Personally, I prefer other less popular languages like SML, but Java serves the point as well. Just be careful not to take Java as the best example of a high-level language, because high-level languages can have better features and be more efficient than Java is.) Software written in a correct implementation of Java on a correct OS can not have buffer overflows. Programs written in C, even in a correct compiler (few exist) on a correct OS, can and frequently do have buffer overflows. I am reluctant to call this a programmer problem, because such bugs are so common, even among extremely good programmers. (Are the authors of Quake III Arena, Apache, MySQL, the Linux Kernel, ssh, BIND, Wu_ftpd just all bad programmers for having buffer overflows in their software? I personally don't think so...)
Some people are reading this article and using it as evidence to support low-level languages like C. ("Abstractions are leaky, so programmers need to have access to low-level details in order to work around leaky abstractions." or "Abstractions are leaky, so there's no point in using abstraction.") I think that's exactly backwards! Essentially, what I'm claiming is that C++ is a poor language for large software precisely because it does not allow programmers to create "tight" abstractions. Some languages do! These languages are much more pleasant to program in, and to build large software in! And in those languages, we can indeed make tight abstractions without the kinds of leaks he's described.
I guess you are a troll (I hope you don't really believe what you're saying!!), but you're missing an important point: FreeBSD has security holes frequently found in it (ie, buffer overflows, heap overflows, format string attacks); bugs that would be impossible to make in a language like (say) Java. Security holes are the most salient example, but there are many perils to trying to do things "manually" and by programmer brute-force in a language like C.
Java's not my favorite language, but programs written in it tend to be more robust than their C counterparts.
Is this a "copyright" bit? (Like the bit set when you make a digital copy of a minidisc?) If so, be careful if you release this program, or you might run into problems similar to my own bit-flipping software !
Are you crazy? Use a network filesystem hosted on one machine, or network storage. Sharing the same physical drive between two concurrently-running operating systems will require special drivers and extra communication between the two (at best), and be totally unreliable at worst.
We use all of our brain.
Well, I use the other half to drink beer and scratch my nuts.
thpt.
Yes, it would be pretty boring. I've done it a little bit for a class I took a few years ago, and it was really not very fun. My feeling is that we have enough corporate-looking fonts already, and that it's much more fun and interesting to push the envelope on new font looks, as well as extend the corporate fonts to cover more of the Unicode charset. I would be interested in a push to create free (as in freedom) corporate fonts to replace existing ones, but it really is a pain in the ass so there'd need to be a good chance of the project producing something worthwhile
I do like to make usable bitmap fonts, though, and I've done some of that.
Sure, it's http://www.andrew.cmu.edu/~twm/embed/dmca.html
If you want your mathematical publications to look really good, just use my fonts.
http://fonts.tom7.com/
Trust me. Instant PhD.
You really shouldn't judge a professor by his New York Times article. It's not a technical article, and it's not intended for the tech-savvy Slashdot audience. It's supposed to 'wow' your average computer user or perhaps drum up some buzz so that he can get better funding. Just because he's a dreamer doesn't mean he doesn't have any idea what he's talking about.
Also, your sarcastic comment about Yale being "CS central" is way off mark. It's not a top-tier school (I think they're ranked in the 20s or so for graduate school), but it is a strong program and they have several really good people there.
I don't agree with what he's saying, either, but that doesn't make him an ass. If you want to make a fair analysis of his research, you should maybe check out one of his research papers at citeseer.
If it has brakes then what is the point of the trees at the bottom?!
bug 178,326 ... "There are not 200,000 bugs in Bugzilla" ... "There are not 200,000 bugs in Bugzilla" (closed - DUP bug 178326) ... "There are not 200,000 bugs in Bugzilla" (closed - DUP bug 178326)
...
... "PROFIT"
bug 178,327
bug 178,328
bug 200,000
I agree with you. I always get dizzy when they do one of those choppy pans. (I-Max can be even worse because the field of view is so much bigger...)
By amazing, you mean, "worse than Doom?"
No, regulation is not the answer. There are loads of technological solutions of varying complexity: hash cash, authentication, etc. If we care a lot about Spam, we should be working to decide on a technology and implement it in our mail readers. (There are some, already, like S/MIME, that have a fair amount of deployment.)
Think about what you're saying: Legislate to try to extend the life of a legacy system? We should not be encouranging the government to do this kind of thing. How much do we hate the DMCA? How much will we hate the anti-anonymous e-mail law? Don't we *want* authenticated and encrypted communication anyway? Why do we use ssh for typing commands at our shell (pretty boring to read, except for passwords) but SMTP for our english messages (often much more sensitive!)?
ahahaha....!!
yikes!
Somehow the idea of sex with 50ms latency doesn't sound so appealing...
Maybe I'm just naive, but can someone explain a believable situation where four slower CPUs (say, 100mhz) would beat two faster ones (200mhz)? There's loads of overhead in an SMP system, so I find it hard to imagine that having more chips would be better. (I don't know about the special weird requirements of a big SQL system, though).
What about Nintendo characters? Is it the fat guy from Ice Hockey or the L-shape from Tetris?
http://snoot.org/toys/wuss/vg/
Well, the academic programming language community doesn't agree with you. We still publish papers and do research and develop new programming languages and new programming language ideas. You might say, "computer programmers are very slow to adopt new programming languages and ideas," and that would be true. But that doesn't mean that computer scientists aren't still working on more abstract, more expressive languages!
This is not a technical whitepaper. This is a dream that a college kid had about a supervirus that controlled the whole internet. It would be much more interesting if he had also dreamed up an implementation, since there are loads of difficult issues that come up when you're forced to detail this kind of idea in the way that's needed to actually write a program. Not even worrying about the obvious scaling issues (especially with regard to failure recovery), there are a bunch of assertions made in the text that are simply wrong, or at least completely unproven. Take, for instance, the statement, "The only way to protect against Curious Yellow is to inoculate every computer with an anti-worm, Curious Blue, which uses similar technology to instantly distribute security patches." (???)
Another example is the "Security, Cryptography..." section, which is essentially just a rambling narrative of a hypothetical situation based on some messed up assumptions:
"Due to the large size of private keys, they cannot be easily remembered and so much be stored electronically somewhere."
Sure, but it's easy to store them encrypted with some memorizable key. That's what PGP does, for instance, and stealing the encrypted private key is pretty useless!
Vague statements like "Using statistical analysis of the propagation of code updates, the source of updates can eventually be traced," are equally underexplained and undermotivated. It's pretty easy to get data anonymously onto the internet -- there are anonymous remailers, web proxies, usenet servers (groups.google.com), etc. I recall a worm whose creator anonymously posted cryptographically signed updates to sci.crypt (or something like that), for instance. Using an internet kiosk or setting up a free AOL account from a payphone and then using one of these would be pretty damn hard to track.
Basically, this is nothing more than wild speculation of the sort, "Wouldn't it be cool if...!", except without the if. Give us technical details and analysis, not a barely believeable science fiction story!
Wow, you've been advocating music and technology since August 2002? What amazing vision!