You are wrong, scripting is just one possibility. You can also write animations purely declaratively using elements like <animate> or <animateMotion>, see the animation chapter in the SVG spec. Another possibility is SMIL.
Erm, while RMS' behaviour towards Symbolics (and the "philosophical" consequences he drew from that event) might have been stupid and annoying, he most definitly didn't drive them out of business. He certainly helped their competition, LMI, to stay alive though, which I fail to see as a bad thing. One could also say that Symbolics didn't exactly play nice with either LMI or the AI labs when they made the deal about the CADR source.
Symbolics died years after that (technically, it is even still alive. You can still buy OpenGenera for the Alpha from them, for example, and they even have some LispMs in stock), because of a mixture of bad management decisions, their target market disappearing in the "AI winter" and stock hardware becoming more competetive with their special-purpose one. There is no single person to blame for their demise.
Another plus is that it is possible for developers in some countries (like germany) to use the BSD license, while they would have to die in order to make their code public domain. This is for some reason not a popular choice (probably because even after the author's death, it takes 90 years before the code is PD).
I personally think that using the same package format as for the ports would be a better idea that introducing yet another mechanism like stow, but that's a detail. I certainly agree that a more modular base system would help.
Doesn't NetBSD do this now?
IMHO it was a very good decision to move perl to ports. I can see the same for other contributed parts at least, say bind, sendmail or cvs which not everybody needs.
From an end-user perspective this may be true, but internally, the ports system is quite ugly (and FreeBSD's more so than the one in OpenBSD and NetBSD's pkgsrc).
One of the biggest problems is that there is no standard way to handle options in port makefiles. As a user, you have to examine the makefile to look for the WITH_* variables used, or hope that the port will tell you before it starts to build - but there is nothing that would allow you to get a list of supported options programatically, which would be needed for a GUI, or for ports that depend on certain options being set in other ports.
The whole thing being basically written in make(1) (I wonder if it is the biggest application of make ever, I wouldn't be surprised) doesn't exactly help either, because it makes introducing changes somewhat delicate. Of course, switching to another system is not realistic, nobody wants to rewrite 8000 ports. Even a small change like moving the one-line package description from it's own file into the main makefile took a lot of work.
It's quite funny that you highlight XML being a markup language (or rather, a tookit to build markup languages), and don't even include document markup as something it's good for.
Despite all the hype behind XML, markup somehow doesn't really seem to be any more hip than in the dark SGML ages. Sometimes I really wonder why all the data-heads try reinventing ASN.1 with more bloat and complexity so hard.
Pull parsers have become a little more popular recently. There is a more thorough overview at xml.com, by the way.
As to your second paragraph, I don't seem to get what you are talking about. Stream-based APIs and XPath generally don't mix at all - how should an XPath expression like//foo[position()=last()] be handled in, say, a SAX handler?
There is, however, some kind of middle ground, namely Streaming Transformations for XML, an XSLT-ripoff based on SAX with a limited XPath lookalike. Quite useful, IMHO.
Um, but why do you have to actually learn (La)TeX for that? If you format your documents with jade or passivetex, you'll probably need to know DSSSL or XSL respectively, but you shouldn't ever have to hack the generated TeX directly.
One would think that economists, having studied the Japanese downfall would have warned against rapid and unchecked growth but no, they had to wait until the virtual walls started to fall apart on them.
Excuse me? Not only economists, every taxi driver could predict the.com crash, and have done so quite vocally. It was hardly a surprise for anyone. That just didn't stop it from happening, because preventing an economical crisis is not something investors and entrepreneurs (can afford to) care about individually.
Not to mention that this syntax would only work in Scheme anyway, scince in Common Lisp the CAR of a form to be evaluated has to be a symbol or a list whose CAR is LAMBDA.
On the other hand, (incf c 4) is probably not such a good name for a programming language either.
Once data is in XML I can manipulate it without having to write a parser.
Um, no. Or yes, but only in not too interesting ways.
An XML processor (Note that the W3C XML Rec carefully avoids the term "parser". That is for a reason.) is more like a lexer than a parser in traditional terms. It tells you about the syntactic elements of an XML document, but nothing about their meaning or relation. In other words, XML is not a language, XML applications are. Yet languages is what people need.
It turns out that you actually cannot do all that much with plain XML without knowledge of the vocabulary used. It is great that you can mix vocabularies, and in a sense embed DSLs in whatever it is that you really want to use (like XInclude, which is usefull in lots of cases, but still an XML language of its own). Actually, I yet have to see anyone manipulate generic XML docs, it is always about specific XML applications. XML is not as general a solutions as everybody (or at least most marketeers) seems to think.
That these applications are easier to deal with than a WordPerfect document embedded in an ASN.1 stream is true, however. But it tells more about WordPerfect and ASN.1 than about the inherently stupid idea of a generic exchange format if understood as anything beyond syntax.
I'm happily using Internet Explorer on my Ultra5 running Solaris box. Of course, Microsoft has stopped developing it after the browser war was won, but I guess they thought it would be a stupid idea to let Netscape take all of the Unix market back then. In many ways, the Java/.NET thing doesn't look that different from the IE/NS one.
The point is that rights aren't
given by anyone, with the philosophical exception of God. They are merely recognized.
Bullshit. Something becomes a right if some people think it would be a good idea, and arrange for this view to become dominant in the society they live in. One particular rhetorical strategy in the struggle to make a "right" become accepted is proclaiming that it can somehow be derived from the words of some deity, or a vague notion of "human nature", but in the end that claim has no more truth value than saying that something will help the economy or the war against terrorism.
What is a "right" and what's not is completly dependent on the currently accepted ethics of the society in whose context this right is debated, and as this can change radically. There is no single, fixed definition, it all has to be agreed upon and fought for, and is highly variable. This process is otherwise known as "civilization." No God involved, it's all done by mere humans.
I just think that the "here's the source, go fix it yourself" attitude is not that much better than the "your software suxx, go fix it" one. Personally I consider user feedback not much less important that actual code patches - and of course, I reserve the right to reject either in my own projects. It's basically a matter of mutual respect, I guess.
That said, the Gnome project certainly has made itself an easy target for some snide remarks regarding user demands when they decided that their target audience are recent windows converts and computer-iliterates;-)
Have you heard that Gnome is open source!? Anybody can make anything for the project and submit a patch.
Sure, everybody could just spend some years getting up to speed with the millions of LOC that make up Gnome, not to mention all other apps they could want to use, so they can fix stuff themselves. On the other hand, there's this new methodology called "division of labour" that has been gaining popularity lately. Maybe the OS movement should look into that.
You can always run all Gnome apps on a KDE desktop and vice versa. You can also run them on twm, or use a plain XLib app with any desktop. That's great.
There are several desktop platforms, and there will always be, because they have different goals (KDE tries to make the desktop as slow and space-wasting as possible, while Gnome's goal is to remove as many useful configuration options as it can while avoiding cross-app integration;-). Has never been different, will always be that way. Only that, thanks to X11, we have interoperability between them. The world is great if you are a Unix user.
I'm serious. People in the Windows world use Excel not only to calculate stuff, but as some kind of application platform. Personally I think that's stupid in most cases, but not offering it is even worse.
Maybe I just couldn't find it anywhere, but: Is Gnumeric easily scriptable? It doesn't have to be Excel or VBA compatible (in fact, about every other language would be better, IMHO), it doesn't need an integrated IDE with debugger etc. like Excel has, but the only thing I could find so far is a "plugins" directory containing.so files - that can't be it. Is there something better, and if so, why the f**k isn't it documented prominently?
Slashdot Mirror
You are wrong, scripting is just one possibility. You can also write animations purely declaratively using elements like <animate> or <animateMotion>, see the animation chapter in the SVG spec. Another possibility is SMIL.
Symbolics died years after that (technically, it is even still alive. You can still buy OpenGenera for the Alpha from them, for example, and they even have some LispMs in stock), because of a mixture of bad management decisions, their target market disappearing in the "AI winter" and stock hardware becoming more competetive with their special-purpose one. There is no single person to blame for their demise.
Another plus is that it is possible for developers in some countries (like germany) to use the BSD license, while they would have to die in order to make their code public domain. This is for some reason not a popular choice (probably because even after the author's death, it takes 90 years before the code is PD).
Does "Kusari" have some meaning in japanese per chance? That one is still a mystery.
Do non-alphanumeric characters count? Otherwise you might be happier with BSD/OS, even if it's not free.
Doesn't NetBSD do this now?
IMHO it was a very good decision to move perl to ports. I can see the same for other contributed parts at least, say bind, sendmail or cvs which not everybody needs.
One of the biggest problems is that there is no standard way to handle options in port makefiles. As a user, you have to examine the makefile to look for the WITH_* variables used, or hope that the port will tell you before it starts to build - but there is nothing that would allow you to get a list of supported options programatically, which would be needed for a GUI, or for ports that depend on certain options being set in other ports.
The whole thing being basically written in make(1) (I wonder if it is the biggest application of make ever, I wouldn't be surprised) doesn't exactly help either, because it makes introducing changes somewhat delicate. Of course, switching to another system is not realistic, nobody wants to rewrite 8000 ports. Even a small change like moving the one-line package description from it's own file into the main makefile took a lot of work.
Despite all the hype behind XML, markup somehow doesn't really seem to be any more hip than in the dark SGML ages. Sometimes I really wonder why all the data-heads try reinventing ASN.1 with more bloat and complexity so hard.
As to your second paragraph, I don't seem to get what you are talking about. Stream-based APIs and XPath generally don't mix at all - how should an XPath expression like //foo[position()=last()] be handled in, say, a SAX handler?
There is, however, some kind of middle ground, namely Streaming Transformations for XML, an XSLT-ripoff based on SAX with a limited XPath lookalike. Quite useful, IMHO.
Um, but why do you have to actually learn (La)TeX for that? If you format your documents with jade or passivetex, you'll probably need to know DSSSL or XSL respectively, but you shouldn't ever have to hack the generated TeX directly.
Can't we perhaps just destroy C++ and maybe safe something else?
On the other hand, (incf c 4) is probably not such a good name for a programming language either.
An XML processor (Note that the W3C XML Rec carefully avoids the term "parser". That is for a reason.) is more like a lexer than a parser in traditional terms. It tells you about the syntactic elements of an XML document, but nothing about their meaning or relation. In other words, XML is not a language, XML applications are. Yet languages is what people need.
It turns out that you actually cannot do all that much with plain XML without knowledge of the vocabulary used. It is great that you can mix vocabularies, and in a sense embed DSLs in whatever it is that you really want to use (like XInclude, which is usefull in lots of cases, but still an XML language of its own). Actually, I yet have to see anyone manipulate generic XML docs, it is always about specific XML applications. XML is not as general a solutions as everybody (or at least most marketeers) seems to think.
That these applications are easier to deal with than a WordPerfect document embedded in an ASN.1 stream is true, however. But it tells more about WordPerfect and ASN.1 than about the inherently stupid idea of a generic exchange format if understood as anything beyond syntax.
Maybe we could find a compromise and remove only the useless stuff next time.
I'm happily using Internet Explorer on my Ultra5 running Solaris box. Of course, Microsoft has stopped developing it after the browser war was won, but I guess they thought it would be a stupid idea to let Netscape take all of the Unix market back then. In many ways, the Java/.NET thing doesn't look that different from the IE/NS one.
A cheap trick to get around the limitation that there are only 17576 TLAs.
DMCA? They have weapons of mass decompilation, dammit!
What is a "right" and what's not is completly dependent on the currently accepted ethics of the society in whose context this right is debated, and as this can change radically. There is no single, fixed definition, it all has to be agreed upon and fought for, and is highly variable. This process is otherwise known as "civilization." No God involved, it's all done by mere humans.
I just think that the "here's the source, go fix it yourself" attitude is not that much better than the "your software suxx, go fix it" one. Personally I consider user feedback not much less important that actual code patches - and of course, I reserve the right to reject either in my own projects. It's basically a matter of mutual respect, I guess.
That said, the Gnome project certainly has made itself an easy target for some snide remarks regarding user demands when they decided that their target audience are recent windows converts and computer-iliterates ;-)
There are several desktop platforms, and there will always be, because they have different goals (KDE tries to make the desktop as slow and space-wasting as possible, while Gnome's goal is to remove as many useful configuration options as it can while avoiding cross-app integration ;-). Has never been different, will always be that way. Only that, thanks to X11, we have interoperability between them. The world is great if you are a Unix user.
I'm serious. People in the Windows world use Excel not only to calculate stuff, but as some kind of application platform. Personally I think that's stupid in most cases, but not offering it is even worse.
Maybe I just couldn't find it anywhere, but: Is Gnumeric easily scriptable? It doesn't have to be Excel or VBA compatible (in fact, about every other language would be better, IMHO), it doesn't need an integrated IDE with debugger etc. like Excel has, but the only thing I could find so far is a "plugins" directory containing .so files - that can't be it. Is there something better, and if so, why the f**k isn't it documented prominently?