3 ms·

How is it verbose? It has much LESS noise than HTML. IMHO, Lisp is the simplest and smallest readable representation of data structure. I will trade JSON for e

How is it verbose? It has much LESS noise than HTML. IMHO, Lisp is the simplest and smallest readable representation of data structure. I will trade JSON for edn [1] any days of the week [1] https://github.com/edn-format/edn https://github.com/edn-format/edn

grzm 9y ago
I share your zeal, but the answer to apparent incredulity isn't to raise the level. People have different tastes when it comes to programming languages and methods, and that's okay. There's often things we can learn from different techniques. To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing. To their point regarding designers, many are more comfortable working with HTML files than application code. That can be a benefit for many teams. Clearly some lispers agree, as they've implemented alternatives like Mustache templates.
- TeMPOraL 9y ago
  The notion of incredulity probably comes from fact that it's literally impossible for HTML encoded in s-expressions to be more verbose than HTML encoded in HTML! > To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing. One does not exclude another. The "template" can be another lisp function (in another file). > Clearly some lispers agree, as they've implemented alternatives like Mustache templates. Probably popular demand. Personally, I don't think they should be used, like ever. Those template languages were a doubly bad idea. First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities. The concepts of "escaping", "sanitization" or "injection" are only relevant when you're abusing a serialization format instead of working with the language at the appropriate level. Second, they all seem to have started with the assumption that "views don't need code". Each of them, over time, slowly discovered that no, views actually do need to have code, and slowly gained variables, conditionals, loops, function calls... and turned into shitty Turing-complete languages they tried so hard not to become. The problem here was always the premise. Views absolutely do need code, and so they should be written in a proper programming language.
  - codedokode 9y ago
    Writing templates in Lisp, I think, is an awful idea. Template languages have evolved for a long time to include all the things you will probably need. For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time. There are all king of template languages around. There are editors that can highlight the syntax, there are plugins to write HTML faster. I don't imagine how you justify writing your own template engine. Probably that is just a NIH symdrome. > First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities. This can be easily solved by validating HTML code. > The concepts of "escaping", Tenmplate engines do necessary escaping automatically. For example, in Twig you just write <div>{{ user.getName() }}</div> and don't have to worry about escaping. I guess in Lisp you cannot even write user.getName() because it doesn't have objects. > Views absolutely do need code, and so they should be written in a proper programming language. In my experience, template engines like Twig have enough features. If you need soem complicated logic, you can write a helper function.
    - TeMPOraL 9y ago
      > Template languages have evolved for a long time to include all the things you will probably need. Which is what turned them into Turing-complete languages that try to pretend they're not. > For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time. Not much time is wasted, especially that s-exps are faster to write than HTML (especially with editor support). Browsers don't understand templates either, so in both cases you have to do some conversions. I'll give a point to HTML-ish template languages here, but I don't believe the time spent on manually converting large chunks of template code into browser-edible HTML and back is anywhere near the critical path on the project. > This can be easily solved by validating HTML code. That's validating vs. making it literally impossible to emit invalid HTML. > I guess in Lisp you cannot even write user.getName() because it doesn't have objects. Haha. Right. No, Lisp actually has objects. You'd write it as (get-name user), since the syntax for function calls in Lisp is consistent.

grzm 9y ago

I share your zeal, but the answer to apparent incredulity isn't to raise the level. People have different tastes when it comes to programming languages and methods, and that's okay. There's often things we can learn from different techniques. To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing. To their point regarding designers, many are more comfortable working with HTML files than application code. That can be a benefit for many teams. Clearly some lispers agree, as they've implemented alternatives like Mustache templates.

TeMPOraL 9y ago
The notion of incredulity probably comes from fact that it's literally impossible for HTML encoded in s-expressions to be more verbose than HTML encoded in HTML! > To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing. One does not exclude another. The "template" can be another lisp function (in another file). > Clearly some lispers agree, as they've implemented alternatives like Mustache templates. Probably popular demand. Personally, I don't think they should be used, like ever. Those template languages were a doubly bad idea. First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities. The concepts of "escaping", "sanitization" or "injection" are only relevant when you're abusing a serialization format instead of working with the language at the appropriate level. Second, they all seem to have started with the assumption that "views don't need code". Each of them, over time, slowly discovered that no, views actually do need to have code, and slowly gained variables, conditionals, loops, function calls... and turned into shitty Turing-complete languages they tried so hard not to become. The problem here was always the premise. Views absolutely do need code, and so they should be written in a proper programming language.
- codedokode 9y ago
  Writing templates in Lisp, I think, is an awful idea. Template languages have evolved for a long time to include all the things you will probably need. For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time. There are all king of template languages around. There are editors that can highlight the syntax, there are plugins to write HTML faster. I don't imagine how you justify writing your own template engine. Probably that is just a NIH symdrome. > First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities. This can be easily solved by validating HTML code. > The concepts of "escaping", Tenmplate engines do necessary escaping automatically. For example, in Twig you just write <div>{{ user.getName() }}</div> and don't have to worry about escaping. I guess in Lisp you cannot even write user.getName() because it doesn't have objects. > Views absolutely do need code, and so they should be written in a proper programming language. In my experience, template engines like Twig have enough features. If you need soem complicated logic, you can write a helper function.
  - TeMPOraL 9y ago
    > Template languages have evolved for a long time to include all the things you will probably need. Which is what turned them into Turing-complete languages that try to pretend they're not. > For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time. Not much time is wasted, especially that s-exps are faster to write than HTML (especially with editor support). Browsers don't understand templates either, so in both cases you have to do some conversions. I'll give a point to HTML-ish template languages here, but I don't believe the time spent on manually converting large chunks of template code into browser-edible HTML and back is anywhere near the critical path on the project. > This can be easily solved by validating HTML code. That's validating vs. making it literally impossible to emit invalid HTML. > I guess in Lisp you cannot even write user.getName() because it doesn't have objects. Haha. Right. No, Lisp actually has objects. You'd write it as (get-name user), since the syntax for function calls in Lisp is consistent.