As pointed out in the comments, this is no longer current. Scott has returned development of Upstart 1.0 to the public eye.
Now that participation is open again, I'd like to encourage anyone who hasn't caught it by now to take a look at Scott's talk from FOSDEM.
A lot of 1.0 is being defined from what's in this talk. Regular readers will probably find that 1.0 doesn't look like what they expected. Scott chose a different design, and I agree with his decision.
A word on the "New Upstart State Machine" series itself: the purpose of the state machine I outlined was simple: prevent another rewrite. It was designed to provide expressive fire power and do nothing else. The hope was to break the cycle of Upstart releases up to that point:
1. Decide on use cases A, B, and C
2. Design and implement Upstart with the tools to meet those cases.
3. Discover use case D, realize that Upstart is useless if it does not meet it.
4. Scrap everything and go to 1
The challenge in designing an Upstart that would beat that is difficult indeed: design software for the use cases we hadn't thought of yet. My approach was to simply develop a very abstract system which was good at generalizing a great many things. Scott's approach was the same, he was simply more conservative in the amount of abstraction applied. He came up with a paired down sibling of object oriented programming, I came up with a hopped up version of second order logic. Ultimately his solution is eons more intuitive (which is not to say simpler. I'd say both systems have a pretty similar number of moving parts), and I'm pleased with the direction things are heading.
Now to code it.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment