"...anyone who's not involved in CS research treats the products of this endeavor as if they were smallpox-infected blankets. Even when it is clearly - in my opinion - good, it winds up ignored. Because of the inescapable grant-related propaganda, it's impossible to tell what's good and what's not.
For example, recently some of the same people involved in the PL research I so dislike built a language called Cyclone, which adds some very useful safety features to C. There are still zillions of free-software projects written in C, and probably most of them could benefit from upgrading to Cyclone. But the thing has the academic kiss of death on it, and no one will touch it. The mailing list is virtually empty.
This is not just prejudice. It is rational mistrust. Academics, as we've seen, have no incentive to build software that's actually relevant, and every incentive to build software that appears to be relevant. They have every incentive to overpromote, and no incentive at all to build an actual user base. In fact, an actual user base is an enormous drag for a CS researcher, because it demands actual support, which does not advance the researcher's career at all. Also, because of the nefarious Bayh-Dole act, CS researchers are frequently armwrestled into patenting their work, which of course they have no incentive to disclose. If the rest of these factors didn't give you a reason not to use academic software, this certainly would.
The result is a world of Potemkin software which appears to be enormously useful, even revolutionary. In reality it is unusable. The researchers are some of the smartest people in the world, and surely some of what they're doing has some merit. But it is almost impossible to figure out what's wheat and what's chaff, and most sensible people just don't come near it."
what the author of this quote doesn't seem to understand is that the primary output of academic research in CS is not an industrial-strength implementation of an actual product, but rather is a prototype whose ideas can be transferred into future products. it's unreasonable to expect a group of graduate students and professors to build software on par with well-tested, well-QAed open-source or commercial products ...
i agree that researchers often don't have an incentive to make robust, industrial-strength implementations of their work, but some systems hackers are actually quite good at making real software that people actually use. examples:
most of the time, though, the way that CS systems research impacts the world is by:
a.) the researchers founding their own company from their research - e.g., VMWare, and more recently KSplice (http://www.ksplice.com/)
b.) a big company implementing features in their own products based on research findings - e.g., machine learning at Google, OS security in Google Chrome, and even gasp OS security in Microsoft Windows OS
The stuff about going after patents isn't true in my experience: I can't think of a single prominent CS academic researcher in systems/PL who spends a lot of time going after patents (... unless they do a startup company, of course).
But otherwise, sure -- academics aren't incentivized to produce usable, non-prototype software. Sometimes they do anyway, but they aren't really rewarded for it professionally (with a few exceptions: e.g. Chord). That is especially true of something like Cyclone, which would require pretty considerable effort to support.
The hope is that by writing papers that clearly describe a new idea, practitioners can make use of ideas developed by researchers (e.g. Cassandra is heavily influenced by the Dynamo paper). That's not always true, but forcing academics to write production-quality software and then provide support for it probably wouldn't make a lot of sense either.
> I can't think of a single prominent CS academic researcher in systems/PL who spends a lot of time going after patents
Well.. what does "prominent" mean? A professor of mine has 10x more patents than papers. He once said, he is angry about not being prominent because of too many patents!
(no papers but patents = holding knowledge back = disturbing innovation?)
Wow, this is great. This is exactly the sort of language people insisting on C for systems programming need. It is basically the same language, but with a few bounds checks inserted by the compiler that eliminate almost all problems with C.
I hope this gains some traction amongst the large open-source C applications. (Things like emacs, xmms2, etc.)
Much as I agree, I'd say widespread adoption is iffy at best. For one thing, Cyclone was last updated in 2006. For another, Cyclone imposes some performance degradation (about 50% slower, according to one paper). For many projects, performance is the reason they're using C in the first place.
I would say that only a very small percentage of C programs are C for speed. Often, they are C for historical reasons instead. (I can't think of any program I use on a daily basis that is C-for-performance, but I can think of a lot that are written in C. This means I get all the crashes and security problems associated with C, but I spend all my time waiting in IO and can't see any of the benefits. These applications would do very well with Cyclone.)
Not so sure. Cyclone is closer to C, so the porting of libraries will be easier. To me, it's a pretty good realization of "C with Safety Features". It seems to have the minimum to accomplish that.
Memory management seems simpler in Go, however. This is a big advantage for Go.
Hmm. I wonder if it might be too close. That is to say, close enough that people think "I'd rather have this implemented as a static checking flag in my C compiler and a few libraries" - and promptly forget it because they have filed it under "feature request" along with the zillion other things they want from a compiler.
The Go designers felt compelled not just to explain why their language is good, but why it ought to have a separate existence and not be implemented as an add-on to C/C++.
close enough that people think "I'd rather have this implemented as a static checking flag in my C compiler and a few libraries" - and promptly forget it
Cyclone seems to go a bit beyond that. I'd have more confidence in this as a basis for writing a highly secure kernel than just "a static checking flag in my C compiler and a few libraries."
This is fabulously done. While some of the pointer types are pretty verbose, they have nice abbreviations for many of them, and the "let" statement is just brilliant.
So basically, the verbose pointer types mean that when you're doing something unusual and/or sketchy, you have to document that fact. I'll consider that another feature as well ;-)
Anybody know if the heap garbage collector that they use is any good?
Man I wish they'd had this when we started on a project at work a year and a half ago...
It was available earlier than that, even. But as pointed out below, this is a research project. I wouldn't use a research project in a production product.
Objective C is not "safe", any more than C++ is. It layers another (very nice! don't get me wrong) layer on top of C's semantics but retains all the problems with C.
- Mencius Moldbug's Unqualified Reservations
(http://unqualified-reservations.blogspot.com/2007/08/whats-w...)