[Pharo-project] <script language="smalltalk">

Mirko Kiefer mirko.kiefer at arcor.de
Sun Nov 28 22:02:44 CET 2010

I think these are very valid points. The main problem is not dealing 
with Javascript itself but the fact that it is _different_ to your 
server side code.
During the last months I've extensively been using Javascript on both 
the client and the server-side and must say that it is a very pleasing 
experience. It actually shares many similarities with Smalltalk, like 
the fact that both are very functional languages. Google's V8 Javascript 
engine actually evolved out of a Smalltalk VM.
In the end it isn't much more than syntax that differs both.
There is a very vibrant community on the rise, involved in projects like 
Node.js and CouchDB. Especially event driven programming in Node.js will 
blow you away when you actually sit down and do some coding with it.
I am convinced that these projects really have what it takes to replace 
a lot of the horribly bloated technology in the software world.

A Smalltalk VM as a browser plugin certainly wouldn't have a future.
To estimate the effort of writing a Smalltalk Interpreter in Javascript 
you may want to talk to the guys behind Cappuccino - http://cappuccino.org/
They left Apple and reimplemented Objective-C in the browser, including 
most of the Cocoa frameworks.
You can write some pretty impressing apps using Cappuccino: 

On 11/28/10 9:17 PM, Igor Stasenko wrote:
> On 28 November 2010 19:41,<csrabak at bol.com.br>  wrote:
>> Em 26/11/2010 16:25, Janko Mivšek<  janko.mivsek at eranova.si>  escreveu:
>>> On  26. 11. 2010  18:20, csrabak at bol.com.br  wrote:>    Em 24/11/2010
>>> 11:50, Jan van de Sandt<  jvdsandt at gmail.com>  escreveu:
>>>>> A Smalltalk  variant would use  Smalltalk as the  source language
>>>>> instead of  Java, the other  parts of GWT  can be reused.  GWT is
>>>>> open source (Apache 2.0 license).
>>>> I  think we  have first  to evaluate  to what  audience/market are
>>>> thinking of  targeting this effort,  then estimate the  effort, in
>>>> order to see if its worth it.
>>>   Specially  we the web  guys are  very interested  of such  a beast,
>>> because we  need to develop more in  more on the client  side and in
>>> JavaScript, which  is a bit  hard, because of our  Smalltalk habits,
>>> you know :)
>> I _do_. However, it is also a major trend "in this vital industry"¹ the
>> increase in restrictions on the client side leading a lot of developers
>> to switch from Javascript (client side computing) to PHP (server side
>> computing), for an example of a popular site which ostensibly writes it
>> in its home page, look at: http://www.quantitativeskills.com/sisa/²
> same problem again: why doing things twice (write same things in
> javascript on client side,
> and then rewrite same thing in PHP on server side). Why, i am asking,
> why server and client side have to
> use different languages? Why industry created such ridiculous
> standards, which forcing us to use multiple languages
> depending on environment?
> A CouchDB, for example, by default supports javascript as a scripting
> language for views on server.
> This means, that people to build their site&  persistency, have to
> know only single language - javascript. No PHP,
> no SQL and other rusty pieces of technology. :)
>> "Security" reasons plus less acquaintance with a newer technology would
>> make this entry in the market very hard in today's environments.
>> Perhaps what's _really_ needed is a good Javascript debugger?
> perhaps. And Self-like object's inspectors and explorers :)
>>>   Even more, Smalltalk on the client (Clamato way) can also solve one
>>> of the main JavaScript problems: debugging on the client side. If we
>>> can have  near the  same debugger on  the client  as we have  in our
>>> IDE's, well, this would be a huge step forward.
>> For a very small community of Smalltalk developers, yes.  What I rose
>> earlier and maintain for discussion is if we have critical mass to reap
>> the rewards of such an effort: we may end in some sort of the Armstrong's
>> words backwards: "It was a huge step forward for Smalltalkers but a non
>> movement forward at all for the majority of web developers."
>>>> If the attempt is  a reinterpretation a Smalltalk base development
>>>> environment would make a difference in the ecosystem we must check
>>>> if  we  aren't  flared  by  our  preference  of  languages  versus
>>>> operational pragmatics.
>>>> If the idea is to have  such environment to the present (and sadly
>>>> minute)  community of  Smalltalk developers,  probably  the effort
>>>> would attend  to a  very small clientèle  and the returns  will be
>>>> elusive and the project will end orphan.
>> So, rephrasing my point above: except if we can produce those artifacts
>> as a simple consequences of subclassing some objects in our environments
>> and having a robust enough usable system, we rather consider carefully
>> the use of our efforts in other areas where the fruits are hanging lower.
> Yes, i agree. Such plugin would require a big efforts to complete.
> And while from tech side, we can foresee the benefits, from market
> side, this is not obvious.
> Because niche is already filled by javascript, which is also dynamic
> language and very powerful one.
> What lacking, is a development environment for javascript, which can
> be used to develop things
> as same pace as in smalltalk dev environment.
>> --
>> Cesar Rabak
>> [1] To whom may be missing: it is a pun with a phrase of one of the
>> woodpecker shows where a line guard says these words when Woody installs
>> himself in one of the telegraph poles.... :-D
>> [2] Their arguments about mobile devices are also IMNSHO compelling.

More information about the Pharo-project mailing list