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.
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*
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.
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*
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.