OK reading a single paper on a large project is likely to lead to one arriving at false conclusions. So with that Caveat:
I think this team has like so many before them got the idea that solving Brook's accidental complexity in selected domains leads towards solving the problem of essential complexity.
Anyone who did not live through the era of "fourth level languages" will not have been inoculated against this error. It seems to me that you can always simplify the programming task in specific domains (often with a DSL) but I have yet to have even got a hint of a solution to the problems of applying such approaches to a wider business process.
This document has some interesting ideas! I especially liked the grammar which defines the accessors for a TCP IP header by feeding in an ascii art image of the header.
what would it make it _much_ cooler would be some way to tie in protocol-state-transitions with packet-structure to have machine generated protocol-parsers.
I wish them luck. In my humble opinion, they're making many mistakes. Their core principles aren't abstract enough. "Golden Box" is a technology not a principle -- and it isn't necessary to get where they want to go. As long as they focus on "small and self-describing", they won't go anywhere. Lisp is beautiful in this way, but that's irrelevant. I heard they even pinned-up some code that Ian wrote. Bad move -- no Golden Calves. You have to be able to throw it all out every few months. There are some other things I could say but won't. I respect Alan Kay more than anyone in this industry. So, again, good luck.
Heh. A grammatical glitch. What I meant was, Is there any idea Alan Kay is more closely identified with than "small and self-describing"?
More importantly, I'd like to hear why you think it's the wrong tree. The point of a small and self-describing design is that it provides extensibility and (logical) scalability that other approaches can't match (or even dream of). Why would that have been a good idea in the Smalltalk days but a bad idea now?
I know it makes perfect sense but it's just not going to get them where they want to go. It's not fair to say that and not back it up, but it would take too long to explain. Suffice it to say that 'small' is right, but not in terms of code, and 'self-describing' doesn't even play a role.
hey, friend, how about a warning that your linking to a PDF!
I didn't buy my laptop this year. Or the year before. Or the year before.
It works perfectly fine, until I click on a PDF link.
And because Adobe has to justify their existence, there are a seemingly infinite number of api's that it tells me it's loading. About 1 every couple seconds. It's all I have to look at while it takes over my machine and ticks by.
My old computer will thank you. And all the other owners of small companies with no budgets for zippy new computers will too.
I think this team has like so many before them got the idea that solving Brook's accidental complexity in selected domains leads towards solving the problem of essential complexity.
Anyone who did not live through the era of "fourth level languages" will not have been inoculated against this error. It seems to me that you can always simplify the programming task in specific domains (often with a DSL) but I have yet to have even got a hint of a solution to the problems of applying such approaches to a wider business process.