Re: Description of the Amber approach in one sentence?

On 1/25/12, Göran Krampe <[hidden email]> wrote:
> Hi!
>
> "OK, back to Amber. Your approach is to build a Smalltalk runtime VM
> out of Javascript and execute it. Did you ever try just translating
> the ST code to its JS equivalent and running that under a JS
> environment ? "
>
> No, Amber is not a "VM in js" - I am curious, why do you think it is?

Maybe because the Google group description is:
"Amber is an implementation of the Smalltalk language that runs on top
of the JavaScript runtime."

This description does not capture that Amber Smalltalk is _compiled_
to a JavaScript program which may be kept in an independent file and
run on any JavaScript interpreter.

Any suggestions for a better definition?

Hannes

> Amber *compiles* Smalltalk into js, very much like a regular Smalltalk
> compiles st to bytecodes. BUT... in order to support Smalltalk semantics the
> generated js is typically a LOT of function calls, so we do currently take a
> fair hit performance wise. Yes, we have a small machinery for so called
> speculative inlining, but there is a lot of room for smarter compilation. We
> should probably peek at what others do in this area.
>
> If you wish to help - the source for the Compiler etc is all there. The
> parser is in js, but you do not need to mess at that level since we have a
> proper AST to work with.
>
> regards, Göran
>

Amber is a full Smalltalk development environment that compiles to javascript.

Laurent

On Wed, Jan 25, 2012 at 3:40 PM, H. Hirzel <[hidden email]> wrote:

On 1/25/12, Göran Krampe <[hidden email]> wrote:
> Hi!
>
> "OK, back to Amber. Your approach is to build a Smalltalk runtime VM
> out of Javascript and execute it. Did you ever try just translating
> the ST code to its JS equivalent and running that under a JS
> environment ? "
>
> No, Amber is not a "VM in js" - I am curious, why do you think it is?

Maybe because the Google group description is:
"Amber is an implementation of the Smalltalk language that runs on top
of the JavaScript runtime."

This description does not capture that Amber Smalltalk is _compiled_
to a JavaScript program which may be kept in an independent file and
run on any JavaScript interpreter.

Any suggestions for a better definition?

Hannes

> Amber *compiles* Smalltalk into js, very much like a regular Smalltalk
> compiles st to bytecodes. BUT... in order to support Smalltalk semantics the
> generated js is typically a LOT of function calls, so we do currently take a
> fair hit performance wise. Yes, we have a small machinery for so called
> speculative inlining, but there is a lot of room for smarter compilation. We
> should probably peek at what others do in this area.
>
> If you wish to help - the source for the Compiler etc is all there. The
> parser is in js, but you do not need to mess at that level since we have a
> proper AST to work with.
>
> regards, Göran
>

Not said:
Its also not bloated like Java or conventional ST implementations.

On Jan 25, 8:15 am, leonsmith <[hidden email]> wrote:
> Thanks for the comments. I understand compilers and have written one.
> Basically all compilers are translators, either they spit out machine
> code or tokens. In the latter case a Virtual machine ( a make-believe
> CPU that has an instruction set made up of those tokens ) executes
> those tokens. The real advantages I see in having JS code generated
> rather than tokens are:
>    1. No VM needed as each browser contains one already for JS.
>    2. JS developers could understand and modify the generated code
> themselves with no knowledge of ST, just OOP.
>    3. The ST developer loses nothing. They still code in ST and use
> all the ST tools we love.
>
> There are probably more, but I know from experience that number 2
> makes Amber an easier sell to Senior Management because of the huge
> base of JS developers they can hire from compared to the small (but
> brilliant) group of ST developers. Also as new hardware is invented
> and the JS people add support for it, Amber is ready to go. As long as
> JS is not obsolete Amber will never be either.
>
> If you have coded in ST for any length of time you know that other
> languages (including JS) can do a lot of the same things, but the
> nature of ST forces you into OO thinking. Its very hard to go back to
> procedural crap.
>
> I just started thinking about this when I was trying to debug my app
> at runtime. It was no longer ST or the JS equivalent. I was trying to
> debug a VM (or interpreter) written in JS.
>
> My two cents and I expect much criticism for it.
>
> On Jan 25, 7:32 am, Guido Stepken <[hidden email]> wrote:
>
>
>
>
>
>
>
> > IMHO, Amber is just adding Smalltalk syntax to common available JavaScript
> > libraries. Smalltalk itself has a complete different design approach:
>
> > Smalltalk offers a habitat for "living objects", floating around in RAM,
> > communicating to each other, being realtime statefully saved into a object
> > database called "image", controlled and debugged by tools, that are written
> > in Smalltalk itself.
>
> > Amber offers a realtime compiler, that translates the philosophical mental
> > modell of communicating, living objects into JavaScript syntax, that is
> > again realtime compiled directly into machinecode, with the great
> > advantage, that it can make use of thousands of already written JavaScript
> > libraries as well as bindings to all available hardware and interfaces, as
> > there is touch, mouse, sound, GPS, barometer, gyro, compass, videoin, GPU
> > and Open/WebGL AND the full set of free available external Google/Facebook
> > API's, as there are maps, voice/picture recognition, navigation, route
> > planning, traffic jam warning, weather forecast, mail, sms, contact
> > databases, social software, independent of hardware, because of browser
> > standards.
>
> > Amber therefore IS THE new milestone in Smalltalk programming.
>
> > regards, Guido Stepken
> > Am 25.01.2012 15:53 schrieb "laurent laffont" <[hidden email]>:
>
> > > Amber is a full Smalltalk development environment that compiles to
> > > javascript.
>
> > > Laurent
>
> > > On Wed, Jan 25, 2012 at 3:40 PM, H. Hirzel <[hidden email]>wrote:
>
> > >> On 1/25/12, Göran Krampe <[hidden email]> wrote:
> > >> > Hi!
>
> > >> > "OK, back to Amber. Your approach is to build a Smalltalk runtime VM
> > >> > out of Javascript and execute it. Did you ever try just translating
> > >> > the ST code to its JS equivalent and running that under a JS
> > >> > environment ? "
>
> > >> > No, Amber is not a "VM in js" - I am curious, why do you think it is?
>
> > >> Maybe because the Google group description is:
> > >> "Amber is an implementation of the Smalltalk language that runs on top
> > >> of the JavaScript runtime."
>
> > >> This description does not capture that Amber Smalltalk is _compiled_
> > >> to a JavaScript program which may be kept in an independent file and
> > >> run on any JavaScript interpreter.
>
> > >> Any suggestions for a better definition?
>
> > >> Hannes
>
> > >> > Amber *compiles* Smalltalk into js, very much like a regular Smalltalk
> > >> > compiles st to bytecodes. BUT... in order to support Smalltalk
> > >> semantics the
> > >> > generated js is typically a LOT of function calls, so we do currently
> > >> take a
> > >> > fair hit performance wise. Yes, we have a small machinery for so called
> > >> > speculative inlining, but there is a lot of room for smarter
> > >> compilation. We
> > >> > should probably peek at what others do in this area.
>
> > >> > If you wish to help - the source for the Compiler etc is all there. The
> > >> > parser is in js, but you do not need to mess at that level since we
> > >> have a
> > >> > proper AST to work with.
>
> > >> > regards, Göran