At first, I chose to use JavaScript to script my PocketPC application, because it was the most obvious "consumer oriented" scripting language, with a free implementation in C (SpiderMonkey, the original JavaScript engine, built into Firefox and many other applications).
It worked, but it was big and slow. And it was a pain in the ass to interface with C and C++, because SWIG doesn't support it, and it has a really nasty extension API.
But I didn't realize how truly horrible it was, until I saw how bad SpiderMonkey JavaScript ranked in the Computer Language Shootout. It's not just the worst, it's MORE THAN TWICE AS BAD as the second worst!
What amazes me about SpiderMonkey JavaScript, is that it manages to be magnificently slow AND waste huge amounts of memory, without actually getting any benefits from all the trade-offs and compromises it made!
It's not just at the bottom of the list of the computer language shootout ranking, it's waaaaay below the next worst language: more than twice as bad, in fact!
Last place SpiderMonkey's ratio to C is 26, while next to last place Smalltalk GST's ratio is 12, so SpiderMonkey's 2.25 times worse than the slowest Smalltalk! (That's with a 1 multiplier for full cpu time and memory use, to consider both.)
In contrast, Lua is the fastest scripting language in the shootout. In a head-to-head comparison with JavaScript, Lua totally smokes JavaScript and leaves it in the dust, with some benchmarks scoring as high as 71, 77, 80 times better than JavaScript.
Lua's an extremely well designed and implemented language, very clean and simple, few compromises and blemishes, excellent licensing terms, very easy to integrate with C and C++ with SWIG and other tools, has few dependencies, runs everywhere, and it's even easy to learn, read and write.
Lua already existed (in an early form) by the time Netscape started kludging together LiveScript then renaming it JavaScript. It would be a better world if Netscape had decided to use Lua instead of inventing their own half-assed language, and getting distracted by the Java Juggernaut.
But in spite of that dot-com-bubble diversion, Lua has finally proven itself, and is extremely popular in the game industry, widely used in games like World of Warcraft. A great way to see how powerful it is, and learn practical Lua programming, is to check out and look at the source code of a sophisticated WOW extension like Auctioneer.
Hey Bill! I remember carrying around a lot of equipment at Usenix and SUG. Once I took two giant SparcStation 2 monitors through customs -- that really sucked. (Especially if you look like me -- you get extra attention. The picture postcard of the pope taking a crap on a jewel encrusted gilded toilet didn't do much to reassure them, either.)
Never trust a computer you can't pick up, and only trust it as far as you can throw it. (And get an insurance policy on your trusty cell phone.)
My 4 meg Sun 3/50 had sound, because I kept an AM radio next to it. NeWS had so much shit to do interpreting the postscript and rendering the graphics and paging to disk, that I liked to listen to draw on the screen, to pass the time!
-Don
Pie menus for GPS navigation and driving
on
GUIs Get a Makeover
·
· Score: 1
Some car computers and GPS navigation systems do limit the commands you can use while the car is in gear, for example Windows Automotive 5.0's AUIT (Automotive User Interface Toolkit), whose "Driver Distraction Control reports to applications when the car is in drive, so they can limit their functionality.
Windows CE for Automotive 3.5s SUI has built-in Driver Distraction
Control safeguards designed to protect drivers from distractions that
can be caused by a computing device. The system provides a standard
interface enabling auto manufacturers to build devices that meet their
individual safety requirements. The SUI also provides a speech queuing
system that keeps order among a set of applications competing to talk
with the user. To prevent applications from "barging in" and confusing
or distracting the driver, the queuing system requires speech-based
interactions to line up. This allows each application to "speak" to
the driver when its turn comes up. The queuing system can be compared
to a digital version of Roberts Rules of Order.
I'm sure there's a snarky digital rights management joke in there somewhere...
When you start TomTom Navigator, it makes you agree to the following before proceeding: "IMPORTANT: When using navigation aids, both hardware and this software product, it is your sole responsibility to place, secure, and use these aids in a manner that will not cause accidents, personal injury or property damage, or in any way obstruct your view. You, the user of this product, are solely responsible for observing safe driving practices. Do not operate this product while driving. Park the vehicle first. [I Agree]"
The purpose of GPS navigation systems warning people not to use them while driving is to protect the asses of the company that developed it from lawsuits.
The purpose of safer user interfaces requiring less visual attention is to protect the asses (and other parts) of the people driving and riding in cars, and other people sharing the road with them.
I think it's important to go beyond legal disclaimers, and to design safer user interfaces, because protecting people from physical harm is at least as important than protecting companies from lawsuits. Of course people are going to use GPS navigation systems while driving, so they should be designed not to require your undivided visual attention. That's where touch screen pie menus with audio/voice feedback come in handy.
It's pointless to submit my complaints to the GIMP developers, because they have heard all the complaints before, and they ignore them with contempt, because they like things the way they are.
GIMP is a dead-end, because of its horrible user interface, its stubborn butt-headed developers, and its stupid name.
Some things are more expensive than money. GIMP is only free if your time is worthless.
-Don
Re:Touch screen talking pie menus
on
GUIs Get a Makeover
·
· Score: 2, Informative
The first publication that described the basic idea of pie menus was "PIXIE: A New Approach to Graphical Man-Machine Communications"; by Wiseman, N. E., Lemke, H. U., and Hiles, J. O.; Proceedings of 1969 CAD Conference Southhampton, IEEE Conference Publication 51, p. 463. The basic idea was also described in "Principles of Interactive Computer Graphics, 2nd. edition"; by Newman, W. M. and Sproull, R. F.; McGraw-Hill, 1979, 1973. Both of those came out a long time before Maya/Alias/PowerAnimator.
In the mean time, I've developed pie menus for many different platforms, including X10 (uwm+forth), X11 (piewm, TCL/Tk), NeWS 1.0, 1.1 (Lite Toolkit), OpenWindows (TNT/Open Look), Multi Player SimCity (X11/TCL/Tk), The Sims (C++/DirectX), ActiveX/OLE (C++), Internet Explorer DHTML Behaviors (JavaScript/XML), Palm (C++/XML), Pocket PC (C++/Lua), SVG (JavaScript), and OpenLaszlo (JavaScript/XML). In my copious spare time I'm also working on developing pie menus for World of Warcraft (Lua/XML)!
-Don
Re:Touch screen talking pie menus
on
GUIs Get a Makeover
·
· Score: 4, Interesting
Of course I've heard of Steve Mann's work, and his Gnu/Linux Wristwatch Video Phone, which used pie menus (but didn't talk as far as I know). He built his prototype pie menu watch in 1998, about 10 years after we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published a paper about pie menus at ACM CHI'88. But in 1988 (and 1998), not many people had hardware they could carry around that was suitible for implementing talking pie menus.
Speech synthesis requires a lot of memory to store a good voice, and speech enabled applications require a lot of task-specific scripting control (so they don't start talking and talking at length about something the user is no longer interested in). I'm using the Lua scripting language on the Pocket PC, to develop flexible speech enabled touch screen pie menu based interfaces, which will run on commonly available Pocket PC phones. (I've done a lot of Palm programming in the past, but that's a dead platform.)
Here's a video that Dave Winer took of me demonstrating an example application: a remote control for "Rock and Roll".
By the way, Photoshop has scripting, too. The GIMP fans should learn more about the competition before trying to trash it. One reason GIMP is so far behind Photoshop, is that many of its developers refuse to try Photoshop or learn more about it, because they want to remain "pure" (i.e. proudly wearing a badge of ignorance). That's why real artists who use Photoshop regularly can't stand GIMP.
I think he meant "See GIMP, for an example of a spectacularly badly designed graphical user interface, and compare it to Photoshop, if you want to see how much better a well designed user interface can be."
I hate Adobe as much as anyone, but there's no reason for GIMP fans to lie about how easy it is to use, compared to Photoshop.
-Don
Re:The problem with guis is they don't work
on
GUIs Get a Makeover
·
· Score: 5, Insightful
There's a lot of scientific user interface research that contradicts your sweeping claim that "There's been no evidence that they actually increase productivity...".
A shell is itself quite a sophisticated user interface, and the commands and scripts you type into the shell are user interfaces, themselves. The TOPS-20 operating system provided completion and help built into the command line of all its utilities and applications. Tell me that's not a user interface. Unix has a much worse, non-standard way of providing parameters to programs and getting help about their parameters, and a lackluster hodge-podge of shells and scripting languages, which are some of the worst text based user interfaces in common use.
There are many things that guis make easier, like picking from a list of choices (menus, trees, scrolling lists, etc), drawing and painting (sure you could paint in a shell by typing in x,y coordinates, but that illustrates my point that there are many common tasks that a gui is better for than a command line).
I understand that you're probably just trying to play the Luddite, by rejecting all graphical user interfaces out of hand in favor of a text based shell, but shouldn't you reject all computers, cell phones and other electronic (and steam driven) devices, if you really want to be consistent? I mean, if you hate bad user interfaces, then you certainly shouldn't use the shell (or at least you should run it under Emacs so you have some reasonable input and output editing ability), because most shells have absolutely horrible user interfaces (i.e. arcane syntax). That's right, the syntax of a scripting (or programming) language IS a user interface. Unfortunately many language designers (i.e. PHP, Perl) have no concept of user interface design, and make many foolish usability mistakes that a competent graphical user interface designer should never make.
Have you ever try to explain csh history substitution syntax to your grandmother? Even if she knows how to send and reply to email with a graphical user interface, it'll probably take her a long time to learn how to use the shell.
-Don
Touch screen talking pie menus
on
GUIs Get a Makeover
·
· Score: 4, Interesting
I've been developing touch screen talking pie menus on handheld devices, like the Pocket PC. Pie menus work very well with touch screens, but of course the way they track and display and give feedback has to be adapted to the quirks of small touch screens. Talking pie menus give you audio feedback with a speech synthesizer, so they don't require a lot of visual attention and hand-eye coordination.
Talking pie menus make it possible to use an application without looking at the screen! That's important for mobile applications like GPS navigation systems, which people use while driving (despite all the warnings again it).
Where is my Zend_DB_DataObject / ZActiveRecord? I just downloaded the alpha Zend Framework and there does not appear to be any reference to ZActiveRecord or any DB_DataObject thingy anywhere.
Well, not entirely true, the news.txt file has one line that says "Removed defunct Zend_Db_DataObject" docs. I saw a reference elsewhere in an old blog that said there were some inherent problems with the design of ZActiveRecord with php 5.1... and it looks like they've removed the documentation from online too... those bastards!!!
The real question is: Will you still be around when the web's finally won?
If you had any perspective, you would realize what an abomination PHP is, and know that we're a long way from realizing the full potential from the web. There's no reason for you to be repeating the mistakes of the past by using PHP, which there are so many better solutions available. How long have you been around, to accuse me of being a newbie?
I've been developing hypermedia browsers and distributed user interfaces ("AJAX") since 1988.
I wrote my first hypermedia browser in PostScript, Forth and C, for the NeWS window system, in 1988, and it was called "HyperTIES":
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. http://www.donhopkins.com/drupal/node/102
I also wrote a hypermedia authoring tool with UniPress Emacs in MockLisp (this article has many images and links to documentation and source code written in C, Forth, PostScript, MockLisp and HyperTIES markup language):
The HyperTIES markup language supported macros, conditionals, loops, variables, even user defined interactive widgets ("applets" scripted in PostScript), and we designed to be easy to understand, with a simple uniform syntax, low syntactic surface area, few exceptions to the rules, consistent naming conventions. In short, everything that PHP lacks. And that was in 1988.
There is no excuse for PHP's horrible design. If you're not aware of its flaws, then you're not qualified to use it. So stop making excuses for it.
Slamb, thanks for asking that question, which was also on my mind. I'd certainly like to know how anyone could have ever conceived of something as dangerous as magic_quotes_gpc and register_globals in the first place, let alone why have they taken so long to remove those flaws?
Those horrible mistakes by PHP's designers are directly responsible for many of the security holes and bugs in millions of PHP programs, because PHP is designed to PRETEND to solve security problems, while failing to actually provide any security. So it's pretty hypocritical to blame the sloppy developers, when you're the one who actually invented those horrible flaws in the first place, and took so long to recognize them as such and remove them.
Thanks a lot for finally removing the foolish flaws that encouraged bad practices, and resulted in many security holes, crashed servers, service interruptions, loss of time, loss of money, and exposure private data, but I'll take a pass on the lecture about the consequences of sloppy programming from the designer of PHP.
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. ThesloppyimplementationcausedmanybugsthatCOREDUMPPHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C semantics [since the original C++ compiler compiled C++ into C.]) Most of those C++ design decisions make absolutely no sense for a dynamic interpreted language like PHP. (Many of them made very little sense for C++ itself, but even less sense in the context off PHP.)
One prime example of how PHP screwed up its object system, is that they blew it on static methods, in a way that makes it impossible to properly implement an ActiveRecord-like ORM (among other us
Why would anyone choose to tie themselves to proprietary Flash and FLEX, when you can have your cake and eat it too with OpenLaszlo, which supports both Flash and DHTML, and is completely Open Source?
So when will FLEX support DHTML or SVG? The answer is NEVER, because it's designed to lock you in and make you depend on Flash 9 -- it not designed to be platform independent, like OpenLaszlo.
I've been interested in SVG (Scalable Vector Graphics) for a long time, and have thought
it would make a good runtime platform for OpenLaszlo applications. With the development of the Legals release, I wanted to see how difficult it would
be to port the DHTML kernel (which is still under development) to SVG. Since Firefox and Opera now support SVG 1.1 natively, it seemed like it was a good time to try this out. SVG is strong on graphics imaging and text rendering, I think of it like a free-software version of Adobe's crown jewels.
With two days of hacking over the weekend, I got a large about of the Sprite API ported to SVG.
Here's a version of the SVG kernel running, try this in Firefox: Try clicking on the gray area of the gray square, the red rect, or the blue rect, or the text string
This tells me that the kernel API is pretty much on target, certainly for runtimes which have HTML/SVG javascript-like event handling.
I was disappointed to learn that SVG 1.1 (which is what Firefox supports now) does not handle input text or wrapping text regions, however
SVG 1.2 does have these, so I look forward to finishing this work when Firefox SVG 1.2 support is released, and then we will have
an OpenLaszlo runtime with the beautiful imaging model from SVG.
If time permits, I will try to clean up the SVG kernel enough to stick into an upcoming Legals release, so interested people can look at it. I
haven't implemented image or data loading yet, and there's some bugs with background color names and defaults.
SVG has been slow to gain traction, but I think it is one of the best hope for high quality portable graphics, and maybe even rich internet apps that
use them, in the future.
Since X-Windows is so pixel oriented, a natural scripting language would be a two-dimensional cellular automata like John von Neuman's 29 State Cellular Automata, which can run "Universal Constructor" programs that reproduce theselves or any other program. Since it's Turing Complete, you could script an emulator for any other language!
The fact that the Self team is looking for work is telling. Sun hired the Self team, and plowed the fruits of their brilliant work into Java instead of Self or Smalltalk, and then Sun scuttled all the Self related projects. Before that, Sun hired the TCL team, announced with much fanfair that TCL was going to be the official web scripting language, then dropped it like a hot potato.
Don't read too much into anyone's promises that Sun is going to support Ruby, especially if they work for Sun and are trying to hire you. They lie to the people they're hiring, and play bait-and-switch, because their real intention is to divert people from competing projects that conflict with Sun's other goals-de-jour. From my past experience with Sun (like James Gosling personally promising me that Sun was totally behind NeWS and would soon make NeWS source public domain), I believe that it's quite likely they'll let the JRuby team work on Ruby for a little while, then divert them onto something else. If you can't beat 'em, hire 'em and tell 'em to stop. That's the way it works in the real world, kids.
What are you, an old COBOL programmer who hates to learn new languages?
Lua is an extremely well designed language, much more efficient than PHP or Ruby.
Where did you get the prejudice that a high level game programming language would be designed for people who can't master other languages? Ruby shines because it's a real programming language, not a toy, and it integrates extremely well with compiled languages like C and C++.
I understand that you may not have heard of Lua, because there are a lot of people like you who are afraid to learn new languages, and reject them out of hand, without even knowing what you're talking about.
But if you have the guts to open your mind to new ideas, then take a look at the computer language shootout, and see which interpreted scripting language is at the top of the pack, with a higher score than JavaScript, Smalltalk GST, Scheme MzScheme, PHP, Smalltalk Visualworks, Ruby, Icon, TCL, Pike, Mozart/OZ, Perl, Erlang Hipe, Python and Scala. Ever heard of any of those languages, old timer? Lua's faster than them all.
Ruby only seems like a great language to newbie programmers who don't know anything but PHP. It's not BAD, but it's not very impressive nor efficient compared to decent languages, and it's horrible compared to excellent languages.
Why is Ruby so far down at the bottom of the list sorted by score, in the Computer Language Shootout? The only other popular web server scripting language that's worse than Ruby is PHP! That's certainly nothing to be proud of.
With such lackluster performance, Ruby looks good to newbie programmers whose only experience is with PHP, but that's only because PHP is so horrible that Ruby looks better in contrast, and they haven't investigated any of the much more efficient, fully developed, well designed languages like Lisp, Python and Lua, which kick Ruby's ass when it comes to performance.
But if your main criteria for choosing a language is that it should only have a single one-size-fits-all unitard web framework, and you don't like the bewildering freedom of having many frameworks to choose from tailored for different situations, then by all means go with Ruby on Rails, and save yourself all the bother and effort of researching and understanding the problem space, and choosing the best tool to fit your application. After all, it levels the Web 2.0 playing field if everybody's trying to tighten their screws and splice their wires with the same hammer.
The fact that Sun hired a major developer of a programming language does NOT necessarily bode well for that language. Sun has a long track record of trying to scuttle technologies that they perceive as a threat, by hiring the developers, and diverting them to work on other things like Java.
Slashdot Mirror
At first, I chose to use JavaScript to script my PocketPC application, because it was the most obvious "consumer oriented" scripting language, with a free implementation in C (SpiderMonkey, the original JavaScript engine, built into Firefox and many other applications).
It worked, but it was big and slow. And it was a pain in the ass to interface with C and C++, because SWIG doesn't support it, and it has a really nasty extension API. But I didn't realize how truly horrible it was, until I saw how bad SpiderMonkey JavaScript ranked in the Computer Language Shootout. It's not just the worst, it's MORE THAN TWICE AS BAD as the second worst!
What amazes me about SpiderMonkey JavaScript, is that it manages to be magnificently slow AND waste huge amounts of memory, without actually getting any benefits from all the trade-offs and compromises it made!
It's not just at the bottom of the list of the computer language shootout ranking, it's waaaaay below the next worst language: more than twice as bad, in fact!
Last place SpiderMonkey's ratio to C is 26, while next to last place Smalltalk GST's ratio is 12, so SpiderMonkey's 2.25 times worse than the slowest Smalltalk! (That's with a 1 multiplier for full cpu time and memory use, to consider both.)
In contrast, Lua is the fastest scripting language in the shootout. In a head-to-head comparison with JavaScript, Lua totally smokes JavaScript and leaves it in the dust, with some benchmarks scoring as high as 71, 77, 80 times better than JavaScript.
Lua's an extremely well designed and implemented language, very clean and simple, few compromises and blemishes, excellent licensing terms, very easy to integrate with C and C++ with SWIG and other tools, has few dependencies, runs everywhere, and it's even easy to learn, read and write.
Lua already existed (in an early form) by the time Netscape started kludging together LiveScript then renaming it JavaScript. It would be a better world if Netscape had decided to use Lua instead of inventing their own half-assed language, and getting distracted by the Java Juggernaut.
But in spite of that dot-com-bubble diversion, Lua has finally proven itself, and is extremely popular in the game industry, widely used in games like World of Warcraft. A great way to see how powerful it is, and learn practical Lua programming, is to check out and look at the source code of a sophisticated WOW extension like Auctioneer.
-Don
Hey Bill! I remember carrying around a lot of equipment at Usenix and SUG. Once I took two giant SparcStation 2 monitors through customs -- that really sucked. (Especially if you look like me -- you get extra attention. The picture postcard of the pope taking a crap on a jewel encrusted gilded toilet didn't do much to reassure them, either.)
Never trust a computer you can't pick up, and only trust it as far as you can throw it. (And get an insurance policy on your trusty cell phone.)
My 4 meg Sun 3/50 had sound, because I kept an AM radio next to it. NeWS had so much shit to do interpreting the postscript and rendering the graphics and paging to disk, that I liked to listen to draw on the screen, to pass the time!
-Don
Some car computers and GPS navigation systems do limit the commands you can use while the car is in gear, for example Windows Automotive 5.0's AUIT (Automotive User Interface Toolkit), whose "Driver Distraction Control reports to applications when the car is in drive, so they can limit their functionality.
I'm sure there's a snarky digital rights management joke in there somewhere...
When you start TomTom Navigator, it makes you agree to the following before proceeding: "IMPORTANT: When using navigation aids, both hardware and this software product, it is your sole responsibility to place, secure, and use these aids in a manner that will not cause accidents, personal injury or property damage, or in any way obstruct your view. You, the user of this product, are solely responsible for observing safe driving practices. Do not operate this product while driving. Park the vehicle first. [I Agree]"
The purpose of GPS navigation systems warning people not to use them while driving is to protect the asses of the company that developed it from lawsuits.
The purpose of safer user interfaces requiring less visual attention is to protect the asses (and other parts) of the people driving and riding in cars, and other people sharing the road with them.
I think it's important to go beyond legal disclaimers, and to design safer user interfaces, because protecting people from physical harm is at least as important than protecting companies from lawsuits. Of course people are going to use GPS navigation systems while driving, so they should be designed not to require your undivided visual attention. That's where touch screen pie menus with audio/voice feedback come in handy.
-Don
Well that certainly cuts to the chase of the problem: Photoshop is EASY TO LEARN, and GIMP simply isn't.
-Don
It's pointless to submit my complaints to the GIMP developers, because they have heard all the complaints before, and they ignore them with contempt, because they like things the way they are.
GIMP is a dead-end, because of its horrible user interface, its stubborn butt-headed developers, and its stupid name.
Some things are more expensive than money. GIMP is only free if your time is worthless.
-Don
Of course I'm familiar with Maya's marking menus and Gordon Kurtenbach's work, which are based on the ideas from (and refer to) the paper, "An Empirical Comparison of Pie vs. Linear Menus", that we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published in 1988.
The first publication that described the basic idea of pie menus was "PIXIE: A New Approach to Graphical Man-Machine Communications"; by Wiseman, N. E., Lemke, H. U., and Hiles, J. O.; Proceedings of 1969 CAD Conference Southhampton, IEEE Conference Publication 51, p. 463. The basic idea was also described in "Principles of Interactive Computer Graphics, 2nd. edition"; by Newman, W. M. and Sproull, R. F.; McGraw-Hill, 1979, 1973. Both of those came out a long time before Maya/Alias/PowerAnimator.
In the mean time, I've developed pie menus for many different platforms, including X10 (uwm+forth), X11 (piewm, TCL/Tk), NeWS 1.0, 1.1 (Lite Toolkit), OpenWindows (TNT/Open Look), Multi Player SimCity (X11/TCL/Tk), The Sims (C++/DirectX), ActiveX/OLE (C++), Internet Explorer DHTML Behaviors (JavaScript/XML), Palm (C++/XML), Pocket PC (C++/Lua), SVG (JavaScript), and OpenLaszlo (JavaScript/XML). In my copious spare time I'm also working on developing pie menus for World of Warcraft (Lua/XML)!
-Don
Of course I've heard of Steve Mann's work, and his Gnu/Linux Wristwatch Video Phone, which used pie menus (but didn't talk as far as I know). He built his prototype pie menu watch in 1998, about 10 years after we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published a paper about pie menus at ACM CHI'88. But in 1988 (and 1998), not many people had hardware they could carry around that was suitible for implementing talking pie menus.
Speech synthesis requires a lot of memory to store a good voice, and speech enabled applications require a lot of task-specific scripting control (so they don't start talking and talking at length about something the user is no longer interested in). I'm using the Lua scripting language on the Pocket PC, to develop flexible speech enabled touch screen pie menu based interfaces, which will run on commonly available Pocket PC phones. (I've done a lot of Palm programming in the past, but that's a dead platform.)
Here's a video that Dave Winer took of me demonstrating an example application: a remote control for "Rock and Roll".
-Don
By the way, Photoshop has scripting, too. The GIMP fans should learn more about the competition before trying to trash it. One reason GIMP is so far behind Photoshop, is that many of its developers refuse to try Photoshop or learn more about it, because they want to remain "pure" (i.e. proudly wearing a badge of ignorance). That's why real artists who use Photoshop regularly can't stand GIMP.
-Don
I think he meant "See GIMP, for an example of a spectacularly badly designed graphical user interface, and compare it to Photoshop, if you want to see how much better a well designed user interface can be."
I hate Adobe as much as anyone, but there's no reason for GIMP fans to lie about how easy it is to use, compared to Photoshop.
-Don
There's a lot of scientific user interface research that contradicts your sweeping claim that "There's been no evidence that they actually increase productivity ...".
A shell is itself quite a sophisticated user interface, and the commands and scripts you type into the shell are user interfaces, themselves. The TOPS-20 operating system provided completion and help built into the command line of all its utilities and applications. Tell me that's not a user interface. Unix has a much worse, non-standard way of providing parameters to programs and getting help about their parameters, and a lackluster hodge-podge of shells and scripting languages, which are some of the worst text based user interfaces in common use.
There are many things that guis make easier, like picking from a list of choices (menus, trees, scrolling lists, etc), drawing and painting (sure you could paint in a shell by typing in x,y coordinates, but that illustrates my point that there are many common tasks that a gui is better for than a command line).
I understand that you're probably just trying to play the Luddite, by rejecting all graphical user interfaces out of hand in favor of a text based shell, but shouldn't you reject all computers, cell phones and other electronic (and steam driven) devices, if you really want to be consistent? I mean, if you hate bad user interfaces, then you certainly shouldn't use the shell (or at least you should run it under Emacs so you have some reasonable input and output editing ability), because most shells have absolutely horrible user interfaces (i.e. arcane syntax). That's right, the syntax of a scripting (or programming) language IS a user interface. Unfortunately many language designers (i.e. PHP, Perl) have no concept of user interface design, and make many foolish usability mistakes that a competent graphical user interface designer should never make.
Have you ever try to explain csh history substitution syntax to your grandmother? Even if she knows how to send and reply to email with a graphical user interface, it'll probably take her a long time to learn how to use the shell.
-Don
I've been developing touch screen talking pie menus on handheld devices, like the Pocket PC. Pie menus work very well with touch screens, but of course the way they track and display and give feedback has to be adapted to the quirks of small touch screens. Talking pie menus give you audio feedback with a speech synthesizer, so they don't require a lot of visual attention and hand-eye coordination.
Talking pie menus make it possible to use an application without looking at the screen! That's important for mobile applications like GPS navigation systems, which people use while driving (despite all the warnings again it).
-Don
Jason asks on his blog:
About face! Retreat! Whitewash web site!!!
-Don
The real question is: Will you still be around when the web's finally won? If you had any perspective, you would realize what an abomination PHP is, and know that we're a long way from realizing the full potential from the web. There's no reason for you to be repeating the mistakes of the past by using PHP, which there are so many better solutions available. How long have you been around, to accuse me of being a newbie?
I've been developing hypermedia browsers and distributed user interfaces ("AJAX") since 1988. I wrote my first hypermedia browser in PostScript, Forth and C, for the NeWS window system, in 1988, and it was called "HyperTIES":
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
http://www.donhopkins.com/drupal/node/102
I also wrote a hypermedia authoring tool with UniPress Emacs in MockLisp (this article has many images and links to documentation and source code written in C, Forth, PostScript, MockLisp and HyperTIES markup language):
HyperTIES Hypermedia Browser and Emacs Authoring Tool for NeWS
http://www.donhopkins.com/drupal/node/101
And I wrote my first web server in ScriptX and C, in 1995:
ScriptX and the World Wide Web: "Link Globally, Interact Locally"
http://www.donhopkins.com/drupal/node/118
Here is the web server module documentation:: www.art.net/~hopkins/Don/lang/scriptx/web.html&hl= en&gl=us&ct=clnk&cd=1
http://www.google.com/search?q=cache:XgEgHkBwCBMJ
The HyperTIES markup language supported macros, conditionals, loops, variables, even user defined interactive widgets ("applets" scripted in PostScript), and we designed to be easy to understand, with a simple uniform syntax, low syntactic surface area, few exceptions to the rules, consistent naming conventions. In short, everything that PHP lacks. And that was in 1988.
There is no excuse for PHP's horrible design. If you're not aware of its flaws, then you're not qualified to use it. So stop making excuses for it.
-Don
A: So they can warm your hands while you're pushing them.
-Don
Slamb, thanks for asking that question, which was also on my mind. I'd certainly like to know how anyone could have ever conceived of something as dangerous as magic_quotes_gpc and register_globals in the first place, let alone why have they taken so long to remove those flaws?
Those horrible mistakes by PHP's designers are directly responsible for many of the security holes and bugs in millions of PHP programs, because PHP is designed to PRETEND to solve security problems, while failing to actually provide any security. So it's pretty hypocritical to blame the sloppy developers, when you're the one who actually invented those horrible flaws in the first place, and took so long to recognize them as such and remove them.
Thanks a lot for finally removing the foolish flaws that encouraged bad practices, and resulted in many security holes, crashed servers, service interruptions, loss of time, loss of money, and exposure private data, but I'll take a pass on the lecture about the consequences of sloppy programming from the designer of PHP.
-Don
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The sloppy implementation caused many bugs that CORE DUMP PHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C semantics [since the original C++ compiler compiled C++ into C.]) Most of those C++ design decisions make absolutely no sense for a dynamic interpreted language like PHP. (Many of them made very little sense for C++ itself, but even less sense in the context off PHP.)
One prime example of how PHP screwed up its object system, is that they blew it on static methods, in a way that makes it impossible to properly implement an ActiveRecord-like ORM (among other us
-Don
Why would anyone choose to tie themselves to proprietary Flash and FLEX, when you can have your cake and eat it too with OpenLaszlo, which supports both Flash and DHTML, and is completely Open Source?
So when will FLEX support DHTML or SVG? The answer is NEVER, because it's designed to lock you in and make you depend on Flash 9 -- it not designed to be platform independent, like OpenLaszlo.
FLEX is not Open Source, so you can't just add support for your favorite runtime or graphics model, the way Henry Minsky added SVG support to OpenLaszlo.
-Don
Since X-Windows is so pixel oriented, a natural scripting language would be a two-dimensional cellular automata like John von Neuman's 29 State Cellular Automata, which can run "Universal Constructor" programs that reproduce theselves or any other program. Since it's Turing Complete, you could script an emulator for any other language!
-Don
It's "X-Windows" with a dash, if you want to maximize your chances of making people who insist on calling it "The X Window System" go apoplectic.
And NeWS invented the BIG small BIG BIG capitalization style, long before NeXT copied it!
-Don
The fact that the Self team is looking for work is telling. Sun hired the Self team, and plowed the fruits of their brilliant work into Java instead of Self or Smalltalk, and then Sun scuttled all the Self related projects. Before that, Sun hired the TCL team, announced with much fanfair that TCL was going to be the official web scripting language, then dropped it like a hot potato.
Don't read too much into anyone's promises that Sun is going to support Ruby, especially if they work for Sun and are trying to hire you. They lie to the people they're hiring, and play bait-and-switch, because their real intention is to divert people from competing projects that conflict with Sun's other goals-de-jour. From my past experience with Sun (like James Gosling personally promising me that Sun was totally behind NeWS and would soon make NeWS source public domain), I believe that it's quite likely they'll let the JRuby team work on Ruby for a little while, then divert them onto something else. If you can't beat 'em, hire 'em and tell 'em to stop. That's the way it works in the real world, kids.
-Don
What are you, an old COBOL programmer who hates to learn new languages? Lua is an extremely well designed language, much more efficient than PHP or Ruby. Where did you get the prejudice that a high level game programming language would be designed for people who can't master other languages? Ruby shines because it's a real programming language, not a toy, and it integrates extremely well with compiled languages like C and C++.
I understand that you may not have heard of Lua, because there are a lot of people like you who are afraid to learn new languages, and reject them out of hand, without even knowing what you're talking about. But if you have the guts to open your mind to new ideas, then take a look at the computer language shootout, and see which interpreted scripting language is at the top of the pack, with a higher score than JavaScript, Smalltalk GST, Scheme MzScheme, PHP, Smalltalk Visualworks, Ruby, Icon, TCL, Pike, Mozart/OZ, Perl, Erlang Hipe, Python and Scala. Ever heard of any of those languages, old timer? Lua's faster than them all.
-Don
Lua totally kicks Ruby's ass in the Computer Language Shootout.
Ruby only seems like a great language to newbie programmers who don't know anything but PHP. It's not BAD, but it's not very impressive nor efficient compared to decent languages, and it's horrible compared to excellent languages.
-Don
Why is Ruby so far down at the bottom of the list sorted by score, in the Computer Language Shootout? The only other popular web server scripting language that's worse than Ruby is PHP! That's certainly nothing to be proud of.
With such lackluster performance, Ruby looks good to newbie programmers whose only experience is with PHP, but that's only because PHP is so horrible that Ruby looks better in contrast, and they haven't investigated any of the much more efficient, fully developed, well designed languages like Lisp, Python and Lua, which kick Ruby's ass when it comes to performance.
But if your main criteria for choosing a language is that it should only have a single one-size-fits-all unitard web framework, and you don't like the bewildering freedom of having many frameworks to choose from tailored for different situations, then by all means go with Ruby on Rails, and save yourself all the bother and effort of researching and understanding the problem space, and choosing the best tool to fit your application. After all, it levels the Web 2.0 playing field if everybody's trying to tighten their screws and splice their wires with the same hammer.
The fact that Sun hired a major developer of a programming language does NOT necessarily bode well for that language. Sun has a long track record of trying to scuttle technologies that they perceive as a threat, by hiring the developers, and diverting them to work on other things like Java.
-Don
Wha chew be talkin bout my mother's thong??!
-Don