Comment by pcfwik | Hacker News Reader

Comment by pcfwik | Hacker News Reader

Parent Full thread

> Let me guess, they published a bunch of papers, did a bunch of experiments like "lets do X but gui" "what if you didn't have to learn syntax" and then nobody ever did anything with any of the work because it was a total dead end.

This response is very confusing to me, and it seems you have a very different understanding of what STEPS did than I do.

In my understanding, the key idea of STEPS was that you can make systems software orders of magnitude simpler by thinking in terms of domain-specific languages, i.e., rather than write a layout engine in C, first write a DSL for writing layout engines and then write the engine in that DSL. See also, the "200LoC TCP/IP stack" https://news.ycombinator.com/item?id=846028

You seem to think they're advocating a Scratch-like block programming environment, but I'm not sure that's accurate. Can you point to where in their work you're finding this focus?

I too believe STEPS was basically a doomed project, but I don't think it's for the reason you've said (moreso just the extreme amount of backwards compatibility users expect from modern systems).

(--- edit: ---)

> You don't make leaps from paying grad students to play around with "how can we make programming better", you get it from all of a sudden an AI can just generate code.

I think this is a more compelling point, but it doesn't seem to explain things like the rise of Git as "a way to make programming (source control) better," and it's not clear how to determine when something counts as an "all of a sudden" sort of technology. They would probably say their OMeta DSL-creation language was this sort of "all of a sudden" technological advance that lets you do things in orders of magnitude less code than before.

That is not a TCP/IP stack in 200 LoC. The thing described is a TCP/IP segment parser with response packet encoder.

The “stack” described [1] can not transmit a payload stream. That also means it avoids the “costly (in terms of lines)” problems of transmit flow control and “reliable send” guarantees in the presence of transmit pipelining needed for even modest throughput. For that matter, it does not even reconstruct the receive stream which is, again, one of the more “costly” elements due to data allocation and gap detection. It also does not appear to handle receive side flow control either, but that could be hidden in the TCP receive engine state which is not described.

These are not minor missing features. The thing described does not bear any resemblance to a actual TCP implementation, instead being more similar to just the receive half of a bespoke stateful UDP protocol.

Now it is possible that the rest of the TCP/IP stack exists in the other lines, as only about 25-ish lines are written down, but you can conclude almost nothing from the described example. The equivalent C code supporting the same features would be similar-ish (under 100 lines) in length, not 10,000 lines. That is not to say it is not a tight implementation of the feature set, but it is not reasonable to use it as evidence of multiple order of magnitude improvements due to representation superiority.

[1] https://worrydream.com/refs/Kay_2007_-_STEPS_2007_Progress_R... Page 44

> That is not a TCP/IP stack in 200 LoC.

I agree --- I mostly think it's interesting as one of the most concrete examples of what they claim to have actually done that I've been able to find.

In general, it's frustrating that, as far as I can tell, they don't seem to have made any of the code from the project open source. Widespread skepticism about their claims due to this is (IMO) justified.

(Edit: for folks interested, it seems like some of the code has found itself scattered around the Web ... https://news.ycombinator.com/item?id=19844088 )

You might want to take a look at the piumarta branch of https://github.com/attila-lendvai/maru/tree/piumarta

This is Attila's attempt at more formally evolving maru through several iterations, and includes gezeira etc.

Personally I find able forth's meta compilation to be more manageable (https://github.com/ablevm/able-forth/tree/current)

But your mileage may vary :)

Disappointingly, the able gui etc was not open sourced, and I fear lost to time.

I guess I'm making a wider claim about the effectiveness of funding 'directed innovation'.

Very often innovations can happen if you fund accomplishing some previously unaccomplished task. Building a nuclear bomb, sending a man to the moon, decoding the genome. The innovations come about because you have smart people trying to solve something nobody has ever tried to solve before, and to do that they slightly revolutionize things.

I'm not aware of a single case where the goal was defined in terms of innovation itself, as in "find a better way to program" and anything useful or even slightly innovative resulted. They are by definition doing something that lots of people are trying to do all the time. It's just very unlikely that you are creating conditions which are novel enough to produce even a slightly new idea or approach.

Generally what you get is a survey of how things are currently done, and some bad ideas about how you could tweak the current state of affairs a little. But if there was a way to just patch up what we already know how to do then it's very likely someone already tried it, really it's likely 1000 people already tried it.

Sorry, added an edit to my above post before I saw this, just to summarize:

I think that's a more reasonable complaint, but I fear it's too vague to be applicable.

The STEPS folks would probably say that a modern computing environment in ~20kloc is something that was previously unaccomplished and thought to be unaccomplishable, but you're writing that off/not counting it as such, presumably because it failed.

On the other end of the spectrum, things like Git (to my knowledge) did come out of the "find a better way to source control" incremental improvement mindset. (Of course, you can say the distributed model was "previously unaccomplished," but the line here is blurry.)

I don't think Git itself is a revolution or new technology. It took what people were trying to do (but with extremely frustrating bad user experience, like taking an hour to change branches locally) and just did it very well by focusing on what is important and throwing away what isn't. It's an achievement of fitting a solution to a problem .

I don't think they DID build a modern computing environment at all. They built something that kindof aped one, but unlike Git they missed the parts that made a computing environment useful for users. It's more like one of those demo-scene demos where you say "Wow how did they get a commodore 64 to do that!?"

If they did build a modern computing environment with 20k LOC, that is a trillion dollar technology. Imagine how much faster Microsoft or Apple would be able to introduce features and build new products if they could do the same work with 2 orders of magnitude less code! That is strong evidence that this wasn't actually the result.

> I don't think they DID build a modern computing environment at all.

I agree that, now, after they've tried and failed, we can say they didn't build a modern computing environment in 20kloc.

My point is just that, when they were pitching the project for funding, there was no real way to know that this "trillion dollar technology" goal would fail whereas nukes/moon mission/etc. would succeed. Hindsight is 20/20, but at the beginning, I don't think any of these projects defined themselves as "doing something that lots of people are trying to do all the time;" instead they would probably say "nobody else has tried for a 20kloc modern computing system, we're going to be the first."

Given they all promised to try something revolutionary, I'm not sure it's fair to claim after-the-fact how obvious it is that one would fail to achieve that vs. another.

But I do take your point that it's important in general not to fall into the trap of "do X but tweak it to be a bit better" and expect grand results from that recipe.

Reply on news.ycombinator.com