Few thoughts about Google Summer of Code
I'll second Gilad's thoughts.
I am familiar with VisualWorks and VA, as well as no longer existent
dialects like Digitalk's. However, the several times I have tried to "get
into Squeak", I've landed in a UI that doesn't work like those I am familiar
with, so it seems much more difficult to learn "the Squeak way". The only
tutorial was about basic Smalltalk syntax and offered no guidance for
Squeak. Perhaps there are some "getting started with Squeak" guides, but
Squeak itself doesn't lead you to them.
We can get any number of people to try a given Smalltalk implementation, but
once they get there, we need to ensure they can get around in it (if they
already think Smalltalk) and can learn how the Smalltalk way differs from
what they are used to otherwise.
Like many people, once I account for sleep, family life, and work, there
isn't a lot of time left for struggling to learn something new, no matter
how popular or interesting it seems to be. We need to reduce the effort to
get over the first hurdles.
-----Original Message-----
From: esug-list-bounces@lists.esug.org
[mailto:esug-list-bounces@lists.esug.org] On Behalf Of Gilad Bracha
Sent: October-30-10 7:09 PM
To: Geert Claes
Cc: esug-list@lists.esug.org
Subject: Re: [Esug-list] Few thoughts about Google Summer of Code
Hi Geert, Rob and others,
On Oct 30, 2010, at 8:24 AM, Geert Claes wrote:
We do have Newspeak listed on http://www.world.st/implementations so
everyone
should make some time :)
Thanks for that and for the good intentions!
If I may, I'll make one more observation. This thread (and similar ones,
oft repeated among Smalltalkers) bemoans the fact that others do not see
the beauty of Smalltalk. What I liked about this thread was that
Smalltalkers were engaged in serious self examination. There seemed to be a
realization that some things need real changes.
Perhaps as part of this self examination, one can see how hard it is to get
out of one's comfort zone. The effort of engaging with and learning
something different is more than most people can find the time and energy
for - even when the differences are relatively modest, as in the case of
Newspeak.
Some of the reasons some of you cannot get around to really getting involved
with Newspeak are quite analogous to the reasons why your Pythonista or Java
(or whatever) colleagues cannot get serious about Smalltalk.
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.
Cheers, Gilad
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On Sun, Oct 31, 2010 at 6:06 PM, Richard Sargent rsargent@5x5.on.ca wrote:
I'll second Gilad's thoughts.
I am familiar with VisualWorks and VA, as well as no longer existent
dialects like Digitalk's. However, the several times I have tried to "get
into Squeak", I've landed in a UI that doesn't work like those I am familiar
with, so it seems much more difficult to learn "the Squeak way". The only
tutorial was about basic Smalltalk syntax and offered no guidance for
Squeak. Perhaps there are some "getting started with Squeak" guides, but
Squeak itself doesn't lead you to them.
There is the Squeak by Example book : http://www.squeakbyexample.org/
Regards,
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
I agree with Richard.. I am familiar with VisualWorks and Digitalk's VSE.
I first met Squeak back in 2007, then Pharo, I llike both. To make a
progress in teaching myself, I invested too much time.
Got positively caught with the Seaside one-click experience image and I am
stick for the moment.
Seems that the Pharo-Squeak communities are not challenged to build
something like VW´s UI Builder.
Having such a feature will help Smalltalk appeal to those developers that
capture small-medium sized client-server projects on their own (around 100
days of effort) that are not interesting targets to the the large
consultancy businesses.
----- Original Message -----
From: "Richard Sargent" rsargent@5x5.on.ca
To: esug-list@lists.esug.org
Sent: Sunday, October 31, 2010 8:06 AM
Subject: Re: [Esug-list] Few thoughts about Google Summer of Code
I'll second Gilad's thoughts.
I am familiar with VisualWorks and VA, as well as no longer existent
dialects like Digitalk's. However, the several times I have tried to "get
into Squeak", I've landed in a UI that doesn't work like those I am
familiar
with, so it seems much more difficult to learn "the Squeak way". The only
tutorial was about basic Smalltalk syntax and offered no guidance for
Squeak. Perhaps there are some "getting started with Squeak" guides, but
Squeak itself doesn't lead you to them.
We can get any number of people to try a given Smalltalk implementation,
but
once they get there, we need to ensure they can get around in it (if they
already think Smalltalk) and can learn how the Smalltalk way differs from
what they are used to otherwise.
Like many people, once I account for sleep, family life, and work, there
isn't a lot of time left for struggling to learn something new, no matter
how popular or interesting it seems to be. We need to reduce the effort to
get over the first hurdles.
-----Original Message-----
From: esug-list-bounces@lists.esug.org
[mailto:esug-list-bounces@lists.esug.org] On Behalf Of Gilad Bracha
Sent: October-30-10 7:09 PM
To: Geert Claes
Cc: esug-list@lists.esug.org
Subject: Re: [Esug-list] Few thoughts about Google Summer of Code
Hi Geert, Rob and others,
On Oct 30, 2010, at 8:24 AM, Geert Claes wrote:
We do have Newspeak listed on http://www.world.st/implementations so
everyone
should make some time :)
Thanks for that and for the good intentions!
If I may, I'll make one more observation. This thread (and similar ones,
oft repeated among Smalltalkers) bemoans the fact that others do not see
the beauty of Smalltalk. What I liked about this thread was that
Smalltalkers were engaged in serious self examination. There seemed to be
a
realization that some things need real changes.
Perhaps as part of this self examination, one can see how hard it is to
get
out of one's comfort zone. The effort of engaging with and learning
something different is more than most people can find the time and energy
for - even when the differences are relatively modest, as in the case of
Newspeak.
Some of the reasons some of you cannot get around to really getting
involved
with Newspeak are quite analogous to the reasons why your Pythonista or
Java
(or whatever) colleagues cannot get serious about Smalltalk.
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.
Cheers, Gilad
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Geert -
<several snips>The "download a new environment" may not mean to a local machine, because I
would like to add that we also expect to pick it up anywhere and probably
also on any device!
I agree.
We are still learning what is the sweet spot in the mobile/cloud universe, and how this relates to earlier client/server experience.
- Dan
Hi again -
I will stop polluting this otherwise sane list, but I can't resist
one more thought...
You know I never left Smalltalk; I'm just using another language
right now ;-). One of the early thoughts I had when working on the
Lively Kernel was to put a Smalltalk "skin" on top of it, and I'd
have a Lively Smalltalk. I was going to release it to SqueakLand as
an April Fool's prank, but the day came and went; then a year came
and went, and so it goes...
Meanwhile, Alex Warth sketched a Smalltalk evaluator in OMeta and put
it up on his Tin Lizzie site. Anticipating various fun language
experiments, we then integrated OMeta (as JavaScript) with the Lively
Kernel, and Robert Krahn put together a Lively version of Alex's
experiment. You might find it intriguing...
http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xhtml
This should work on Safari, Chrome, Firefox and Opera, with iPad and
IE9 working RSN. You should be able to select expressions and
evaluate them with cmd-p or something similar (different in different
browsers and platforms). If all else fails, you should be able to
bring up a menu with cmd-click, and select Text-functions/print-it.
Don't forget to scroll the Smalltalk workspace up -- the best
examples are out of view.
So, is this a joke?
Modern JavaScripts runs at a speed comparable to Squeak
The graphics are resolution-independent and anti-aliased
It runs in almost every browser
You don't need to install it to run
You can save your work on a web page and share it that way too
Of course it's only a two-day hack, but what if someone actually got
serious about it? And what about the synergy with Gilad's interest
in compiling Newspeak to JS? For me, I think we could have a lot of
fun in the next year. If this tickles your fancy, hop on the Lively
Kernel mail list and we'll try to give you some support. The
documentation is sparse but the people are friendly.
All the best
- Dan
On 10/31/2010 11:32 PM, Dan Ingalls wrote:
Doesn't load in Firefox 3.6 (pistons spin forever), crashes the browser
in Epiphany (WebKit-based). :(
Paolo
I see the¨"loading" splashbox, it is taking more than 10 minutes from when
started, how much time it takes to load?
----- Original Message -----
From: "Paolo Bonzini" bonzini@gnu.org
To: "Dan Ingalls" dan@squeakland.org
Cc: esug-list@lists.esug.org
Sent: Sunday, October 31, 2010 8:48 PM
Subject: Re: [Esug-list] Is he kidding?
On 10/31/2010 11:32 PM, Dan Ingalls wrote:
Doesn't load in Firefox 3.6 (pistons spin forever), crashes the browser in
Epiphany (WebKit-based). :(
Paolo
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
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/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/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/storecarthttp://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/exampleshttp://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-apphttp://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://emberapp.com/
http://www.thecssawards.com/
http://cssmania.com/galleries/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/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/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-2010http://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
Hi Dan,
Very cool. So let me expand on what I am after. I want to write full scale Newspeak programs that don't know or care about the DOM or the browser and run them in the browser. I want to run that same program natively on a mac or Windows. I also want to run the same program with a UI tweaked for a touchscreen of the appropriate size, natively on a tablet - any tablet.
I even want to run the full IDE this way, though that is less crucial.
And again, allowing for size and functionality, I want to run Newspeak apps a smartphone. Independent of whether its Android, IOS, Windows 7 or RIM or whatever else.
This is a tall order, and of all these things perhaps the browser is the most important, and could subsume the others. And I want it in a mature Newspeak that is secure as well as elegant.
We'll see if I get there, and when.
End commercial.
On Oct 31, 2010, at 3:32 PM, Dan Ingalls wrote:
Hi again -
I will stop polluting this otherwise sane list, but I can't resist one more thought...
You know I never left Smalltalk; I'm just using another language right now ;-). One of the early thoughts I had when working on the Lively Kernel was to put a Smalltalk "skin" on top of it, and I'd have a Lively Smalltalk. I was going to release it to SqueakLand as an April Fool's prank, but the day came and went; then a year came and went, and so it goes...
Meanwhile, Alex Warth sketched a Smalltalk evaluator in OMeta and put it up on his Tin Lizzie site. Anticipating various fun language experiments, we then integrated OMeta (as JavaScript) with the Lively Kernel, and Robert Krahn put together a Lively version of Alex's experiment. You might find it intriguing...
http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xhtml
This should work on Safari, Chrome, Firefox and Opera, with iPad and IE9 working RSN. You should be able to select expressions and evaluate them with cmd-p or something similar (different in different browsers and platforms). If all else fails, you should be able to bring up a menu with cmd-click, and select Text-functions/print-it. Don't forget to scroll the Smalltalk workspace up -- the best examples are out of view.
So, is this a joke?
Modern JavaScripts runs at a speed comparable to Squeak
The graphics are resolution-independent and anti-aliased
It runs in almost every browser
You don't need to install it to run
You can save your work on a web page and share it that way too
Of course it's only a two-day hack, but what if someone actually got serious about it? And what about the synergy with Gilad's interest in compiling Newspeak to JS? For me, I think we could have a lot of fun in the next year. If this tickles your fancy, hop on the Lively Kernel mail list and we'll try to give you some support. The documentation is sparse but the people are friendly.
All the best
- Dan
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Cheers, Gilad
Hi guys
Let me restate clearly the goal of pharo:
We want a small, clean kernel. Now it does not mean that we want a smalltalk like one of the 80 :)
nor one that is only looking like Smalltalk from far :). We want an innovative Smalltalk. Right now we are re-aligning the current implementation (you know squashing wrong lines and adding abstractions).
Of course there are work. We would love to have a UIBuilder (and this is not because of lack of vision) and a lot more.
But we want new way to structure program (traits, modules,...), solutions to provide security concerns..... But this is something that needs time to build prototype, evaluate redo, turn them into more robust solutions. So dan if you want to take pharo and run it into JS please go. We are writing a new compiler which can be
certainly tweaked to generate jsbytecode (if any).
Now Dan may be you should have started to build a smalltalk on Javascript and people may have understood your intentions.
From far it looked like Morphic with a funny (not fun) syntax.
Stef
PS: in 2001 we could only do anything beside Java, nowadays it seems that the dogma changed again and that
we cannot do anything but Javascript. This is not what you said of course I read well english but this is a fun to see cycles.