11–20 of 21 posts
So close to BNF, and so clear in its deviations. Would be nice if I could use something like this to extend Python or JS and compile to them...
Yes, TCP/IP is damned simple if you model it as a trivial lock-step protocol. And this is a slick little piece of code. But it has nothing whatsoever to do with the 10,000+ lines of code that modern operating systems deploy to allow hundreds of competing TCPs to figure out how to share a link. Interview question: what's the important thing TCP provides over UDP? Fail answer: I don't know. Push answer: Reliability. Wi…
Can you explain why there would be hundreds of competing TCPs? I thought there were only a handful (Tahoe, Reno, Vegas, New Reno et al) of popular algorithms for the congestion control bit but it's all still TCP as specced in RFC 2581, no? From where does all the complexity come?
The "meta-meta language-language" he mentions is OMeta. OMeta combines parsing and lexing and allows you to build your AST in your host language. It's really expressive and beats the pants off any other parsing framework I've used. The Viewpoints group is doing some of the most exciting work in CS right now, there's a lot of other interesting ideas they've been working on. There are Python and Ruby implementations av…
http://irbseminars.intel-research.net/ (since this link is very interesting in its own right, i am going to post it directly to HN as an article)
The "meta-meta language-language" he mentions is OMeta. OMeta combines parsing and lexing and allows you to build your AST in your host language. It's really expressive and beats the pants off any other parsing framework I've used. The Viewpoints group is doing some of the most exciting work in CS right now, there's a lot of other interesting ideas they've been working on. There are Python and Ruby implementations av…
Solving a problem is hard. Generalizing it to a class of problems is harder. Encapsulating it in a language with specialized syntax and semantics is harder still.
I think this is one reason that DSLs are not that popular, and is one reason why most new languages mimic existing languages like crazy (apart from for user-familiarity to ease adoption). The exceptions, like brainfuck and lolcats, use familiar semantics; and are only novel in syntax.
As for a Moore's Law for software, I'm going with Fred Brooks' Law of "No Silver Bullet". Complexity is hard, the best we can do is abstract away foundational concepts into components, as we understand them, and then SOTSOG.
The TCP/IP diagram syntax is really cool - but because it's clear, not because it's short; I think the parsing code in C would actually be shorter than the ASCII art.
Earlier quoted context omitted.
There's a post about the background and motivation for the OS (Renraku) here: http://daeken.com/renraku-future-os If you want to talk more about it or OS dev in general, feel free to ping me on IRC (Daeken on freenode) or on AIM (bloomfilter).
Are you doing this for fun or do you have something else in mind ? I'm curious :)
It was a risk though, because I had to trust that I understood the problem domain well enough to invest a lot of time in the parser/interpreter. - First comment on blog http://www.moserware.com/2008/04/towards-moores-law-software... Solving a problem is hard. Generalizing it to a class of problems is harder. Encapsulating it in a language with specialized syntax and semantics is harder still. I think this is one reas…
Note that Fred Brooks argues for conceptual integrity, provided by a single human being, as the most important guarantee of product quality. If you use components, then you are accepting a system partitioning that has been decided many layers above you. If you design languages, then you cut out most of those layers. This gives you far more control over product quality.
Yeah, it's hard. Quality is hard. If your primary goal is anything other than quality, you will probably not produce a product with much of it. That's the real reason why there's no silver bullet.
Yes, TCP/IP is damned simple if you model it as a trivial lock-step protocol. And this is a slick little piece of code. But it has nothing whatsoever to do with the 10,000+ lines of code that modern operating systems deploy to allow hundreds of competing TCPs to figure out how to share a link. Interview question: what's the important thing TCP provides over UDP? Fail answer: I don't know. Push answer: Reliability. Wi…
It was a risk though, because I had to trust that I understood the problem domain well enough to invest a lot of time in the parser/interpreter. - First comment on blog http://www.moserware.com/2008/04/towards-moores-law-software... Solving a problem is hard. Generalizing it to a class of problems is harder. Encapsulating it in a language with specialized syntax and semantics is harder still. I think this is one reas…
Given that DSLs are hard, it does not follow that sticking "foundational concepts" into "components" is a better strategy than DSLs. If you write a DSL, you are standing on the shoulders of real giants. If you rely on components, you are going with the recently formed current conventional wisdom, and you are standing on the shoulders of relative peons. Note that Fred Brooks argues for conceptual integrity, provided b…
In what sense do you mean that? Serious question, not sarcastic. It seems to me that if you build a DSL you're not standing on anybody's shoulders, which seems rather a disadvantage, but I say this to show you what I'm not understanding in your point, not as a criticism, as I believe you meant something else.
Yes, TCP/IP is damned simple if you model it as a trivial lock-step protocol. And this is a slick little piece of code. But it has nothing whatsoever to do with the 10,000+ lines of code that modern operating systems deploy to allow hundreds of competing TCPs to figure out how to share a link. Interview question: what's the important thing TCP provides over UDP? Fail answer: I don't know. Push answer: Reliability. Wi…
Can you explain why there would be hundreds of competing TCPs? I thought there were only a handful (Tahoe, Reno, Vegas, New Reno et al) of popular algorithms for the congestion control bit but it's all still TCP as specced in RFC 2581, no? From where does all the complexity come?
That's what TCP actually buys you.
You can make a reliable UDP protocol with a few tens of lines of code. It's called "TFTP", and it's god-awful slow.
