<script language="smalltalk">

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

<script language="smalltalk">

Torsten Bergmann
>How easy/hard to integrate smalltalk VM into browsers? It it feasible?

You need to run as a plugin in the browser, so the VM has to be
in process (DLL on windows instead of exe for instance)

>I know, there is (or was) a Squeak browser plugin.

Yes there was/is a Squeak ActiveX control for InternetExplorer
and a Netscape plugin for NS compatible browsers.
Dont know about the maintenance state...
As you already said ... they are more like "applet providers"
in Java. AFAIK they are not interfacing with the scripting
engines of the browser.

>While i thinking, that it would be cool to use smalltalk directly in
>pages, as javascript.

That would mean to run on the client in the browser and mean to:

 - build a small downloadable VM as a plugin into the browser
   since the plugin itself is browser dependent and OS dependent
   you have to build one for each of the major browsers and OS's on the
   market,

   Dont know about the other browsers but for Internet Explorer
   you would have to implement the ActiveScripting Engine COM interfaces.

   This would mean you could then use it in any application that is an
   ActiveX scripting host (like IE, Word, Windows Scripting shell, ...)
   and you get the <script language="smalltalk"> for free in IE.

   For instance vbscript.dll and jscript.dll are done this way.
   I think ActivePerl, ActivePython, ... from Activestate.com
   are implemented similar.

   You also have to think about securing your VM since typically a
   script executed in a webbrowser should not access files/clipboard/etc.
   otherwise it would be easy to harm computers from a website.

 - build a small (kernel) image that provides basic functionality,
   comes with the VM above and and accepts the scripts to run them

 - for the bare bone scripting part you should check out
   "squeaksource.com/Sapphire"

   I'm sure it could be done but you would need time and good knowledge
   of C/C++, Squeak VM creation, Scripting, ...

Question left is why you want all this. Instead of Smalltalk you
can use JavaScript for the browser/client part of your app.
JavaScript is very dynamic and meanwhile supported and fast enough in nearly any browser....

Bye
T.

--
GMX DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Igor Stasenko
On 24 November 2010 00:46, Torsten Bergmann <[hidden email]> wrote:

>>How easy/hard to integrate smalltalk VM into browsers? It it feasible?
>
> You need to run as a plugin in the browser, so the VM has to be
> in process (DLL on windows instead of exe for instance)
>
>>I know, there is (or was) a Squeak browser plugin.
>
> Yes there was/is a Squeak ActiveX control for InternetExplorer
> and a Netscape plugin for NS compatible browsers.
> Dont know about the maintenance state...
> As you already said ... they are more like "applet providers"
> in Java. AFAIK they are not interfacing with the scripting
> engines of the browser.
>
>>While i thinking, that it would be cool to use smalltalk directly in
>>pages, as javascript.
>
> That would mean to run on the client in the browser and mean to:
>
<skipping technical details>
:)

>
> Question left is why you want all this. Instead of Smalltalk you
> can use JavaScript for the browser/client part of your app.
> JavaScript is very dynamic and meanwhile supported and fast enough in nearly any browser....
>

Yes. This is a question which i would like to discuss and get an
answer from community.
One of the discrepancies, when developing Seaside applications is
dealing with JS.
What, if you could eliminate it, and use smalltalk on server and
client sides both.
Don't you think this could make many things much easier to do?

What if you would be able to expose parts of your application directly
to client side, by simply telling:
html exportClass: MyClientSideClass

instead of

html script: 'a string containing script'

> Bye
> T.
>
> --
> GMX DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit
> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
>
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Janko Mivšek
In reply to this post by Torsten Bergmann
I'm pretty sure that any plugin based solution will have a dead-end, as
all Smalltalk plugins so far had. There are just too many browsers to
support out there. FireFox, IE, Safari, Android, Symbian, ... We are too
small community to afford maintaining a plugin on so many different
browsers.

