[Pharo-project] <script language="smalltalk">
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 >
>> >> 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
>> >> you know :)
>> > I _do_. However, it is also a major trend "in this vital
>> > industry"¹ the increase in restrictions on the client side leading
>> > 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
>> 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
>> as a scripting language for views on server. This means, that
>> people to build their site & persistency, have to know only single
>> 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"
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
> 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
often i have no other ways, but just put ' echo $foo ' in PHP, and
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
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. 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
>> be used to develop things as same pace as in smalltalk dev
> 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
Igor Stasenko AKA sig.
More information about the Pharo-project