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

Igor Stasenko siguctua at gmail.com
Mon Nov 29 15:12:57 CET 2010


On 29 November 2010 13:24,  <csrabak at bol.com.br> wrote:
> 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.
>
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.




More information about the Pharo-project mailing list