I wrote that article you're commenting on. Not only is your premise totally wrong that the X in MacOS X stands for X-Windows ("Of course, that Mac your friend is using is running X11"), but also the conclusion you draw from your mistaken beliefs are totally illogical ("the statement is now a complete contradiction of his entire argument against X"). Complete? Entire? How did you decide that?
Please press rewind, check your facts, read Logic 101 for Dummies, and try again. Since your facts AND the logic of your conclusions were so off base, I'll give you another chance, and I hope you can come to the correct conclusion that X-Windows totally sucks balls, next time you try to think it through again.
I was digging through some old papers, and ran across a 15 year old "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2, from June 1988. Here's an article that illustrates how far the usage of the term "X Windows" has evolved over the past 15 years. (Too bad The Window System Improperly Known as X Windows itself hasn't evolved.)
Someone on slashdot asks, "Why is it still called X-Windows?". Predictably, the first reply says: "It isn't. It's called 'The X Window System.' Or simply 'X'. 'X Windows' is a misnomer."
He didn't ask why it is "X-Windows". He asked why it's called "X-Windows". You're wrong that it isn't called "X-Windows". It is! It's just that it isn't "X-Windows". Being something is independent of being called something.
The answer to the question 'Why is it still called X-Windows?' is: It's still called X-Windows in order to annoy the X-Windows Fanatics, who take it upon themselves to correct you every time you call it X-Windows. That's why it's called X-Windows.
The following definitive guide to the consequences of saying "X Windows" is from the June 1988 "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2:
Things That Happen When You Say 'X Windows'
THE OFFICAL NAMES The official names of the software described herein are: X X Window System X Version 11 X Window System, Version 11 X11
Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).
The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!
You are forced to explain toolkit programming to X neophytes.
Bob Schiefler says, "You should know better than that!"
The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.
Ditto for the controller board for the disk on your new Sun.
Your hair falls out.
xmh refuses to come up in a useful size, no matter what you fiddle.
You inexplicitly lose both of your complete Ultrix Doc sets.
"The comment was from a book published in 1994, based on mailing list contributions from 91 an 92."
Incorrect: I originally wrote the X-Windows Disaster chapter specifically for the Unix-Haters handbook -- it wasn't ever posted to the unix-haters mailing list. It does quote a few messages from people like Jamie Zawinski and Steve Strassman, which they posted to the unix-haters mailing list, but I wrote most of the chapter later, specifically for the book, after porting multi player SimCity to X11.
The expression "X-Windows: The first fully modular software disaster" comes from an anonymous flier that was distributed at one of the original X-Windows conferences. (No I didn't write it, but I certainly agree with the sentiment!)
-Don
Official Notice
Post Immediately
X: Dangerous Virus!
First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated piblicly that "MIT assumes no resonsibility...". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.
After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X cannot even be guessed.
X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure it's up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment is being maintained on hundreds of computers, maybe even your own.
Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.
This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
Ultimately DEC and MIT must be held accountable for this heinous *software crime*, brought to justice, and made to pay for a *software cleanup*. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
Don't be fooled! Just say no to X.
X-Windows:...A mistake carried out to perfection.
X-Windows:...Dissatisfaction guaranteed.
X-Windows:...Don't get frustrated without it.
X-Windows:...Even your dog won't like it.
X-Windows:...Flaky and built to stay that way.
X-Windows:...Complex nonsolutions to simple nonproblems.
X-Windows:...Flawed beyond belief.
X-Windows:...Form follows malfunction.
X-Windows:...Garbage at your fingertips.
X-Windows:...Ignorance is our most important resource.
X-Windows:...It could be worse, but it'll take time.
X-Windows:...It could happen to you.
X-Windows:...Japan's secret weapon.
X-Windows:...Let it get in *your* way.
X-Windows:...Live the nightmare.
X-Windows:...More than enough rope.
X-Windows:...Never had it, never will.
X-Windows:...No hardware is safe.
X-Windows:...Power tools for power fools.
X-Windows:...Putting new limits on productivity.
X-Windows:...Simplicity made complex.
X-Windows:...The cutting edge of obsolescence.
X-Windows:...The art of incompet
"It doesn't just provide a linear frame buffer to work with either."
The graphics model provided by X11 is that of a MicroVAX framebuffer on acid.
("What's a MicroVax"? A tiny little personal VAX. "What's a VAX?" It's an old minicomputer from DEC. "Why should I care?" Because its ancient design still deeply effects the X11 graphics model.)
-Don
Myth: X is "Device Independent"
X is extremely device dependent because all X graphics are specified in pixel coordinates. Graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's "Cheese Shop" sketch, or a grail seeker in "Monty Python and the Holy Grail." Even the simplest applications must answer many difficult questions:
FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.
Here's some nifty X10 window manager code I wrote in Forth in 1986:
X.f - X10 window system interface for Forth. Xlib.f - X10 XLib interface for Forth. xutil.f - X10 utilities for Forth. uwm.f - X10 uwm window manager interface for Forth. load-fuwm.f - X10 uwm library loader for Forth window manager. fuwm-main.f - X10 Forth window manager main driver. menulist.f - pie menus and linear menus for Forth window manager.
hacks.f - X10 Forth window manager hacks.
I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)
The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.
Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.
Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!
Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).
Are you actually bragging that your desktop requires as much memory as 3,520 Commodode 64's? Why does that make you think X-Windows is doing just fine?
A single Commodore 64 can draw a clock on the screen, with most of its 64K of memory left over. How many C64s worth of memory does X-Windows require to tell the time?
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.
X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
"It would be like nature documentaries stepping in and stopping wolves from eating their prey."
That sounds like it would make a great Reality Television program! Maybe they could get that Australian aligator chap who sticks his thumb up animals' bums to do it.
So they found four inaccuracies in the wikipedia articles they tested -- did they correct them while they were at it?
When they found thee errors in the Encyclopedia Britanica article, too bad they couldn't check the discussion page and history of modifications to see when and how they got there.
-Don
Re:Perl and Python are older than Java
on
Java Is So 90s
·
· Score: 1
No, Java was designed in the 90's, not the 80's. Gosling was working on NeWS (the Network extensible Window System, based on PostScript) in the 80's. NeWS pioneered the ideas behind AJAX, but it used PostScript instead of JavaScript, PostScript instead of XML, and PostScript instead of HTML. Just a wee bit more consistent and integrated than AJAX.
Sure, PHP programs "don't have to be" a nightmare, but they usually are. You could say the same thing about Perl, so why aren't you using that instead? Take a step back, though: your program "doesn't have to be" written in PHP or Perl! It could be written in a much better langauge like Python or Ruby, then you wouldn't have to spend so much energy fighting against the limitations and quirks of the language itself.
PHP is NOT modular -- it's a horribly designed, ill conceived language that throws up all kinds of pointless road blocks and diversions, that other languages don't waste your time with. If your excuse is "it doesn't have to be that way", then why are you using PHP in the first place? If you have such good and capable developers, then why on God's earth are they pissing away their time and effort with PHP? If it's because PHP is the only language they know, and they're not willing to learn and use better languages, then they're certainly not very capable developers, are they?
Oh, come on. It's just stupid to use PHP. If you don't know why, then you should educate yourself, not evangelize it without understanding its weaknesses. The only excuse for using PHP is that you don't know any other programming language, and you're afraid to learn a better one like Python or Ruby. And if that's the case, then what are you doing in the computer industry? Go sell used cars or something!
-Don
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Could the Mac's foolish idea of only letting the user resize a window from the lower right corner, but NOT the upper right corner, NOR the lower left corner, NOR the upper left corner, NOR the top edge, NOR the bottom edge, NOR the left edge, NOR the right edge, be characterized as "elegant simplicity"? I'd characterize that as stubborn stupidity.
Due to the fact that they haven't fixed this obvious shortcoming since 1984, I'd say that the Mac user interface designers themselves are "dumbed down", if not "coked up".
-Don
MockLisp is to Lisp as JavaScript is to Java
on
The Future of Emacs
·
· Score: 1
Certainly, Lisp is a better language than Java, in theory. But take a look at the actual Emacs Lisp you're comparing to Java. The Lisp in Emacs is a yucky old loosely nailed together plywood treehouse Erzatz Lisp, with "buffer scoping" thrown in, which makes it totally unlike any standard Lisp implementation, plus it has no native code extension API (plugins or DLL modules). No other Lisp but Emacs Erzatz Lisp stores variables bindings in buffers, such that when you switch buffers, your variable bindings change!
Gnu Emacs wasn't the first Emacs to use a mutant Erzatz Lisp.
At least Gnu Emacs Erzatz Lisp was an improvement over Gosling Emacs "MockLisp" (UniPress Emacs). MockLisp resembles Lisp only in the worst possible way (same annoyingly pesky parenthetical syntax, but none of the solid well designed semantics).
MockLisp actually used an ill-conceived form of lazy evaluation, which is lethal when foolishly combined with dynamic scoping (no closures). When you called a MockLisp function, the parameters were't evaluated until the called function decided to fetch the argument with the (arg name prompt) function (which also would prompt the user for the argument if it was missing).
The horrible problem with MockLisp was that the (arg) fetching function evaluated the CALLER's parameter expression in the CALLEE's dynamic scope! Bzzzt! Argument expressions could be passed deep down from function to function, so you had no way of knowing what context any of your arguments would be evaluated in. So thanks to dynamic scoping, you actually had to name ALL of your local variables uniquely across the entire MockLisp program (which causes problems when integrating packages written by different people). The convention was to use a unique prefix for all arguments of each function, cross your fingers, and for God's sake don't get recursive.
MockLisp was so un-lisp-like that it didn't even have basic data types like dictionaries. This MockLisp code (a hypermedia browser authoring tool for HyperTIES) implemented a master index to look up article titles and synonyms, and it had to represent a dictionary as a buffer, and abuse buffer local keyboard abbreviation tables (which were fast because they were implemetned in C) to look up names.
It's astounding how disasterously designed MockLisp was, yet Gnu Emacs Erzatz Lisp still copied some of its ill-conceived ideas like buffer scoping. Emacs implemented with a real Lisp programming language would simply represent buffers as regular data types, and provide sane variable scoping (i.e. an object oriented programming system like CLOS) so that there was no need for "buffer scoping" built into the language. There's nothing so special about buffers that they deserve to be built into the programming language's scoping rules.
MockLisp is to Lisp as JavaScript is to Java. They're both badly designed programming languages that ripped off the names of better designed programming languages, to fool people into believing they didn't suck.
-Don
Re:Backgrounds of the PHP developers.
on
PHP 5.1.0 Released
·
· Score: 1
Oh, come on, don't be such an apologist for what is clearly Bad Programming Language Design. PHP is the vice grips of programming tools, which damages everything it touches, and doesn't do anything very well.
So you can concede that PHP is a badly designed broken tool, but you claim that it doesn't matter, because 99% of the time it's the fault of the programmer? Maybe PHP just attracts and cultivates bad programmers? Why would you choose a deeply flawed tool like PHP, when other excellent well designed tools like Python and Ruby are available for free?
Anyone who tries to tell you that AJAX is a "new approach to web applications" is just rebranding old technology and hyping buzzwords, not engineering software in the real world. Because of browser and DHTML incompatibilities and limitiations, AJAX is like cocaine: it seems glamorous until you actually start using it, then the unintended consequences totally fuck you up.
Special Hazard Precautions for AJAX:
INGESTION: NAUSEA, VOMITING, AND DIARRHEA. EYES: EYE IRRITANT UPON DIRECT CONTACT. SKIN: MAY CAUSE SKIN IRRITATION UPON PROLONGED CONTACT. INHALATION: NONE UNDER NORMAL USE. PROLONGED INHALATION BY UNORTHODOX USE (NON-WETTED) OR ABUSE (SNIFFING) COULD PRODUCE LUNG DISEASE (SILICOSIS). N/K
Emergency/First Aid Proc: INGEST: IF EATEN/DRUNK--YOU MAY THROW UP. DRINK SIPS OF WATER/MILK. IF VOMIT CONTINUES, CALL POISON CTR/DR. EYES: IRRIT. FLUSH W/WATER 15 MIN. IF IRRIT PERSISTS, CALL POISON CTR/DR. SKIN: IRRIT. REMOVE WET CLOTHES. FLUSH W/WARM WATER 15 MIN. IF IRRIT PERSISTS, CALL DR/POISON CTR. INHAL: IF INHALED, MAY COUGH. TAKE SLOW DEEP BREATHS OF FRESH AIR, SIP WATER. IF COUGH PERSISTS, CALL DR/POISON CTR.
It just means your Perl 5 programs will break in many horrible and unexpected ways, if you ever try to port them to Perl 6. But that's absolutely wonderful, if you enjoy Perl's flaws because you want to lock your employer into depending on you and paying you to keep the code running for many years.
Using Perl is simply foolish, irresponsible, short sighted, and self serving. But if you want to really "stick it to the man" who's paying you to design their web site, then it's the perfect weapon of mass destruction and corporate sabotage.
Tony Bove' also has the distinction of developing the most elegantly packaged interactive multimedia CDROM title in the industry: Haight Ashbury in the 60's.
He pioneered the concept of the "refillable software stash box", which is big enough that it takes up a whole cigar box of shelf space, and it holds a whole lot of... refillable software.
You wouldn't think I was changing the subject if you bothered to read the articles I pointed to. There's some really important stuff in there that I think you should know, otherwise you're going to re-discover it all the hard way, when you're up the creek without a paddle. Don't think Parrot is the first time somebody's tried something like that. Guile started with a much more coherent language (Scheme) than Parrot is saddled with (Perl), and Guile didn't succeed for many of the same reasons that Parrot will fail.
From Ian Bicking's remarks in the discussion titled "A vision for Parrot":
[...] I don't think this is really correct -- I think it was mostly because
Tcl was a lame language, and was being pushed as an application
scripting language. Of course, Lisp is close to RMS's heart, which is
why the FSF proposed Scheme as an alternative over other languages.
Simplicity was always essential for an application scripting language,
which is probably why Perl wasn't a serious contender. It was also a
long time ago, when Python was young. And the translation dream.
[...]
But you're right, it is a really hard problem anyway. And there's lots
of details.
You have to deal with competing naming conventions -- Scheme allows
almost all characters in its functions, for instance. Lots of languages
have different namespaces for functions and variables. Something like
Smalltalk has an entirely different notion of method naming, even though
its semantics are close to these other languages. It seems small, but
it's a pain.
There's also issues with errors -- if you want a usable language, a
traceback like Python's should be a bare minimum in this day. But what
does that look like with mixed languages? What does that even look like
with one language, ontop of a VM that's meant to be generic? This is
often dealt with very poorly as VM developers mostly test with trivial
and correct programs.
And of course there's a huge number of problems with objects. Mutable
vs. immutable strings being a good example -- it's not just a n x m
problems, it's a straight-up no-good-solution problem. There's no
*right* way to deal with this. Each language means something different
by "string", and yet it's so important to each language that if you
expect them to interoperate *at all* you need to deal with that. Do you
annotate functions and methods so that some automatic interoperation
layer can be used? Do you force users to use awkward constructions,
exposing the fact that they're accessing another language? Do you
create wrappers? Do you just punt, and assume some simplistic behavior
will be good enough, even though it's not predictable to the programmer?
C#/CLR I believe has resolved these issues by forcing the languages to
adapt to a common set of semantics. I just can't imagine a common set
of semantics that would bring Perl and Python together -- Python and
Ruby, sure, but there's not enough common ground with Perl to do that.
I bothered to learn Perl in 1989, and have been watching it decay ever since. But I've also bothered to learn other languages that are much better than Perl, and I choose to use those instead.
So let me get you right: do you actually think it's a good thing that Perl 6 treats "print (1+2)+3" differently than "print(1+2) + 3"? How is that "easier to read"?
Slashdot Mirror
I wrote that article you're commenting on. Not only is your premise totally wrong that the X in MacOS X stands for X-Windows ("Of course, that Mac your friend is using is running X11"), but also the conclusion you draw from your mistaken beliefs are totally illogical ("the statement is now a complete contradiction of his entire argument against X"). Complete? Entire? How did you decide that?
Please press rewind, check your facts, read Logic 101 for Dummies, and try again. Since your facts AND the logic of your conclusions were so off base, I'll give you another chance, and I hope you can come to the correct conclusion that X-Windows totally sucks balls, next time you try to think it through again.
-Don
Things that happen when you say 'X Windows':
I was digging through some old papers, and ran across a 15 year old "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2, from June 1988. Here's an article that illustrates how far the usage of the term "X Windows" has evolved over the past 15 years. (Too bad The Window System Improperly Known as X Windows itself hasn't evolved.)
The following definitive guide to the consequences of saying "X Windows" is from the June 1988 "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2:
Things That Happen When You Say 'X Windows'
THE OFFICAL NAMES
The official names of the software described herein are:
X
X Window System
X Version 11
X Window System, Version 11
X11
Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).
The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!
You are forced to explain toolkit programming to X neophytes.
Bob Schiefler says, "You should know better than that!"
The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.
Ditto for the controller board for the disk on your new Sun.
Your hair falls out.
xmh refuses to come up in a useful size, no matter what you fiddle.
You inexplicitly lose both of your complete Ultrix Doc sets.
R2 won't build.
Bob Schiefler says "Type 'man X'".
Your nifty new X screen saver just won't go away.
The window you're working in loses input focus. Permanently.
"The comment was from a book published in 1994, based on mailing list contributions from 91 an 92."
Incorrect: I originally wrote the X-Windows Disaster chapter specifically for the Unix-Haters handbook -- it wasn't ever posted to the unix-haters mailing list. It does quote a few messages from people like Jamie Zawinski and Steve Strassman, which they posted to the unix-haters mailing list, but I wrote most of the chapter later, specifically for the book, after porting multi player SimCity to X11.
The expression "X-Windows: The first fully modular software disaster" comes from an anonymous flier that was distributed at one of the original X-Windows conferences. (No I didn't write it, but I certainly agree with the sentiment!)
-Don
Official Notice
Post Immediately
X: Dangerous Virus!
First, a little history. The X window system escaped from Project Athena at MIT where it was being held in isolation. When notified, MIT stated piblicly that "MIT assumes no resonsibility...". This is a very disturbing statement. It then infiltrated Digital Equipment Corporation, where it has since corrupted the technical judgement of this organization.
After sabotaging Digital Equipment Corporation, a sinister X consortium was created to find a way to use X as part of a plan to dominate and control interactive window systems. X windows is sometimes distributed by this secret consortium free of charge to unsuspecting victims. The destructive cost of X cannot even be guessed.
X is truly obese - whether it's mutilating your hard disk or actively infesting your system, you can be sure it's up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment is being maintained on hundreds of computers, maybe even your own.
Digital Equipment Corporation is already shipping machines that carry this dreaded infestation. It must be destroyed.
This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
Ultimately DEC and MIT must be held accountable for this heinous *software crime*, brought to justice, and made to pay for a *software cleanup*. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
Don't be fooled! Just say no to X.
X-Windows: ...A mistake carried out to perfection. ...Dissatisfaction guaranteed. ...Don't get frustrated without it. ...Even your dog won't like it. ...Flaky and built to stay that way. ...Complex nonsolutions to simple nonproblems. ...Flawed beyond belief. ...Form follows malfunction. ...Garbage at your fingertips. ...Ignorance is our most important resource. ...It could be worse, but it'll take time. ...It could happen to you. ...Japan's secret weapon. ...Let it get in *your* way. ...Live the nightmare. ...More than enough rope. ...Never had it, never will. ...No hardware is safe. ...Power tools for power fools. ...Putting new limits on productivity. ...Simplicity made complex. ...The cutting edge of obsolescence. ...The art of incompet
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
X-Windows:
"It doesn't just provide a linear frame buffer to work with either."
The graphics model provided by X11 is that of a MicroVAX framebuffer on acid.
("What's a MicroVax"? A tiny little personal VAX. "What's a VAX?" It's an old minicomputer from DEC. "Why should I care?" Because its ancient design still deeply effects the X11 graphics model.)
-Don
Myth: X is "Device Independent"
X is extremely device dependent because all X graphics are specified in pixel coordinates. Graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's "Cheese Shop" sketch, or a grail seeker in "Monty Python and the Holy Grail." Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display, DefaultScreen(display)), WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!! (server dumps core & falls into the chasm)
FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.
Here's some nifty X10 window manager code I wrote in Forth in 1986:
X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.
I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)
The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.
Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.
Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!
Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).
-Don
Goal: Crush Microsoft. BZZZT!
Goal: Write once, run everywhere. BZZZT!
Goal: 100% Pure Java. BZZZT!
Three strikes. You're out.
Are you actually bragging that your desktop requires as much memory as 3,520 Commodode 64's? Why does that make you think X-Windows is doing just fine?
A single Commodore 64 can draw a clock on the screen, with most of its 64K of memory left over. How many C64s worth of memory does X-Windows require to tell the time?
-Don
The X-Windows Disaster
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.
X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
Official Dangerous Virus notice distributed at the X-Windows Conference.
A wikipedia salesman walks into a bar...
-Don
"It would be like nature documentaries stepping in and stopping wolves from eating their prey."
That sounds like it would make a great Reality Television program! Maybe they could get that Australian aligator chap who sticks his thumb up animals' bums to do it.
-Don
So they found four inaccuracies in the wikipedia articles they tested -- did they correct them while they were at it?
When they found thee errors in the Encyclopedia Britanica article, too bad they couldn't check the discussion page and history of modifications to see when and how they got there.
-Don
No, Java was designed in the 90's, not the 80's. Gosling was working on NeWS (the Network extensible Window System, based on PostScript) in the 80's. NeWS pioneered the ideas behind AJAX, but it used PostScript instead of JavaScript, PostScript instead of XML, and PostScript instead of HTML. Just a wee bit more consistent and integrated than AJAX.
-Don
Sure, PHP programs "don't have to be" a nightmare, but they usually are. You could say the same thing about Perl, so why aren't you using that instead? Take a step back, though: your program "doesn't have to be" written in PHP or Perl! It could be written in a much better langauge like Python or Ruby, then you wouldn't have to spend so much energy fighting against the limitations and quirks of the language itself.
PHP is NOT modular -- it's a horribly designed, ill conceived language that throws up all kinds of pointless road blocks and diversions, that other languages don't waste your time with. If your excuse is "it doesn't have to be that way", then why are you using PHP in the first place? If you have such good and capable developers, then why on God's earth are they pissing away their time and effort with PHP? If it's because PHP is the only language they know, and they're not willing to learn and use better languages, then they're certainly not very capable developers, are they?
-Don
Oh, come on. It's just stupid to use PHP. If you don't know why, then you should educate yourself, not evangelize it without understanding its weaknesses. The only excuse for using PHP is that you don't know any other programming language, and you're afraid to learn a better one like Python or Ruby. And if that's the case, then what are you doing in the computer industry? Go sell used cars or something!
-Don
Don't you mean: (lisp-p) ?
-Don
forth ?know if honk else forth learn then
Could the Mac's foolish idea of only letting the user resize a window from the lower right corner, but NOT the upper right corner, NOR the lower left corner, NOR the upper left corner, NOR the top edge, NOR the bottom edge, NOR the left edge, NOR the right edge, be characterized as "elegant simplicity"? I'd characterize that as stubborn stupidity.
Due to the fact that they haven't fixed this obvious shortcoming since 1984, I'd say that the Mac user interface designers themselves are "dumbed down", if not "coked up".
-Don
Certainly, Lisp is a better language than Java, in theory. But take a look at the actual Emacs Lisp you're comparing to Java. The Lisp in Emacs is a yucky old loosely nailed together plywood treehouse Erzatz Lisp, with "buffer scoping" thrown in, which makes it totally unlike any standard Lisp implementation, plus it has no native code extension API (plugins or DLL modules). No other Lisp but Emacs Erzatz Lisp stores variables bindings in buffers, such that when you switch buffers, your variable bindings change!
Gnu Emacs wasn't the first Emacs to use a mutant Erzatz Lisp. At least Gnu Emacs Erzatz Lisp was an improvement over Gosling Emacs "MockLisp" (UniPress Emacs). MockLisp resembles Lisp only in the worst possible way (same annoyingly pesky parenthetical syntax, but none of the solid well designed semantics).
MockLisp actually used an ill-conceived form of lazy evaluation, which is lethal when foolishly combined with dynamic scoping (no closures). When you called a MockLisp function, the parameters were't evaluated until the called function decided to fetch the argument with the (arg name prompt) function (which also would prompt the user for the argument if it was missing).
The horrible problem with MockLisp was that the (arg) fetching function evaluated the CALLER's parameter expression in the CALLEE's dynamic scope! Bzzzt! Argument expressions could be passed deep down from function to function, so you had no way of knowing what context any of your arguments would be evaluated in. So thanks to dynamic scoping, you actually had to name ALL of your local variables uniquely across the entire MockLisp program (which causes problems when integrating packages written by different people). The convention was to use a unique prefix for all arguments of each function, cross your fingers, and for God's sake don't get recursive.
MockLisp was so un-lisp-like that it didn't even have basic data types like dictionaries. This MockLisp code (a hypermedia browser authoring tool for HyperTIES) implemented a master index to look up article titles and synonyms, and it had to represent a dictionary as a buffer, and abuse buffer local keyboard abbreviation tables (which were fast because they were implemetned in C) to look up names.
It's astounding how disasterously designed MockLisp was, yet Gnu Emacs Erzatz Lisp still copied some of its ill-conceived ideas like buffer scoping. Emacs implemented with a real Lisp programming language would simply represent buffers as regular data types, and provide sane variable scoping (i.e. an object oriented programming system like CLOS) so that there was no need for "buffer scoping" built into the language. There's nothing so special about buffers that they deserve to be built into the programming language's scoping rules.
MockLisp is to Lisp as JavaScript is to Java. They're both badly designed programming languages that ripped off the names of better designed programming languages, to fool people into believing they didn't suck.
-Don
So you can concede that PHP is a badly designed broken tool, but you claim that it doesn't matter, because 99% of the time it's the fault of the programmer? Maybe PHP just attracts and cultivates bad programmers? Why would you choose a deeply flawed tool like PHP, when other excellent well designed tools like Python and Ruby are available for free?
-Don
AJAX Special Hazard Precautions
Anyone who tries to tell you that AJAX is a " new approach to web applications" is just rebranding old technology and hyping buzzwords, not engineering software in the real world. Because of browser and DHTML incompatibilities and limitiations, AJAX is like cocaine: it seems glamorous until you actually start using it, then the unintended consequences totally fuck you up.
Special Hazard Precautions for AJAX:
INGESTION: NAUSEA, VOMITING, AND DIARRHEA. EYES: EYE IRRITANT UPON DIRECT CONTACT. SKIN: MAY CAUSE SKIN IRRITATION UPON PROLONGED CONTACT. INHALATION: NONE UNDER NORMAL USE. PROLONGED INHALATION BY UNORTHODOX USE (NON-WETTED) OR ABUSE (SNIFFING) COULD PRODUCE LUNG DISEASE (SILICOSIS). N/K
Emergency/First Aid Proc: INGEST: IF EATEN/DRUNK--YOU MAY THROW UP. DRINK SIPS OF WATER/MILK. IF VOMIT CONTINUES, CALL POISON CTR/DR. EYES: IRRIT. FLUSH W/WATER 15 MIN. IF IRRIT PERSISTS, CALL POISON CTR/DR. SKIN: IRRIT. REMOVE WET CLOTHES. FLUSH W/WARM WATER 15 MIN. IF IRRIT PERSISTS, CALL DR/POISON CTR. INHAL: IF INHALED, MAY COUGH. TAKE SLOW DEEP BREATHS OF FRESH AIR, SIP WATER. IF COUGH PERSISTS, CALL DR/POISON CTR.
Here's the entire Ajax information sheet, with more warnings and hazard precautions.
-Don
Somebody should port WINE to Windows, so then you wouldn't need Linux to run Windows applications.
<EmilyLitella>Oh, never mind.</EmilyLitella>
-Don
It just means your Perl 5 programs will break in many horrible and unexpected ways, if you ever try to port them to Perl 6. But that's absolutely wonderful, if you enjoy Perl's flaws because you want to lock your employer into depending on you and paying you to keep the code running for many years.
Using Perl is simply foolish, irresponsible, short sighted, and self serving. But if you want to really "stick it to the man" who's paying you to design their web site, then it's the perfect weapon of mass destruction and corporate sabotage.
-Don
Tony Bove' also has the distinction of developing the most elegantly packaged interactive multimedia CDROM title in the industry: Haight Ashbury in the 60's. He pioneered the concept of the "refillable software stash box", which is big enough that it takes up a whole cigar box of shelf space, and it holds a whole lot of ... refillable software.
-Don
<understatement degree="gross">Having tons of developers isn't necessarily an advantage when designing the core of a runtime system.</understatement>
Thanks for your open invitation join the big party going on in the kitchen, and throw my own ingredients into the delicious rock soup you all are cooking. Please seriously consider my proposal to add generalized overloading of white space to Parrot, based on Bjarne Stroustrup's brilliant and well thought out paper: Generalized Overloading for C++2000.
What good is Parrot, if it can't support all the wonderful features of C++?
-Don
You wouldn't think I was changing the subject if you bothered to read the articles I pointed to. There's some really important stuff in there that I think you should know, otherwise you're going to re-discover it all the hard way, when you're up the creek without a paddle. Don't think Parrot is the first time somebody's tried something like that. Guile started with a much more coherent language (Scheme) than Parrot is saddled with (Perl), and Guile didn't succeed for many of the same reasons that Parrot will fail.
From Ian Bicking's remarks in the discussion titled "A vision for Parrot":
I bothered to learn Perl in 1989, and have been watching it decay ever since. But I've also bothered to learn other languages that are much better than Perl, and I choose to use those instead.
So let me get you right: do you actually think it's a good thing that Perl 6 treats "print (1+2)+3" differently than "print(1+2) + 3"? How is that "easier to read"?
-Don