First of all, 'language' is a very wide concept, almost so wide as to be meaningless. I could call the correct sequence of buttons on my VCR a language and still have some justification in doing so.
Actually, you would be entirely justified in doing so. A command sequence in your VCR's command language consists of a series of "words". That most of the words are very short ones does not disqualify it as a language.
Observing the common ground between limited "end-user" command languages and general-purpose programming languages is certainly not meaningless. It is useful to see all HCI as a space of possibilities, some which have very general expressive power and some which severely delimit interactions. Concluding ahead of time that all end-user interfaces belong in a small subspace of this realm will almost certainly prevent designers from designing the most effective interfaces. I suggest you read the Stephen Johnson article I pointed to earlier regarding textual interfaces.
I would probably say that the two major qualities dividing interfaces and languages are complexity and responsiveness. Interfaces are much more simple and more limited than languages. Besides, interfaces are oriented towards the command -> response -> next command -> next response type of operation, while languages work in a different way (formulate -> solve -> implement -> test -> etc.).
I don't believe either of these distinctions is justified.
Re: complexity, I think you mean "flexibility" rather than "complexity". The graphical interaction language of a Macintosh is considerably more complex than pure LISP. And in the flexibility realm, so-called interface designers care just as much as language designers do. Even Tog makes concessions to the idea of making interfaces flexible and powerful for the sake of experienced users. Conversely, so-called language designers aim for things like consistency and usability, concepts traditionally associated with graphical user interfaces. "Interface designers" are designing interfaces for a different kind of user than "language designers", so they make a different set of engineering tradeoffs between flexibility and ease of learning. However, the essential goals are still the same.
As for responsiveness, Lisp hackers and other functional language programmers commonly program in interactive programming environments. Perhaps you should reread my comment and note the point about "read-eval-print" loops. If you don't know what a read-eval-print loop is, look it up. If you think all programming occurs in a static "design-code-compile-test" paradigm, you should study a greater variety of programming systems.
Sorry to burst your pro-MS bubble, but this was a design Apple tested for the Lisa GUI. There's an article the ACM published which has screenshots of these old 1980-82 era prototypes.
Spoken with the true inflammatory ire of an AC. I am not pro-MS by any means. I pointed out that Windows deployed the idea of a fixed dock before NeXT, and it did. By your standard, Apple deserves no credit for the popularity of the GUI, because it was all invented by Xerox.
No, that's not true except in a trivial sense. A programming language is not an interface, it it rather a framework and a set of tools for structuring the problem and the solution. That's a very big difference and probably the one that confused Tog.
The distinction isn't so large. Programming languages have several functions. One of them is communicating ideas between one programmer and another. Another is to provide an interface between the human programmer and the computer; it is an interface with (one hopes) considerably greater flexibility than a typical user language, but it is an interface nonetheless.
Would you consider bash a user interface? Of course: it is a command shell, one of the earliest forms of HCI. It is also a programming language. The existence of LISP shells and read/eval/print "interactive programming" environments only makes the commonality between interfaces and languages more apparent. As another example, I challenge you to design a good Web search engine that does not employ some form of query language as an interface.
GUIs are simply an visual/gestural interactive language. People have even worked on "visual" programming languages whose syntax consists of pictures rather than text streams (though they are usually awful).
The distinction between "human interface" and "programming language" is so blurry as to be meaningless. That people regard them as vastly separate realms testifies only to the mental inflexibility (and historical shortsightedness) of most visually oriented designers. Interface thinkers like Stephen Johnson, who (IMHO) has many more interesting things to say about interfaces than Tognazzini, have often pointed out that languages can be an interface. The point and grunt religion, however, has not paid attention.
Whatever he has to say about BASIC is completely irrelevant, because that is simply not his field of expertise. He is first and foremost a human factors engineer.
I'm not going to get in a flamewar with Tog apologists, so I'll just say this and bow out of this thread. Every programmer knows that computer languages are one form of human-computer interface. That Tognazzini is so deeply mistaken about such a fundamental interface (every human being uses language constantly) speaks to, perhaps, a fundamental confusion about some issues.
I suggest you take a look at his comments on the "human factors engineering" of web authorship.
What have YOU done that qualifies you to make disparaging remarks about the man who helped define the Graphical User Interface as we know it?
The argument from authority has never impressed me. People with impressive resumes can make mistakes. I just suggested that people pay closer attention, that's all.
The dock is actually from NeXTStep/OpenStep, which Apple owns the rights to outright. If anyone is ripping anyone off, it's Windows ripping off NeXTStep
Actually, the dock may just be the one interface convention actually invented by Microsoft. Windows 1.0, which predates NeXT by about 4 years, had all its icons (including open applications) fixed in a row at the bottom of the screen. They didn't look like buttons, but since you couldn't move them up out of this area, it functioned much like a Dock/taskbar.
It's kind of funny, at the time Mac interface designers blasted Windows 1.0 for not allowing you to move those icons around. Of course, Windows 1.0 was a total interface disaster in almost every other way, but it had a fixed dock. It's pretty hard to track down pictures of the Windows 1.0 interface, but here are a few:
I used to respect Tognazzini a great deal. However, close reading of his writing, over an extended period of time, has led me to believe that he has questionable judgment about many issues. Just examine his article, How Programmers Stole the Web, where he claims that:
BASIC is the paragon of computer programming languages, because it uses a "simple" state-machine paradigm (I can only assume he means programs composed of global variables and GOTOs, like a finite-state automaton).
JavaScript is counterintuitive because it (a) resembles C++ instead of BASIC and (b) the code must be enclosed in comments (he thinks an XML-based inline programming language would have been the better choice, apparently ignorant of how bulky and clumsy pure XML-syntax programming languages like ColdFusion Markup Language (CFML) have turned out.)
Tognazzini calls it "inexplicable" that VBScript is not cross-browser and cross-platform, and seems to imply that this is due to engineers' habits of "enforced illogic" (which leads engineers to hate BASIC)---not on the Microsoft attempt to turn the Web into their proprietary fiefdom.
These are only a sample of the glaring Deep Wrongness in the article I link to above.
In addition, Tog is a relentless Apple partisan, despite his objections to the new Aqua interface. This clouds his perception of all Apple-related issues. For example, among other things, he says in the Aqua/OS X interface article that "Apple could argue, and few would deny it, that Apple was first and Microsoft is the one who made things difficult by failing to accurately copy the Mac interface." Ignoring, of course, the fact that Microsoft would have been perfectly happy to copy the Apple interface exactly, except that Apple is one of the most litigious companies in the IT industry (have you seen Microsoft threaten to sue KDE over their Windows98 theme?).
IMHO, Tognazzini has suffered from a lesser form of the same brain rot that has affected Jon Katz since becoming published on the web: free to spout off without an editor, never forced to confront dissenting opinions before publication, he has become something of an autodidact. This may seem a bit harsh, but I urge the programmers in the audience to read the "How Programmers Stole the Web" article. It reveals a great deal about the didacticism of Tognazzini's thought habits, and will probably cast a very different light on his supposedly authoritative interface design ideas.
I once respected Tog. Occasionally, he comes up with some good insights. However, don't let his impressive resume blind you to his often misled assertions.
The "code morphing" layer is what makes Crusoe stand apart from the rest. It optimizes on the fly the instuction set it's running on the fly. This means that your aps will run faster and faster as it runs. This layer is what gives the Crusoe it's speed.
The only way "code morphing" could run faster than native code is by exploiting runtime information to perform optimizations that are not possible at compile time. In other words, self-modifying code that runs faster than static code.
This is plausible, but that doesn't mean there would be no performance benefit in compiling native code. Research on self-modifying code is not unique to Crusoe---it's a very active area of research, and there are two major kinds: JIT and dynamic compilation. JIT, which you're probably all familiar with from Java, involves translationg code (typically from a foreign instruction set) and performing optimizations at runtime; dynamic compilation involves "staging" code at compile time to modify itself in a disciplined manner at runtime. JITs and dynamic compilation are very different in the nature of optimizations they perform; one of the major differences is that because dynamic compilation performs its analysis at compile-time, it can theoretically perform much deeper and more sophisticated optimizations.
Crusoe does no staging (it can't: it executes fully precompiled code), so its optimizations operate under severe time constraints. Therefore, Crusoe's code morphing is likely to produce code optimality akin to that emitted by a JIT compilation system: shallower analysis, shallower optimizations. Which almost certainly makes Crusoe's "code morphing" worse than native staged dynamic compilation would be.
In summary: my point is that self-modifying native code that improves its performance at runtime is entirely possible without "code morphing". On the other hand, binary x86 compatibility is arguably Crusoe's major selling point, so there's not much impetus for them to bother encouraging any kind of native code compilation. Anyway, I get the impression that Crusoe's entire architecture would have to be revamped if they wanted to run native code so it's a moot point.
If you're thoroughly confused by now, try visiting the dynamic compilation project at the University of Washington for more information on dynamic compilation.
~k.lee
(BTW: this does not mean that Crusoe does not embody any technical innovations. In particular, the hardware support the chip provides for its runtime code translation is very interesting.)
Incorrect. The Pentium, a.k.a. P5 core, does not have a RISC chip under the hood. It is superscalar and pipelining, but it does not translate x86 code into 32-bit-wide microops, as the P6 (Pentium II/Celeron) core does. Interesting how you feel free to pontificate about processor technologies when you don't know the difference between them.
Sun writes: The bytecode format was designed with generating machine codes in mind, so the actual process of generating machine code is generally simple. Efficient code is produced: the compiler does automatic register allocation and some optimization when it produces the bytecodes.
This is Sun's hype, not technical truth. Current JIT compilers perform only the most basic of optimizations when translating to machine code, because they operate under extreme time constraints. The machine code generated is "efficient", but only in comparison with the code emitted by a circa 1980 C compiler.
The choice of a high-level bytecode format made naive translation into machine code very simple, but it placed optimization between a rock and a hard place. You can't optimize load/store reordering, register reuse, or anything even vaguely machine-dependent at bytecode compile time, because bytecodes don't express those operations. On the other hand, you can't perform sophisticated optimizations such as the more complex forms of dataflow analyses during JIT compilation, because you don't have enough time. Hence, optimization suffers at both ends.
In any case, it's not clear to me how bytecodes are particularly "CISC". The term CISC was retroactively invented by RISC partisans to designate a particular microprocessor instruction set architecture, of which the 386 is the prime example. The JVM is not a microprocessor; it is a virtual machine, and there are features in the JVM instruction set that would never have appeared even in a CISC processor.
Basically, nothing you've said has convinced me or anyone else that RISC translation is nearly as efficient as CISC translation. Please provide an example of software or hardware that does RISC-CISC translation or even does RISC-RISC translation to support your claims that, "adequate performance could probably be achieved."
I suppose that it's difficult to use technical facts to convince those who have no technical background. However, that is not the entire population.
Perhaps you missed my point about native P6 code emitted by modern compilers, and its similarity to RISC code. I suggest you reread it. If RISC emulation is so slow, then x86 emulation should be slow for all the same reasons. Translating modern x86 code to RISC code is, in effect, a RISC to RISC translation. And the Crusoe demo seemed to indicate that yes, it is fast.
The fact that ecampbel's comments in this thread have been moderated so high is proof positive that when you referee technical opinions by popular vote, you get lousy technical opinions.
RISC code is extremely optimized for a specific processor architecture, and optimizing RISC code is a very processor intensive job.
So is optimizing CISC code, or, for that matter, translating CISC code to VLIW and then optimizing the VLIW instructions. In fact, students of compilers and architecture history know perfectly well that optimizing RISC code is actually much easier than optimizing CISC code. One of the prime motivations behind the uniform register file and instruction set of RISC architecture was ease of compilation.
Taking highly optimized RISC code (most of the time significantly reorded to exploit parrel and pipelining efficiencies), and trying to generate equivelent instructions in another architecutre would be very slow.
This might have some relevance, except that modern Intel architecture code usually consists of simple, RISC-like operations that are just as idiosyncratically reordered to exploit the pipelining/superscalar efficiencies in modern Intel chips. If translating RISC code is slow, then so is translating modern x86 code. See my other comment in this thread.
If RISC code was indeed easier to emulate, then JAVA would compile to RISC instructions, not CISC bytecodes. It compiles down to CISC bite codes so that the JIT on a particular platform can take one or two bite codes and expand them into the native instruction set of the operating system, and optomize them from there.
Java, nee Oak, was designed for embedded applications; the original motivation for using CISC-like bytecodes (and a stack architecture, of all things) was code compactness. Ease of translation into native machine code for JITs was not one of the primary concerns when the bytecode format was selected.
Another reason, there has never been a RISC emulator that has performed at anywhere close to a resonable speed. Any emulation of the Mac done on the PC only handles 68k CISC code. The reason for this is that RISC emulation is just too slow.
No; the reason is the lack of market demand. The x86 architecture's relative poverty of registers, and their nonuniformity, make it rather difficult to emulate, say, PowerPC code efficiently, but adequate performance could probably be achieved.
Emulating CISC based hardware is vastly easier than achieving acceptable performance emulating RISC based hardware. With CISC based hardware, each instruction does a lot, and might take several clock ticks to execute. The Transmeta emulator can come along and translate the instruction into equivalent Crusoe instructions, and achieve roughly comparable performance.
In principle, this is correct. In practice, Intel engineers made a deliberate design decision in the P5 and P6 generations to spend time making the RISC-like instructions fast (using deep pipelines, register renaming, and other magic), and the CISC-like instructions slow. Implementation of rarely-used, complex CISC instructions was simply too much of a performance drag.
As a result, modern optimizing compilers for x86 hardware generate very RISC-like code: mostly loads, stores, branches, and ALU ops. Look at the x86 assembly emitted by gcc -S sometime. Sensible compilers these days simply don't emit REP MOVSB or other behemoth CISC instructions left over from the 386 days.
Any putative performance gain from translating "complicated" instructions to many optimized Crusoe instructions is probably marginal. Hence, your argument about the relative "inefficiency" of Crusoe with regard to translating from RISC native code is incorrect.
BTW: for the interested, check out this Ars Technica article, which provides a fairly accessible discussion of why the RISC/CISC distinction isn't a very useful means of characterizing processors anymore.
I never said Newsweek or Salon were good, did I? Only "professional" and "middlebrow".
There was a funny Suck article a few months back where they called the Time offices and asked why they should renew their subscription when Newsweek offers identical content at half the price:
In retrospect, I do realize that comparing Slashdot to Newsweek was a little extreme. Slashdot does have good interviews and technology articles sometimes. And there is the occasional "Insightful" comment that's actually insightful.
what you're calling a common occurance strikes me as being fairly rare. May I suggest that you're used to forums where opposing viewpoints are normally screened out in subtle ways, and when you're actually forced to confront a disagreement you feel like someone is unfairly "shouting you down"?
I've been on unmoderated e-mail lists and newsgroups aplenty. I have zero problems with confronting disagreement. It's when disagreement consists of aggressive regurgitation of common evangelical propaganda, with a clear implication that anyone who disagrees with it is a moron, that I object. And that's happened to me plenty of times.
OTOH your experiences may differ, of course.
And by the way: "right-wing libertarian" is at least *supposed* to be something of an oxymoron (believe it or not, it's possible to be neither left nor right, which is how a lot of libertarians would classify themselves).
I use the term "right-wing libertarian" to distinguish them from "left-wing libertarians". Please see the following URL for a description of the latter:
You are certainly correct, however, if you mean that many views held by right-wing libertarians overlap very little with right-wing traditionalists or conservatives.
Maybe Sterling's point is that the Cantos (for example) will continue to be of practical interest long after the STL has gone to join Simula, Multics, and PL/I in the dustbin of history.
Perhaps you underestimate the longevity of code.
I once had a professor who told me that Boeing (or maybe it was one of the major airlines...) had a billion lines of COBOL in its computer systems. That kind of code base cannot be ported by humans to a newer language--not in next year, not in the next decade. Never. That COBOL, the professor said, is effectively a part of Western civilization, like the Empire State Building. Precluding the invention of superhuman AI (at which point all bets are off), he may have been right.
Given the amount of code that is currently being written in C++, STL might be of interest as long as the Cantos. Not that I'd bet on it, even though I think Pound is overrated.
What, then, is the Slashdot community? Are the various forums and communities that exist all over the Internet totally devoid of intelligentsia?
My definition of an intelligentsia is a small group of intellectuals committed to the free exchange of ideas and an active engagement in politics and social issues.
I think the Slashdot community is neither small enough nor, on average, intelligent enough to qualify as an intelligentsia. If you browse with your threshold at 3 or 4, Slashdot only approaches the quality of a middlebrow professional magazine like Salon or Newsweek.
Furthermore, there seems to be an aversion to open, friendly political debate in the Slashdot community. As in many other online forums, there's a strong right-wing libertarian faction that all-too-often shouts down all other views [0]. More importantly, there's a widespread hackish idea that politics is cheap talk, and that a person's opinions are worth no more than the code (s)he writes--a fact that prominent programmers in the community often use to dismiss political debate or criticism ("Shut up and show me the code.").
There may very well be an intelligentsia on the Internet. But I think that the subscribers of nettime-list or its cousins come much closer than Slashdot.
I'm sure I'll get thoroughly flamed for writing this. That's okay; my karma's high enough to take a few hits.
~k.lee
[0] If you're a libertarian, then please pause a moment before you flame me. I'm not saying that all libertarians are narrow-minded and rude; of course that's not true. I am saying that the fervor of some fundamentalist libertarians online often has a negative impact on the free exchange of political ideas, and that the large proportion of right-wing libertarians online makes pro-libertarian flame-fests a frequent occurrence.
Children do not have a natural urge to look at stuff that has no meaning or relevence to their age. They -do- have an urge to explore, though, which should be encouraged. They encounter something meaningless to them, they'll probably ask about it and move on. It's not going to hold any interest for them. . . . There is an exception to this. Children from severely dysfunctional families, with seriously screwed-up family dynamics, where their parents are living a gigantic lie, 24/7, are much more likely to behave in ways that do not reflect their age.
I'd like to know what kind of credentials you have re: child psychology. This sort of statement strikes me as incredibly naive, and I wonder if you're just making this up or you have some familiarity with actual research that suggests that only dysfunctional children like to look at porn sites.
From what I have read, all children are curious about sex from a very early age. A child that wanders onto a porn site may very well be interested, and early exposure to the wrong types of material (i.e. extreme sadomasochism [0], bestiality, pedophilia etc.) can have a negative impact on the child's sexuality for the rest of his/her life. Parents therefore have an understandable interest in controlling their children's exposure to sexual materials.
Censorware is extremely dangerous, of course, but spreading naive nonsense about the necessity for childrens' freedom, as opposed to parents' discretion, doesn't clarify the issue. It only clouds it.
~k.lee
p.s. In this post I focus on sex because I don't think children have as much of a natural interest in, say, neo-Nazism, though the same argument applies.
[0] I am not saying that sadomasochism is an immoral lifestyle for adults. However, if a 4-year-old child wanders onto a site that depicts women being tied up and beaten with a nightstick, with a caption that says, in effect, "Isn't this wonderful!"--that has a lasting negative effect on the child's sexual attitudes, because the child has no capacity for approaching that material critically. Only a fool would assert otherwise. And if you really believe healthy children have no interest in sadomasochism or other disturbing images, clearly you have not watched a cartoon or read a fairy tale lately.
Having worked with the gcc compiler for many years I can say that math fluctuations are increadibly easy to introduce through optimization.
Amen. Somebody should moderate this up. The pro-optimization faction here on/. seems to be a bunch of semi-competent high school-grade programmers who have no idea how incredibly difficult numerical computing is.
Free clue of the day: it's hard to write a program that produces good floating point results for any nontrivial computation. Seemingly trivial optimizations can result in accumulated errors and numerical instability that completely fsck up the entire calculation. Nothing could be worse for the SETI project than a legion of arrogant C hackers submitting blocks processed with patched, "optimized" clients that have different numerical behavior than the original.
It's too bad this guy's an AC-- this comment actually brings up a novel revenue model for OSS that I've never heard before. Moderators, wield your points.
A factual error yourself - Sun released it under the SCSL IIRC.
Oops-- brain burp. You're right, of course. Profuse apologies. OTOH my post was a/. comment, not an article that I am posting on a website that purports to give worthwhile opinions about the OS market. I think it's reasonable to hold such articles to a higher standard, right?
Anyway, my point stands either way. Sun supports Linux, but only so far.
I don't mean this to be a flame, but when are we going to stop posting links to osOpinion? The general quality of osOpinion articles seems to be very low: I have yet to read a single piece that does not contain vague handwaving generalizations and even factual errors. For example, in the above piece by Dave Leigh, he writes:
Microsoft also claims that Linux has no journaling file system, ignoring the fact that the SGI's XFS is a journaling file system. They also ignore the fact that NT 4.0 itself lacks a journaling file system!!
First of all, wasn't there a thread a couple of weeks ago in which we discussed the journalling abilities of NTFS? Second, XFS has not been released for Linux yet. Third, there is a journalling filesystem for Linux, but it's not XFS: it's ReiserFS.
I've got Doom, Quake, and other multiple player games for entertainment (although I'm personally a board game fan).
This is just silly. Game support under Linux is extremely sparse right now. In a world where even Macintosh doesn't get ports of even the most popular games (witness the recent Half-Life debacle), we'd be really foolish to claim that Linux has enough games for the average home consumer.
Thirdly, even if other Unixes were cannibalized, what would it matter? Linux would remain, and the point I made in the above paragraph works in reverse. Those Unix developers that now exist will move to Linux with no effort, and there will be no discernible effect in the workplace.
Clearly, this was written by somebody who doesn't know much about Unix. Linux is like Unix, and the transition would likely be easier for commercial Unix developers to make, but it's hardly going to be a transparent, effortless transition.
An entertaining footnote (#40): Again, the Gartner Group plays tug-of-war with themselves. The same short report recognizes that SCO and SGI are competitors and supporters of Linux, but the Gartner Group never bothers to answer the question as so why this may be the case. Clearly, the study in question is severely flawed and displays a shocking lack of understanding.
No, clearly Dave Leigh displays a shocking lack of understanding about the technology industry, where relationships of simultaneous competition and support are incredibly common. Sun, for example, supports Linux by releasing StarOffice under the GPL; on the other hand, it would be entirely happy cannibalizing the Linux market to grow Solaris/Java if it could. In fact, most astute observers believe this is exactly where Sun wants to lead us.
And the above list is just a quick sampling of Leigh's errors and misunderstandings. The mistakes are all the more annoying since they appear to be direct regurgitations of things that have been repeated countless time by the less-iformed zealots [0] here on/.
If I want to hear things like this, I'll read an old/. thread with my threshold down to 0. There's no good reason to link it as an article. Most osOpinion articles seem pretty much the same: they may be flattering to Linux, but they don't elevate the level of discourse, and they don't belong here.
~k.lee
[0] As opposed to the well-informed zealots, who are (unfortunately) all too rare.
I can't believe this ridiculous comment got moderated up.
Linux is open source, remember? The idea of China slipping security holes in the backdoor is pretty silly when we have a peer review process built into the system (and any security-conscious agency will definitely do a security audit before using Linux on any critical network). The chance that China will slip backdoors into Linux is about the same as the chance that Microsoft will slip backdoors into Emacs.
Moderators: do this thread a favor and moderate the parent comment back down.
The fact is that Netscape STILL dominates the Browser war for two reasons: 1) Companies use netscape on all their UNIX boxes. 2) Companies use netscape on all their Win95 boxes. IE wasn't free when the majority of companies purchased their licenses, and Netscape continues to dominate the market share in the commercial sector, which is roughly twice the size of the personal or private sector.
What a wonderful fact. Unfortunately it's incorrect. If you look at the server stats all across the web, you will see that IE is definitely winning the battle. Anyway, Communicator 4 and IE 4 were both released under equally free terms (and equally large downloads) so your argument about the cost of running either is vacuous.
Furthermore many pro-Linux people I know have been grumbling about the lack of the latest RealPlayer support and other niceties that people in the Windows world take for granted. Availability of certain plugins count almost as much these days as the browser.
You see, one of the most important differences between Windows and Linux is that Windows is all smoke and mirrors (marketing) whereas Linux is an product that is actually well made and capable of delivering on its promises. The public will grow tired of the illusion sooner or later, its all a matter of time.
This sort of Manifest-Destiny-style triumphalism is doing untold damage to the Linux community.
First of all, in case you haven't noticed, the biggest growth sector in computing is in online applications, not the desktop OS. The killer apps of the Internet revolution are websites. Nobody is going to care that Linux is robust if you can't access the next eBay through it. And there's nothing the Linux community can do to duplicate those websites because they are unique proprietary services that depend upon an irreproducible community of participants.
Second, assuming blithely that Windows is all smoke and mirrors, and will remain so forever, is simply a mistake. If you really believe that the tens of thousands of programmers at Microsoft with IQ in the 130's and up are incapable of producing a decent product, you need to re-examine your assumptions.
NT workstation, properly tuned, is very stable. Not as stable as Linux, but certainly not the crash-prone piece of snail-speed junk that some Linux advocates claim it is. Also, if you've seen the snapshots of Windows 2000's web-like desktop, you should be very afraid: I think Microsoft is closer to producing a consumer appliance "Internet OS" than anyone else out there.
The last thing the Linux community needs right now is complacency. Bill Gates got to where he is today by being utterly paranoid at every step that someone's going to crush him; we would do well to emulate him in this respect. With the DOJ trial winding down, Microsoft will soon be running without hobbles again. Linux coders need to rise to the challenge, and quickly. Dave was absolutely on target about the crucial importance of Mozilla. Mozilla may very well be the most important Linux software project ever.
Well, for graphics that small, size doesn't matter much anyway. Network packets come in large chunks of bytes, so the additional time spent downloading 144 vs. 45 bytes is negligible unless you're downloading a thousand of them-- in which case you'd probably be better off combining them into one image so the compression can exploit redundancies.
And then we get the comment "Religion and freedom have never really gotten along." Nice tie, but it doesn't explain a few people like Gangis Kahn, Napolean, or Hitler (who prosecuted the Jewish RACE much more so than the religion).
This is classic faulty syllogism. Go study some elementary logic.
JonKatz says: "Religion implies not freedom." (p -> !q)
The only full contradiction to this is: "Religion implies freedom, and vice versa." (p q)
You replied with, "Non-religion can also result in no freedom!" (!p -> !q).
Of course there have been oppressive non-religious regimes, but your statement doesn't even contradict JonKatz's statement, much less refute it. Besides, it's obvious that religions throughout history have been used as a tool of social control and hence have usually led to less freedom more often than more.
Of course, the rest of JonKatz's article was a wordy, overwrought pile of non sequiturs and faulty syllogisms anyway, so this point is rather moot.
The Dvorak/Qwerty debate is getting rather old [0]. What's more interesting is how the authors of this article progress generalize from this single extremely particular QWERTY example onto more general economic grounds-- specifically, the Microsoft trial.
Laissez-faire economists like to say that the cost of switching to another office suite, rather than staying with Microsoft, outweighs the benefits of switching to another suite; and therefore, there is no market failure. They ignore the huge and ruinous long-term costs of staying with Microsoft.
If Microsoft did not have a monopoly position that enabled it to exploit "network effects", would everyone bother upgrading to the latest version of Office every single time? The most commonly used Office application, Microsoft Word, has not changed appreciably since version 6.0.
However, since Microsoft is fond of making their file formats non-backwards-compatible (often with automatic conversions whenever someone opens a document), people using Microsoft products to exchange documents with each other are effectively coerced into switching whenever one employee, department, or client in the network upgrades to Microsoft products. No user wants to deal with this, but they must upgrade anyway; not when they feel the need for more features (which almost nobody does, for Office) but whenever Microsoft feels like releasing a new edition of its viral applications into the market.
Of course, according to the laissez-faire people, the present cost of staying with Microsoft is still lower than switching, so there is no such thing as network effects. But that's the very definition of network effects: the result of using a greedy algorithm over a network where such an algorithm is non-optimal.
This whole issue shows how dangerous it is to take advice about technical issues from people who have a vested interest in supporting a particular economic model.
~k.lee
[0] Maybe the authors are right, and maybe they aren't; I type at 100+ wpm, and unless I am going to get a huge speedup (> 200 wpm) in typing speed I am not going to bother switching one way or the other.
You might want to consider storing it somewhere else though because the last thing you'd want is joe average launching turbo vi to mess up his config file.
Joe Average will not be launching vi in the first place, and if he goes messing around in his.files (which are hidden by default in ls and most graphical file managers) he has either learned enough to know what he's doing, or will learn the hard way shortly. Putting.files in your home directory is no risk to the newbie because the newbie will not find them in the first place.
Now that's interesting's I guess those guys were trying their generic vi/emacs editors on XML. Jesus! The idea of XML is definitely not that you open vi and start hacking away.
Clearly you know practically nothing about software engineering, because if you did then you'd realize that typing in code is only a tiny fraction of the battle. Reading ColdFusion code is as annoying, compared to reading C, as writing it, because of the verbosity. No tool can remedy that.
If you're suggesting that programmers abandon the source text entirely and start programming using visual tools exclusively, then I've obviously been wasting my time here.
I wasn't talking about enclosing the original source but rather about replacing it
So was I. My point was that the following:
int main(void) {
printf("hello"); return 0; }
contains exactly 5 characters of string literal. The rest is actual program content. In an XML scheme, the program content would have to be written something like the following:
which gains us very little except extra verbosity. If you had bothered to go look up some ColdFusion code on the web, you'd have realized what I was saying.
I have programmed in an XML-syntax-based programming language. You have not. Please don't tell me how it feels. It's annoying. In fact, it's so annoying that Allaire (makers of ColdFusion) included a <CFSCRIPT> tag in the latest version, which allows you to write JavaScript-like, non-XML code instead.
The real reason is that C++ syntax is so complex he would have a hard time building the tool. Can you say #define?
If you really think Bjarne Stroustrup would have trouble building a javadoc-like tool for C++, you need a reality check. C++ syntax is complicated, but compiler authors have had tools (like lex, yacc, bison) for dealing with complicated syntax for years. Clearly, the *compiler* parses C++, so a javadoc-like tool could do so as well. Go learn a bit about compilers (e.g., write one [0]) before you start schooling the rest of us on the complexity of parsing computer languages.
Slashdot Mirror
First of all, 'language' is a very wide concept, almost so wide as to be meaningless. I could call the correct sequence of buttons on my VCR a language and still have some justification in doing so.
Actually, you would be entirely justified in doing so. A command sequence in your VCR's command language consists of a series of "words". That most of the words are very short ones does not disqualify it as a language.
Observing the common ground between limited "end-user" command languages and general-purpose programming languages is certainly not meaningless. It is useful to see all HCI as a space of possibilities, some which have very general expressive power and some which severely delimit interactions. Concluding ahead of time that all end-user interfaces belong in a small subspace of this realm will almost certainly prevent designers from designing the most effective interfaces. I suggest you read the Stephen Johnson article I pointed to earlier regarding textual interfaces.
I would probably say that the two major qualities dividing interfaces and languages are complexity and responsiveness. Interfaces are much more simple and more limited than languages. Besides, interfaces are oriented towards the command -> response -> next command -> next response type of operation, while languages work in a different way (formulate -> solve -> implement -> test -> etc.).
I don't believe either of these distinctions is justified.
Re: complexity, I think you mean "flexibility" rather than "complexity". The graphical interaction language of a Macintosh is considerably more complex than pure LISP. And in the flexibility realm, so-called interface designers care just as much as language designers do. Even Tog makes concessions to the idea of making interfaces flexible and powerful for the sake of experienced users. Conversely, so-called language designers aim for things like consistency and usability, concepts traditionally associated with graphical user interfaces. "Interface designers" are designing interfaces for a different kind of user than "language designers", so they make a different set of engineering tradeoffs between flexibility and ease of learning. However, the essential goals are still the same.
As for responsiveness, Lisp hackers and other functional language programmers commonly program in interactive programming environments. Perhaps you should reread my comment and note the point about "read-eval-print" loops. If you don't know what a read-eval-print loop is, look it up. If you think all programming occurs in a static "design-code-compile-test" paradigm, you should study a greater variety of programming systems.
~k.lee
Sorry to burst your pro-MS bubble, but this was a design Apple tested for the Lisa GUI. There's an article the ACM published which has screenshots of these old 1980-82 era prototypes.
Spoken with the true inflammatory ire of an AC. I am not pro-MS by any means. I pointed out that Windows deployed the idea of a fixed dock before NeXT, and it did. By your standard, Apple deserves no credit for the popularity of the GUI, because it was all invented by Xerox.
~k.lee
No, that's not true except in a trivial sense. A programming language is not an interface, it it rather a framework and a set of tools for structuring the problem and the solution. That's a very big difference and probably the one that confused Tog.
The distinction isn't so large. Programming languages have several functions. One of them is communicating ideas between one programmer and another. Another is to provide an interface between the human programmer and the computer; it is an interface with (one hopes) considerably greater flexibility than a typical user language, but it is an interface nonetheless.
Would you consider bash a user interface? Of course: it is a command shell, one of the earliest forms of HCI. It is also a programming language. The existence of LISP shells and read/eval/print "interactive programming" environments only makes the commonality between interfaces and languages more apparent. As another example, I challenge you to design a good Web search engine that does not employ some form of query language as an interface.
GUIs are simply an visual/gestural interactive language. People have even worked on "visual" programming languages whose syntax consists of pictures rather than text streams (though they are usually awful).
The distinction between "human interface" and "programming language" is so blurry as to be meaningless. That people regard them as vastly separate realms testifies only to the mental inflexibility (and historical shortsightedness) of most visually oriented designers. Interface thinkers like Stephen Johnson, who (IMHO) has many more interesting things to say about interfaces than Tognazzini, have often pointed out that languages can be an interface. The point and grunt religion, however, has not paid attention.
~k.lee
Whatever he has to say about BASIC is completely irrelevant, because that is simply not his field of expertise. He is first and foremost a human factors engineer.
I'm not going to get in a flamewar with Tog apologists, so I'll just say this and bow out of this thread. Every programmer knows that computer languages are one form of human-computer interface. That Tognazzini is so deeply mistaken about such a fundamental interface (every human being uses language constantly) speaks to, perhaps, a fundamental confusion about some issues.
I suggest you take a look at his comments on the "human factors engineering" of web authorship.
What have YOU done that qualifies you to make disparaging remarks about the man who helped define the Graphical User Interface as we know it?
The argument from authority has never impressed me. People with impressive resumes can make mistakes. I just suggested that people pay closer attention, that's all.
~k.lee
Actually, the dock may just be the one interface convention actually invented by Microsoft. Windows 1.0, which predates NeXT by about 4 years, had all its icons (including open applications) fixed in a row at the bottom of the screen. They didn't look like buttons, but since you couldn't move them up out of this area, it functioned much like a Dock/taskbar.
It's kind of funny, at the time Mac interface designers blasted Windows 1.0 for not allowing you to move those icons around. Of course, Windows 1.0 was a total interface disaster in almost every other way, but it had a fixed dock. It's pretty hard to track down pictures of the Windows 1.0 interface, but here are a few:
~k.lee
I used to respect Tognazzini a great deal. However, close reading of his writing, over an extended period of time, has led me to believe that he has questionable judgment about many issues. Just examine his article, How Programmers Stole the Web, where he claims that:
These are only a sample of the glaring Deep Wrongness in the article I link to above.
In addition, Tog is a relentless Apple partisan, despite his objections to the new Aqua interface. This clouds his perception of all Apple-related issues. For example, among other things, he says in the Aqua/OS X interface article that "Apple could argue, and few would deny it, that Apple was first and Microsoft is the one who made things difficult by failing to accurately copy the Mac interface." Ignoring, of course, the fact that Microsoft would have been perfectly happy to copy the Apple interface exactly, except that Apple is one of the most litigious companies in the IT industry (have you seen Microsoft threaten to sue KDE over their Windows98 theme?).
IMHO, Tognazzini has suffered from a lesser form of the same brain rot that has affected Jon Katz since becoming published on the web: free to spout off without an editor, never forced to confront dissenting opinions before publication, he has become something of an autodidact. This may seem a bit harsh, but I urge the programmers in the audience to read the "How Programmers Stole the Web" article. It reveals a great deal about the didacticism of Tognazzini's thought habits, and will probably cast a very different light on his supposedly authoritative interface design ideas.
I once respected Tog. Occasionally, he comes up with some good insights. However, don't let his impressive resume blind you to his often misled assertions.
~k.leeThe "code morphing" layer is what makes Crusoe stand apart from the rest. It optimizes on the fly the instuction set it's running on the fly. This means that your aps will run faster and faster as it runs. This layer is what gives the Crusoe it's speed.
The only way "code morphing" could run faster than native code is by exploiting runtime information to perform optimizations that are not possible at compile time. In other words, self-modifying code that runs faster than static code.
This is plausible, but that doesn't mean there would be no performance benefit in compiling native code. Research on self-modifying code is not unique to Crusoe---it's a very active area of research, and there are two major kinds: JIT and dynamic compilation. JIT, which you're probably all familiar with from Java, involves translationg code (typically from a foreign instruction set) and performing optimizations at runtime; dynamic compilation involves "staging" code at compile time to modify itself in a disciplined manner at runtime. JITs and dynamic compilation are very different in the nature of optimizations they perform; one of the major differences is that because dynamic compilation performs its analysis at compile-time, it can theoretically perform much deeper and more sophisticated optimizations.
Crusoe does no staging (it can't: it executes fully precompiled code), so its optimizations operate under severe time constraints. Therefore, Crusoe's code morphing is likely to produce code optimality akin to that emitted by a JIT compilation system: shallower analysis, shallower optimizations. Which almost certainly makes Crusoe's "code morphing" worse than native staged dynamic compilation would be.
In summary: my point is that self-modifying native code that improves its performance at runtime is entirely possible without "code morphing". On the other hand, binary x86 compatibility is arguably Crusoe's major selling point, so there's not much impetus for them to bother encouraging any kind of native code compilation. Anyway, I get the impression that Crusoe's entire architecture would have to be revamped if they wanted to run native code so it's a moot point.
If you're thoroughly confused by now, try visiting the dynamic compilation project at the University of Washington for more information on dynamic compilation.
~k.lee
(BTW: this does not mean that Crusoe does not embody any technical innovations. In particular, the hardware support the chip provides for its runtime code translation is very interesting.)
The Pentium does this in hardware too.
Incorrect. The Pentium, a.k.a. P5 core, does not have a RISC chip under the hood. It is superscalar and pipelining, but it does not translate x86 code into 32-bit-wide microops, as the P6 (Pentium II/Celeron) core does. Interesting how you feel free to pontificate about processor technologies when you don't know the difference between them.
Sun writes: The bytecode format was designed with generating machine codes in mind, so the actual process of generating machine code is generally simple. Efficient code is produced: the compiler does automatic register allocation and some optimization when it produces the bytecodes.
This is Sun's hype, not technical truth. Current JIT compilers perform only the most basic of optimizations when translating to machine code, because they operate under extreme time constraints. The machine code generated is "efficient", but only in comparison with the code emitted by a circa 1980 C compiler.
The choice of a high-level bytecode format made naive translation into machine code very simple, but it placed optimization between a rock and a hard place. You can't optimize load/store reordering, register reuse, or anything even vaguely machine-dependent at bytecode compile time, because bytecodes don't express those operations. On the other hand, you can't perform sophisticated optimizations such as the more complex forms of dataflow analyses during JIT compilation, because you don't have enough time. Hence, optimization suffers at both ends.
In any case, it's not clear to me how bytecodes are particularly "CISC". The term CISC was retroactively invented by RISC partisans to designate a particular microprocessor instruction set architecture, of which the 386 is the prime example. The JVM is not a microprocessor; it is a virtual machine, and there are features in the JVM instruction set that would never have appeared even in a CISC processor.
Basically, nothing you've said has convinced me or anyone else that RISC translation is nearly as efficient as CISC translation. Please provide an example of software or hardware that does RISC-CISC translation or even does RISC-RISC translation to support your claims that, "adequate performance could probably be achieved."
I suppose that it's difficult to use technical facts to convince those who have no technical background. However, that is not the entire population.
Perhaps you missed my point about native P6 code emitted by modern compilers, and its similarity to RISC code. I suggest you reread it. If RISC emulation is so slow, then x86 emulation should be slow for all the same reasons. Translating modern x86 code to RISC code is, in effect, a RISC to RISC translation. And the Crusoe demo seemed to indicate that yes, it is fast.
~k.lee
The fact that ecampbel's comments in this thread have been moderated so high is proof positive that when you referee technical opinions by popular vote, you get lousy technical opinions.
RISC code is extremely optimized for a specific processor architecture, and optimizing RISC code is a very processor intensive job.
So is optimizing CISC code, or, for that matter, translating CISC code to VLIW and then optimizing the VLIW instructions. In fact, students of compilers and architecture history know perfectly well that optimizing RISC code is actually much easier than optimizing CISC code. One of the prime motivations behind the uniform register file and instruction set of RISC architecture was ease of compilation.
Taking highly optimized RISC code (most of the time significantly reorded to exploit parrel and pipelining efficiencies), and trying to generate equivelent instructions in another architecutre would be very slow.
This might have some relevance, except that modern Intel architecture code usually consists of simple, RISC-like operations that are just as idiosyncratically reordered to exploit the pipelining/superscalar efficiencies in modern Intel chips. If translating RISC code is slow, then so is translating modern x86 code. See my other comment in this thread.
If RISC code was indeed easier to emulate, then JAVA would compile to RISC instructions, not CISC bytecodes. It compiles down to CISC bite codes so that the JIT on a particular platform can take one or two bite codes and expand them into the native instruction set of the operating system, and optomize them from there.
Java, nee Oak, was designed for embedded applications; the original motivation for using CISC-like bytecodes (and a stack architecture, of all things) was code compactness. Ease of translation into native machine code for JITs was not one of the primary concerns when the bytecode format was selected.
Another reason, there has never been a RISC emulator that has performed at anywhere close to a resonable speed. Any emulation of the Mac done on the PC only handles 68k CISC code. The reason for this is that RISC emulation is just too slow.
No; the reason is the lack of market demand. The x86 architecture's relative poverty of registers, and their nonuniformity, make it rather difficult to emulate, say, PowerPC code efficiently, but adequate performance could probably be achieved.
~k.lee
Emulating CISC based hardware is vastly easier than achieving acceptable performance emulating RISC based hardware. With CISC based hardware, each instruction does a lot, and might take several clock ticks to execute. The Transmeta emulator can come along and translate the instruction into equivalent Crusoe instructions, and achieve roughly comparable performance.
In principle, this is correct. In practice, Intel engineers made a deliberate design decision in the P5 and P6 generations to spend time making the RISC-like instructions fast (using deep pipelines, register renaming, and other magic), and the CISC-like instructions slow. Implementation of rarely-used, complex CISC instructions was simply too much of a performance drag.
As a result, modern optimizing compilers for x86 hardware generate very RISC-like code: mostly loads, stores, branches, and ALU ops. Look at the x86 assembly emitted by gcc -S sometime. Sensible compilers these days simply don't emit REP MOVSB or other behemoth CISC instructions left over from the 386 days.
Any putative performance gain from translating "complicated" instructions to many optimized Crusoe instructions is probably marginal. Hence, your argument about the relative "inefficiency" of Crusoe with regard to translating from RISC native code is incorrect.
BTW: for the interested, check out this Ars Technica article, which provides a fairly accessible discussion of why the RISC/CISC distinction isn't a very useful means of characterizing processors anymore.
~k.lee
I never said Newsweek or Salon were good, did I? Only "professional" and "middlebrow".
There was a funny Suck article a few months back where they called the Time offices and asked why they should renew their subscription when Newsweek offers identical content at half the price:
http://www.suck.com/daily/99/11/18/
(The answer, BTW, is priceless.)
In retrospect, I do realize that comparing Slashdot to Newsweek was a little extreme. Slashdot does have good interviews and technology articles sometimes. And there is the occasional "Insightful" comment that's actually insightful.
~k.lee
what you're calling a common occurance strikes me as being fairly rare. May I suggest that you're used to forums where opposing viewpoints are normally screened out in subtle ways, and when you're actually forced to confront a disagreement you feel like someone is unfairly "shouting you down"?
I've been on unmoderated e-mail lists and newsgroups aplenty. I have zero problems with confronting disagreement. It's when disagreement consists of aggressive regurgitation of common evangelical propaganda, with a clear implication that anyone who disagrees with it is a moron, that I object. And that's happened to me plenty of times.
OTOH your experiences may differ, of course.
And by the way: "right-wing libertarian" is at least *supposed* to be something of an oxymoron (believe it or not, it's possible to be neither left nor right, which is how a lot of libertarians would classify themselves).
I use the term "right-wing libertarian" to distinguish them from "left-wing libertarians". Please see the following URL for a description of the latter:
http://world.std.com/~mhuben/leftlib.html
You are certainly correct, however, if you mean that many views held by right-wing libertarians overlap very little with right-wing traditionalists or conservatives.
~k.lee
Maybe Sterling's point is that the Cantos (for example) will continue to be of practical interest long after the STL has gone to join Simula, Multics, and PL/I in the dustbin of history.
Perhaps you underestimate the longevity of code.
I once had a professor who told me that Boeing (or maybe it was one of the major airlines...) had a billion lines of COBOL in its computer systems. That kind of code base cannot be ported by humans to a newer language--not in next year, not in the next decade. Never. That COBOL, the professor said, is effectively a part of Western civilization, like the Empire State Building. Precluding the invention of superhuman AI (at which point all bets are off), he may have been right.
Given the amount of code that is currently being written in C++, STL might be of interest as long as the Cantos. Not that I'd bet on it, even though I think Pound is overrated.
~k.lee
What, then, is the Slashdot community? Are the various forums and communities that exist all over the Internet totally devoid of intelligentsia?
My definition of an intelligentsia is a small group of intellectuals committed to the free exchange of ideas and an active engagement in politics and social issues.
I think the Slashdot community is neither small enough nor, on average, intelligent enough to qualify as an intelligentsia. If you browse with your threshold at 3 or 4, Slashdot only approaches the quality of a middlebrow professional magazine like Salon or Newsweek.
Furthermore, there seems to be an aversion to open, friendly political debate in the Slashdot community. As in many other online forums, there's a strong right-wing libertarian faction that all-too-often shouts down all other views [0]. More importantly, there's a widespread hackish idea that politics is cheap talk, and that a person's opinions are worth no more than the code (s)he writes--a fact that prominent programmers in the community often use to dismiss political debate or criticism ("Shut up and show me the code.").
There may very well be an intelligentsia on the Internet. But I think that the subscribers of nettime-list or its cousins come much closer than Slashdot.
I'm sure I'll get thoroughly flamed for writing this. That's okay; my karma's high enough to take a few hits.
~k.lee
[0] If you're a libertarian, then please pause a moment before you flame me. I'm not saying that all libertarians are narrow-minded and rude; of course that's not true. I am saying that the fervor of some fundamentalist libertarians online often has a negative impact on the free exchange of political ideas, and that the large proportion of right-wing libertarians online makes pro-libertarian flame-fests a frequent occurrence.
Children do not have a natural urge to look at stuff that has no meaning or relevence to their age. They -do- have an urge to explore, though, which should be encouraged. They encounter something meaningless to them, they'll probably ask about it and move on. It's not going to hold any interest for them. . . . There is an exception to this. Children from severely dysfunctional families, with seriously screwed-up family dynamics, where their parents are living a gigantic lie, 24/7, are much more likely to behave in ways that do not reflect their age.
I'd like to know what kind of credentials you have re: child psychology. This sort of statement strikes me as incredibly naive, and I wonder if you're just making this up or you have some familiarity with actual research that suggests that only dysfunctional children like to look at porn sites.
From what I have read, all children are curious about sex from a very early age. A child that wanders onto a porn site may very well be interested, and early exposure to the wrong types of material (i.e. extreme sadomasochism [0], bestiality, pedophilia etc.) can have a negative impact on the child's sexuality for the rest of his/her life. Parents therefore have an understandable interest in controlling their children's exposure to sexual materials.
Censorware is extremely dangerous, of course, but spreading naive nonsense about the necessity for childrens' freedom, as opposed to parents' discretion, doesn't clarify the issue. It only clouds it.
~k.lee
p.s. In this post I focus on sex because I don't think children have as much of a natural interest in, say, neo-Nazism, though the same argument applies.
[0] I am not saying that sadomasochism is an immoral lifestyle for adults. However, if a 4-year-old child wanders onto a site that depicts women being tied up and beaten with a nightstick, with a caption that says, in effect, "Isn't this wonderful!"--that has a lasting negative effect on the child's sexual attitudes, because the child has no capacity for approaching that material critically. Only a fool would assert otherwise. And if you really believe healthy children have no interest in sadomasochism or other disturbing images, clearly you have not watched a cartoon or read a fairy tale lately.
Having worked with the gcc compiler for many years I can say that math fluctuations are increadibly easy to introduce through optimization.
/. seems to be a bunch of semi-competent high school-grade programmers who have no idea how incredibly difficult numerical computing is.
Amen. Somebody should moderate this up. The pro-optimization faction here on
Free clue of the day: it's hard to write a program that produces good floating point results for any nontrivial computation. Seemingly trivial optimizations can result in accumulated errors and numerical instability that completely fsck up the entire calculation. Nothing could be worse for the SETI project than a legion of arrogant C hackers submitting blocks processed with patched, "optimized" clients that have different numerical behavior than the original.
~k.lee
It's too bad this guy's an AC-- this comment actually brings up a novel revenue model for OSS that I've never heard before. Moderators, wield your points.
~k.lee
A factual error yourself - Sun released it under the SCSL IIRC.
/. comment, not an article that I am posting on a website that purports to give worthwhile opinions about the OS market. I think it's reasonable to hold such articles to a higher standard, right?
Oops-- brain burp. You're right, of course. Profuse apologies. OTOH my post was a
Anyway, my point stands either way. Sun supports Linux, but only so far.
~k.lee
- Microsoft also claims that Linux has no journaling file system, ignoring the fact that the SGI's XFS is a journaling file system. They also ignore the fact that NT 4.0 itself lacks a journaling file system!!
- I've got Doom, Quake, and other multiple player games for entertainment (although I'm personally a board game fan).
- Thirdly, even if other Unixes were cannibalized, what would it matter? Linux would remain, and the point I made in the above paragraph works in reverse. Those Unix developers that now exist will move to Linux with no effort, and there will be no discernible effect in the workplace.
- An entertaining footnote (#40): Again, the Gartner Group plays tug-of-war with themselves. The same short report recognizes that SCO and SGI are competitors and supporters of Linux, but the Gartner Group never bothers to answer the question as so why this may be the case. Clearly, the study in question is severely flawed and displays a shocking lack of understanding.
And the above list is just a quick sampling of Leigh's errors and misunderstandings. The mistakes are all the more annoying since they appear to be direct regurgitations of things that have been repeated countless time by the less-iformed zealots [0] here onFirst of all, wasn't there a thread a couple of weeks ago in which we discussed the journalling abilities of NTFS? Second, XFS has not been released for Linux yet. Third, there is a journalling filesystem for Linux, but it's not XFS: it's ReiserFS.
This is just silly. Game support under Linux is extremely sparse right now. In a world where even Macintosh doesn't get ports of even the most popular games (witness the recent Half-Life debacle), we'd be really foolish to claim that Linux has enough games for the average home consumer.
Clearly, this was written by somebody who doesn't know much about Unix. Linux is like Unix, and the transition would likely be easier for commercial Unix developers to make, but it's hardly going to be a transparent, effortless transition.
No, clearly Dave Leigh displays a shocking lack of understanding about the technology industry, where relationships of simultaneous competition and support are incredibly common. Sun, for example, supports Linux by releasing StarOffice under the GPL; on the other hand, it would be entirely happy cannibalizing the Linux market to grow Solaris/Java if it could. In fact, most astute observers believe this is exactly where Sun wants to lead us.
If I want to hear things like this, I'll read an old
~k.lee
[0] As opposed to the well-informed zealots, who are (unfortunately) all too rare.
I can't believe this ridiculous comment got moderated up.
Linux is open source, remember? The idea of China slipping security holes in the backdoor is pretty silly when we have a peer review process built into the system (and any security-conscious agency will definitely do a security audit before using Linux on any critical network). The chance that China will slip backdoors into Linux is about the same as the chance that Microsoft will slip backdoors into Emacs.
Moderators: do this thread a favor and moderate the parent comment back down.
~k.lee
The fact is that Netscape STILL dominates the Browser war for two reasons:
1) Companies use netscape on all their UNIX boxes.
2) Companies use netscape on all their Win95 boxes. IE wasn't free when the majority of companies purchased their licenses, and Netscape continues to dominate the market share in the commercial sector, which is roughly twice the size of the personal or private sector.
What a wonderful fact. Unfortunately it's incorrect. If you look at the server stats all across the web, you will see that IE is definitely winning the battle. Anyway, Communicator 4 and IE 4 were both released under equally free terms (and equally large downloads) so your argument about the cost of running either is vacuous.
Furthermore many pro-Linux people I know have been grumbling about the lack of the latest RealPlayer support and other niceties that people in the Windows world take for granted. Availability of certain plugins count almost as much these days as the browser.
You see, one of the most important differences between Windows and Linux is that Windows is all smoke and mirrors (marketing) whereas Linux is an product that is actually well made and capable of delivering on its promises. The public will grow tired of the illusion sooner or later, its all a matter of time.
This sort of Manifest-Destiny-style triumphalism is doing untold damage to the Linux community.
First of all, in case you haven't noticed, the biggest growth sector in computing is in online applications, not the desktop OS. The killer apps of the Internet revolution are websites. Nobody is going to care that Linux is robust if you can't access the next eBay through it. And there's nothing the Linux community can do to duplicate those websites because they are unique proprietary services that depend upon an irreproducible community of participants.
Second, assuming blithely that Windows is all smoke and mirrors, and will remain so forever, is simply a mistake. If you really believe that the tens of thousands of programmers at Microsoft with IQ in the 130's and up are incapable of producing a decent product, you need to re-examine your assumptions.
NT workstation, properly tuned, is very stable. Not as stable as Linux, but certainly not the crash-prone piece of snail-speed junk that some Linux advocates claim it is. Also, if you've seen the snapshots of Windows 2000's web-like desktop, you should be very afraid: I think Microsoft is closer to producing a consumer appliance "Internet OS" than anyone else out there.
The last thing the Linux community needs right now is complacency. Bill Gates got to where he is today by being utterly paranoid at every step that someone's going to crush him; we would do well to emulate him in this respect. With the DOJ trial winding down, Microsoft will soon be running without hobbles again. Linux coders need to rise to the challenge, and quickly. Dave was absolutely on target about the crucial importance of Mozilla. Mozilla may very well be the most important Linux software project ever.
~k.lee
Well, for graphics that small, size doesn't matter much anyway. Network packets come in large chunks of bytes, so the additional time spent downloading 144 vs. 45 bytes is negligible unless you're downloading a thousand of them-- in which case you'd probably be better off combining them into one image so the compression can exploit redundancies.
~k.lee
And then we get the comment "Religion and freedom have never really gotten along." Nice tie, but it doesn't explain a few people like Gangis Kahn, Napolean, or Hitler (who prosecuted the Jewish RACE much more so than the religion).
This is classic faulty syllogism. Go study some elementary logic.
JonKatz says: "Religion implies not freedom." (p -> !q)
The only full contradiction to this is: "Religion implies freedom, and vice versa." (p q)
You replied with, "Non-religion can also result in no freedom!" (!p -> !q).
Of course there have been oppressive non-religious regimes, but your statement doesn't even contradict JonKatz's statement, much less refute it. Besides, it's obvious that religions throughout history have been used as a tool of social control and hence have usually led to less freedom more often than more.
Of course, the rest of JonKatz's article was a wordy, overwrought pile of non sequiturs and faulty syllogisms anyway, so this point is rather moot.
~k.lee
The Dvorak/Qwerty debate is getting rather old [0]. What's more interesting is how the authors of this article progress generalize from this single extremely particular QWERTY example onto more general economic grounds-- specifically, the Microsoft trial.
Laissez-faire economists like to say that the cost of switching to another office suite, rather than staying with Microsoft, outweighs the benefits of switching to another suite; and therefore, there is no market failure. They ignore the huge and ruinous long-term costs of staying with Microsoft.
If Microsoft did not have a monopoly position that enabled it to exploit "network effects", would everyone bother upgrading to the latest version of Office every single time? The most commonly used Office application, Microsoft Word, has not changed appreciably since version 6.0.
However, since Microsoft is fond of making their file formats non-backwards-compatible (often with automatic conversions whenever someone opens a document), people using Microsoft products to exchange documents with each other are effectively coerced into switching whenever one employee, department, or client in the network upgrades to Microsoft products. No user wants to deal with this, but they must upgrade anyway; not when they feel the need for more features (which almost nobody does, for Office) but whenever Microsoft feels like releasing a new edition of its viral applications into the market.
Of course, according to the laissez-faire people, the present cost of staying with Microsoft is still lower than switching, so there is no such thing as network effects. But that's the very definition of network effects: the result of using a greedy algorithm over a network where such an algorithm is non-optimal.
This whole issue shows how dangerous it is to take advice about technical issues from people who have a vested interest in supporting a particular economic model.
~k.lee
[0] Maybe the authors are right, and maybe they aren't; I type at 100+ wpm, and unless I am going to get a huge speedup (> 200 wpm) in typing speed I am not going to bother switching one way or the other.
Joe Average will not be launching vi in the first place, and if he goes messing around in his
Now that's interesting's I guess those guys were trying their generic vi/emacs editors on XML. Jesus! The idea of XML is definitely not that you open vi and start hacking away.
Clearly you know practically nothing about software engineering, because if you did then you'd realize that typing in code is only a tiny fraction of the battle. Reading ColdFusion code is as annoying, compared to reading C, as writing it, because of the verbosity. No tool can remedy that.
If you're suggesting that programmers abandon the source text entirely and start programming using visual tools exclusively, then I've obviously been wasting my time here.
I wasn't talking about enclosing the original source but rather about replacing it
So was I. My point was that the following:
contains exactly 5 characters of string literal. The rest is actual program content. In an XML scheme, the program content would have to be written something like the following:
which gains us very little except extra verbosity. If you had bothered to go look up some ColdFusion code on the web, you'd have realized what I was saying.
I have programmed in an XML-syntax-based programming language. You have not. Please don't tell me how it feels. It's annoying. In fact, it's so annoying that Allaire (makers of ColdFusion) included a <CFSCRIPT> tag in the latest version, which allows you to write JavaScript-like, non-XML code instead.
The real reason is that C++ syntax is so complex he would have a hard time building the tool. Can you say #define?
If you really think Bjarne Stroustrup would have trouble building a javadoc-like tool for C++, you need a reality check. C++ syntax is complicated, but compiler authors have had tools (like lex, yacc, bison) for dealing with complicated syntax for years. Clearly, the *compiler* parses C++, so a javadoc-like tool could do so as well. Go learn a bit about compilers (e.g., write one [0]) before you start schooling the rest of us on the complexity of parsing computer languages.
~k.lee
[0] Yes, I have written one. Many CS students do.