Eeeek! Ack! It's not X-Windows!!!!! It's The X Window System, not X-Windows!!!! Stop saying X-Windows!!! Ack! Eeeek! Urp! Oop! AYYYYYEEE!!!! [HEAD EXPLODES] KABOOM! [Brains and skull fragments dripping from the walls.]
-Don
PS:
To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.
You could use emacs just fine from a decwriter or "glass tty". Teco Emacs on ITS knew how to support the dumbest terminals by just displaying the current line. You could ^N down through the file to list out each line, and use normal emacs editing commands on any part of the file. Typing ^L would redisplay the current line.
Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.
On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)
RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."
Here's a cool research paper from Sony's Computer Science Labs, about "tilting pie menus". I love it! I can't wait till all cell phones can sense tilt. Tilt control rocks!
It looks to me like it's written in C, not Java. So how does that support your argument that Java on cell phones isn't slow?
Since you're such a big Java fan, why don't you port the Gameboy emulator to Java, and find out first hand how fast it runs and how much memory it requires? Please report back -- it will be very interesting to know how much bigger and slower the Gameboy emulator is, after being rewritten from C to Java. Good luck!
Implementing special purpose scripting languages with XML is a great idea, and works quite well.
What is GSL? And what do you REALLY think about it?
-Don
Connected.TV
runs on your Palm, and turns it into a universal
remote control integrated with a personalized
TV program guide. It has programmable
touch-screen buttons with
Pie Menus,
that let you stroke in different directions
to invoke different commands. And it also supports the hardware and silkscreen buttons on the Palm, for your most commonly used commands.
Pie menus enable multiple functions on a single touch-screen button, so you can not only touch, but also stroke up, down left or right. They're fast, reliable and easy to use with your finger instead of a pen, and with only one hand. You get much more functionality out of the same amount of screen space, so the resulting remote control interfaces are less cluttered and more functional.
You can touch the pause button and stroke down
to stop, touch the program description and stroke up to switch to the channel, stroke left and right to page to the previous and next programs, stroke down to link to the index, etc.
I'm currently developing a ConnectedTV skin editor, that will let you create your own remote control interfaces with custom buttons and graphics, program them with any IR command, and bake your own pie menus.
The skin editor isn't available yet, but I'm interested in hearing from people who would like to beta test it, and who have opinions about what it should do. I'm especially interested in hearing from Pronto users: not only is ConnectedTV much cheaper than Pronto because runs on your existing Palm, but it also has useful features like the pie menus and the personalized TV guide, integrated with a universal remote control. So you can take your Palm with you wherever you go (like the kitchen, bathroom, school or work), and browse the ConnectedTV guide any time you want.
A free two week trial of ConnectedTV for the Palm is available at Connected.TV.
Why do you assume that I hate America and our freedom, because I question the integrity of our leaders? You're the unpatriotic one. It's people like you that enabled Hitler to come to power. Bugger off.
The Open Group announcing that they're interested in Open Source Software is like the Deutsche Democratic Republic announcing they're interested in becoming a democratic republic.
DDR (Deutsche Democratic Republic) was the name of East Germany during the time it was a Communist, non-democratic non-republic, which was as ironic as the Open Group calling themselves an open group.
To bring it into the present: It's as ironic as George Bush announcing he's finally going to pay attention to military intelligence, instead of fabricating his own.
Great post! You hit all the nails on the head.
Double word score, because some anonymous bozo thought it was so well written that you must have cut-and-pasted it. The sincerest form of flattery.
You should write it up and publish it somewhere more serious than slashdot.
Oh, come on, deep down you know I'm right, and you're just getting all huffy because you've invested so much time and effort in such a badly designed language. You've painted yourself into a corner, and now you don't want to admit that it was a bad idea.
There's a damn good reason that the widely held opinion of people who know both languages, is that Python is much easier to read and maintain than Perl. I've known Perl since 1989, and program extensively in Python. When did you learn Perl, and how much Python code have you written?
If you could be convinced that Python was easier to read than Perl, would you use it instead? I bet not, because Perl zeallots use Perl for all the wrong reasons, and they actually enjoy its flaws.
Can you explain your reasons for believing Perl is easier to learn and read than Python? It's simply not true, so such a belief must be based on an unspoken fallacy. Does it have something to do with your job security? Are you afraid that if your code is readable, you will be more easily replaced? That's the main reason Perl is so popular, but Perl programmers hate it when people point that out. They worship and revel in the arcane syntax, thinking it makes them more manly.
You may be very manly and irreplacable in your job because you use Perl, but there's no way you could possibly make the argument that Perl is easier to read than Python. Go ahead, try!
Water certainly is XML, but it supports an additional syntax: ConciseXML.
Water uses an extended XML syntax called "Concise XML", that's compatible but more general and concise than XML. Here's the description of Concise XML from the Water web site. They discuss some interesting observations and the rationale behind Concise XML in the "The Trouble with XML article. And here is a chapter of the Water book describing ConciseXML.
What is ConciseXML?
ConciseXML(TM) is a language-independent markup syntax compatible with XML 1.0, but designed to handle every type of data including non-hierarchial data, program logic, document markup, and binary data. ConciseXML is both concise and precise, eliminating two major limitations of XML and extending the use of XML.
Features of ConciseXML
Conciseness
Many people avoid XML in many circumstances because of its verbosity. ConciseXML is as concise at representing logic as the "semi-colon" syntax of C/C++/Java/C#. ConciseXML can also be as concise as the Comma Separated Value (CSV) syntax for data.
Precision
ConciseXML has no ambiguity of meaning. There is only one way to represent parts/fields of an object. This stands in contrast to XML where there can be many syntactic forms for the identical meaning or semantics.
XML Compatibility
Is ConciseXML compatible with XML?
ConciseXML maintains both forward-compatibility as well as backward-compatibility with XML. Any XML document is also a valid ConciseXML document. Any ConciseXML document can be represented in XML without any loss of information. For each ConciseXML extension to XML, there is a corresponding form in XML. A ConciseXML expression or document can mix and match ConciseXML and XML syntax at all levels.
ConciseXML Extends XML
ConciseXML makes XML more flexible by eliminating many of the constraints of XML. Here are some examples.
Attribute values can be any expression
Example: <input size=3/> or <person birth=<date 2002 10 2/>/>
XML requires that all attributes values are quoted. That effectively requires that all values are of type string. Elements are often used to work around this limitation, but that presents another set of problems.
Attribute keys can be non-strings
Example: <thing 0="foo" 1="bar"/>
XML does not let an attribute key start with a digit. That effectively prevents integers from being attribute keys. ConciseXML makes it possible to easily represent array-like fields with integer keys.
Tagname of an element can be any expression
Example: <foo.bar/>
XML Namespaces are a step in this direction, but ConciseXML makes it possible to have any expression as the tagname of an element.
Attribute keys are optional
Example: <date 2002 month=10 day=28/>
In the CSV (Comma Separated Value) syntax and in all major programming languages, field or argument values are given by position, not by keyword.
Closing tagname is optional
Not only does this remove unnecessary clutter, but when ConciseXML is used as the syntax for dynamic languages, the tagname may not be known until runtime, and therefore the closing tagname must be optional.
I've developed a production web site in Python and Zope (http://www.Connected.TV),
and I like Zope a lot, and absolutely love Python. But Zope is much more complicated than it needs to be, and not well documented at all. The Zope developers are certainly aware of those problems, and working to correct them. I don't agree with all the directions they're taking (like the messy dtml and crippled xml page templates that want to be a programming language but aren't quite -- didn't they already make that mistake with XSLT? Why repeat the mistakes of the past?), but since it's written in Python, you don't have to use the crazy stuff, and you can just drop down to Python and program the hell out of it to do whatever you want.
Zope's DTML is a pain in the ass, and the xml page templates are lame and bizarre. What I would really love, would be an elegent xml based and fully functional web templating and programming language like Water, implemented in open source Python, embedded in an interactive dynamic object publishing content management web server framework like Zope (but simpler).
If you're interested in language design, definitely read the white papers like the Water Rationale on the Water web site. They're to the point, brilliantly written, and hit the nail on the head.
Water is a language for the web that embodies the three primary functionalities needed for general purpose information manipulation into one unified language:
- Code: Water is a general purpose object oriented programming language that is, at its core, more flexible than Javascript, Visual Basic and Java.
- Data: Water permits the description of persistent structured data on the web via an XML syntax yet having the capability of computing values that may contain self-referencial interconnections.
- Markup: Since Water is a superset of HTML, it inherits all of HTML's capabilities.
The syntax of Water is a superset of HTML, or, more properly, a superset of XML. HTML has proven to be an easily understandable markup language since it has been learned by millions of people in the several years that the web has existed. XML is a standard for putting structured data on the web. Water extends the syntax of XML to make a language less cumbersome to write code in. Water provides a way to define functions and call them in addition to defining and instantiating objects. The object system is a multiple-inheritance, prototype-based object system with annotations. This will be described below, but for now it's sufficient to say that it is more powerful yet simpler than the class-instance object systems currently in vogue in languages such as Java and C++.
[...]
We Need Another Language Like A Hole in the Head
Right now the plethora of languages on the web causes more than headaches. New ones seem to be born monthly. Having to learn two or more to get a task done is more than twice as hard as one language because the interface between the languages is always additional hair which is, more often than not, poorly documented.
Why do we have HTML, XML, Java, Javascript, C++, Visual Basic, VRML, XSLT, PHP, etc? Because none of them are flexible enough to give programmers the functionality they need in building a modern Web application. Looking within the scope of what each of the above intends to cover, we often find serious flaws. But when we try to move outside of that scope, say doing markup in Java, we have a full-fledged disaster on our hands.
We do not need a new language for implementing some specialized functionality. Sooner or later that specialized functionality will need general purpose utilities like condi
The word "secure" is just as misunderstood and abused as the word "love". It has many different meanings in many different contexts. Programming in Java doesn't protect your children from terrorists.
Unless the security product allows untrusted users to enter and execute Python code, then there's no contradiction in using Python to develop a secure application. Security isn't something that springs from the programming language itself -- it depends on what you do with the language. Security is largely a social issue, which is why it was a good call to remove the "rexec" module for the reasons Guido stated.
The idea of adding "data tainting" to Python or any other language is a misguided attempt to force the programming language to guarentee a kind of security that you can only get by designing, implementing and debugging your program properly. No programming language can protect against lazyness or stupidity, and it's misguided to try to provide a false sense of security at the linguistic level.
Ada??! Isn't that the Wireless Robot Programming Language designed by the U.S. Government, and promoted by IBM? Ada's main feature isn't just strong typing -- it's specifically designed for flipping out and killing people! After all, robots are mammals!!!
Ada's a much better programming language for destroying Microsoft than Java, because Ada has built-in support for cutting off heads all the time without even thinking about it, instead of silly promises about "write once run anywhere" and those totally homosexual inner classes!
Your hard time with Python is caused by your own reading disability and your fear of learning a new language, not by any flaw in the Python language.
Indentation without brackets makes block nesting much more readable and obvious, than brackets without indentation.
Perl code is fundamentally unreadable, and readable Perl code is the extremely rare exception to the rule. Perl does nothing to encourage people to write good code -- just the opposite. But Python supports and encourages clean maintainable readable code.
Most vociferous Perl advocates are sadly monolinguistic (they aren't proficient with any other languages), or else they would realize how horrible Perl is in comparison, and how much time and effort they're needlessly wasting. Monolinguestic Perl programmers are usually quite polylinguaphobic (afraid of learning new languages like Python), because Perl was so hard to learn, and they assume out of ignorance that all languages are just as compex, messy and hard to learn and maintain as Perl.
Like the Senator from South Carolina argued against bilingual education: If English was good enough for Jesus, then it's good enough for the students of our state.
Pitfall 9: Analog to Digital Conversion. When using wireless technology for robot communication, human agents and external objects are impacted by the technological limitations in converting analog inputs into digital outputs. For instance, the conversion process can distort soft sounds in voice recognition (analog "hear" converted to digital "held"). Solution: Take advantage of conversions not significantly affected by technological limitations.
Alternate Solution: Poke the human agent's eyes out with a sharp stick, to mask the impact of the bandwidth limitations of wireless technology on the analog human visual input system.
ActiveX/COM and component software is widely misunderstood in the open source community, because many people don't know a thing about it, and just repeat what they've heard from dot-commercial propoganda campaigns, which spread as much hyperbolic misinformation as they can make up from their imaginations.
It's unfortunate that some people have to discredit the open source community by spreading misinformation instead of trying to learn the truth. You can't fight effectively against something you don't understand, especially if the lies you believe make you think it's much worse than it is.
You're repeating a bunch of common misconceptions about ActiveX that Netscape and Sun spread in their battle against Microsoft. Unfortunately, the foolish wing of the Open Source community worshiped anything Netscape and Sun said as gospel, because they believed that their enemy's enemy is their friend.
ActiveX is not tied to Windows. It runs just fine on the Mac, Unix and other platforms. I successfully used it on the Mac in 1996. Mozilla has an open source clone of COM/ActiveX called "XPCOM", which you're using right now if you're running Mozilla.
Your claim that "the [ActiveX] security is next to nonexistent" is false, and you're spreading misinformation, which does more harm than good to the open source community.
ActiveX certainly does have quite an elaborate security model. So does Java, but it's different. ActiveX lets you implement components in any language, even Java, so the capabilities of the ActiveX control depend on the language in which it's implemented. So there's another layer of security, that Java is lacking.
ActiveX controls implemented in C++ (like this implementation of pie menus can make Win32 calls, but by default the browser is set up to require user confirmation before running the control. ActiveX components can be packaged with cryptographically signed certificates, and the user can manage which certificates they trust, reject, accept, etc.
ActiveX controls implemented in JavaScript (like this implementation of pie menus are restricted to the safe capabilities of JavaScript running in the browser. Those can download and run without requiring confirmation from the user, just like any other JavaScript code or Java applet. So it's no less secure than Java and JavaScript.
Your opinion that open source makes component technology unnecessary is extremely naive, and simply wrong. Obviously you have never written a a portable program to the gnu specification with a configure script, or looked into how that sausage factory works. Are you actually proposing doing that stuff at run-time??!
If Sun had understood the problems that ActiveX/COM was addressing, instead of ignoring them on purpose, Java would have been much more useful: easier to integrate with code written in other languages, easier to use as a plug-in application scripting language, easier to switch between different VMs, easier to write native extensions. But Sun's goal is to lock you into using "100% Pure Java", so they weren't interested in solving those problems.
Sun has finally tried to solve some of these problems (with belated and questionable success), but that was only AFTER getting their ass kicked by Microsoft and their noses rubbed in their own filth. Not only did Microsoft's Java VM beat the pants off of Sun's, but it was also deeply integrated with COM, so you could write COM components in Java, and use COM components from Java.
Sun was broadsided by the deep level of integration that Microsoft achieved with their Java VM, because Sun never even bothered to learn about COM, nor did they want to address any of the problems that COM solved. That's why Sun pushes RMI instead of CORBA, and had to be dragged kicking and screaming to web services.
In a nutshell, the problem that COM solves is integrating components written in different langua
Actually, holding down the mouse button while dragging is difficult for many people and in many situations. People may have low coordination due to physical disability, age (young and old), or situation (using a computer in a moving car, or simply being distracted from concentrating 100% on the computer). It's generally easier to position the mouse when you're not holding a button down, because it requires less muscular tension.
You can more easily use pie menus by clicking them up (pressing and releasing the button in the same place, moving without holding the button down, then clicking again to select), as well as with quick press-drag-release gestures. Both click-up and drag methods allow you to reselect, correct errors and cancel during tracking, and move out further from the center to gain leverage and more precise control over the selection. Other forms of gesture recognition (like handwriting) which don't allow reselection, or require you to hold down the button during the gesture, are essentially more error prone and require more coordination to use successfully.
To bring it back to the topic of this discussion: I totally agree with Marc Andreessen that web browsing innovation is dead. But I disagree on the date that it died. However, I'm quite optimistic that innovation can be revived.
The necessary components are all in place: XML, web services, dynamic html, scripting languages, rich libraries of open source software components ready for the picking, plug-in component architectures, cheap consumer devices with lots of memory, processing power and pixels, a high speed worldwide network with gobs of bandwidth, ubiquitous wireless networking, yadda, yadda, yadda...
But everybody's still imitating the same old user interfaces designed in the 80's, which were drastically influenced by brutal constraints that simply do not apply any more. For years after the invention of the motion picture camera, they still used it to film plays on stage. We're still in that stage of user interface design, but it's finally beginning to change.
Component technology provides a way out of the dilema. It's too bad that Netscape failed on that front, while Microsoft has thrived. Netscape refused to support OLE/COM/ActiveX, yet they failed to provide a viable alternative. Mozilla actually uses its own cross platform version of "XPCOM" internally, yet it still doesn't support ActiveX components at the user level: Sun and Microsoft are't the only companies who sacrifice the needs of the users to the political dictates of the organization.
Sun's HotJava browser was an innovative step forward in the right direction. But instead of doing something cool like that, Netscape just changed the name of LiveScript to JavaScript in order to deceive consumers, and trotted out Java applets to play animations of dancing bears and juggling clowns. Netscape announced to great fanfair that they were now driving the Java bandwagon (to Sun's dismay), and that they were going to rewrite ther browser in 100% Pure Java, which would be much better than Internet Explorer. But they never did.
Apple's CyberDog browser was based on OpenDoc. It was the coolest demonstration of OpenDoc, that clearly justified component technology and illustrated the vast possibilities in a useful way. It was much more advanced than anything Microsoft could do with OLE.
Again, Netscape announced to great fanfair that they were going to support OpenDoc and all the wonderful lego-like features of CyberDog, which would be much better than ActiveX. But they never did.
Netscape steadfastly refused to support ActiveX because of their political beliefs, not based on the technology or the needs of the user. That might be forgivable had they ever provided a viable alternative, which they never did. Component technologies are not exclusive -- they could have supported ActiveX early on, while continuing to dabble in the art of developing their own alternatives.
Oh, Netscape certainly promised alternatives, but they never delivered. In all the time it took them to burn through their promises, what did they ever do to actually improve the user interface? All that stuff they never finished was eventually going to "enable" this wonderful new age of innovation, which we still haven't seen yet. And now we hear it's going to be another five years until anything new happens.
So I find it pretty amusing that Marc Andreessen would say that "There hasn't been any innovation on the browser in the last five years. And five years from now there won't be any changes".
This is the same guy who lost a fortune shorting the bubble, then went long just as it popped. I'd take it as a strong indication that wonderful innovations in the browser are just around the corner!
I guess mouse gestures will be there with IE 6.5 or IE 7.0.. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.
Opera was not the first browser with gestures.
HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.
Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX).
Here's a streaming quicktime demo of ActiveX pie menus.
Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.
Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).
Here is the
JavaScript Pie Menus web page, with links to examples, documentation, etc.
But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!
That dilemma dones't apply to pie menus.
Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.
Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.
The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.
Slashdot Mirror
-Don
-Don
PS: To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.
Here's a picture of MIT-MC, including the Decwriter console and a VT52. I think the box to the right of the VT52 is the 10/11 interface.
http://catalog.com/hopkins/images/mc-console.jpg
The only pictures I have of rms's house (which burnt down), are of Devon climbing up a tree to the roof:
http://catalog.com/hopkins/images/devon-climbing.j pg
p g
http://catalog.com/hopkins/images/devon-landing.j
And of course, here's a picture of RMS asking, "I don't know, why do you wrap a gerbil in duct tape?":
http://catalog.com/hopkins/images/jsol-rms-gerbil- liz-mg.jpg
On the left is JSOL, and the two people on the right are Liz and MG (who RMS branded an "Evil Software Hoarder" for developing Gosling's Emacs at UniPress.)
RMS is quick on his feet, and can be hillariously funny, unless you make the mistake of being offended. MG ran into RMS at a science fiction convention, and asked him "I heard there was a rumor about you house burning down." RMS snapped back "That's true, but where you work, I think you would have heard about it in advance."
-Don
Tilting Operations for Small Screen Interfaces (Tech Note)p df
By Jun Rekimoto, Sony Computer Science Laboratory, Inc. www.csl.sony.co.jp/person/rekimoto/papers/uist96.
HTML version from google:
http://216.239.53.104/search?q=cache:xf0Rxikgk34J: www.csl.sony.co.jp/person/rekimoto/papers/uist96.p df+tilt+pie+menu&hl=en&ie=UTF-8
-Don
Now what are you talking about how the Gameboy emulator written in C and Assembler proves that Java runs fast on cell phones?
-Don
http://www.wildpalm.co.uk/GoBoy/GoBoy7650_12_src.z ip
It looks to me like it's written in C, not Java. So how does that support your argument that Java on cell phones isn't slow?
Since you're such a big Java fan, why don't you port the Gameboy emulator to Java, and find out first hand how fast it runs and how much memory it requires? Please report back -- it will be very interesting to know how much bigger and slower the Gameboy emulator is, after being rewritten from C to Java. Good luck!
-Don
Implementing special purpose scripting languages with XML is a great idea, and works quite well. What is GSL? And what do you REALLY think about it? -Don
Pie menus enable multiple functions on a single touch-screen button, so you can not only touch, but also stroke up, down left or right. They're fast, reliable and easy to use with your finger instead of a pen, and with only one hand. You get much more functionality out of the same amount of screen space, so the resulting remote control interfaces are less cluttered and more functional.
You can touch the pause button and stroke down to stop, touch the program description and stroke up to switch to the channel, stroke left and right to page to the previous and next programs, stroke down to link to the index, etc.
I'm currently developing a ConnectedTV skin editor, that will let you create your own remote control interfaces with custom buttons and graphics, program them with any IR command, and bake your own pie menus.
The skin editor isn't available yet, but I'm interested in hearing from people who would like to beta test it, and who have opinions about what it should do. I'm especially interested in hearing from Pronto users: not only is ConnectedTV much cheaper than Pronto because runs on your existing Palm, but it also has useful features like the pie menus and the personalized TV guide, integrated with a universal remote control. So you can take your Palm with you wherever you go (like the kitchen, bathroom, school or work), and browse the ConnectedTV guide any time you want.
A free two week trial of ConnectedTV for the Palm is available at Connected.TV.
-Don
As long as they stop promoting Motif, I will be happy. Print it out and burn it.
-Don
DDR (Deutsche Democratic Republic) was the name of East Germany during the time it was a Communist, non-democratic non-republic, which was as ironic as the Open Group calling themselves an open group.
To bring it into the present: It's as ironic as George Bush announcing he's finally going to pay attention to military intelligence, instead of fabricating his own.
-Don
And who do you think wrote tha AC post in the first place? He says he did. Why don't you believe him -- did you write it?
-Don
There's a damn good reason that the widely held opinion of people who know both languages, is that Python is much easier to read and maintain than Perl. I've known Perl since 1989, and program extensively in Python. When did you learn Perl, and how much Python code have you written?
If you could be convinced that Python was easier to read than Perl, would you use it instead? I bet not, because Perl zeallots use Perl for all the wrong reasons, and they actually enjoy its flaws.
Can you explain your reasons for believing Perl is easier to learn and read than Python? It's simply not true, so such a belief must be based on an unspoken fallacy. Does it have something to do with your job security? Are you afraid that if your code is readable, you will be more easily replaced? That's the main reason Perl is so popular, but Perl programmers hate it when people point that out. They worship and revel in the arcane syntax, thinking it makes them more manly.
You may be very manly and irreplacable in your job because you use Perl, but there's no way you could possibly make the argument that Perl is easier to read than Python. Go ahead, try!
-Don
Water uses an extended XML syntax called "Concise XML", that's compatible but more general and concise than XML. Here's the description of Concise XML from the Water web site. They discuss some interesting observations and the rationale behind Concise XML in the "The Trouble with XML article. And here is a chapter of the Water book describing ConciseXML.
What is ConciseXML?
ConciseXML(TM) is a language-independent markup syntax compatible with XML 1.0, but designed to handle every type of data including non-hierarchial data, program logic, document markup, and binary data. ConciseXML is both concise and precise, eliminating two major limitations of XML and extending the use of XML.
Features of ConciseXML
Conciseness
Many people avoid XML in many circumstances because of its verbosity. ConciseXML is as concise at representing logic as the "semi-colon" syntax of C/C++/Java/C#. ConciseXML can also be as concise as the Comma Separated Value (CSV) syntax for data.
Precision
ConciseXML has no ambiguity of meaning. There is only one way to represent parts/fields of an object. This stands in contrast to XML where there can be many syntactic forms for the identical meaning or semantics.
XML Compatibility
Is ConciseXML compatible with XML?
ConciseXML maintains both forward-compatibility as well as backward-compatibility with XML. Any XML document is also a valid ConciseXML document. Any ConciseXML document can be represented in XML without any loss of information. For each ConciseXML extension to XML, there is a corresponding form in XML. A ConciseXML expression or document can mix and match ConciseXML and XML syntax at all levels.
ConciseXML Extends XML
ConciseXML makes XML more flexible by eliminating many of the constraints of XML. Here are some examples.
Attribute values can be any expression
Example: <input size=3/> or <person birth=<date 2002 10 2/>/>
XML requires that all attributes values are quoted. That effectively requires that all values are of type string. Elements are often used to work around this limitation, but that presents another set of problems. Attribute keys can be non-strings
Example: <thing 0="foo" 1="bar"/>
XML does not let an attribute key start with a digit. That effectively prevents integers from being attribute keys. ConciseXML makes it possible to easily represent array-like fields with integer keys.
Tagname of an element can be any expression
Example: <foo.bar/>
XML Namespaces are a step in this direction, but ConciseXML makes it possible to have any expression as the tagname of an element.
Attribute keys are optional
Example: <date 2002 month=10 day=28/>
In the CSV (Comma Separated Value) syntax and in all major programming languages, field or argument values are given by position, not by keyword.
Closing tagname is optional
Not only does this remove unnecessary clutter, but when ConciseXML is used as the syntax for dynamic languages, the tagname may not be known until runtime, and therefore the closing tagname must be optional.
[...]
Zope's DTML is a pain in the ass, and the xml page templates are lame and bizarre. What I would really love, would be an elegent xml based and fully functional web templating and programming language like Water, implemented in open source Python, embedded in an interactive dynamic object publishing content management web server framework like Zope (but simpler).
If you're interested in language design, definitely read the white papers like the Water Rationale on the Water web site. They're to the point, brilliantly written, and hit the nail on the head.
-Don
[Interesting excerpts from http://www.waterlang.org/doc/water_rationale.htm]:
Water Rationale
Fry, May 2002
Overview
Water is a language for the web that embodies the three primary functionalities needed for general purpose information manipulation into one unified language:
- Code: Water is a general purpose object oriented programming language that is, at its core, more flexible than Javascript, Visual Basic and Java.
- Data: Water permits the description of persistent structured data on the web via an XML syntax yet having the capability of computing values that may contain self-referencial interconnections.
- Markup: Since Water is a superset of HTML, it inherits all of HTML's capabilities.
The syntax of Water is a superset of HTML, or, more properly, a superset of XML. HTML has proven to be an easily understandable markup language since it has been learned by millions of people in the several years that the web has existed. XML is a standard for putting structured data on the web. Water extends the syntax of XML to make a language less cumbersome to write code in. Water provides a way to define functions and call them in addition to defining and instantiating objects. The object system is a multiple-inheritance, prototype-based object system with annotations. This will be described below, but for now it's sufficient to say that it is more powerful yet simpler than the class-instance object systems currently in vogue in languages such as Java and C++.
[...]
We Need Another Language Like A Hole in the Head
Right now the plethora of languages on the web causes more than headaches. New ones seem to be born monthly. Having to learn two or more to get a task done is more than twice as hard as one language because the interface between the languages is always additional hair which is, more often than not, poorly documented.
Why do we have HTML, XML, Java, Javascript, C++, Visual Basic, VRML, XSLT, PHP, etc? Because none of them are flexible enough to give programmers the functionality they need in building a modern Web application. Looking within the scope of what each of the above intends to cover, we often find serious flaws. But when we try to move outside of that scope, say doing markup in Java, we have a full-fledged disaster on our hands.
We do not need a new language for implementing some specialized functionality. Sooner or later that specialized functionality will need general purpose utilities like condi
Unless the security product allows untrusted users to enter and execute Python code, then there's no contradiction in using Python to develop a secure application. Security isn't something that springs from the programming language itself -- it depends on what you do with the language. Security is largely a social issue, which is why it was a good call to remove the "rexec" module for the reasons Guido stated.
The idea of adding "data tainting" to Python or any other language is a misguided attempt to force the programming language to guarentee a kind of security that you can only get by designing, implementing and debugging your program properly. No programming language can protect against lazyness or stupidity, and it's misguided to try to provide a false sense of security at the linguistic level.
-Don
Ada's a much better programming language for destroying Microsoft than Java, because Ada has built-in support for cutting off heads all the time without even thinking about it, instead of silly promises about "write once run anywhere" and those totally homosexual inner classes!
-Don
Indentation without brackets makes block nesting much more readable and obvious, than brackets without indentation.
Perl code is fundamentally unreadable, and readable Perl code is the extremely rare exception to the rule. Perl does nothing to encourage people to write good code -- just the opposite. But Python supports and encourages clean maintainable readable code.
Most vociferous Perl advocates are sadly monolinguistic (they aren't proficient with any other languages), or else they would realize how horrible Perl is in comparison, and how much time and effort they're needlessly wasting. Monolinguestic Perl programmers are usually quite polylinguaphobic (afraid of learning new languages like Python), because Perl was so hard to learn, and they assume out of ignorance that all languages are just as compex, messy and hard to learn and maintain as Perl.
Like the Senator from South Carolina argued against bilingual education: If English was good enough for Jesus, then it's good enough for the students of our state.
-Don
-Don
It's unfortunate that some people have to discredit the open source community by spreading misinformation instead of trying to learn the truth. You can't fight effectively against something you don't understand, especially if the lies you believe make you think it's much worse than it is.
You're repeating a bunch of common misconceptions about ActiveX that Netscape and Sun spread in their battle against Microsoft. Unfortunately, the foolish wing of the Open Source community worshiped anything Netscape and Sun said as gospel, because they believed that their enemy's enemy is their friend.
ActiveX is not tied to Windows. It runs just fine on the Mac, Unix and other platforms. I successfully used it on the Mac in 1996. Mozilla has an open source clone of COM/ActiveX called "XPCOM", which you're using right now if you're running Mozilla.
Your claim that "the [ActiveX] security is next to nonexistent" is false, and you're spreading misinformation, which does more harm than good to the open source community.
ActiveX certainly does have quite an elaborate security model. So does Java, but it's different. ActiveX lets you implement components in any language, even Java, so the capabilities of the ActiveX control depend on the language in which it's implemented. So there's another layer of security, that Java is lacking.
ActiveX controls implemented in C++ (like this implementation of pie menus can make Win32 calls, but by default the browser is set up to require user confirmation before running the control. ActiveX components can be packaged with cryptographically signed certificates, and the user can manage which certificates they trust, reject, accept, etc.
ActiveX controls implemented in JavaScript (like this implementation of pie menus are restricted to the safe capabilities of JavaScript running in the browser. Those can download and run without requiring confirmation from the user, just like any other JavaScript code or Java applet. So it's no less secure than Java and JavaScript.
Your opinion that open source makes component technology unnecessary is extremely naive, and simply wrong. Obviously you have never written a a portable program to the gnu specification with a configure script, or looked into how that sausage factory works. Are you actually proposing doing that stuff at run-time??!
If Sun had understood the problems that ActiveX/COM was addressing, instead of ignoring them on purpose, Java would have been much more useful: easier to integrate with code written in other languages, easier to use as a plug-in application scripting language, easier to switch between different VMs, easier to write native extensions. But Sun's goal is to lock you into using "100% Pure Java", so they weren't interested in solving those problems.
Sun has finally tried to solve some of these problems (with belated and questionable success), but that was only AFTER getting their ass kicked by Microsoft and their noses rubbed in their own filth. Not only did Microsoft's Java VM beat the pants off of Sun's, but it was also deeply integrated with COM, so you could write COM components in Java, and use COM components from Java.
Sun was broadsided by the deep level of integration that Microsoft achieved with their Java VM, because Sun never even bothered to learn about COM, nor did they want to address any of the problems that COM solved. That's why Sun pushes RMI instead of CORBA, and had to be dragged kicking and screaming to web services.
In a nutshell, the problem that COM solves is integrating components written in different langua
You can more easily use pie menus by clicking them up (pressing and releasing the button in the same place, moving without holding the button down, then clicking again to select), as well as with quick press-drag-release gestures. Both click-up and drag methods allow you to reselect, correct errors and cancel during tracking, and move out further from the center to gain leverage and more precise control over the selection. Other forms of gesture recognition (like handwriting) which don't allow reselection, or require you to hold down the button during the gesture, are essentially more error prone and require more coordination to use successfully.
-Don
The necessary components are all in place: XML, web services, dynamic html, scripting languages, rich libraries of open source software components ready for the picking, plug-in component architectures, cheap consumer devices with lots of memory, processing power and pixels, a high speed worldwide network with gobs of bandwidth, ubiquitous wireless networking, yadda, yadda, yadda...
But everybody's still imitating the same old user interfaces designed in the 80's, which were drastically influenced by brutal constraints that simply do not apply any more. For years after the invention of the motion picture camera, they still used it to film plays on stage. We're still in that stage of user interface design, but it's finally beginning to change.
Component technology provides a way out of the dilema. It's too bad that Netscape failed on that front, while Microsoft has thrived. Netscape refused to support OLE/COM/ActiveX, yet they failed to provide a viable alternative. Mozilla actually uses its own cross platform version of "XPCOM" internally, yet it still doesn't support ActiveX components at the user level: Sun and Microsoft are't the only companies who sacrifice the needs of the users to the political dictates of the organization.
Sun's HotJava browser was an innovative step forward in the right direction. But instead of doing something cool like that, Netscape just changed the name of LiveScript to JavaScript in order to deceive consumers, and trotted out Java applets to play animations of dancing bears and juggling clowns. Netscape announced to great fanfair that they were now driving the Java bandwagon (to Sun's dismay), and that they were going to rewrite ther browser in 100% Pure Java, which would be much better than Internet Explorer. But they never did.
Apple's CyberDog browser was based on OpenDoc. It was the coolest demonstration of OpenDoc, that clearly justified component technology and illustrated the vast possibilities in a useful way. It was much more advanced than anything Microsoft could do with OLE.
Again, Netscape announced to great fanfair that they were going to support OpenDoc and all the wonderful lego-like features of CyberDog, which would be much better than ActiveX. But they never did.
Netscape steadfastly refused to support ActiveX because of their political beliefs, not based on the technology or the needs of the user. That might be forgivable had they ever provided a viable alternative, which they never did. Component technologies are not exclusive -- they could have supported ActiveX early on, while continuing to dabble in the art of developing their own alternatives.
Oh, Netscape certainly promised alternatives, but they never delivered. In all the time it took them to burn through their promises, what did they ever do to actually improve the user interface? All that stuff they never finished was eventually going to "enable" this wonderful new age of innovation, which we still haven't seen yet. And now we hear it's going to be another five years until anything new happens.
So I find it pretty amusing that Marc Andreessen would say that "There hasn't been any innovation on the browser in the last five years. And five years from now there won't be any changes".
This is the same guy who lost a fortune shorting the bubble, then went long just as it popped. I'd take it as a strong indication that wonderful innovations in the browser are just around the corner!
-Don
Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.
Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.
Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).
Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.
That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.
Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.
The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.
When using a handwr
-Don