Hello Dan,
I'd like to thank you for your inspiring observations, and add some
information on recent developments inline.
At 21:48 30/10/2010, Dan Ingalls wrote:
Good People -
Adoption of a language, like any other adoption, is generally a function
of the needs and wants of the audience, and the strengths and weaknesses
of the substance being promoted. For better or worse, this function
can be significantly biased at the outset by marketing. As
technologists, we repeatedly underestimate the importance of marketing
and, even when we know we need to promote our systems, we fail because
the skills of marketing are not simply technical skills.
Who are our users?
We all have our own answer for this. I'll answer for myself so that
I can be articulate -- these are the users I would like to attract, or
who I feel would find our system valuable if they used it...
Kids at play - ie people 8-16 who are doing fun things
Kids at work - ie students 8-20 who are doing more serious things like
math (including computer science), physics, graphics, music, etc
Computer professionals at play - most of us
Computer professionals at work - most of us
About the computing context
The computing context has changed a lot over the years. It used to
be personal computers running Mac, Windows or Unix, and it used to be
simple functions like text editing and experiments with media. Now
it is mostly running in "the" browser, and communicating over
the web. A couple of things have remained key values, though:
The ability to create new content simply and directly, and the ability to
pull together existing content flexibly. By "content" I
mean both media and functions (services). The ability to assemble
existing content has been the greatest strength and weakness of Smalltalk
over the years. For internal content, Smalltalk is unmatched in its
ability to make every extension, whether music, graphics, or a financial
model, as natural as a built-in language feature. For external
content, however, Smalltalk has historically faltered at the edges of its
monolithic system.
What do the users need and want?
The ability to create new content simply and directly,
the ability to assemble existing content flexibly, and
the ability to share any results easily.
There is a Smalltalk- and Seaside-based solution for web applications
that provide this sort of functionality. In particular, it allows
managing and sharing application functionality and executions as content.
Here is an example:
- URL for the definition of an activity model (user-defined service):
http://www.afacms.com/cats/activities/shopping/Seaside/
- URL for one of its executions:
http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/
- URL to the cart items during that execution:
http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/fillandconfirmcart-trace/myfilledcart-trace/storecart
I'd like in particular your attention to the "Twitter & England
traffic info communication" example, whose definition and detailed
documentation are available via:
http://www.afacms.com/examples
This example wants to show that the distinction between internal and
external "functional content" is somehow blurred in this
solution, since it allows "wrapping" web services as if they
were implemented in Smalltalk.
Further explanations and examples may be found online via:
http://www.afacms.com/blog/pontoon-app
Another application example would be creating websites for online
authoring and execution of eToys projects. This would whoever require
integrating Lively Kernel libraries into Seaside.
What is important for
marketing
An old quote of Alan's is still relevant here: "Simple things
should be simple, and complex things should be possible."
Smalltalk has always suffered from two main barriers: installation
and integration. Once you have it installed, and if you don't need
to access anything outside, it is unmatched in its ability to make simple
things simply, and to achieve complex goals as well. Within its
self-contained context, its image model is perfect for saving, restoring,
and sharing work between sessions, between machines, and between
users.
In the world of today, people expect any new thing of interest to spring
to life in their browser.
In the above-mentioned solution, sophisticated business logic may keep to
be coded is Smalltalk, while the application allows online definition and
integration of new functionality by end-user programming. End-user
defined services are directly represented as executable models.
They expect it to look
attractive, cool, powerful; anything but geeky...
http://emberapp.com/
http://www.thecssawards.com/
http://cssmania.com/galleries/
You want this, too, right? So we can use "we" in place of
"they".
We expect it to be immediately useful. For a computer language,
this means you can immediately try out some expressions and make
something happen. We want this. We are busy, and we don't
have time to download a new environment, figure out a new browser, learn
a new graphics system, right?
We expect it to be incremental - do some work, save it, pick it up later
- we expect the comforts of Smalltalk-style development.
We expect it to be sharable - do something and send it to someone.
It's what we do with email, photos and videos. We probably want it
to be self-sharing, how about your workspace in your facebook page, and
tweets about each cool new thing.
Online definition of complex executable models is currently possible.
Now, I'm in the process of simplifying yet more the online programming
interface so as end-users can implement simple services really simply
(without any training). There is no need for ordinary end-users to
download or install any piece of software, although, Smalltalk
programmers can still update and extend online the application server
code.
We are currently investigating opportunities for very large deployments
for individualized support to Older Adults. Our marketing arguments are
summarized here:
http://www.aas-platform.com/about/aas/key-features/
We try to contribute to the community grow by creating a significant
space for development and commercialization of online reusable
"atomic" services, in particular for Seaside components and
wrappers for web services like those by major web actors. The following
web-site is setup and will hopefully develop further in the coming
weeks:
http://pontoonity.com/
More on potential application to user-generated services may be found
here:
http://www.aas-platform.com/about/related-work/ugs/
This work relates further to Lively Wiki, as described here:
http://www.rezarazavi.com/about/cv/publications/iwst-2010
I'd greatly appreciate any feedback from your part,
Best regards,
/Reza
These are the things that Gilad
and I are grappling with, and I think everyone on this list probably
thinks the same way from time to time. Gilad is trying to fix some
of the modularity problems in Smalltalk and exploit some of its greatest
strengths, while figuring out how to host it in today's (or tomorrow's)
browsers. And I've been playing around with what's possible using
JavaScript directly, but with some Smalltalk comforts like a nice
browser, work in a live editable environment, and save your project state
as a web page.
To return to Gilad's post,
[my interpretation: We don't take the time and effort to explore
new systems, and we don't take the time and effort to make our own
systems easy for others to explore]
I am well aware that this is not
a terribly actionable observation. It's just the way it is. What
one can do is identify weaknesses and work hard at fixing them, and hope
that some people will find it worthwhile to become truly
involved.
I feel the same way. But if you feel the same way from time to
time, perhaps you should start a movement to do something similar, or see
how you could contribute to NewSpeak or the Lively Kernel; not to
abandon Smalltalk but to experiment with how to carry *its goals* and
*your desires* forward.
Nothing is holding us back
- D
_______________________________________________
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org