Therefore I see the only viable long-term solution a Smalltalk on top of
JavaScript VM. Yes, I know, this is a very limited environment for
Smalltalk standards, but it is the least evil from all choices we have.

We actually have some effords done or underway already, like ST2JS,
Clamato, also Seaside's JavaScript from Smalltalk way of programming. I
think we should continue this way and, as I said, forget any plugin way.

Best regards
Janko

On 23. 11. 2010 23:46, Torsten Bergmann wrote:

>> How easy/hard to integrate smalltalk VM into browsers? It it feasible?
>
> You need to run as a plugin in the browser, so the VM has to be
> in process (DLL on windows instead of exe for instance)
>
>> I know, there is (or was) a Squeak browser plugin.
>
> Yes there was/is a Squeak ActiveX control for InternetExplorer
> and a Netscape plugin for NS compatible browsers.
> Dont know about the maintenance state...
> As you already said ... they are more like "applet providers"
> in Java. AFAIK they are not interfacing with the scripting
> engines of the browser.
>
>> While i thinking, that it would be cool to use smalltalk directly in
>> pages, as javascript.
>
> That would mean to run on the client in the browser and mean to:
>
>  - build a small downloadable VM as a plugin into the browser
>    since the plugin itself is browser dependent and OS dependent
>    you have to build one for each of the major browsers and OS's on the
>    market,
>
>    Dont know about the other browsers but for Internet Explorer
>    you would have to implement the ActiveScripting Engine COM interfaces.
>
>    This would mean you could then use it in any application that is an
>    ActiveX scripting host (like IE, Word, Windows Scripting shell, ...)
>    and you get the <script language="smalltalk"> for free in IE.
>
>    For instance vbscript.dll and jscript.dll are done this way.
>    I think ActivePerl, ActivePython, ... from Activestate.com
>    are implemented similar.
>
>    You also have to think about securing your VM since typically a
>    script executed in a webbrowser should not access files/clipboard/etc.
>    otherwise it would be easy to harm computers from a website.
>
>  - build a small (kernel) image that provides basic functionality,
>    comes with the VM above and and accepts the scripts to run them
>
>  - for the bare bone scripting part you should check out
>    "squeaksource.com/Sapphire"
>
>    I'm sure it could be done but you would need time and good knowledge
>    of C/C++, Squeak VM creation, Scripting, ...
>
> Question left is why you want all this. Instead of Smalltalk you
> can use JavaScript for the browser/client part of your app.
> JavaScript is very dynamic and meanwhile supported and fast enough in nearly any browser....
>
> Bye
> T.
>

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

csrabak
Em 24/11/2010 09:39, Janko Mivšek < [hidden email] > escreveu:

> I'm pretty sure that any plugin based solution will have a dead-end,
> as  all  Smalltalk plugins  so  far had.  There  are  just too  many
> browsers  to  support  out  there.  FireFox,  IE,  Safari,  Android,
> Symbian,  ... We  are too  small community  to afford  maintaining a
> plugin on so many different browsers.

I can agree with that, giving the past history of Smalltalk plugins.

Besides, we've to accept a simple fact of life: for the end user there
is not any apparent benefit of such additional plugin. Or, in other words:

There is no compelling reason for an end user feel the need of an
additional piece of SW to be installed in his/her computer, even harder
if in a corporative environment where you have to get permits from
sysadmins, etc.


>  Therefore I see  the only viable long-term solution  a Smalltalk on
> top  of  JavaScript  VM.  Yes,  I  know,  this  is  a  very  limited
> environment for Smalltalk  standards, but it is the  least evil from
> all choices we have.

Except if this technology has something different from present state of
art, this new layer (a.k.a. indirection) will have the single effect of
bringing the smalltalk code to appear slower than 'native' javascript,
without any benefit to the end user.

>  We actually have some effords done or underway already, like ST2JS,

