No More Coding From Scratch? 323
Susan Elliott Sim asks: "In the science fiction novel, 'A Deepness in the Sky,' Vernor Vinge described a future where software is created by 'programmer archaeologists' who search archives for existing pieces of code, contextualize them, and combine them into new applications. So much complexity and automation has been built into code that it is simply infeasible to build from scratch. While this seems like the ultimate code reuse fantasy (or nightmare), we think it's starting to happen with the availability of Open Source software. We have observed a number of projects where software development is driven by the identification, selection, and combination of working software systems. More often than not, these constituent parts are Open Source software systems and typically not designed to be used as components. These parts are then made to interoperate through wrappers and glue code. We think this trend is a harbinger of things to come. What do you think? How prevalent is this approach to new software development? What do software developers think about their projects being used in such a way?"
Oh my (Score:2, Insightful)
Did we ever really code from scratch? (Score:1, Insightful)
We're already there (Score:3, Insightful)
On the other hand, I welcome the idea that my free code would be used by others - it is a flattering prospect, I suppose.
Others profit from this sort of re-use: COM, CORBA, Jars, etc...
No way Jose. (Score:4, Insightful)
Some basic tasks like file io or token processing and such minor things might be reused. But even then porting something so simple like a string tokenizer written for a full fledged virtual memory OS like Unix/WinXP to a fixed memory handheld device is highly non trivial, especially if you want to handle multi-byte i18n char streams
If the author sells what he was smoking while coming up with the article, he stands to make tons of money.
Re:Did we ever really code from scratch? (Score:1, Insightful)
Furthermore, its not "All good art starts with theft" its "Good artists copy, great artists steal".
Re:No way Jose. (Score:3, Insightful)
You claim that this rocket failure is due to software reuse. That just sounds wrong to me. I don't think that not starting from scratch is that relevant. I could more convincingly argue that the failure is due to the software not being tested with the input values that it would receive during operational use. That is important, be the code new or old; and when a failure costs millions, not doing so is inexcusable.
Or maybe... (Score:2, Insightful)
Some context for people who didn't read the book (Score:5, Insightful)
First, Vernor Vinge has a PhD in Computer Science. This obviously doesn't guarantee he can't be wrong, but to those commenters who said something like "these ideas are idiotic"... you've got an uphill battle to convince me that you're that much smarter than Vernor Vinge, especially as most of you saying that don't show me you understood what he was saying in the first place.
Second, A Deepness In The Sky is set in his "zones of thought" universe. In this universe, the fundamental limits of computation vary depending on where you are physically in the galaxy. This is only faintly hinted at in A Deepness In The Sky, it is explicitly spelled out in A Fire Upon the Deep. This limit on computation may or may not be real. One of the effects of this limit on computation is that you can build a system larger than you can really handle, and eventually all such systems come apart in one way or another. This story is set thousands of years in the future and it is explicitly (albeit subtly) pointed out that the software running the ramscoop ships has direct continuity with modern software. (Qeng Ho computers use the UNIX epoch as the most fundamental form of timekeeping; apparently even the relativistic compensation is layered on top of that.) We are at the very, very beginning, where it is still feasible to burn an OS down entirely and start from scratch.... or is that really still feasible? (Perhaps Microsoft will soon find out.)
Those of you posting that "we can always wrap it up in an API or whatever", I'd say two things: First, you get the Law of Leaky Abstractions working against you. The higher up the abstractions you go, the more problems you have. (Look it up if you don't know what that is.) The more sub-systems you make, the larger the state space of the total system becomes (exponentially), and the harder it is to know what's going on. It is entirely plausible that you eventually hit a wall beyond which you can't pass without being smarter, which, per the previous paragraph, you can't be.
In other places in the galaxy, you can be smarter, and Vernor Vinge postulates the existence of stable societies on the order of thousands or tens of thousands of years or beyond, where the society actually outlasts the component species, because the software base that makes up the species does not exceed the ability of the relevant intelligence to understand it.
Both cases (software might exceed intelligence, intelligence might grow with software) are extremely arguable, and I do not think he is advocating either one per se. (Leave that for his Singularity writings.) But you do him a disservice if you think he is not aware of the issues; he's extremely aware of the issues, to the point that he is the reason some of us are aware of the issues.
(Even this is a summary. In isolation, probably the best argument is that it is always possible to create a software system one can not understand or control, but one person can be wise enough to avoid that situation. However, in A Deepness in the Sky Vernor Vinge explicitly talks about how in a societal situation, one can be forced by competitive pressures to over-integrate your system and make it vulnerable. "OK, but the government can be smart enough to realize that's going to happen and step in to stop it." First... smart government? But even if you overcome that objection, now your society faces death-by-surveillance and other automated law enforcement mechanisms, which since they can't be human-intelligent will fail. If you avoid that (and it is a big temptation), then you face the problem of anarchy. And remember that "governance" is anything that governs; even if the "formal government" doesn't regulate you to soceital death, private corporations may do it. Anyhow, upshot, Vernor Vinge has done a lot of thinking on this topic, it shows in his books, it is not showing in the criticisms I've seen posted, and when it gets down to it he really has more questions than answers.)
Re:Components for Linux, anyone? (Score:3, Insightful)
On DOS and Windows, applications tended to be all-in-one blobs that use proprietary file formats and only depend on the operating system itself. Thus, OLE made sense. There was OLE-type technologies on Linux (such as Bonobo and KParts) but they never took off in any big way due to the general lack of need. In most cases, they were just used for automation, which better technologies such as DBus now exist.
As for "real code reuse" on Linux... try ldd-ing any application and seeing how many other libraries it uses to do it's bidding. Many application's I've written are just sticking together bits and pieces of other libraries, and that's in C++. I'd go as far as saying that code reuse on Linux is currently better than that in Windows. Generating quick applications with Linux tends to be pretty easy using bash, Python and even C, C++ or C#, where libraries have directly translated into "components" and "modules". The thing on Linux slowing down development isn't having to reinvent the wheel every time you write code, but rather, deciding what libraries you want to depend on and the difficulty of the languages favoured in Linux development, like C.
Since you bring it up, OLE seems to be taking a backseat in Windows now, where ActiveX is rarely used by anything other than IE plugins. Now clipboard/d'n'd/DDE and Microsoft Office are the only times I actively see it being used. COM is still heavily in use by libraries such as DirectX, however. It was never really used to it's full potential, such as to open Photoshop documents in Microsoft's preview application. Windows, with