On 29 November 2010 13:24, <csra...@bol.com.br> wrote: > Em 28/11/2010 18:17, Igor Stasenko < siguc...@gmail.com > escreveu: > >> On 28 November 2010 19:41, wrote: >> > Em 26/11/2010 16:25, Janko Mivšek < janko.miv...@eranova.si > >> >escreveu: >> >> On 26. 11. 2010 18:20, csra...@bol.com.br wrote: > Em 24/11/2010 >> >> 11:50, Jan van de Sandt < jvdsa...@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.