I understand these are a different beast: they 'translate' Smalltalk code
into 'equivalent' javascript to be fed to the browsers.
> Clamato,  

This is an hybrid, but basically tries to emulate some 'dialect' of Smalltalk
in javascript.  In the end, you need to master a nth language which is not
nor javascript nor smalltalk anymore.  Again, if the advantages of such
approach are quickly accrued the additional effort to do so will deter
the widespread of the technology.

[snipped]

my 0.019999....

--
Cesar Rabak

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Jan van de Sandt
Perhaps a Smalltalk variant of the Google Web Toolkit (GWT) would be a good idea.

GWT compiles Java code into browser specific obfuscated Javascript code. At development time you can run and debug the Java code directly in the browser by using some kind of browser plugin. When you are ready to deploy you generate the Javascript code and your app runs in all modern browsers without any plugins.

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).

Jan.

GWT Homepage: http://code.google.com/intl/nl/webtoolkit/




On Wed, Nov 24, 2010 at 1:52 PM, <[hidden email]> wrote:
Em 24/11/2010 09:39, Janko Mivšek < [hidden email] > escreveu:

> I'm pretty sure that any plugin based solution will have a dead-end,
> as  all  Smalltalk plugins  so  far had.  There  are  just too  many
> browsers  to  support  out  there.  FireFox,  IE,  Safari,  Android,
> Symbian,  ... We  are too  small community  to afford  maintaining a
> plugin on so many different browsers.

I can agree with that, giving the past history of Smalltalk plugins.

Besides, we've to accept a simple fact of life: for the end user there
is not any apparent benefit of such additional plugin. Or, in other words:

There is no compelling reason for an end user feel the need of an
additional piece of SW to be installed in his/her computer, even harder
if in a corporative environment where you have to get permits from
sysadmins, etc.


>  Therefore I see  the only viable long-term solution  a Smalltalk on
> top  of  JavaScript  VM.  Yes,  I  know,  this  is  a  very  limited
> environment for Smalltalk  standards, but it is the  least evil from
> all choices we have.

Except if this technology has something different from present state of
art, this new layer (a.k.a. indirection) will have the single effect of
bringing the smalltalk code to appear slower than 'native' javascript,
without any benefit to the end user.

>  We actually have some effords done or underway already, like ST2JS,

I understand these are a different beast: they 'translate' Smalltalk code
into 'equivalent' javascript to be fed to the browsers.
> Clamato,

This is an hybrid, but basically tries to emulate some 'dialect' of Smalltalk
in javascript.  In the end, you need to master a nth language which is not
nor javascript nor smalltalk anymore.  Again, if the advantages of such
approach are quickly accrued the additional effort to do so will deter
the widespread of the technology.

[snipped]

my 0.019999....

--
Cesar Rabak


Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

csrabak
Em 24/11/2010 11:50, Jan van de Sandt < [hidden email] > escreveu:

> Perhaps a Smalltalk variant of the Google Web Toolkit (GWT) would be
> a good idea.
>  GWT compiles Java code  into browser specific obfuscated Javascript
> code.  At development  time  you can  run  and debug  the Java  code
> directly in the  browser by using some kind  of browser plugin. When
> you are  ready to deploy you  generate the Javascript  code and your
> app runs in all modern browsers without any plugins.
>   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.

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.

> GWT Homepage: http://code.google.com/intl/nl/webtoolkit/


Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Janko Mivšek
On 26. 11. 2010 18:20, [hidden email] wrote:
> Em 24/11/2010 11:50, Jan van de Sandt < [hidden email] > 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 :)

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.

> 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.

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Igor Stasenko
2010/11/26 Janko Mivšek <[hidden email]>:

> On 26. 11. 2010 18:20, [hidden email] wrote:
>> Em 24/11/2010 11:50, Jan van de Sandt < [hidden email] > 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 :)
>
> 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.
>
indeed. debugging JS is hard. Most of the times, all you can do is to
put 'alert(...)'
in interesting places, to see what's going wrong.
But there are things, like
http://www.mozilla.org/projects/venkman/
didn't tried it.

