A NEW PARADIGM FOR SMALLTALK - Geeks beware 
Author Message
 A NEW PARADIGM FOR SMALLTALK - Geeks beware

Richard A. O'Keefe wrote in the squeak email list:

    XML is fairly optimized for humans to be able to type it on the fly,
    but it still has lots of fiddly little rules.

He *must* be kidding.  SGML had lots of support for human-writability,
but it was all stripped out to make XML.  The goal for XML is machine
readability, and the MathML specification openly confesses that MathML
is too verbose and error-prone for people to write.

Hi,

Just ignore the complexities of XML and go for the simplicities. Your
support matters.

<this_is_a_simple_tag with_an_attribute="thevalue">
        <this_is_a_tag_without_an_attribute>
                But with text sub item
        </<this_is_a_tag_without_an_attribute>
</this_is_a_simple_tag>

If you use the simple version of XML you'll gain in the long run. Only
computer geeks use complex systems that normal people can't understand.
DTDs or Document Type Defintions which define what tags are permitted are
ok but they add complexity that's beyond normal human comprehension they
suck. Use tags that are dynamic and create software that's flexible in
understanding tags rather than imposing structure on people - this lets
people impose structure on software. The end user rules the wasteland of
software. The user is king not the programmer. Sorry to destroy your
illusions. Refocuse your attention on the user. XML is powerful for it's
dynamic flexiblity. The mistake in XML is the DTD's and other complexities.
Gravitate to the simplicities. Life will be harder but more rewarding for
programmers when you support you human users in the objectives that they
wish to solve. Why are you here? What do you hear from your users? That
they want complex systems? Or that they want simple systems? Smalltalk is
too complex. Simplify it? How? Anyway that you can. Java is winning the
war? Smalltalk is dead? Not a chance. But it is dead if we don't simplify
and create a system that people - I mean real people, and not just you and
I techies - can use. Real people. Simple people. People who buy and use
Windoze systems. They are the real mass computer users out there. If you
want Smalltalk to succeed then you must begin to address their concerns and
reduce the complexity by at least 10 times - maybe even 100 times. Are you
up to it? I doubt that it's possible for computer scientists or computer
geeks to create a system that normal, everyday joe and janes can use
effectively and program effortlessly. What is wrong with smalltalk? Why do
you live with what's wrong. Change it now. My biggest pet peeve is the
image. What a horrible single user notion the image is. It locks us into a
cage with oursleves. Almost like a prision. Yes a prision. You can't escape
it until you tear down the wall just like the east and west germans did a
few years back. Save your self from the machine guns of the image that
Smalltalk systems propagate. What a horrible idea the image is. It prevents
sharing of objects. Objects are just memory creatures not shared object
database creatures. No current or self respecting Smalltalk product would
name itself smallltalk in the light of collaborative technologies and
object databases unless it DOES NOT use an image. All object data MUST be
stored in a "conncurrent object database" that is shared amoung Smalltalk
systems. Each smalltalk system should be a RAM cache of objects from a
shared object database. All objects should exist only in the shared object
data base system. RAM is just a cache of objects from the data base. The
image should no longer exist. The collection hierarchy is a systemic
example of why smalltalk is too complex. There are 10+ collection classes.
This is way too many. How about one that the user can configure to their
needs. How about higher level objects. Lets give users the systems that the
original creator of smalltalk intended. A simple system that even 10 year
olds can program. Smalltalk as it stands is 30+ years of legacy. Some of
this legacy is relevant today. What parts are relevant to you? What parts
are relevant to the average Joe or Jane in the streets? Or in business?
Smalltalk, like Java junk, C++ binary toung, C machine language, C# (shape)
microbrain crap, and other languages directed at "computer geeks" are
missing the point. The point, as I understand it from Alan Kay's and Doug
Englebart's orginal messages, is to create systems that the average person
- as in non-propeller head - human being can use to program to do their
bidding. Smalltalk as it stands is a dead language - just like C++ and Java
junk - because it requires people who use it to learn too much computer
science. Ten years ago I taught a 40+ year computer veterian Smalltalk in
30 daze - days - and he said "wow, Smalltalk let me do 90% engineering
(civil) and only 10% computer science - this is amazing, I love Smalltalk".
The problem is that he had to do 10% computer science instead of 1%.

