The Dreamup: A codeless alternative to the Web

I don't really see this as a Web competitor; all you need is for someone to throw together a dreamup.js and then it should work in every modern browser. No need for a proprietary application.

Secondly, the Achilles' heel of instructions.txt is that a lot of things in web dev are just impossible for describe. Bootstrap and friends go a long way towards given us some sort of standardized terminology to describe common components, but not every site uses them. A lot of sites build their own. At that point the usefulness drops, because instead of saying things like "give them a little space" you have to say things like "give it a margin of 2px on the top, -5px on the left, a solid #f5f5f5 border on the left, a border radius of 20%...."

That being said, this is a good idea. The vast, vast majority of websites do not need to wade outside of what is "normal." Everyone would benefit from having a more accessible alternative to HTML & CSS, given that the current alternatives look like Twitter and Facebook.

This is not codeless, the instructions.txt file that you include in the app is where you write instructions in for what the app is, this is code.

It’s a call for discussion, friends. You may want to go into technical / semantic discussion like nexuist and Splizard here are doing, and that’s fine. A lot of the details are still missing to work through, indees. But if we jump to solve that cognitive dissonance too soon, I feel we may miss meatier parts of the discussion.

The whole point of the article to me seems to be to avoid that temptation to be too pragmatic for a while, and allow space for seeing alternate paths to the future. I admit that this can feel handwavey even to myself, but it can still be valuable to start from a high level view. What if the world proposed by the author were possible and true as is? What kinds of applications would you naively want to build? That's what inspires me here. A worrydream.com sort of approach, perhaps? :)

A familiar dream, that kind of misses the actual challenge of programming is not the syntax. HTML really doesn't take long to learn - at least, not the kind that's being produced here. The hard part is unambiguously describing what you actually want. That's what code is, at a fundamental level - a way of describing exactly what you want in a way that cannot be misinterpreted.

Consider the instructions.txt given; 'This is an application called "My Bikes".'.

Okay, so what does "called" imply here? Is this what you want displayed in a title bar? Or is this the name that should be used for links to this application? Or is this text that should be displayed in large type at the top of the page? Or is this the name you're going to refer to it as in other "instruction.txt" files, when you want to link or reference this app? Or is this the label that should be used when someone adds their app to their phone home screen? Or something else entirely? I would argue that any of these would be valid interpretations of the phrase, but I'd bet that at least some of them would not be what the author originally intended (or even considered) when they wrote the phrase.

Consequently, you might find that you need to say something more like 'This is an application. The browser title bar should be "My Bikes". The displayed heading should be "My Bikes" in large, sans-serif font. When other pages link to this page, they should use the link text 'EricaTheGreat's Bikes'..." etc, etc.

And you can bet that pretty soon, users of this language will start complaining that "I have to type so much to get even the most basic things going. Could I just simplify it down to something like 'title bar: "My Bikes", heading text: "My Bikes", heading size: large, heading font: sans-serif"... "

Well look at that! In making this statement unambiguous, we've just created a very verbose programming language!

It remains as ever a delightful dream, but unfortunately one that doesn't actually solve the real problem - that natural language uses a lot of words to say things that are ambiguous and ill suited to producing the desired outcome.

The trouble I’ve found with English-based languages (Inform 7) is that if you go beyond the intended range of examples, you very quickly start having to learn specific syntax—syntax which could be expressed much more cleanly as traditional code. Always consider how a new language model can integrate or fall back on existing languages.

what about doing your web on word and save as html? doesn't seem like any code at all.