On Mon, Dec 20, 2010 at 8:00 PM, Steve Wart <[email protected]> wrote: > > On Mon, Dec 20, 2010 at 3:54 PM, Julian Leviston <[email protected]> > wrote: > > I'm not actually sure how relevant something that doesn't "join in the > conversation" rather than try to reinvent EVERYTHING is, though... what I > mean by that, is Apple have got very very good at layering their > architecture with replaceable bits... I think this approach is infinitely > useful, because it means if any single piece needs fixing, replacing or > modification, then it can be re-tooled relatively easily and quickly. It's > proper objected-orientedism. (For want of a better word). > > I agree. I think that FONC shouldn't be tied down to an > implementation, but ultimately we have to deploy to some hardware. I > have been very focused on iOS and have struggled with geting Squeak > and Croquet to expose the low-level bits in a productive way. And in > the end I decided if I'm going to do iOS programming, there's no point > in fighting the platform, and so I do it in Objective C where I can > and C++ where I must. > > In fact, I don't really care about platform independence. At all. > > But you must know the edit, compile, download loop is not the most > efficient way to be doing things. We do it because the platform > demands it, and it's the best way to deliver quality to the end-user. > The point of Smalltalk to me is that the programmer is the end-user, > and very few of the dynamic languages I've seen really live up to that > standard. >
I don't think platforms have anything to do with this design trade-off. I think we can capture the trade-off in purely mathematical terms; what Carl Hewitt is attempting to do right now with ActorScript and Direct Logic. If you give up static phasing, then you need inconsistency robustness. This inconsistency arises naturally in distributed, federated systems. No amount of reflection can ease dealing with it, and, in fact, reflection makes you think more clearly about these requirements... Your claim that "The point of Smalltalk to me is that the programmer is the end-user", seems like a non-sequitir. In fact, it is more accurate to say that social processes require the ability to manage inconsistencies and resolve them quickly. We've developed such processes over centuries. For example, in accounting, we have GAAP (Generally Accepted Accounting Principles, even if we appear to be moving to the European system in the US merely for convenience of multi-nationals), and basic concepts like a balance sheet and a general ledger, and the idea that your books have to balance out each accounting "period". What we have yet to develop -- and part of this is the fault of the success of Smalltalk -- is "GAAP for programming". There have been some attempts in the past by really smart programmers, such as Butler Lampson and Paul McJones and others (Vesta software management tool) and even yearly journals/conferences dedicated to software configuration management and version control. But nobody has really dealt with these problems from the perspective of lessons learned from the Smalltalk disaster. And Smalltalk really is "clever". (Sorry Dan Ingalls.) And REST is also "clever", just in a different way. (Sorry Roy Fielding). By the way, just relying on social process observations is not enough. You need to explain it mathematically. That's the challenge in defining "Alternatives to Edit-Compile-Download Loops".
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
