<script language="smalltalk">
Locked
<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 |
Re: <script language="smalltalk">
|
|
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: > :) > > 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. |
Re: <script language="smalltalk">
|
|
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 |
|
|
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 |
Re: <script language="smalltalk">
|
|
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: |
|
|
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/ |
Re: <script language="smalltalk">
|
|
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 |
Re: <script language="smalltalk">
|
|
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. > 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. |
|
|
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. |
Re: <script language="smalltalk">
|
|
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/² > 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. > 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. |
|
|
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. > 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 >> >> > > |
|
|
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. >> >> > > |
|
|
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 |
Re: <script language="smalltalk">
|
|
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. > > 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. |
Re: <script language="smalltalk">
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |