Me? I'm happy to describe it as a markup language.
An interesting related question: Is CSS a style sheet language, or now something more? It has variables, performs calculations (using the calc function), can add strings to the page (using a pseudo element) and can create animation. It might not count as a programming language, but it has morphed into a strange hybrid beast between style sheet and programming language.
And a modification would have fit as a title, HN will allow a title of this length:
"Turning HTML Into A Programming Language With an Extension"
You're full title: HTML Is A Programming Language: An extension to HTML to end the eternal discusion
That was, literally, 1 single character over the HN limit. I'm sure you can have figured one out-- I included a colon when I tested it, that's an easy candidate to leave off.
Sure it's not as nice of a soundbite for posting here or your tweet, but it's accurate. I think most of us here will at least scan a title, but often get annoyed when it runs up against the click-bait line. "Is/as" did not stop it from sounding like the opening of an old claim that has started arguments. This really seems like a deliberate misdirection playing off an old argument to garner more attention for your post.
I've been thinking of this lately, with some cognitive dissonance. It's weird because I think of lisp s-expressions like a better version of json. Terraform, AWS and others have tried to add loops and interpolation to json in weird ways that would have been natural for lisp syntax.
But lisp could be encoded into an html-like structure, and it has some nice benefit of more descriptive endings than parenthesis spaghetti, or potentially using what's inside the block as raw data that's easier to pass through than using a triple string quote.
But I've always thought of json as an improvement to XML/HTML. There's been a lot of innovation and creative syntax like dhall and hcl, but some small modifications to HTML could make it more next-gen.
Clojure has basically this in Hiccup, far and away the best HTML templating experience I have ever had. You don't mix in code with HTML, you just write your code exactly as you normally would. It's a fantastic coding experience, and really really made me wish for something similar in Elixir.
FWIW, after spending some time exploring JSX implementations I think JSX is actually more spiritually aligned which lisp/s-expressions than Hiccup is. JSX commonly has a mental model that maps to hyperscript (which is a good baseline model), and that aligns with Hiccup perfectly. But JSX isn’t hyperscript, it’s a DSL that doesn’t define any runtime semantics. It’s also commonly associated with React or similar VDOMs, but nothing specifies that it actually evaluates to that. The only thing that’s specified is that it’s an expression and has specific expression syntax.
An increasingly popular example of how far that can be taken is Solid/DOM Expressions, which eliminate JSX at compile time and produce reactive DOM calls. It’s easy (at least since I’ve been exploring the space) to imagine compiling the same JSX to absolutely different implementations.
Granted Hiccup lives in a language with first class macros so it’s easy to imagine the same there too! But Hiccup itself is essentially hyperscript, and would need to be executed in a macro designed for that to be as versatile as JSX.
(Here’s hoping there’s interest in that! Every time I dive in this space I find myself wishing it all existed in a lisp and not in a Wild West of AST tooling)
Maybe I'm just an idiot here (haven't really used JSX outside of React) but what would you consider spiritual alignment to s-expressions? There's a lot of baggage that comes along with them, and Hiccup carries some but not all, but at the end of the day Hiccup is actually composed of literal s-expressions.
I hoped I explained the position clearly in the first place, but I’ll try again. Ultimately Hiccup is hyperscript in Clojure syntax. It’s literally s-expressions, yes, and insofar as that’s true so is JSX compiled to h or equivalent. But JSX’s compilation target is undefined until specified by the developer, and like a lisp DSL it can be and often is compiled from its list structure into semantically very different computations. Again, all possible with Hiccup, but at least from what I saw when I worked in Clojure that wasn’t typically the case, it was almost always a very direct 1:1 mapping to hyperscript. Which is fine, it’s a good model for rendering UI! I just think it’s fascinating that I see more application of the advantages of lisp (macros, DSLs, creative/clever optimization of using and computing essentially a list of symbols) in the JSX space.
For others following along at home who haven't heard of hyperscript before, you can track down leads by searching for react-hypescript - otherwise you'll endup at https://hyperscript.org/docs/ which seems to also be a html/js system but not what is referred to here.
IOW similar to https://github.com/goodeggs/teacup and a few other libraries that produce markup from inside a programming language with minimalized syntactic fuzz?
Oh that looks neat! I mentioned Hiccup because the person I replied to specifically called out lispy languages, but yeah I saw that there were similar options for other languages.
Lispers seemingly want to see everything as s-expr ;)
In the case of SGML-heritage markup like HTML, often enough I've seen them fail to understand that it's not so much about arbitrarily nested element structures but about content models where an element contains a sub-element sequence specified by a regular expression (aka regular tree languages). This model information is then used to infer omitted tags, etc. It's also quite different from JSON.
The big difference between Genshi and Jinja (which ended up winning) is that Genshi templates are valid XHTML using the "py:" XML namespace for control flow, and Jinja templates use their own syntax (and therefore can template things other than XML).
I love Genshi, and still occasionally maintain a big Python project that uses it for several purposes (generating html, and processing xml from and to various formats)!
Genshi was based on an earlier Python XML templating system called Kid, which is what TurboGears used by default, before switching to Genshi.
You write Genshi templates as XML (although it also supports plain text templates), and it had serializers that translated the xml streams your templates produce to xhtml or different varieties of html.
Genshi is also great for generating other formats of xml, much easier to use and more powerful than XSLT.
For example, I used it to generate tediously repetitive and low level VML and CCML files for an interactive voice response system, by writing high level Genshi macros and xml data, which felt a lot like Lisp programming!
Genshi is so simple (which makes it easy to learn and use), it would be trivial to implement a Genshi-compatible xml processor in JavaScript, using JavaScript expressions to evaluate strings for if conditionals, variable bindings, etc.
It may be 15 years old, but I'd joyfully use Genshi again to transform XML to XML, long before I ever considered coming within a mile of XSLT (yech).
My impression of XSLT is that there were representatives from every different programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough of what was special about their own paradigm into the standard to showcase it while sabotaging the others and making them all look foolish, but not enough to actually get any work done or lord forbid synergistically dovetail together into a unified whole.
The only way I was ever able to get anything done with XLST was to use Microsoft's script extensions to drop down into JavaScript and just solve the problem with a few lines of code. And that begs the question of why am I not just solving this problem with a few lines of JavaScript code instead of inviting XSLT to the party?
But for generating HTML with JavaScript/TypeScript now, I prefer Svelte. But partially because it has a lot of similarities with Genshi and OpenLaszlo.
OpenLaszlo is another XML/JavaScript based programming language I really enjoyed using, but that's now obsolete. It was a lot like Adobe FLEX, but it existed before FLEX, and it was designed to abstract the Flash player away instead of locking you into the Flash player like FLEX was. You wrote xml files with embedded JavaScript (ActionScript for FLEX) scripts and expressions. And the Laszlo compiler could compile it into either a .flv file that ran in the Flash player, or JavaScript/HTML that ran identically in the web browser.
I've written about OpenLaszlo before. (Excerpting old posts and updating broken links to archive.org):
DonHopkins on May 16, 2014 | parent | context | favorite | on: What web developers thought of in the noughties as...
Some alternatives to MVC for user interface programming that I've used and love are constraints / data binding / events and delegates.
I worked on the internals of "Garnet", a constraint based user interface management system written in Common Lisp on X11 (Brad Meyers' research system developed in the 90's at CMU) -- http://www.cs.cmu.edu/afs/cs/project/garnet/www/papers.html -- and also on the internals and applications of "OpenLaszlo", an open source cross platform XML/JavaScript based web programming system that supports Flash and browser JavaScript/HTML.
I've used OpenLaszlo a lot, and I will testify that the "instance first" technique that Oliver describes is great fun, works very well, and it's perfect for the kind of exploratory / productizing programming I like to do. (Like tacking against the wind, first exploring by creating instances, then refactoring into reusable building block classes, then exploring further with those...)
OpenLaszlo's declarative syntax, prototype based object system, xml data binding and constraints support that directly and make it easy.
OpenLaszlo's declarative syntax and compiler directly support instance first development (with a prototype based object system) and constraints (built on top of events and delegates -- the compiler parses the constraint expressions and automatically wires up dependences), in a way that is hard to express elegantly in less dynamic, reflective languages. (Of course it was straightforward for Garnet to do with Common Lisp macros!)
skybrian on Dec 20, 2019 | parent | context | favorite | on: Homoiconicity isn’t the point (2012)
This seems similar to Ant's relationship to XML?
DonHopkins on Dec 20, 2019 [–]
That Ant is a domain specific language for translating XML into Java stack traces?
skybrian on Dec 20, 2019 | parent [–]
I meant that Ant is built on a generic language for representing data.
But XML isn't a great choice and JSON wouldn't work well either. S-expressions are popular with Lisp programmers and unpopular with most other people.
It seems like there might be some other solution?
DonHopkins on Dec 20, 2019 | root | parent [–]
My remark was just an old Java joke I repurposed for Ant!
"Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back
OpenLaszlo used XML with embedded JavaScript in a way that let you extend XML by defining your own tags in XML+JavaScript. I've done a lot of work with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML.
OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele).
The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades.
OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995.
>Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development.
>Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case.
The important bit here being that the custom element API simply doesn't allow declaring all relevant features of elements except their names.
Whereas (SGML) DTDs such as in any DTD for HTML before HTML5, elements were declared like this
<!element img - - EMPTY>
for elements with declared content EMPTY ("void elements" in HTML5 parlance), and
<!element html O O
(head,body)>
as a basic example for tag omission/inference, where given these tag omission indicators (the letter O in the respective position), you can omit the html tags (and also head, and many other start- and end-element tags) when SGML can unambiguously infer those for you.
To down voters: No seriously, it doesn't. XHTML has self-closing tags but HTML does not. It will happily ignore your self-closing tags if you have them but it accomplishes nothing. Self closing tags lived and died with XHTML.
> Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
> It will happily ignore your self-closing tags if you have them but it accomplishes nothing.
Sure. They are optional for HTML elements. That’s not the same thing as “HTML doesn’t have them”. HTML has them, understands them, and chooses to only do something with them for foreign elements.
The problem with using it in this situation is not that HTML doesn’t have self-closing tags, it’s that custom elements cannot be void elements.
Foreign elements are elements from XML namespaces so obviously XML rules apply.
> That’s not the same thing as “HTML doesn’t have them”.
HTML has always ignored them. They have no affect on any HTML element. If you attempt to use them as in XML, on normal elements, they do not close that element. If you use them on void elements, they obviously also do nothing. It's utterly meaningless in HTML.
Until HTML5 came along, they were the start of a NET. It was incorrect syntax that would probably end up causing a parse error later in the document thus mangling it. However because browsers didn't fully comply with SGML-based HTML parsing, the mangling didn’t happen and the result was that this syntax mistake would have no effect. Two bugs cancelling each other out.
That is a different situation to HTML5, which explicitly states that it’s an acceptable no-op.
“This is okay, but you don’t need to do anything with it” is a different situation to “This is a NET” followed by “I don’t know what a NET is, so I’m going to mis-parse it as an attribute and then ignore it because it makes no sense as an attribute”.
No, I wanted to try the DOMParser API and build a programming language that was valid HTML and would be closest to the HTML spirit, that's why I built the expressions as a stack language, to avoid introducing syntax for arithmentic, comparison and boolean expressions. It would be much concise with custom syntax for that but further away from HTML
Your <Computer> scientists were so preoccupied with whether or not they could, they didn't stop to think if they should. <-- seemed very relevant. I'm still not sure if I'm impressed or horrified.
The popular YouTube channel Computerphile tackled this topic back in 2016:
HTML IS a Programming Language (Imperative vs Declarative): https://www.youtube.com/watch?v=4A2mWqLUpzw
Me? I'm happy to describe it as a markup language.
An interesting related question: Is CSS a style sheet language, or now something more? It has variables, performs calculations (using the calc function), can add strings to the page (using a pseudo element) and can create animation. It might not count as a programming language, but it has morphed into a strange hybrid beast between style sheet and programming language.