>>> Progress Today
Most of the storage framework is now written, which means there will soon be an easy way to save and restore Dryice objects (including the bytecode which is generated by the compiler).
I also did a fair bit of work with the webpage, so there's a bit more information there now, including an outline/roadmap and a list of features I want the language to have.
>>> Musings about Object and Functional Models
So Dryice is (or will be) a weird mix of functional and object-oriented models. Functional models are good, especially in threaded programming, because they tend to assume most data structures are immutable. Immutable data structures are less complex code-wise and don't need locking (locking requires a lot of overhead). So Dryice's data structures will be as immutable as they can be, and I'll only allow changes (and do locking) where I really need to.
But I also like the object-oriented paradigm. My experience writing software so far has shown me that it's an incredibly powerful way to do things, and I don't think any modern language is complete without it. Hell, I'll admit it, OOP is central to my way of thinking about programs. ;)
The problem is, to be really useful, objects need to be mutable. (This certainly isn't true for all objects, but it is true for a non-trivial subset.) This is fine if you have proper locking in place for those that need it, but there is a danger that objects (I am speaking here of Dryice objects, not native C++ objects) may be touched by multiple threads before they are fully constructed. I don't think I need to explain why this is bad.
So my current dilemma is this: if Dryice constructors can execute arbitrary (byte)code (including spawning/touching other threads), how do I prevent other threads from getting hold of an object before it gets to a consistent state?
My intuition suggests there is only one solution to this problem ... collect all the object's data members (by calling its various constructors), and wait to create the object itself until the very last moment. But I guess we'll see how the details shake out in implementation.
22:41:22 up 1 day, 21:24, 3 users, load average: 0.24, 0.06, 0.02