Stop repeating the same old knee-jerk diatribes you've heard the other kids yelling, without checking your facts first. Complaining about Flash because ads annoy you is like complaining about water because squirt guns annoy you. Flash and water have a lot more uses than simply annoying you.
Flash is excellent for developing rich web applications, which are entirely different than home page "flash intros" that you want a button to skip, or flying hamburgers that pop up on top of yahoo's home page.
By "rich web application", I mean the entire interactive client side of the application runs in the Flash player. Well written Flash based applications are high quality, responsive, uniform across platforms, and much better than anything that is possible with html/ajax.
There are several different approaches to writing Flash based rich web applications. The worst proprietary way is using Macromedia's Flash tool. The most expensive and legally restricted way is using Macromedia's Flex server. The best and free way is using OpenLaszlo, which is open source, and IBM's Laszlo IDE for Eclipse, which is also open source.
It would be interesting to compare Macromedia/Adobe's Zorn Eclipse plug-in, with IBM's Laszlo Eclipse plug-in. I wonder who better understands how to write plug-in IDE's for Eclipse: IBM or Macromedia/Adobe? And who better understands Open Source software?
Macromedia's Flex is a knock-off of Laszlo, which was developed earlier and is more mature, and open source. So now Macromedia's doing a knock-off of IBM's Eclipse plug-in for Laszlo.
Does Macromedia actually think they're going to convince open source developers to use Flex, by throwing out an Eclipse plug-in, while still charging $20,000 per cpu for the Flex server software?
IBM and Laszlo are a lot more serious about Open Source and Eclipse than Macromedia/Adobe.
Is Macromedia making Flex open source, or are they just making a tool for creating Flex applications open source? What good is a free tool, if the server software it requires costs tens of thousands of dollars per cpu?
The opportunistic business suit Jim Clark should never be confused with the XML god James Clark, who has helped forge many useful standards, and written tons of excellent open source code implementing those standards. His venerable "expat" xml parser is at the core of many important products and open source software projects.
...Although it's fair to say that Bill Joy's "csh" language did have a strong influence on the Perl programming language. But I've never heard him claim credit for that.
To clear up an ambiguity in my comment: Bill Joy tried to take credit for Java. Bill Joy doesn't deserve credit for Java. Of course Bill Joy also doesn't deserve credit for the language first called LiveScript then renamed JavaScript either, but he never tried to take credit for that, he just endorsed it after it was renamed.
Bill Joy does however deserve full credit for the "csh" shell scripting language, which, as languages go, is a horribly designed total piece of shit, chock full of gaping security holes, and dripping with syntactic syrup if ipecac. Fortunately he didn't manage to get any of his original ideas from "csh" into Java.
The following announcement was made 6 a.m. PST Monday, December 4, 1995.
Key points of this release are:
* Sun and Netscape announce JavaScript, an object-oriented
scripting language based on the Java programming language.
[THAT IS A LIE: JavaScript is NOT based on Java. They are quite different, especially when you consider their object models, which are as different as day and night, and quite incompatible.]
* 28 leading technology companies endorse JavaScript, including
Oracle, Sybase, Digital Equipment, H-P and IBM.
* JavaScript is aimed at making it easier for non-programmers
to create web pages that employ Java applets, without having to
learn how to program in Java. This is expected to bring a new
level of interactivity and multimedia capabilities to the Internet
and corporate Intranets.
* Netscape and Sun plan to submit JavaScript to industry
consortiums as a proposed open standard.
[But not Java!]
NETSCAPE AND SUN ANNOUNCE JAVASCRIPT(TM), THE OPEN,
CROSS-PLATFORM OBJECT SCRIPTING LANGUAGE FOR ENTERPRISE
NETWORKS AND THE INTERNET
28 Industry-Leading Companies Have Expressed Their Endorsement of
JavaScript(TM) As A Complement To Java(TM)
For Easy Online Application Development
MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape Communications
Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today
announced [the fact that Netscape renamed their pre-existing language called "LiveScript" that had nothing to do with Java to the misleading name] JavaScript(TM), an open, cross-platform object scripting language
for the creation and customization of applications on enterprise networks
and the Internet. The JavaScript language complements [but otherwise has nothing in common with] Java(TM), Sun's
industry-leading object-oriented, cross-platform programming language. The
initial version of JavaScript is available now as part of the beta version
of Netscape Navigator(TM) 2.0, which is currently available for downloading
from Netscape's web site.
In addition, 28 industry-leading companies, including America Online, Inc.,
Apple Computer, Inc., Architext Software, Attachmate Corporation, AT&T,
Borland International, Brio Technology, Inc., Computer Associates, Inc.,
Digital Equipment Corporation, Hewlett-Packard Company, Iconovex
Corporation, Illustra Information Technologies, Inc., Informix Software,
Inc., Intuit, Inc., Macromedia, Metrowerks, Inc., Novell, Inc., Oracle
Corporation, Paper Software, Inc., Precept Software, Inc., RAD
Technologies, Inc., The Santa Cruz Operation, Inc., Silicon Graphics, Inc.,
Spider Technologies, Sybase, Inc., Toshiba Corporation, Verity, Inc., and
Vermeer Technologies, Inc., have expressed their endorsement of JavaScript
as an open standard object scripting language and intend to provide it
in future products. The draft specification of JavaScript, as well as
the final draft specification of Java, is planned for publishing and
submission to appropriate standards bodies for industry review and
comment this month.
[But Sun will never make Java an open standard, despite this promise.]
JavaScript is an easy-to-use object scripting language designed for
creating live online applications that link together objects and resources
on both clients and servers. While Java is used by programmers to create
new objects and applets [and has nothing to do with JavaScript], JavaScript is designed for use by HTML page
authors and enterprise application developers to dynamically script the
behavior of objects running on either the client or the server. JavaScript
is analogous to Visual Basic in that it can be used by people with little
or no programming experience to quickly construct complex applications.
JavaScript's design represents the next generation of software designed
specifically for the Internet and is:
Netscape and Apple Announce Plans to Develop Netscape Navigator for
Apple's Cyberdog
Netscape To Support Apple's OpenDoc, Cyberdog Technologies; Apple Chooses
Netscape Navigator for Cyberdog
MOUNTAIN VIEW, Calif., CUPERTINO, Calif.--Aug. 27, 1996--Apple Computer,
Inc. and Netscape Communications Corporation today announced that they
have signed an agreement for Netscape to develop a new version of
Netscape Navigator that supports Cyberdog, Apple's Internet suite, and
OpenDoc, the open component architecture. To be called Netscape Navigator
for Cyberdog, Netscape will develop a custom component developed
specifically for the Apple Cyberdog Internet suite.
In addition, Apple will distribute Netscape Navigator for Cyberdog with
its Mac OS, as the default browsing component for Cyberdog. Apple's plans
also call for the product to be incorporated with the Mac OS in Apple
computers.
"With this agreement, Netscape has demonstrated the strength of its
support for Apple's Cyberdog Internet suite and the industry-standard
OpenDoc component architecture," said Larry Tesler, vice president of
Apple's AppleNet division. "With Cyberdog and other initiatives, Apple
has been incorporating Internet access directly into the OS and Macintosh
applications, so that Internet access is user-content and experience
driven, rather than accessible only through stand-alone browsers."
"Today's announcement that Apple and Netscape will work together to offer
Netscape Navigator for Cyberdog, and plans for its future incorporation
into the Mac OS and other OpenDoc-compatible applications, will provide
users a leading Internet client that is optimized for the Macintosh
environment," said Mike Homer, senior vice president of marketing at
Netscape. "Macintosh users will be able to leverage both the advantages
of an easy-to-use environment and the leading-edge features of Netscape
Navigator."
Cyberdog: Incorporating Internet Access into the OS
Cyberdog is a full-featured Internet/intranet suite of products with a
common look and feel. With Cyberdog, one application can be used to
access information on the Internet, intranet and local area AppleTalk or
AppleShare networks. Cyberdog also includes many built-in data-types such
as for GIF and JPEG files and QuickTime movies.
Cyberdog, one application can be used to access information on the
Internet, intranet and local area AppleTalk or AppleShare networks.
Cyberdog also includes many built-in data-types such as for GIF and JPEG
files and QuickTime movies.
Cyberdog is tightly integrated with the Mac OS. For example, a user can
take a Cyberitem (an icon that represents a universal resource locator,
or URL) in the web browser and drag it to the Finder. This Cyberitem can
then be used to access that particular resource directly from the
desktop. Independent developers can extend Cyberdog by building their own
OpenDoc components.
Netscape Navigator for Cyberdog will allow users to embed browsing
capabilities in other OpenDoc-compatible applications. For example, using
an OpenDoc-supported word processor such as ClarisWorks or Corel's
WordPerfect, a computer user would be able to incorporate live links to
web sites that would provide continuously updated information. In
addition, Netscape Navigator for Cyberdog will be customized to work with
the Cyberdog suite, providing seamless integration through features and
look and feel.
OpenDoc
OpenDoc is a multiplatform, component software architecture that enables
developers to evolve current applications into component software or to
create new component software applications. OpenDoc software will run on
the Mac OS, as well as Windows, Windows NT, OS/2 and AIX systems. With
software enabled by OpenDoc, users will be able
The cooperation between Netscape and Sun to rewrite Navigator in Java was frustrated by the same problem as the cooperation between Novel and Sun: the notorious "Butthead Factor" of Sun engineers.
This is one of the documents recently unsealed in the legal case between Sun Microsystems Inc. and Microsoft Corp. over whether Microsoft behaved in an anti-competitive fashion in its handling of Java.
From: Charles Fitzgerald
Sent: Thursday, July 03, 1997 6:01 PM
To: Bill Gates; Paul Maritz; Jim Allchin; Bob Muglia
Cc: Russ Arun; David Cole; John Ludwig
Subject: Novell and Java
"[...] Needless to say, we asked why they were talking to us. They claim to be frustrated with the JavaSoft's lack of speed, resource limits and the "butthead factor" of their engineers. [...]"
Flex (which is tied to Flash) is a cool product and a great idea, but what inspired it? OpenLaszlo
is a high level JavaScript/XML based language for programming "AJAXian" rich web applications that "just happen to" run on the Flash player.
Laszlo used to cost about ten thousand dollars per license, but it is now fully open source and free. Flex costs more than ten thousand dollars per server license, and has restrictions on how you can modify and redistribute Flex components.
Macromedia has a spotty track record supporting their server software over the long haul, and now that Adobe's bought them, Flex is in Flux.
Laszlo is here to stay because it's available now, free and open source, and you're not restricted in how you can modify and reuse Laszlo and its components.
Flex is a lot like Laszlo, because Flex is Macromedia's imitation of Laszlo, but Flex is intended to lock you into Flash instead of giving you independence from it.
The most important difference between Laszlo and Flex, is that Laszlo is not tied to Flash, it "just happens to" use it right now, because that's the most practical target platform at this point in history. Laszlo is a high level JavaScript/XML based language which currently targets the Flash player as its initial platform, with more to come.
Laszlo abstracts away Flash dependencies, so it will target other runtimes than Flash in the future, as they mature and shake out: Java (Rhino/Java2D), C# (CLR, GDI+, Avalon), C++ (SpiderMonkey, CGI+, Quartz, Cairo, AGL), SVG (Adobe, Batik, Firefox), DHTML (web browsers, JavaScript, AJAX).
But right now Flash rules, and Laszlo is the best way to develop rich web applications that run on Flash.
One really interesting possible target platform for Laslo is an open source Flash player, that can easily be integrated into applications and games, and uses OpenGL with hardware accellerated rendering.
AJAX is not a new idea. Here's what we were doing with NeWS, 17 years ago... Substitute "JavaScript" for "PostScript", "web server" for "NeWS client", "web browser" for "NeWS server". Sound familiar?
The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).
As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.
-Don
Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS
[...]
NeWS has extensions to the PostScript language that allow for programs
(light weight processes), running in the display server, to receive input
events on behalf of NeWS clients (other programs running on the same
computer, or at some remote site). They may process input locally (on the
same machine and in the same process where the events are happening),
without consuming any communications bandwidth. This is a big advantage,
if you want fast, responsive graphical feedback.
NeWS processes can
communicate with each other by manipulating shared data structures, and by
sending messages through the event queue. They can receive low level input
events ("The left mouse button was released at location (X,Y) in window W
at time T"), and give graphical feedback ("erase the old slider, redraw it
at its new position, and fill the border with bright red"). They can
translate input from the user into high level, application specific
events, which are sent to the client ("set the volume of the CD player to
100%"). NeWS processes can run autonomously in the server, without a
connection to a client, providing "desk accessories" such as a calculator,
event journaling, menus, and control panels.
According to the fellow from Adobe who talked at the PostScript BOF at
the X conference, Adobe's Display PostScript provides output
capabilities, but has no facilities for receiving input directly from
of the X event queue. As I understand his explanation, the X server
must send X events over the IPC link (network, shared memory, modem,
or whatever) to the client, which must then translate the events into
PostScript commands, and send them back over the link to be executed
by Display PostScript. Because there is no way for PostScript programs
to read events off of the X event queue, the client must process input
events behalf of the display server. Messages must go on a round trip,
from the X server, to the client, and back to the Display PostScript
extension in the server, to produce any graphical output on the
screen.
[...]
The NeWS "Lite" user interface toolkit is written entirely in PostScript.
Menus, buttons, windows, sliders, scroll bars, and even terminal
emulators, are implemented as device independent PostScript programs, in
NeWS's object oriented PostScript programming environment. Since the
toolkit can run in the server, clients can share the same
code, and a copy of the toolkit does not have to be linked into each
client. It's easy to mod
Here's a summary that I wrote up of Will Wright's Spore demo, which he gave at the Game Developers Conference:
The Future of Content
What I learned about content from the Sims. ...and why it's driven me to procedural methods. ...And what I now plan to do with them.
Will Wright
Game Developers Conference
3/11/2005 http://www.donhopkins.com/home/WillWrightSporeDemo.html
"Advice: If you have a weird idea that's so outside of the box, don't forget it. You should go back and revisit your weird ideas later, because you can never know where they might lead to." -Will Wright
Here's a summary that I wrote up of Will Wright's Spore demo, which he gave at the Game Developers Conference:
The Future of Content
What I learned about content from the Sims. ...and why it's driven me to procedural methods. ...And what I now plan to do with them.
Will Wright
Game Developers Conference
3/11/2005 http://www.donhopkins.com/home/WillWrightSporeDemo.html
"Advice: If you have a weird idea that's so outside of the box, don't forget it. You should go back and revisit your weird ideas later, because you can never know where they might lead to." -Will Wright
Methodology of Window Systems is a great book. It had an article by James Gosling and David Rosenthal, about a PostScript based window system they wrote called SunDew, which was eventually named NeWS.
Subject: The Worst Job in the World
From: Michael Tiemann <tiemann@cygnus.com>
I have a friend who has to have the worst job in the world: he is a Unix system administrator. But it's worse than that, as I will soon tell.
Being a Unix system administrator is like being a tech in a biological warfare laboratory, except that none of the substances are labeled consistently, any of the compounds are just as likely to kill you by themselves as they are when mixed with one another, and it is never clear what distinction is made between a catastrophic failure in the lab and a successful test in the field.
But I don't want to tell you about biological warfare, I want to tell you about what makes my friend's job so terrible. First, some context.
The training for Unix system administration is a frightening process. When machines start dying, users start screaming, and everything grinds to a halt, the novice feels the cold fingers of terror clutching about his heart.
#!/bin/sh
# this doesn't work, but no time to fix it -- hope nothing crashes
progname=$0
But if one stays the course, one might some day achieve the dubious satisfaction of being able to mutter "at least I know why it broke!".
#!/bin/sh
# This works...I wonder if it will get me laid
progname="[jibber jabber omited due to slashdot junk filters, and rightly so]"
But there are many who must dwell in this miasma both day and night. What makes my friend's job so ugly is that he doesn't only work with just any strain of Unix -- he works with Solaris. And he doesn't just deal with just any braindead users -- his users are the executives at Sun Microsystems.
Let me tell you about Sun Microsystems. At Sun, there's a long history of executives playing pranks on one another. For April Fools, these rowdies would play tricks like putting a golf course (complete with putting green) in Scott McNealy's office, or floating Bill Joy's Ferrari in one of the landscaped ponds. Things have come a long way since then. Now every day is April Fools, and my friend doesn't like it one bit.
VP: "Admin!! What the fuck is this thing running on my machine?"
Admin: "It's Solaris, sir."
VP: "Get it off of my machine at once!"
Admin: "But sir, Ed Zander told me that you should be running Solaris now."
VP: "Zander, huh? I'll fix him. Is he running Solaris?"
Admin: "No sir."
VP: "Why not?"
Admin: "If he ran Solaris, he wouldn't be able to get any work done."
VP: "Very well, restore my machine to SunOS, and put this Solaris crap on Zander's machine."
Admin: "But sir..."
VP: "That's an order! And tell him Scott gave you the directive himself!"
Admin: "Yes, sir."
[later...]
Zander: "Admin!! What the fuck is this thing running on my machine?"
Admin: "It's Solaris, sir."
Zander: "Get it off of my machine at once!"
Admin: "But sir, Scott McNealy told me that you should be running Solaris now."
Zander: "McNealy, huh? I'll fix him. Is he running Solaris?"
August 1996 Press Release
WASHINGTON -- Psychoanalytic theory holds that trekphobia -- the fear, anxiety, anger, discomfort and aversion that some ostensibly sciencefictional people hold for Star Trek -- is the result of repressed Trekkie urges that the person is either unaware of or denies. A study appearing in the August 1996 issue of the Journal of Abnormal Psychology, published by the American Star Trek Association (ASTA), provides new empirical evidence that is consistent with that theory.
Researchers at the University of Georgia conducted an experiment involving 35 trekphobic men and 29 nontrekphobic men as measured by the Index of Trekphobia scale. All the participants selected for the study described themselves as exclusively sciencefictional both in terms of sexual arousal and experience.
Each participant was exposed to trekually explicit episodic stimuli consisting of Sciencefictional, male Treksexual, Next Generational, Klingon S&M, Vulcan Tantra, and Star Wars Oriented videotapes (but not necessarily in that order). Their degree of Trekual arousal was measured by penile plethysmography, which precisely measures and records male tumescence.
Men in both groups were aroused by about the same degree by the video depicting Next Generational sexual behavior and by the video showing two Klingons engaged in sexual behavior. The only significant difference in degree of arousal between the two groups occurred when they viewed the video depicting Kirk/Spock treksexual sex: 'The Trekphobic men showed a significant increase in penile circumference to the Kirk/Spock treksexual video, but the control [nontrekphobic] men did not.'
Broken down further, the measurements showed that while 66% of the nontrekphobic group showed no significant tumescence while watching the Kirk/Spock treksexual video, only 20% of the trekphobic men showed little or no evidence of arousal. Similarly, while 24% of the nontrekphobic men showed definite tumescence while watching the Klingon S&M video, 54% of the trekphobic men did.
When asked to give their own subjective assessment of the degree to which they were aroused by watching each of the three videos, men in both groups gave answers that tracked fairly closely with the results of the objective physiological measurement, with one exception: the trekphobic men significantly underestimated their degree of arousal by the Kirk/Spock treksexual video.
Do these findings mean, then, that trekphobia in men is a reaction to repressed treksexual urges, as psychoanalysis theorizes? While their findings are consistent with that theory, the authors note that there is another, competing theoretical explanation: cancelation anxiety. According to this theory, viewing the Kirk/Spock treksexual videotape may have caused negative emotions (such as cancelation anxiety) in the trekphobic men, but not in the nontrekphobic men. As the authors note, 'anxiety has been shown to enhance arousal and erection,' and so it is also possible that 'a response to treksexual stimuli [in these men] is a function of the threat condition rather than sexual arousal per se. These competing notions can and should be evaluated by future research.'
Article: 'Is Trekphobia Associated With Trekkie Arousal?' by Henry E. Adams, Ph.D., Lester W. Wright, Jr., Ph.D. and Bethany A. Lohr, University of Georgia, in Journal of Abnormal Psychology, Vol. 105, No. 3, pp 440-445.
The American Star Trek Association (ASTA), in Washington,DC, is the largest scientific and professional organization representing trekkies in the United States and is the world's largest association of geeks. ASTA's membership includes more than 142,000 virgins, dweebs, mama's boys, pear shaped fans, Klingon speakers and costumers. Through its divisions in 49 subfields of Trekology and affiliations with 58 state and Canadian provincial associations, ASTA works to advance Star Trek as a science, as a profession and as a means of promoting human welfare, splitting infinitives, and bravely going where no man has gone before.
"I swear I've heard of people who quit their jobs and moved just so they could live in a city that wasn't full of Homophobic Mor(m)ons like Orson Scott Card running the place."
The XSLT approach would work fine, transforming XML into Laszlo programs or XML data that Laszlo programs read and write. But it's even easier to express the logic in Laszlo directly, instead of using XSLT.
XSLT is a weak, clumsy language, not intended for expressing complex logic. It's not object oriented and it's hard to reuse templates or create program with high level abstractions, using XSLT. It's certainly been abused to build extremely complex systems mish-mashed with Perl and Java to perform the high level logic, but there are simpler approaches that work better than XSLT.
Laszlo reads and writes XML directly, and JavaScript is much more powerful and easier to program than XSLT. Most imporantly, Laszlo has built-in xpath data binding and constraints, which automatically map back and forth between the XML data and the Laszlo views.
It's much easier to program XML views and editors with Laszlo's constraints and data binding, than with XSLT or all that model/view/controller nonsense. There's no need to write a special purpose controller for each view, thanks to Laszlo's automatically maintained constraints, and point-to-point event system, which are more powerful and general purpose than MVC. Declarative programming with constraints is easy to understand, write and maintain.
You describe the views by writing XML object prototypes with JavaScript expressions and methods. You can use constraint expressions and xpath expressions to transform and bind live XML to your view attributes, and write prototypes for sub-objects which are automatically instantiated according to the content and shape of the XML data.
Instead writing an imperative loop over the XML sub-elements via DOM, you just declare a prototype of what one element should look like (which can have recursive sub-elements, to create trees). You can bind the view attributes to the XML model -- it's two-way binding, supporting multiple views! You can attach methods to handle events and specialize the behavior of each instance. Laszlo automatically replicates and binds as many views of the appropraite type as necessary, to represent the XML data. It supports lazy replication, so you can scroll over large datasets without creating more views than are visible.
XML is the model. The replication manager automatically creates views of the appropriate class, whose instance variables are two-way bindings to the XML data itself. So when the user changes the value of a text field that's viewing a string from an xml attribute, it directly edits the xml attribute, automatically causing all other views and constraints depending on that attribute to update.
Programming in Laszlo is like having a simpler, more powerful, more general purpose approach to model/view/controller built into the language. You don't have to write a bunch of special purpose code to implement each of your models (xml data) and controllers (the Laszlo runtime), so you can focus on programming interactive views of XML data in Laszlo.
Laszlo ships with a full set of standard user interface widgets, including the gui controls you'd expect and require for building full featured desktop applications. And they actually look nice and scale properly because they're skinned with Flash graphics.
But Laszlo goes far beyond ordinary form based applications, because it's ideal for implementing rich animated feedback for "direct manipulation" user interfaces, and interactive data driven Information Visualization.
Adobe's SVG viewer supports inline SVG in Internet Explorer (but not Firefox/Mozilla). It uses the "Binary Behaviors" ActiveX plug-in interfaces. It participates in the browser page rendering process like an ordinary html element, and you can use namespaces to embed SVG elements inline with html on the web page.
That's the same way Microsoft's VML elements work, which is just another Binary Behavior plug-in bundled with the browser. Basically you make a binary ActiveX object and give it an ID, then you declare a namespace to be associated with that id, which binds all elements in that namespace to be handled by the ActiveX object. It's a generic way to extend the web browser with ActiveX controls.
Mozilla also has a plug-in interface, but it doesn't provide the kind of inline rendering features that Internet Explorer's Binary Behaviors support.
When Adobe developed their SVG plug-in, they took advantage of some of the "advanced" Mozilla plug-in interfaces, to support their JavaScript integration (not inline rendering). But between Mozilla 0.99 and Mozilla 1.0, those plug-in interfaces changed, in a way that actually broke Adobe's SVG viewer in Mozilla. After Mozilla 1.0 shipped, any page that used even the simplest standard SVG would actually crash Mozilla.
Mozilla 1.0 crashing with Adobe's SVG plug-in was the first nail in SVG's coffin, and Adobe buying Macromedia was the last.
Slashdot Mirror
A spreadsheet with 3 columns? Oooooh nooooo! But my spreadsheet only has 2 colums. What am I to do? I want to be like you!
Don't you mean X-Windows? Get it right.
-Don
-Don
Flash is excellent for developing rich web applications, which are entirely different than home page "flash intros" that you want a button to skip, or flying hamburgers that pop up on top of yahoo's home page.
By "rich web application", I mean the entire interactive client side of the application runs in the Flash player. Well written Flash based applications are high quality, responsive, uniform across platforms, and much better than anything that is possible with html/ajax.
There are several different approaches to writing Flash based rich web applications. The worst proprietary way is using Macromedia's Flash tool. The most expensive and legally restricted way is using Macromedia's Flex server. The best and free way is using OpenLaszlo, which is open source, and IBM's Laszlo IDE for Eclipse, which is also open source.
It would be interesting to compare Macromedia/Adobe's Zorn Eclipse plug-in, with IBM's Laszlo Eclipse plug-in. I wonder who better understands how to write plug-in IDE's for Eclipse: IBM or Macromedia/Adobe? And who better understands Open Source software?
-Don
IBM already released an open source Eclipse plugin for developing Laszlo applications, on November 18, 2004. Laszlo is open source, and so is the Eclipse tool for developing Laszlo applications.
Does Macromedia actually think they're going to convince open source developers to use Flex, by throwing out an Eclipse plug-in, while still charging $20,000 per cpu for the Flex server software?
IBM and Laszlo are a lot more serious about Open Source and Eclipse than Macromedia/Adobe.
-Don
-Don
-Don
-Don
Bill Joy does however deserve full credit for the "csh" shell scripting language, which, as languages go, is a horribly designed total piece of shit, chock full of gaping security holes, and dripping with syntactic syrup if ipecac. Fortunately he didn't manage to get any of his original ideas from "csh" into Java.
-Don
The following announcement was made 6 a.m. PST Monday, December 4, 1995.
Key points of this release are:
* Sun and Netscape announce JavaScript, an object-oriented scripting language based on the Java programming language. [THAT IS A LIE: JavaScript is NOT based on Java. They are quite different, especially when you consider their object models, which are as different as day and night, and quite incompatible.]
* 28 leading technology companies endorse JavaScript, including Oracle, Sybase, Digital Equipment, H-P and IBM.
* JavaScript is aimed at making it easier for non-programmers to create web pages that employ Java applets, without having to learn how to program in Java. This is expected to bring a new level of interactivity and multimedia capabilities to the Internet and corporate Intranets.
* Netscape and Sun plan to submit JavaScript to industry consortiums as a proposed open standard. [But not Java!]
NETSCAPE AND SUN ANNOUNCE JAVASCRIPT(TM), THE OPEN, CROSS-PLATFORM OBJECT SCRIPTING LANGUAGE FOR ENTERPRISE NETWORKS AND THE INTERNET
28 Industry-Leading Companies Have Expressed Their Endorsement of JavaScript(TM) As A Complement To Java(TM) For Easy Online Application Development
MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape Communications Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today announced [the fact that Netscape renamed their pre-existing language called "LiveScript" that had nothing to do with Java to the misleading name] JavaScript(TM), an open, cross-platform object scripting language for the creation and customization of applications on enterprise networks and the Internet. The JavaScript language complements [but otherwise has nothing in common with] Java(TM), Sun's industry-leading object-oriented, cross-platform programming language. The initial version of JavaScript is available now as part of the beta version of Netscape Navigator(TM) 2.0, which is currently available for downloading from Netscape's web site.
In addition, 28 industry-leading companies, including America Online, Inc., Apple Computer, Inc., Architext Software, Attachmate Corporation, AT&T, Borland International, Brio Technology, Inc., Computer Associates, Inc., Digital Equipment Corporation, Hewlett-Packard Company, Iconovex Corporation, Illustra Information Technologies, Inc., Informix Software, Inc., Intuit, Inc., Macromedia, Metrowerks, Inc., Novell, Inc., Oracle Corporation, Paper Software, Inc., Precept Software, Inc., RAD Technologies, Inc., The Santa Cruz Operation, Inc., Silicon Graphics, Inc., Spider Technologies, Sybase, Inc., Toshiba Corporation, Verity, Inc., and Vermeer Technologies, Inc., have expressed their endorsement of JavaScript as an open standard object scripting language and intend to provide it in future products. The draft specification of JavaScript, as well as the final draft specification of Java, is planned for publishing and submission to appropriate standards bodies for industry review and comment this month. [But Sun will never make Java an open standard, despite this promise.]
JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets [and has nothing to do with JavaScript], JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server. JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications. JavaScript's design represents the next generation of software designed specifically for the Internet and is:
Netscape and Apple Announce Plans to Develop Netscape Navigator for Apple's Cyberdog
Netscape To Support Apple's OpenDoc, Cyberdog Technologies; Apple Chooses Netscape Navigator for Cyberdog
MOUNTAIN VIEW, Calif., CUPERTINO, Calif.--Aug. 27, 1996--Apple Computer, Inc. and Netscape Communications Corporation today announced that they have signed an agreement for Netscape to develop a new version of Netscape Navigator that supports Cyberdog, Apple's Internet suite, and OpenDoc, the open component architecture. To be called Netscape Navigator for Cyberdog, Netscape will develop a custom component developed specifically for the Apple Cyberdog Internet suite.
In addition, Apple will distribute Netscape Navigator for Cyberdog with its Mac OS, as the default browsing component for Cyberdog. Apple's plans also call for the product to be incorporated with the Mac OS in Apple computers.
"With this agreement, Netscape has demonstrated the strength of its support for Apple's Cyberdog Internet suite and the industry-standard OpenDoc component architecture," said Larry Tesler, vice president of Apple's AppleNet division. "With Cyberdog and other initiatives, Apple has been incorporating Internet access directly into the OS and Macintosh applications, so that Internet access is user-content and experience driven, rather than accessible only through stand-alone browsers."
"Today's announcement that Apple and Netscape will work together to offer Netscape Navigator for Cyberdog, and plans for its future incorporation into the Mac OS and other OpenDoc-compatible applications, will provide users a leading Internet client that is optimized for the Macintosh environment," said Mike Homer, senior vice president of marketing at Netscape. "Macintosh users will be able to leverage both the advantages of an easy-to-use environment and the leading-edge features of Netscape Navigator."
Cyberdog: Incorporating Internet Access into the OS
Cyberdog is a full-featured Internet/intranet suite of products with a common look and feel. With Cyberdog, one application can be used to access information on the Internet, intranet and local area AppleTalk or AppleShare networks. Cyberdog also includes many built-in data-types such as for GIF and JPEG files and QuickTime movies.
Cyberdog, one application can be used to access information on the Internet, intranet and local area AppleTalk or AppleShare networks. Cyberdog also includes many built-in data-types such as for GIF and JPEG files and QuickTime movies.
Cyberdog is tightly integrated with the Mac OS. For example, a user can take a Cyberitem (an icon that represents a universal resource locator, or URL) in the web browser and drag it to the Finder. This Cyberitem can then be used to access that particular resource directly from the desktop. Independent developers can extend Cyberdog by building their own OpenDoc components.
Netscape Navigator for Cyberdog will allow users to embed browsing capabilities in other OpenDoc-compatible applications. For example, using an OpenDoc-supported word processor such as ClarisWorks or Corel's WordPerfect, a computer user would be able to incorporate live links to web sites that would provide continuously updated information. In addition, Netscape Navigator for Cyberdog will be customized to work with the Cyberdog suite, providing seamless integration through features and look and feel.
OpenDoc
OpenDoc is a multiplatform, component software architecture that enables developers to evolve current applications into component software or to create new component software applications. OpenDoc software will run on the Mac OS, as well as Windows, Windows NT, OS/2 and AIX systems. With software enabled by OpenDoc, users will be able
E-mail from Microsoft's Charles Fitzgerald to MS execs on Novell/MS Java meeting
This is one of the documents recently unsealed in the legal case between Sun Microsystems Inc. and Microsoft Corp. over whether Microsoft behaved in an anti-competitive fashion in its handling of Java.
From: Charles Fitzgerald
Sent: Thursday, July 03, 1997 6:01 PM
To: Bill Gates; Paul Maritz; Jim Allchin; Bob Muglia
Cc: Russ Arun; David Cole; John Ludwig
Subject: Novell and Java
"[...] Needless to say, we asked why they were talking to us. They claim to be frustrated with the JavaSoft's lack of speed, resource limits and the "butthead factor" of their engineers. [...]"
Laszlo used to cost about ten thousand dollars per license, but it is now fully open source and free. Flex costs more than ten thousand dollars per server license, and has restrictions on how you can modify and redistribute Flex components.
Macromedia has a spotty track record supporting their server software over the long haul, and now that Adobe's bought them, Flex is in Flux. Laszlo is here to stay because it's available now, free and open source, and you're not restricted in how you can modify and reuse Laszlo and its components.
Flex is a lot like Laszlo, because Flex is Macromedia's imitation of Laszlo, but Flex is intended to lock you into Flash instead of giving you independence from it.
The most important difference between Laszlo and Flex, is that Laszlo is not tied to Flash, it "just happens to" use it right now, because that's the most practical target platform at this point in history. Laszlo is a high level JavaScript/XML based language which currently targets the Flash player as its initial platform, with more to come.
Laszlo abstracts away Flash dependencies, so it will target other runtimes than Flash in the future, as they mature and shake out: Java (Rhino/Java2D), C# (CLR, GDI+, Avalon), C++ (SpiderMonkey, CGI+, Quartz, Cairo, AGL), SVG (Adobe, Batik, Firefox), DHTML (web browsers, JavaScript, AJAX).
But right now Flash rules, and Laszlo is the best way to develop rich web applications that run on Flash.
One really interesting possible target platform for Laslo is an open source Flash player, that can easily be integrated into applications and games, and uses OpenGL with hardware accellerated rendering.
-Don
The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).
As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.
-Don
Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS
[...]
NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback.
NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels.
According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen.
[...]
The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to mod
-Don
Oops, sorry for repeating the message. I kept getting network errors each time I posted it, so I had to try several times until it worked (twice).
The Future of Content
...and why it's driven me to procedural methods.
...And what I now plan to do with them. o .html
What I learned about content from the Sims.
Will Wright
Game Developers Conference
3/11/2005
http://www.donhopkins.com/home/WillWrightSporeDem
"Advice: If you have a weird idea that's so outside of the box, don't forget it. You should go back and revisit your weird ideas later, because you can never know where they might lead to." -Will Wright
-Don
The Future of Content
...and why it's driven me to procedural methods.
...And what I now plan to do with them. o .html
What I learned about content from the Sims.
Will Wright
Game Developers Conference
3/11/2005
http://www.donhopkins.com/home/WillWrightSporeDem
"Advice: If you have a weird idea that's so outside of the box, don't forget it. You should go back and revisit your weird ideas later, because you can never know where they might lead to." -Will Wright
-Don
-Don
From: Michael Tiemann <tiemann@cygnus.com>
I have a friend who has to have the worst job in the world: he is a Unix system administrator. But it's worse than that, as I will soon tell. Being a Unix system administrator is like being a tech in a biological warfare laboratory, except that none of the substances are labeled consistently, any of the compounds are just as likely to kill you by themselves as they are when mixed with one another, and it is never clear what distinction is made between a catastrophic failure in the lab and a successful test in the field.
But I don't want to tell you about biological warfare, I want to tell you about what makes my friend's job so terrible. First, some context.
The training for Unix system administration is a frightening process. When machines start dying, users start screaming, and everything grinds to a halt, the novice feels the cold fingers of terror clutching about his heart.
#!/bin/sh
# this doesn't work, but no time to fix it -- hope nothing crashes
progname=$0
But if one stays the course, one might some day achieve the dubious satisfaction of being able to mutter "at least I know why it broke!".
#!/bin/sh
# This works...I wonder if it will get me laid
progname="[jibber jabber omited due to slashdot junk filters, and rightly so]"
But there are many who must dwell in this miasma both day and night. What makes my friend's job so ugly is that he doesn't only work with just any strain of Unix -- he works with Solaris. And he doesn't just deal with just any braindead users -- his users are the executives at Sun Microsystems.
Let me tell you about Sun Microsystems. At Sun, there's a long history of executives playing pranks on one another. For April Fools, these rowdies would play tricks like putting a golf course (complete with putting green) in Scott McNealy's office, or floating Bill Joy's Ferrari in one of the landscaped ponds. Things have come a long way since then. Now every day is April Fools, and my friend doesn't like it one bit.
VP: "Admin!! What the fuck is this thing running on my machine?"
Admin: "It's Solaris, sir."
VP: "Get it off of my machine at once!"
Admin: "But sir, Ed Zander told me that you should be running Solaris now."
VP: "Zander, huh? I'll fix him. Is he running Solaris?"
Admin: "No sir."
VP: "Why not?"
Admin: "If he ran Solaris, he wouldn't be able to get any work done."
VP: "Very well, restore my machine to SunOS, and put this Solaris crap on Zander's machine."
Admin: "But sir..."
VP: "That's an order! And tell him Scott gave you the directive himself!"
Admin: "Yes, sir."
[later...]
Zander: "Admin!! What the fuck is this thing running on my machine?"
Admin: "It's Solaris, sir."
Zander: "Get it off of my machine at once!"
Admin: "But sir, Scott McNealy told me that you should be running Solaris now."
Zander: "McNealy, huh? I'll fix him. Is he running Solaris?"
August 1996 Press Release WASHINGTON -- Psychoanalytic theory holds that trekphobia -- the fear, anxiety, anger, discomfort and aversion that some ostensibly sciencefictional people hold for Star Trek -- is the result of repressed Trekkie urges that the person is either unaware of or denies. A study appearing in the August 1996 issue of the Journal of Abnormal Psychology, published by the American Star Trek Association (ASTA), provides new empirical evidence that is consistent with that theory.
Researchers at the University of Georgia conducted an experiment involving 35 trekphobic men and 29 nontrekphobic men as measured by the Index of Trekphobia scale. All the participants selected for the study described themselves as exclusively sciencefictional both in terms of sexual arousal and experience. Each participant was exposed to trekually explicit episodic stimuli consisting of Sciencefictional, male Treksexual, Next Generational, Klingon S&M, Vulcan Tantra, and Star Wars Oriented videotapes (but not necessarily in that order). Their degree of Trekual arousal was measured by penile plethysmography, which precisely measures and records male tumescence.
Men in both groups were aroused by about the same degree by the video depicting Next Generational sexual behavior and by the video showing two Klingons engaged in sexual behavior. The only significant difference in degree of arousal between the two groups occurred when they viewed the video depicting Kirk/Spock treksexual sex: 'The Trekphobic men showed a significant increase in penile circumference to the Kirk/Spock treksexual video, but the control [nontrekphobic] men did not.'
Broken down further, the measurements showed that while 66% of the nontrekphobic group showed no significant tumescence while watching the Kirk/Spock treksexual video, only 20% of the trekphobic men showed little or no evidence of arousal. Similarly, while 24% of the nontrekphobic men showed definite tumescence while watching the Klingon S&M video, 54% of the trekphobic men did.
When asked to give their own subjective assessment of the degree to which they were aroused by watching each of the three videos, men in both groups gave answers that tracked fairly closely with the results of the objective physiological measurement, with one exception: the trekphobic men significantly underestimated their degree of arousal by the Kirk/Spock treksexual video.
Do these findings mean, then, that trekphobia in men is a reaction to repressed treksexual urges, as psychoanalysis theorizes? While their findings are consistent with that theory, the authors note that there is another, competing theoretical explanation: cancelation anxiety. According to this theory, viewing the Kirk/Spock treksexual videotape may have caused negative emotions (such as cancelation anxiety) in the trekphobic men, but not in the nontrekphobic men. As the authors note, 'anxiety has been shown to enhance arousal and erection,' and so it is also possible that 'a response to treksexual stimuli [in these men] is a function of the threat condition rather than sexual arousal per se. These competing notions can and should be evaluated by future research.'
Article: 'Is Trekphobia Associated With Trekkie Arousal?' by Henry E. Adams, Ph.D., Lester W. Wright, Jr., Ph.D. and Bethany A. Lohr, University of Georgia, in Journal of Abnormal Psychology, Vol. 105, No. 3, pp 440-445.
The American Star Trek Association (ASTA), in Washington,DC, is the largest scientific and professional organization representing trekkies in the United States and is the world's largest association of geeks. ASTA's membership includes more than 142,000 virgins, dweebs, mama's boys, pear shaped fans, Klingon speakers and costumers. Through its divisions in 49 subfields of Trekology and affiliations with 58 state and Canadian provincial associations, ASTA works to advance Star Trek as a science, as a profession and as a means of promoting human welfare, splitting infinitives, and bravely going where no man has gone before.
"I swear I've heard of people who quit their jobs and moved just so they could live in a city that wasn't full of Homophobic Mor(m)ons like Orson Scott Card running the place."
XSLT is a weak, clumsy language, not intended for expressing complex logic. It's not object oriented and it's hard to reuse templates or create program with high level abstractions, using XSLT. It's certainly been abused to build extremely complex systems mish-mashed with Perl and Java to perform the high level logic, but there are simpler approaches that work better than XSLT.
Laszlo reads and writes XML directly, and JavaScript is much more powerful and easier to program than XSLT. Most imporantly, Laszlo has built-in xpath data binding and constraints, which automatically map back and forth between the XML data and the Laszlo views.
It's much easier to program XML views and editors with Laszlo's constraints and data binding, than with XSLT or all that model/view/controller nonsense. There's no need to write a special purpose controller for each view, thanks to Laszlo's automatically maintained constraints, and point-to-point event system, which are more powerful and general purpose than MVC. Declarative programming with constraints is easy to understand, write and maintain.
You describe the views by writing XML object prototypes with JavaScript expressions and methods. You can use constraint expressions and xpath expressions to transform and bind live XML to your view attributes, and write prototypes for sub-objects which are automatically instantiated according to the content and shape of the XML data.
Instead writing an imperative loop over the XML sub-elements via DOM, you just declare a prototype of what one element should look like (which can have recursive sub-elements, to create trees). You can bind the view attributes to the XML model -- it's two-way binding, supporting multiple views! You can attach methods to handle events and specialize the behavior of each instance. Laszlo automatically replicates and binds as many views of the appropraite type as necessary, to represent the XML data. It supports lazy replication, so you can scroll over large datasets without creating more views than are visible.
XML is the model. The replication manager automatically creates views of the appropriate class, whose instance variables are two-way bindings to the XML data itself. So when the user changes the value of a text field that's viewing a string from an xml attribute, it directly edits the xml attribute, automatically causing all other views and constraints depending on that attribute to update.
Programming in Laszlo is like having a simpler, more powerful, more general purpose approach to model/view/controller built into the language. You don't have to write a bunch of special purpose code to implement each of your models (xml data) and controllers (the Laszlo runtime), so you can focus on programming interactive views of XML data in Laszlo.
Laszlo ships with a full set of standard user interface widgets, including the gui controls you'd expect and require for building full featured desktop applications. And they actually look nice and scale properly because they're skinned with Flash graphics.
But Laszlo goes far beyond ordinary form based applications, because it's ideal for implementing rich animated feedback for "direct manipulation" user interfaces, and interactive data driven Information Visualization.
-Don
Oops -- I pasted the wrong url into the link. Here is the right link to Inline SVG in Internet Explorer with Adobe SVG.
Adobe's SVG viewer supports inline SVG in Internet Explorer (but not Firefox/Mozilla). It uses the "Binary Behaviors" ActiveX plug-in interfaces. It participates in the browser page rendering process like an ordinary html element, and you can use namespaces to embed SVG elements inline with html on the web page.
That's the same way Microsoft's VML elements work, which is just another Binary Behavior plug-in bundled with the browser. Basically you make a binary ActiveX object and give it an ID, then you declare a namespace to be associated with that id, which binds all elements in that namespace to be handled by the ActiveX object. It's a generic way to extend the web browser with ActiveX controls.
Mozilla also has a plug-in interface, but it doesn't provide the kind of inline rendering features that Internet Explorer's Binary Behaviors support.
When Adobe developed their SVG plug-in, they took advantage of some of the "advanced" Mozilla plug-in interfaces, to support their JavaScript integration (not inline rendering). But between Mozilla 0.99 and Mozilla 1.0, those plug-in interfaces changed, in a way that actually broke Adobe's SVG viewer in Mozilla. After Mozilla 1.0 shipped, any page that used even the simplest standard SVG would actually crash Mozilla.
Mozilla 1.0 crashing with Adobe's SVG plug-in was the first nail in SVG's coffin, and Adobe buying Macromedia was the last.
-Don