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

csrabak at bol.com.br csrabak at bol.com.br
Mon Nov 29 12:24:05 CET 2010

Em 28/11/2010 18:17, Igor Stasenko < siguctua at gmail.com > escreveu:

> On 28 November 2010 19:41, wrote:
> > Em  26/11/2010  16:25, Janko  Mivšek  < janko.mivsek at eranova.si  >
> >escreveu:
> >> On 26. 11. 2010  18:20, csrabak at bol.com.br wrote: > Em 24/11/2010
> >> 11:50, Jan van de Sandt < jvdsandt at gmail.com > escreveu:
> >>
> >> >> A Smalltalk variant would use Smalltalk as the source language
> >> >> instead of Java, the other parts of GWT can be reused.  GWT is
> >> >> open source (Apache 2.0 license).
> >>
> >> > I think we  have first to evaluate to  what audience/market are
> >> > thinking of targeting this effort, then estimate the effort, in
> >> > order to see if its worth it.
> >>  Specially we the  web guys are very interested  of such a beast,
> >> because we need to develop more in more on the client side and in
> >> JavaScript, which is a bit hard, because of our Smalltalk habits,
> >> you know :)
> > I  _do_.  However,  it  is  also  a major  trend  "in  this  vital
> > industry"¹ the increase in restrictions on the client side leading
> > a  lot  of  developers  to  switch from  Javascript  (client  side
> > computing) to  PHP (server  side computing), for  an example  of a
> > popular site which ostensibly writes it in its home page, look at:
> > http://www.quantitativeskills.com/sisa/²
> > same problem  again: why doing things twice  (write same things in
> javascript on  client side,  and then rewrite  same thing in  PHP on
> server side). Why,  i am asking, why server and  client side have to
> use  different  languages?  Why  industry  created  such  ridiculous
> standards, which  forcing us to use multiple  languages depending on
> environment?  A CouchDB, for example, by default supports javascript
> as  a scripting  language for  views  on server.   This means,  that
> people to build  their site & persistency, have  to know only single
> language  - javascript. No  PHP, no  SQL and  other rusty  pieces of
> technology. :)

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"

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

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


Cesar Rabak

More information about the Pharo-project mailing list