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