Lets eliminate the propeller head requirement from Smalltalk so that
Smalltalk can evolve with millions and millions of common simple folk
users.

More info at http://www.*-*-*.com/ .

I will enjoy responding to any who wish to express their support or
dissent. The best way to have me respond to your message is to email me at

All the best in your life and computing experience,

Peter William Lount, Smalltalk.org Future Generator

http://www.*-*-*.com/
http://www.*-*-*.com/



Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware

Quote:

> More info at http://www.zoku.com.

Uhh... I didn't find any. Lots of inspirational quotes, and a fair bit
of ranting, but precious little information.

Quote:
> Peter William Lount

                                      Steve


Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware

Quote:
>If you use the simple version of XML you'll gain in the long run.

Yes.

Quote:
> The mistake in XML is the DTD's and other complexities.

Exactly!

Quote:
>Ten years ago I taught a 40+ year computer veterian Smalltalk in
>30 daze - days - and he said "wow, Smalltalk let me do 90% engineering
>(civil) and only 10% computer science - this is amazing, I love Smalltalk".
>The problem is that he had to do 10% computer science instead of 1%.

Yes!

How do we do it?  Well, my idea is by having a soft gradient between pure
application and "canned" objects and fully flexible programmable objects.

Start with a green square.  Let the user specify that the color can be
green, red or orange.  Wow, their first "live" object!  Let her specify
that the color of that part over there should be the same as that other
part over there.  Wow, action at a distance, a 'smart' object.  More
complex relationships can also be expressed without any procedural
code, but if those don't suffice, allow code to be used.

That way, 'programming' is motivated by need and introduced gently.
You can do a lot without looking under the hood, but if you do
look, it won't bite you.

Quote:
>More info at http://www.zoku.com.

Interesting.  Looks like maybe too much complex infrastructure.

Marcel
--

Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
                                          - Alan Kay -



Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware

Quote:
>What is wrong with smalltalk? Why do
>you live with what's wrong. Change it now. My biggest pet peeve is the
>image. What a horrible single user notion the image is. It locks us into a
>cage with oursleves. Almost like a prision. Yes a prision. You can't escape
>it until you tear down the wall just like the east and west germans did a
>few years back. Save your self from the machine guns of the image that
>Smalltalk systems propagate. What a horrible idea the image is.

I agree with you here.  The ideal implementation is to have the vm connect
to an object database to retrieve sourcecode, bytecode, cached machine code,
configuration maps -- everything.

Quote:
> It prevents sharing of objects.

This is what I'm confused about.  How so?  Can you elaborate?  While I agree
the image is a horrible idea, I find that there are work-arounds to the
concept, and it doesn't prevent you from building a close to ideal system
using an oodb, fully supporting the sharing of objects.

Ian



Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware
The image was a wonderful idea in 1980, and it is still a pretty good
one.  After having used it for 20 years, we understand its weaknesses
and want something better.  Neverthless, it is silly to say that the
image is a horrible idea.

-Ralph



Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware

Quote:

>The image was a wonderful idea in 1980, and it is still a pretty good
>one.  After having used it for 20 years, we understand its weaknesses
>and want something better.  Neverthless, it is silly to say that the
>image is a horrible idea.

Actually the concept of an image isn't really that bad of an idea.. It's how
it's usually used in Smalltalk implementations which is such a real shame.
Such a very simple change could have made it so much better..  This is why
it's practically horrible.

IMO, how it should have been done, is that the image should be a state
cache, instead of something where the state in the image is something
mutable and conrolled by the developer.  For example, an implementation
could be made such that you could simply delete your image, and then upon
startup initializers would be run which would generate the state required
for the frameworks.  In this way, you are separating or not allowing
changeable persistent state to dictate the behavior of the application.  In
such a way, the image is just a convenient cache of state, which is
immutable.

This is important, because we all know that having subtle changes in state
can have a drastic effect on application behavior, and it's difficult to
ensure that the state you have is the correct state required.

