Ship it with Squeak

Marcel Weiher 320089961391-0001 at t-online.de
Wed Jun 28 10:33:17 UTC 2000


> From: Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se>
>
> To make real progress, everyone should be thinking much longer, on  
a much
> higher level. HTML (and everything else about the web) is/will be  
the MS-DOS
> of the next two decades--it will dominate, will not be abandoned  
so that
> huge efforts will be spent on compatibility backwards, it will  
represent the
> worst possible solution to the problems it addresses, and hold  
back progress
> to an immense degree. XML (et al)? Jeez, it's just one of the  
first hacks to
> remedy these things, within the original boundaries.

Sorry, I disagree vehemently with this rant, er, analysis.  HTML is  
an *excellent* solution to the problem it address, because it is so  
simple that it actually works (put that last clause in bold, italic,  
caps, with three underlines and exclamation marks).  Mind you, it is  
not a good solution for some of the things people are forcing it to  
do, like precise layout -> ouch!

XML is the only hope for reprieve from the tyranny of proprietary,  
opaque and fragile data formats.  It also makes heterogenous  
interoperability a real possibility, by making it *easy*.   
Furthermore, it combines the worlds of UNIX (everything is a text  
file) and objects (everything is an object).  Each world brings with  
it a very powerful and composable abstractions, but so far they've  
had a heck of time dealing with each other.  It also has the power to  
free us from the grip of (relational) databases for structured data,  
by both being a viable alternative and interoperable.

> > I think Squeak is a little
> > more powerful than JavaScript ... Also, Squeak always has "authoring 
> > turned on" so it opens vistas of "SuperSwikis" of active media that 
> > can be added to, etc.

There is no doubt (at least in my mind) that Squeak is more powerful  
than JavaScript.  However, that becomes irrelevant if the  
specification says JavaScript.  A Squeak script that won't be  
executed is of limited usefulness.  Of course, I personally think  
JavaScript is a curse, because most of the things it 'dynamicizes' do  
not gain by being dynamic.  Most information does just fine in a  
static representation, and I don't need dancing paper-clips to cheer  
me up...

> > .... and there are a variety of ways to deal with the existing web 
> > conventions.
>
> HTML, XML, JavaScript, DHTML, BLAHABLAHATML, yadda yadda yadda.  
The best way
> to predict the future is to ignore them :)

Ignore HTML and especially XML only at your own peril!

> The advent of the web and these dinosaur technologies is a disaster.

It is a democratic upheaval with some blood-letting.

>  Ten years ago we were using our computers to do productive work.
>  Now we're back to making them work again.

Sorry, the only difference I see is that nowadays designers think  
they want to know what all that is, because it is "cool".

> Then, courses would teach people Quark XPress and
> then about kerning, typefaces, point sizes, ligatures, and so on--real 
> useful skills and knowledge for graphic designers.

Quark XPress is not a useful skill.  I consider Quark a part of the  
problem set, not the solution.  Proprietary file-format, vendor  
lock-in, monolithic, buggy apps, silly "plug-in" architectures that  
are just another mechanism for vendor lock-in etc.

Now if there were a vendor-independent, usable language for  
specifying layout, typography and design...and no, neither TeX nor  
Postscript fit the bill.  Maybe you could even create an XML-based  
language for that purpose, though I don't think the FO-part of XSL is  
really what's needed either.  Of course, if it is XML-based, you'd  
probably want an equivalent more human-accessible version as well.

>  Today they're having to
> teach them Unix file system syntax and image representation  
formats so that
> people can put images in their documents, which used to be done by  
cut &
> paste back then.

What's stopping them from using GUI HTML builders with cut-paste  
image placement for their HTML work?  Why didn't they hand-code  
Postscript before?  Answer: because hand-coding Postscript is so much  
more difficult than hand-coding HTML that they never would have  
dared.  You're comparing apples with oranges.

> It's essentially a counterrevolution of the techies.

Partly.  Geeky/techie things have suddenly become "cool", so "cool"  
people try to do stuff that they really have no clue about when there  
are better ways to accomplish the same thing (for example letting a  
real techie do it in 1/10th the time).

> Notice that Linux, the great "new" thing formerly known as Unix,  
is 30+ years old,

Yes, I am also somewhat underwhelmed by Linux, though if that's what  
it takes to spread an at least partially decent OS, oh well...

> HTML is a much poorer version of the 35 years old SGML,

This is actually incorrect.  HTML is an application of SGML, not a  
"poorer version", exactly the sort of thing SGML was invented for.

> To make real progress the existing stuff needs to be abandoned--so this 
> won't happen. Backward compatibility is the best way to hinder genuine 
> progress.

Numb-minded backwards compatiblity, yes.  Standards are a way of  
achieving *compatibility* instead of *backwards compatibility*.   
Open, extensible standards like XML (and many of the languages that  
have been defined with XML) allow you to use the standard for those  
>90% of things that don't require more, and still do what you want by  
extending where necessary, in a controlled fashion.

This is vastly different from closed backwards compatibility  
enforced by MS-DOS or Java "industry standards".  These typically  
preclude innovation.

> Watching the tape of what Engelbart had on a real, working system  
in '68,
> makes you cry a few tears, seeing things that won't be in real use  
in the
> next 10 or 20 years, easily.

Well, let's get to work on it, although I have to admit that I  
myself am closer to Sketchpad...

Marcel





More information about the Squeak-dev mailing list