>> 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.
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

csrabak
In reply to this post by Janko Mivšek
Em 26/11/2010 16:25, Janko Mivšek < [hidden email] > escreveu:

> On  26. 11. 2010  18:20, [hidden email]  wrote: >  Em 24/11/2010
> 11:50, Jan van de Sandt < [hidden email] > 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/²

"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?


>  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.

--
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.

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Igor Stasenko
On 28 November 2010 19:41,  <[hidden email]> wrote:

> Em 26/11/2010 16:25, Janko Mivšek < [hidden email] > escreveu:
>> On  26. 11. 2010  18:20, [hidden email]  wrote: >  Em 24/11/2010
>> 11:50, Jan van de Sandt < [hidden email] > 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.
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Mirko-2
In reply to this post by Igor Stasenko


On 11/27/10 3:33 AM, Igor Stasenko wrote:

> 2010/11/26 Janko Mivšek<[hidden email]>:
>> On 26. 11. 2010 18:20, [hidden email] wrote:
>>> Em 24/11/2010 11:50, Jan van de Sandt<  [hidden email]>  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 :)
>>
>> 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.
>>
> indeed. debugging JS is hard. Most of the times, all you can do is to
> put 'alert(...)'
> in interesting places, to see what's going wrong.
> But there are things, like
> http://www.mozilla.org/projects/venkman/
> didn't tried it.
>
Igor, I recommend having a look at the build in developer tools in
Safari or Google Chrome (they are the same). They give you a very
powerful debugging and profiling environment and the option to inspect
all Javascript objects on runtime. On the debugging side there is
actually very little that you would miss from Pharo.

>>> 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.
>> --
>> Janko Mivšek
>> AIDA/Web
>> Smalltalk Web Application Server
>> http://www.aidaweb.si
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Mirko-2
In reply to this post by Igor Stasenko
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:
http://280slides.com/

On 11/28/10 9:17 PM, Igor Stasenko wrote:

> On 28 November 2010 19:41,<[hidden email]>  wrote:
>> Em 26/11/2010 16:25, Janko Mivšek<  [hidden email]>  escreveu:
>>> On  26. 11. 2010  18:20, [hidden email]  wrote:>    Em 24/11/2010
>>> 11:50, Jan van de Sandt<  [hidden email]>  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.
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

csrabak
In reply to this post by Igor Stasenko
Em 28/11/2010 18:17, Igor Stasenko < [hidden email] > escreveu:

> On 28 November 2010 19:41, wrote:
> > Em  26/11/2010  16:25, Janko  Mivšek  < [hidden email]  >
> >escreveu:
> >> On 26. 11. 2010  18:20, [hidden email] wrote: > Em 24/11/2010
> >> 11:50, Jan van de Sandt < [hidden email] > 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. :)

Perhaps my example has been misunderstood because I've put it in the
fly without more explanation: the developers at SISA will _replace_
client side code with server side code and opted for PHP for whichever
reason they felt to do so.

Attempting to answer your question about "why server and  client side
have to use  different  languages?" is a subject for another thread,
but in nutshell it can be explained by the "one size does not fit all"
moto.

What's "rusty" or "classic" or "proven" technology is in the
beholder's eyes.... for a lot of 'gurus' Smalltalk is 'rusty' or
'antique' and belongs to museum.

About "Why  industry  created..." the answer comes from marketting
forces and attempts to 'lead' or 'gain market share'.
 
>
> > "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 :)
>
[snipped]

> > 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.
>

Yes, like Eclipse ends up 'borrowing' a lot of features from Smalltalk
environments and seems to those new wave of developers as genuine
'new' ideas, I think Smalltalk can at most be like a reference model
for this.

Regards,

