3 ms·
To be fair the author acknowledges this. To make an analogy, this seems to me more like the equivalent of ASM than the equivalent of C, the only reasonable way
by qsort 6y ago
To be fair the author acknowledges this. To make an analogy, this seems to me more like the equivalent of ASM than the equivalent of C, the only reasonable way to make this work is to have a high-level language that "compiles down" to Hope.
- lisper 6y agoSure, but now you've come full-circle: what is that high-level language going to look like, if not a traditional markup language? And if Hope is intended to be object code rather than source code, what's the point of making it a text format at all?
- qsort 6y agoIf I have to be honest I don't see much from this either, but a potential upside is structural separation of text and presentation in a way that's different from HTML/CSS, in this case the content would be pure ASCII text as opposed to a tree structure/object model. I'm not sure I agree with this premise either, the hierarchical structure seems inherently semantical to me, but the argument of the OP is it isn't the case. > what's the point of making it a text format at all? The text part is ASCII, so it make sense to represent it as such. The "presentation" part could be binary.
- Poefke 6y agoThe only reason I used a text format is because I wanted to keep the code as simple as possible. Only introducing extra complexity when I hit a wall somewhere. I don't know if the current format will scale to more complex use cases, but I really like the fact that you can read HTML and reason about it, so I kept to that in Hope as well. As for the text part, that is simple. I like to be able to manipulate text as text. There are many many tools to work with plain text. I can use regular expressions to search through text, get ranges of the result and apply an annotation to those ranges. You lose a lot of that in any other format.