Of course, modular Smalltalk's, where you have the concepts of dynamically
loading IC's, parcels, etc..  Go a fair ways to help remedy this problem.

Ian



Wed, 18 Jun 1902 08:00:00 GMT  
 A NEW PARADIGM FOR SMALLTALK - Geeks beware
Well, better here than continuing on the Squeak list :)


[snip Richard O'Keefe's telling point that XML was designed to be simple
for machines & tools, not human writers (or readers)]

Quote:
> Just ignore the complexities of XML and go for the simplicities. Your
> support matters.

> <this_is_a_simple_tag with_an_attribute="thevalue">
>       <this_is_a_tag_without_an_attribute>
>               But with text sub item
>       </<this_is_a_tag_without_an_attribute>
> </this_is_a_simple_tag>

*This* is simple? Ok. We have *very* different understandings of simple.

And simple to deal with in some contexts and cases is often very complex
to deal with in other. I shall coin a phrase: Call this the "scalability
problem." ;)

Quote:
> If you use the simple version of XML you'll gain in the long run. Only
> computer geeks use complex systems that normal people can't understand.

My observatoin is that 1) computer geeks use systems *they* don't
understand, and 2) normal people use *even those* systems, too.

Quote:
> DTDs or Document Type Defintions which define what tags are permitted are
> ok but they add complexity that's beyond normal human comprehension they
> suck.

Huh? Sorry, but when writing an XML document, there's no need to refer
to a DTD in DTD syntax. Documentation will suffice. But the absence of a
DTD eliminates all sorts of precision that would enable you to use
various sorts of computer validation. This is a win? This is added
simplicity? Better I should have to write a {*filter*} regex to figure out
whether I consistently used "name" as element rather than "name" as
attribute in a huge file?

Come on.

Quote:
> Use tags that are dynamic

I don't understand "dynamic tags". My best guess is that you mean "ad
hoc" tags. Ad hoc tags for ad hoc uses, and not always then---this is my
motto (hereby coined, or maybe minted).

Quote:
> and create software that's flexible in
> understanding tags rather than imposing structure on people - this lets
> people impose structure on software.

Huh? A DTD *does* impose structure on software. Indeed, it then lets you
use software to help you impose structure on documents. Etc. But enough.
This is *way* too much rhetoric.

[snip]

Quote:
>But it is dead if we don't simplify
> and create a system that people - I mean real people, and not just you and
> I techies - can use. Real people. Simple people.

[snip]

Ok, here's what blew my gasket and caused this reply. GIVE IT A REST.
"Real people, simple people." Grrr. I'm a real person. And, actually,
I'm not a "techie" either. I have a fair bit of technical inclination
and ability...and so do *oodles* of "simple" people.

Patronization and derogation is *not* going to win you friends.

Or perhaps I'm simply wrong. The "for Dummies" etc. series *seems* to
prove otherwise. But frankly, I would fall down in shame to have written
such a work...and I'm no stranger to the desire to "popularize". Or to
the practice: I teach introductory classes (in philosophy). *Introduce*
is the right word, because, ideally, it will be an *ongoing*
relationship, as each side adjusts or is adjusted toward the other.

A significant problem with so much computing isn't the "complexity" *per
se* (though complification is a problem), it's that so much is just
plain wretchedly unpleasant. Down the ergnomatics of most computers and
their setups. Improving *that* is something both the "techies" and
"simple people" can benefit from.

--
Bijan Parsia
http://www.*-*-*.com/
...among many things.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. A New Programming Paradigm

2. New design paradigm?

3. Loadable modules - New paradigm of Tcl programming?

4. GDB-Tcl : A new paradigm for debugging

5. Beware: New Virus or something

6. Need VisualWorks Smalltalk,Fusion,Paradigm Plus

7. For Nerds and Geeks: The ultimate challenge 9341

8. Network geeks have slowed me down again

9. Biology Seeks a Few Good Geeks

10. OT: MacOS seminar for *nix geeks

11. distributing python programs to non-geeks

12. For Nerds and Geeks: The ultimate challenge 3990

 

 
Powered by phpBB® Forum Software