←back to thread

218 points mdhb | 6 comments | | HN request time: 0s | source | bottom
Show context
taeric ◴[] No.44392596[source]
Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop.

Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is inevitable that someone will want to template something that isn't well formed, but can combine into a well formed thing. And then you are stuck trying to find how to do it. (Or correlated entities on a page that are linked, but not on the same tree, as it were. Think "label" and "for" as an easy example in plain markup.)

If I could wave my magic wand, what we need is fewer attempts to make templates all fit in with the rube goldberg that is the standard document layout for markup. People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well. Sure, you might have to do math to get things to fit, but why do we feel that is something that we have to force the machine to do again and again and again on the same data?

replies(9): >>44392668 #>>44394054 #>>44394866 #>>44395165 #>>44395166 #>>44396349 #>>44396377 #>>44396559 #>>44400705 #
wahern ◴[] No.44392668[source]
> Also hard not to feel like this is reaching hard to try and recreate xslt.

I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT.

I think where XSLT fell over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.

replies(10): >>44392743 #>>44393457 #>>44393524 #>>44393568 #>>44394220 #>>44396687 #>>44397104 #>>44397246 #>>44398865 #>>44403888 #
notpushkin ◴[] No.44393524[source]
I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day.

I also have a simple playground for XSLT: https://xsltbin.ale.sh/

replies(1): >>44394296 #
nine_k ◴[] No.44394296[source]
XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks.

But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.

replies(4): >>44394413 #>>44395604 #>>44395862 #>>44398906 #
agumonkey ◴[] No.44394413[source]
I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
replies(2): >>44394473 #>>44398941 #
1. nine_k ◴[] No.44394473[source]
It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
replies(1): >>44394489 #
2. agumonkey ◴[] No.44394489[source]
The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
replies(1): >>44396191 #
3. HelloNurse ◴[] No.44396191[source]
Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.

XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.

replies(2): >>44396925 #>>44397177 #
4. agumonkey ◴[] No.44396925{3}[source]
I get it, but it's hard to track
replies(1): >>44397171 #
5. HelloNurse ◴[] No.44397171{4}[source]
If by "hard to track" you mean not knowing what template is producing an observed bad output, the modularity of self-contained templates and XPath expression is likely to help with debugging.
6. friendzis ◴[] No.44397177{3}[source]
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible