I just saw this use of HTML lists and tables for syntax, and I liked it. I think that HTML is the future of all UIs, thus also of PLs.
The possibilities of using HTML instead of plain text are huge, and I wish that the syntax-obsessed would focus on HTML instead of plain text.
skip to main |
skip to sidebar
Manuel Simoni's blog about programming (languages).
Linkroll
- Alarming Development
- Alex Payne — Online Writing
- Arcane Sentiment
- Awelon Blue
- blog.might.net
- Dependent Types Reddit
- Dynamic Aspects
- eighty-twenty
- Existential Type
- Hack the Planet
- HXA7241
- Kazimir Majorinc's Lisp Notes
- Lambda the Ultimate
- Linux Weekly News
- Loper OS
- Luke Gorrie's weblog
- Making it stick.
- One Mistake After Another
- Paul Graham
- Paul Snively's Blog
- Philosophy Made Manifest
- PiLuD: Programming Language Design
- Proggit
- Real World Technologies Forums
- Send More Paramedics
- State of Code
- Stevey's Blog Rants
- Structural insight
- Subvert the dominant paradigm
- Taylor Campbell's blag
- The BileBlog
- The ByteBaker
- Trivium
- Ward's wiki
- wingolog
3 comments:
But note that even the author had trouble editing it; unlike HTML, plain text is really easy to write. Structure takes work, so you might as well put it in the language rather than in the file format.
Tables are interesting, but I think html (or xml, or sgml...) is a mistake. All of them are lousy to parse. Sure, you can get a library to do it for you, but it still means that every time you want to do automatic code transforms or use any tools that actually understand your source, there's a giant round-trip through xerces or similar.
What I'd far rather have is a system where the code is stored in a syntax tree format, with editors that understand the format and can present the code in user-tailored representations.
The advantages of such a system would be legion; it eliminates many of the fiddly little holy wars (tabs/spaces, 1tbf/newline, crlf/lf, indented scope/braced scope/if-endif scope, indent depth, anything involving non-syntactic whitespace...). It removes noise from diffs and revision control submissions. It makes syntax highlighting and automated refactoring dead simple.
It also allows you to view code in different ways *on the fly*. So you could tableify someone else's code if that helped you understand it better. Or you could view it in other representations.
Once the display form of the code is decoupled from the underlying storage mechanism, a host of possibilities open up. You could edit state machines with a box and arrow system, "pure" functions (as in, no side effects, output is a pure function of input) in tables, have exception handling or comments in floating bubbles...
The idea you're on the edge of has huge potential, but [h|x|sg]ml is the Wrong Answer. It's the same thought process that "fixed" C by giving us C++.
(Author of the language here) I am glad you liked the syntax and I liked your post title very much. You hinted at one of my inspirations ;-)
To clarify some things mentioned in the comments:
When I started, I was trying to implement a language that could be embedded into rich text. I believe HTML will eventually eat most of the other rich-text formats.
I am also very comfortable with HTML, so editing lists and tables in it is no big deal for me. Although I had to spend some time to create CSS to make the code in the tables readable.
As for separating code structure from layout... I am not sure. I was thinking along the same lines (thought of extending YAML a little bit to have a plain-text version of Humble). But since I added tables it became harder to achieve this. And I don't want to drop tables now :-).
HTML can be extended with CSS and JavaScript. So you would still probably have more freedom to play with code form than in other formats.
Post a Comment