[Pharo-project] <script language="smalltalk">
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 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
On 24 November 2010 00:46, Torsten Bergmann <astares@gmx.de> 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 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
-- Best regards, Igor Stasenko AKA sig.
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
Em 24/11/2010 09:39, Janko Mivšek < janko.mivsek@eranova.si > 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
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, <csrabak@bol.com.br> wrote:
Em 24/11/2010 09:39, Janko Mivšek < janko.mivsek@eranova.si > 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
Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@gmail.com > 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/
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote:
Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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 :) 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
2010/11/26 Janko Mivšek <janko.mivsek@eranova.si>:
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote:
Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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 :)
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.
On 11/27/10 3:33 AM, Igor Stasenko wrote:
2010/11/26 Janko Mivšek<janko.mivsek@eranova.si>:
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote:
Em 24/11/2010 11:50, Jan van de Sandt< jvdsandt@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 :)
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
Em 26/11/2010 16:25, Janko Mivšek < janko.mivsek@eranova.si > escreveu:
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote: > Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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/² "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.
On 28 November 2010 19:41, <csrabak@bol.com.br> wrote:
Em 26/11/2010 16:25, Janko Mivšek < janko.mivsek@eranova.si > escreveu:
On  26. 11. 2010  18:20, csrabak@bol.com.br  wrote: >  Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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.
-- Best regards, Igor Stasenko AKA sig.
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,<csrabak@bol.com.br> wrote:
Em 26/11/2010 16:25, Janko Mivšek< janko.mivsek@eranova.si> escreveu:
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote:> Em 24/11/2010 11:50, Jan van de Sandt< jvdsandt@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.
Em 28/11/2010 18:17, Igor Stasenko < siguctua@gmail.com > escreveu:
On 28 November 2010 19:41, wrote:
Em 26/11/2010 16:25, Janko Mivšek < janko.mivsek@eranova.si > escreveu:
On 26. 11. 2010 18:20, csrabak@bol.com.br wrote: > Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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. :)
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
On 29 November 2010 13:24, <csrabak@bol.com.br> wrote:
Em 28/11/2010 18:17, Igor Stasenko < siguctua@gmail.com > escreveu:
On 28 November 2010 19:41, wrote:
Em  26/11/2010  16:25, Janko  Mivšek  < janko.mivsek@eranova.si  > escreveu:
On 26. 11. 2010 Â 18:20, csrabak@bol.com.br wrote: > Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt@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. :)
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.
participants (6)
-
csrabak＠bol.com.br -
Igor Stasenko -
Jan van de Sandt -
Janko Mivšek -
Mirko Kiefer -
Torsten Bergmann