Re: Pony for Pharo VM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Pony for Pharo VM

ken.dickey
 
Not to discourage people, but I have not seen cases where a "strong"
type system would be able to scale for _real_ Smalltalk applications.

As an example, we are comfortable with something close to "high school
math".

"Rational numbers"
(1/2) + (1/3) + (1/6). "--> 1 "

"Complex numbers"
[ :n | n * n] value: (-4 sqrt). "--> -4 "

"BigNums"
111 factorial. " -->  
1762952551090244663872161047107075788761409536026565516041574063347346955087248316436555574598462315773196047662837978913145847497199871623320096254145331200000000000000000000000000
"

Just this is hugely complex to model in a "type safe" language.

Add metaprogramming (e.g. #doesNotUnderstand:), source level debugging
of live stacks and GC of large object spaces and you have a very large
(space) and very slow (interlocking cache granularity) interpreter.

Please prove me wrong.

$0.02,
-KenD

Reply | Threaded
Open this post in threaded view
|

Re: Pony for Pharo VM

Robert Withers-2
 

On 4/9/20 11:41 AM, [hidden email] wrote:
> and you have a very large
> (space) and very slow (interlocking cache granularity) interpreter.
>
> Please prove me wrong.

What!? That at best Pony on CogSpur64 VM would be a ๐™ซ๐™š๐™ง๐™ฎ ๐™จ๐™ก๐™ค๐™ฌ
(๐™ž๐™ฃ๐™ฉ๐™š๐™ง๐™ก๐™ค๐™˜๐™ ๐™ž๐™ฃ๐™œ ๐™˜๐™–๐™˜๐™๐™š ๐™œ๐™ง๐™–๐™ฃ๐™ช๐™ก๐™–๐™ง๐™ž๐™ฉ๐™ฎ)
๐™ž๐™ฃ๐™ฉ๐™š๐™ง๐™ฅ๐™ง๐™š๐™ฉ๐™š๐™ง? Damn son! That could/would/should mean its ON!
Like chocolate flapjacks and maple syrup! But don't forget the butter,
cause its all butter. CogVM serving breakfast after a long, intense
night! ^,^ A design laboratory.

*waits to hear from Pony, on challenge*
*its all butter*

--
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: Pony for Pharo VM

Robert Withers-2
 
Oops, sorry for all of my shit talking. I have been watching Fox news
streaming all day and just realized it was jacking my amygdala. All
these epinephrines and cortisols, Arggg!

New OFF! I'll run with my dogs and play a little Trombone. I'm better
already. Still a polite and interesting challenge. Please prove Ken wrong.

K, r

On 4/9/20 11:58 AM, Robert wrote:

>
> On 4/9/20 11:41 AM, [hidden email] wrote:
>> and you have a very large
>> (space) and very slow (interlocking cache granularity) interpreter.
>>
>> Please prove me wrong.
> What!? That at best Pony on CogSpur64 VM would be a ๐™ซ๐™š๐™ง๐™ฎ ๐™จ๐™ก๐™ค๐™ฌ
> (๐™ž๐™ฃ๐™ฉ๐™š๐™ง๐™ก๐™ค๐™˜๐™ ๐™ž๐™ฃ๐™œ ๐™˜๐™–๐™˜๐™๐™š ๐™œ๐™ง๐™–๐™ฃ๐™ช๐™ก๐™–๐™ง๐™ž๐™ฉ๐™ฎ)
> ๐™ž๐™ฃ๐™ฉ๐™š๐™ง๐™ฅ๐™ง๐™š๐™ฉ๐™š๐™ง? Damn son! That could/would/should mean its ON!
> Like chocolate flapjacks and maple syrup! But don't forget the butter,
> cause its all butter. CogVM serving breakfast after a long, intense
> night! ^,^ A design laboratory.
>
> *waits to hear from Pony, on challenge*
> *its all butter*
>
--
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: Pony for Pharo VM

ken.dickey
 
On 2020-04-09 14:35, Robert wrote:
> Oops, sorry for all of my shit talking.

Hey.  No worries.

Time to let go and lighten up.

Make each day a celebration.  We are not guaranteed another.

Good on ya,
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: Pony for Pharo VM

Shaping1
In reply to this post by ken.dickey
 

Hi Ken.

 

Not to discourage people, but I have not seen cases where a "strong"

type system would be able to scale for _real_ Smalltalk applications.

 

Youโ€™re right.ย  It doesn't.ย  I'm not suggesting that.

 

The type safety is not for app-level Smalltalk development.ย  It's for building the VM only.

 

I want to use the Pony concurrency model at the Smalltalk level.ย  Thatโ€™s the gist of it.ย  Otherwise, I want a Smalltalk, not a statically compiled language.

 

Six ref-caps that explicitly represent Ponyโ€™s concurrency model in code.ย  They are essentially type qualifiers related specifically to concurrency.ย  The plan is to reduce, if possible, the number of ref-caps the programmer must explicitly use/place in the code when coding a state-machine in Smalltalk, without producing a toy or straightjacket (without making it too simple or too rigid).ย  This may require implementing the VM more as a change to (fork of) Pony instead of using Pony to implement the VM.ย  Iโ€™m not sure yet. ย ย ย 

 

The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load.ย  I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: ย I donโ€™t use Forth because I donโ€™t want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo).ย  Itโ€™s distracting. ย It dilutes focus on the domain work/layer, and tends to cause mistakes there.

 

The programmerโ€™s domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. ย The ref-caps are, however, mixed freely with domain logic in current Pony code.ย  I think thatโ€™s a mistake.ย  But thatโ€™s how it is now.ย  I think of this layer mixing as an intermediate design stage of Pony.ย  I want to abstract-out some or all ref-caps as the VM is built.ย 

 

Pony language is not the remarkable thing here. I see it as a better C or better Rust.ย  Itโ€™s very good (as Algol-60-ish-looking crap-syntaxes go), but thatโ€™s not what this is about. ย Itโ€™s about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps.ย  We would still obviously need to respect the Pony compilerโ€™s determination of where ref-cap use is correct or not.ย  Your Pony program wonโ€™t compile if you donโ€™t use the ref-caps correctly, and you donโ€™t get the guarantees or a running program without the compile.ย  Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees.ย  Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.ย 

 

 

Shaping

 

 

"Rational numbers"

(1/2) + (1/3) + (1/6). "--> 1 "

 

"Complex numbers"

[ :n | n * n] value: (-4 sqrt). "--> -4 "

 

"BigNums"

111 factorial. " -->

1762952551090244663872161047107075788761409536026565516041574063347346955087248316436555574598462315773196047662837978913145847497199871623320096254145331200000000000000000000000000

"

 

Just this is hugely complex to model in a "type safe" language.

 

Add metaprogramming (e.g. #doesNotUnderstand:), source level debugging of live stacks and GC of large object spaces and you have a very large

(space) and very slow (interlocking cache granularity) interpreter.

 

Please prove me wrong.

 

$0.02,

-KenD