A few days with Nicolas...
Locked
 
|
Hi folks!
I just dropped off Nicolas on the airport here in Sweden, he is going home after staying with me for a few days and working together with our common customer (HTML5 app, js mainly, no Amber there). Now, apart from showing Nicolas the beautiful Stockholm archipelago :) we of course also talked about Amber and where things are going with it and lots of other stuff in the Smalltalk community. Personally I haven't had much time at all lately for Amber, but I am still here, don't worry. Nicolas on the other hand showed me *awesome* Amber stuff he has been working quite hard on, but I don't want to "steal his thunder" so please look forward to impressive stuff Coming Soon to a browser near you, sorry Nicolas, but I just had to tell :) We also played a teeny bit with Dart, especially taking a closer look at the js it produces. One thing that we were especially interested in was how the heck they support DNU (noSuchMethod they call it) without adding their own lookup procedure. It turns out they do a really dirty trick - and we are unsure about how it will scale when compiling a larger Dart app to js. If there is a Dart guru lurking, please give us more info. After a "cursory look" it seems they take *all message sends* in your app (you know, that can be a fairly long list) and implement *all* of them in the base prototype in js as "return this.noSuchMethod();"-kinda. Hehe, what a hack! Clever, but... hm. And yeah, it also means it only works for messages that are known to be sent at compile time - in other words, sure, you do have a working DNU, but you sure don't have #perform:. We are also unsure about how they produce that list, do they support all messages my app sends, or all messages my app and all the libraries I use sends? Not sure. Dart is a bit dualistic in nature - in some ways it is fully dynamic, and in other perspectives it is quite static. It will be interesting to see where it lands in the end. Reading up on Dart it is quite obvious that they *want* to come as close to the "Smalltalk dynamic way of live environment interactive coding" as they possibly can. But how close can you get with the other constraints they are trying to satisfy? Hard to tell. What I do know though is that Amber is soon taking a few more large steps forward - and it will be really fun to see what the community (both the Smalltalk and the larger HTML5 community including Dartisans) will say when Nicolas new stuff starts to land in github. Am I a teaser? You bet I am. regards, Göran |
|
|
Göran Krampe wrote: > Hi folks! > > I just dropped off Nicolas on the airport here in Sweden, he is going > home after staying with me for a few days and working together with our > common customer (HTML5 app, js mainly, no Amber there). > > Now, apart from showing Nicolas the beautiful Stockholm archipelago :) > we of course also talked about Amber and where things are going with it > and lots of other stuff in the Smalltalk community. > > Personally I haven't had much time at all lately for Amber, but I am > still here, don't worry. > > Nicolas on the other hand showed me *awesome* Amber stuff he has been > working quite hard on, but I don't want to "steal his thunder" so please > look forward to impressive stuff Coming Soon to a browser near you, > sorry Nicolas, but I just had to tell :) > > We also played a teeny bit with Dart, especially taking a closer look at > the js it produces. One thing that we were especially interested in was > how the heck they support DNU (noSuchMethod they call it) without adding > their own lookup procedure. > > It turns out they do a really dirty trick - and we are unsure about how > it will scale when compiling a larger Dart app to js. If there is a Dart > guru lurking, please give us more info. After a "cursory look" it seems > they take *all message sends* in your app (you know, that can be a > fairly long list) and implement *all* of them in the base prototype in > js as "return this.noSuchMethod();"-kinda. Hehe, what a hack! Clever, > but... hm. Well, without knowing it is done this way in Dart, I proposed this solution myself to Nicolas over irc... so more people think it is not such a bad idea... > And yeah, it also means it only works for messages that are known to be > sent at compile time - in other words, sure, you do have a working DNU, > but you sure don't have #perform:. We are also unsure about how they > produce that list, do they support all messages my app sends, or all > messages my app and all the libraries I use sends? Not sure. Perform: I see no problem doing this in Amber so that it works the both way. Shortcut the "known" method sends, and "interpret/compute/simulate" the unknown ones. Of course, I would never propose such a trick if the side-effect would be cutting perform: away. In Amber, this list is easy to produce: whenever you load a method, it contains (and should in .deploy as well) the list of sent selectors. > Dart is a bit dualistic in nature - in some ways it is fully dynamic, > and in other perspectives it is quite static. It will be interesting to > see where it lands in the end. Reading up on Dart it is quite obvious > that they *want* to come as close to the "Smalltalk dynamic way of live > environment interactive coding" as they possibly can. But how close can > you get with the other constraints they are trying to satisfy? Hard to > tell. > > What I do know though is that Amber is soon taking a few more large > steps forward - and it will be really fun to see what the community > (both the Smalltalk and the larger HTML5 community including Dartisans) > will say when Nicolas new stuff starts to land in github. > > Am I a teaser? You bet I am. > > regards, Göran Herby |
|
|
Hi!
On 07/06/2012 11:25 AM, Herby Vojčík wrote: > Göran Krampe wrote: >> It turns out they do a really dirty trick - and we are unsure about how >> it will scale when compiling a larger Dart app to js. If there is a Dart >> guru lurking, please give us more info. After a "cursory look" it seems >> they take *all message sends* in your app (you know, that can be a >> fairly long list) and implement *all* of them in the base prototype in >> js as "return this.noSuchMethod();"-kinda. Hehe, what a hack! Clever, >> but... hm. > > Well, without knowing it is done this way in Dart, I proposed this > solution myself to Nicolas over irc... so more people think it is not > such a bad idea... Yeah, ok, when I wrote "really dirty trick" and "what a hack" I actually meant that it was "sneaky/funny" and not actually bad. Given whatever constraints we have to work with - it obviously is one way of doing these things. >> And yeah, it also means it only works for messages that are known to be >> sent at compile time - in other words, sure, you do have a working DNU, >> but you sure don't have #perform:. We are also unsure about how they >> produce that list, do they support all messages my app sends, or all >> messages my app and all the libraries I use sends? Not sure. > > Perform: I see no problem doing this in Amber so that it works the both > way. Shortcut the "known" method sends, and "interpret/compute/simulate" > the unknown ones. Of course, I would never propose such a trick if the > side-effect would be cutting perform: away. > > In Amber, this list is easy to produce: whenever you load a method, it > contains (and should in .deploy as well) the list of sent selectors. ...but (forgive me from being dense) what do you gain with these shortcuts? I mean, we still do the lookup machinery ourselves, don't we? AFAICT the whole point in Dart is to NOT do lookups yourself and instead rely on js (and thus speed). regards, Göran |
|
|
Göran Krampe wrote: > Hi! > > On 07/06/2012 11:25 AM, Herby Vojčík wrote: >> Göran Krampe wrote: >>> It turns out they do a really dirty trick - and we are unsure about how >>> it will scale when compiling a larger Dart app to js. If there is a Dart >>> guru lurking, please give us more info. After a "cursory look" it seems >>> they take *all message sends* in your app (you know, that can be a >>> fairly long list) and implement *all* of them in the base prototype in >>> js as "return this.noSuchMethod();"-kinda. Hehe, what a hack! Clever, >>> but... hm. >> >> Well, without knowing it is done this way in Dart, I proposed this >> solution myself to Nicolas over irc... so more people think it is not >> such a bad idea... > > Yeah, ok, when I wrote "really dirty trick" and "what a hack" I actually > meant that it was "sneaky/funny" and not actually bad. Given whatever > constraints we have to work with - it obviously is one way of doing > these things. > >>> And yeah, it also means it only works for messages that are known to be >>> sent at compile time - in other words, sure, you do have a working DNU, >>> but you sure don't have #perform:. We are also unsure about how they >>> produce that list, do they support all messages my app sends, or all >>> messages my app and all the libraries I use sends? Not sure. >> >> Perform: I see no problem doing this in Amber so that it works the both >> way. Shortcut the "known" method sends, and "interpret/compute/simulate" >> the unknown ones. Of course, I would never propose such a trick if the >> side-effect would be cutting perform: away. >> >> In Amber, this list is easy to produce: whenever you load a method, it >> contains (and should in .deploy as well) the list of sent selectors. > > ...but (forgive me from being dense) what do you gain with these > shortcuts? I mean, we still do the lookup machinery ourselves, don't we? > AFAICT the whole point in Dart is to NOT do lookups yourself and instead > rely on js (and thus speed). I was dense, too. This was to enable to compile directly to foo._bar_(baz) instead of to smalltalk.send(foo, "_bar_", [baz]) for known selector baz:. And still use smalltalk.send in case of the selector being not known at compile-time. > regards, Göran Herby |
|
|
Herby Vojčík wrote: > > > Göran Krampe wrote: >> Hi! >> >> On 07/06/2012 11:25 AM, Herby Vojčík wrote: >>> Göran Krampe wrote: >>>> It turns out they do a really dirty trick - and we are unsure about how >>>> it will scale when compiling a larger Dart app to js. If there is a >>>> Dart >>>> guru lurking, please give us more info. After a "cursory look" it seems >>>> they take *all message sends* in your app (you know, that can be a >>>> fairly long list) and implement *all* of them in the base prototype in >>>> js as "return this.noSuchMethod();"-kinda. Hehe, what a hack! Clever, >>>> but... hm. >>> >>> Well, without knowing it is done this way in Dart, I proposed this >>> solution myself to Nicolas over irc... so more people think it is not >>> such a bad idea... >> >> Yeah, ok, when I wrote "really dirty trick" and "what a hack" I actually >> meant that it was "sneaky/funny" and not actually bad. Given whatever >> constraints we have to work with - it obviously is one way of doing >> these things. >> >>>> And yeah, it also means it only works for messages that are known to be >>>> sent at compile time - in other words, sure, you do have a working DNU, >>>> but you sure don't have #perform:. We are also unsure about how they >>>> produce that list, do they support all messages my app sends, or all >>>> messages my app and all the libraries I use sends? Not sure. >>> >>> Perform: I see no problem doing this in Amber so that it works the both >>> way. Shortcut the "known" method sends, and "interpret/compute/simulate" >>> the unknown ones. Of course, I would never propose such a trick if the >>> side-effect would be cutting perform: away. >>> >>> In Amber, this list is easy to produce: whenever you load a method, it >>> contains (and should in .deploy as well) the list of sent selectors. >> >> ...but (forgive me from being dense) what do you gain with these >> shortcuts? I mean, we still do the lookup machinery ourselves, don't we? >> AFAICT the whole point in Dart is to NOT do lookups yourself and instead >> rely on js (and thus speed). > > I was dense, too. This was to enable to compile directly to > foo._bar_(baz) instead of to smalltalk.send(foo, "_bar_", [baz]) for > known selector baz:. And still use smalltalk.send in case of the > selector being not known at compile-time. > >> regards, Göran > > Herby |
Re: A few days with Nicolas...
|
In reply to this post by gokr
Meh... It always sounds interesting but taste fake in the end. They insist in not getting it, but don't worry world... natural selection doesn't fail... one day you'll have truly anthropomorphized CPU's and software languages :) On Friday, July 6, 2012 3:39:13 AM UTC-3, Göran Krampe wrote: Hi folks! |
|
|
In reply to this post by gokr
On 6 Jul., 08:39, Göran Krampe <[hidden email]> wrote:
> Hi folks! > > I just dropped off Nicolas on the airport here in Sweden, > ... > > Am I a teaser? You bet I am. > So, when will we see a complete CMS like let's say TYPO3 written in Amber? :) Greets from the beautiful City of Hamburg... |
Administrator
|
In reply to this post by gokr
Göran, Nico, any update om the "awesome" Amber stuff? :) |
Re: A few days with Nicolas...
|
|
Hey there!
I've been very busy with other stuff and didn't have much time for Amber lately. I plan to spend more time on it this month though :) Nico Geert Claes <[hidden email]> writes: > Göran Krampe-3 wrote >> >> ... >> Nicolas on the other hand showed me *awesome* Amber stuff he has been >> working quite hard on, but I don't want to "steal his thunder" so please >> look forward to impressive stuff Coming Soon to a browser near you, >> sorry Nicolas, but I just had to tell :) >> ... >> > > Göran, Nico, any update om the "awesome" Amber stuff? :) > > > > -- > View this message in context: http://forum.world.st/A-few-days-with-Nicolas-tp4638661p4642846.html > Sent from the Amber Smalltalk mailing list archive at Nabble.com. |
Re: A few days with Nicolas...
|
|
sounds great Nico!
glad to hear that
On Fri, Aug 3, 2012 at 1:53 PM, Nicolas Petton <[hidden email]> wrote: Hey there! |
|
Administrator
|
In reply to this post by Nicolas Petton
awesome Amber stuff news? :) |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |