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.