--
Cesar Rabak

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Igor Stasenko
On 29 November 2010 13:24,  <[hidden email]> wrote:

> Em 28/11/2010 18:17, Igor Stasenko < [hidden email] > escreveu:
>
>> On 28 November 2010 19:41, wrote:
>> > Em  26/11/2010  16:25, Janko  Mivšek  < [hidden email]  >
>> >escreveu:
>> >> On 26. 11. 2010  18:20, [hidden email] wrote: > Em 24/11/2010
>> >> 11:50, Jan van de Sandt < [hidden email] > 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. :)
>
> Perhaps my example has been misunderstood because I've put it in the
> fly without more explanation: the developers at SISA will _replace_
> client side code with server side code and opted for PHP for whichever
> reason they felt to do so.
>
yeah.. good luck then :)

> Attempting to answer your question about "why server and  client side
> have to use  different  languages?" is a subject for another thread,
> but in nutshell it can be explained by the "one size does not fit all"
> moto.
>
that was a rhetoric question.

I don't think that it is necessary to port code for calculating
statistical data, if you using same language.
Because its just a numerical processing, and should be no different no
matter where you running it.
What may need changing is I/O interfaces, when you moving from client
to server side.
This means a lot less work comparing to porting everything into
another language.

> What's "rusty" or "classic" or "proven" technology is in the
> beholder's eyes.... for a lot of 'gurus' Smalltalk is 'rusty' or
> 'antique' and belongs to museum.
>

It is my personal view, of course. Rusty because, every time i need to
fix something in PHP or Javascript,
often i have no other ways, but just put ' echo $foo ' in PHP, and
alarm(foo) in javascript to see what wrong with data,
instead of simply seeing same variable (and a lot of other related
vars) directly in debugger.
This is what makes me angry every time , because i used to have
debugger & browser in smalltalk, constantly available
at any moment under my fingertips.

The problem with these languages, i think, that they were evolved from
very simple and very limited initial requirements, which later grew to
more and more powerful & flexible features, once users started
demanding more.
In contrast to smalltalk, where its structure & design (including
environment) were took multiple iterations before final one , which
then made public.

Ruby and Perl, i think, having same ill fundament. They were created
with no strategy in mind: its just a toys which later became
professional instruments, because of gaining popularity. Both lacking
systematic approach in design.

And the reason why they all fail will be same: no strategy &
systematic design from very starting.
You can't build a plane without planning stages and knowing exactly
what materials you will need for every detail. It will never fly.

> About "Why  industry  created..." the answer comes from marketting
> forces and attempts to 'lead' or 'gain market share'.
>
>>
>> > "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 :)
>>
> [snipped]
>
>> > 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.
>>
>
> Yes, like Eclipse ends up 'borrowing' a lot of features from Smalltalk
> environments and seems to those new wave of developers as genuine
> 'new' ideas, I think Smalltalk can at most be like a reference model
> for this.
>
> Regards,
>
> --
> Cesar Rabak
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: <script language="smalltalk">

Simon Denier-3
In reply to this post by csrabak

On 26 nov. 2010, at 19:26, Janko Mivšek wrote:

> On 26. 11. 2010 18:20, [hidden email] wrote:
>> Em 24/11/2010 11:50, Jan van de Sandt < [hidden email] > 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 :)
>
> 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.


Well then,
We have the Smalltalk IDE but nobody is interested to look at it because it's Smalltalk.
We have Seaside but nobody is interested to look at it because it's Smalltalk.

But maybe if someone brings a Javascript IDE built in Smalltalk, people will start to look at it :) We may even already have one edge with PetitParser.
(and the trick is of course that you don't advertize Smalltalk, you advertize Javascript).

Strangely, this reminds me of the story of Lucid which built a powerful C++ IDE... in Lisp. This leads to XEmacs.

http://www.jwz.org/doc/lemacs.html
http://dreamsongs.com/Cadillac.html

--
 Simon