1,228 karma · joined July 4, 2009
http://selflanguage.org
http://russell-allen.com
http://russellallen.com.au
Ideally this story should be changed to this URL which has further comments by the author attached to it. Also The Conversation is a legitimate Australian academic site.
It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs[1], though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Tuffle's approach? Or can Truffle realistically aim for the best of both worlds?
One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?
[1] https://bibliography.selflanguage.org/_static/third-generati...
I vaguely recall some mention in one of the docs I read a while back that you were having difficulties with the JIT causing noticable pauses/latency in interactive environments like Morphic, comparison to the OpenSmalltalkVM.
Am I recalling correctly, and if so is it still the case?
And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!
There wasn't any automatic way to go from the morph instances to equivalent morph constructors, or any way to save the morph instances to copy and use later. So I ended up ignoring the instance manipulation and just coded morph creation methods.
In this way, the morph class hierarchy became much like a hierarchy of factories.
This mattered when I was doing a GUI to run on my Compaq iPaq because a lot of morphs (such as menus) were being created afresh each time they were needed. This was really slow and I only made it usable by caching the created menus and only displaying them when needed.
On Self I would have just copied the previously constructed menuMorph prototype and displayed it (if of course I had been able to port the huge pile of C++ that is the Self VM to the iPaq :)
This was ages ago though and I haven't played properly with modern Squeak or Cuis.
I did have to do some persuading to get IT to install the plugin in the first place though.
It was doomed tech in hindsight though, together with all the other plugins.
Yes, yes, I know. But...
So how far off is Unicode from being 'done'? At what point will they be able to stop adding characters and scripts?
1: https://www.forbes.com/sites/natalierobehmed/2016/08/25/the-...
I’m not proud, but I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate.
But it is a little unsatisfactory to have this ad-hoc method of hard forking. Maybe there should be in future some sort of public process to determine whether an action is consistent with the intentional meaning of the contract (as opposed to the machine meaning). We could all agree to appoint some qualified person to hear disputes and determine whether the code has got it wrong and we should fix the code with a hard fork. Let's call that person a 'judge'.
Now that judge will need to have procedures and rules. He or she isn't deciding on a whim, after all. These rules will set out things like what evidence the judge can look at to determine the intentional meaning of the contract. Just for giggles, let's call one of those rules the 'parol evidence rule'. Also, we don't want anyone to be able to bug the judge and waste their time, so we need some rules as to who can ask the judge to look at a dispute. I'm feeling creative, so let's call those rules 'standing rules'.
What would be really fabulous is if this system could be paid by the taxpayer out of general revenue. That way we can reduce the likelihood of the biggest, richest investors bribing the judges.
But this is obviously all fantasy. No one would ever build such a system.
The linked description is a little out of date but all the basics are still correct. It's quite a flexible system.
[1]: http://pharo.org/ [2]: http://squeak.org/ [3]: http://www.jvuletich.org/Cuis/Index.html
For most lawyers out drafting contracts, we're still in the days of mainframes. We write code by hand which will probably never be run on a real judge, but we hope we haven't made any bugs.
So I don't really understand, but I'm not going to force my tastes on others.
Bald's Leechbook is fascinating for many reasons. One in particular they refer to in the article - the local Anglo-Saxon remedies are in general lacking in theory and so more or less evidence based. Later medieval medicine was possibly in many ways worse - Roman and Greek ideas of the four humours were imported and applied as received truth. Later medicine was much more likely to take the approach of "Who are ya going to believe? Aristotle or your lyin' eyes?"
Anglo-Saxon medicine had no overarching theory to apply. So their salves and potions and magic incantations tended to be adhoc, complicated, and, occasionally, actually worked.
Just a comment from someone not in the US :)