3 ms·

Thumbs up for actually giving an example! Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable

Thumbs up for actually giving an example! Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable.

deleted 11y ago
[deleted]
wz1000 11y ago
> Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable. That is only because this is Lisp that generates HTML. Also, in the example you had given, there are no closing tags. Closing tags are just superfluous visual clutter and are not actually needed. To take an example from http://c2.com/cgi/wiki?LispVsXml http://c2.com/cgi/wiki?LispVsXml This XML <dictionary> <email>electronic mail</email> <html>hypertext transport language</html> <xml>extensible markup language</xml> </dictionary> can become (dictionary (e-mail "electronic mail") (html "hypertext transport language") (xml "extensible markup language")) As you can see, all the superfluousness of the XML syntax is lost and reduced to its bare minimum.
- founderling 11y ago
  That is only because this is Lisp that generates HTML. Ok, so it is not the way you initially stated '<img id=animal src="my_kitten.jpg"> becomes (html [:image {:id "animal" :src "my_kitten.jpg"}])'. You rather showed an example of how to create html elements programmatically. Then you should compare it to JS: Your ClojureScript: (html [:image {:id "animal" :src "my_kitten.jpg"}]) My JS: html("image",{id:"animal",src:"my_kitten.jpg"}) If we use a function html(elementType,properties) that creates an element. Looks pretty nice to me.
  - wz1000 11y ago
    Yes, my second example which translated XML to equivalent Lisp would be better at illustrating my point. With a Lisp, you don't need HTML as there is no distinction between code and data. Your Lisp is rendered and displayed on screen. It doesn't emit an intermediary language. How do you programmatically manipulate this "data"? Within Lisp itself. Lisp acts as both HTML and JavaScript. Lisp programmers regularly do this with the power of Lisp macros. I suggest you read the "Lisp vs XML" page I linked to in order to understand this better. Lisp directly exposes its syntax tree to the programmer and allows them to manipulate it to their liking.
    - founderling 11y ago
      Lisp acts as both HTML and JavaScript So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure. I like the content/presentation/behavior separation from a developers point of view and from a users point of view. As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely. As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
      - wz1000 11y ago
        > So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure. No, only thing that goes away the cognitive burden of keeping in mind the original HTML, CSS and the JS representation/modifications of HTML and the interaction of all three. As many websites are currently designed, content if often loaded and inserted into the HTML by JS. The separation of concerns enforced by this system is extremely blurry. You could also tell the interpreter to not evaluate macros and just display the content as is. > As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely. You can do all three in the same language and still maintain separation of concerns, like is done in most other languages and with native apps. > As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background. Again, you could tell the interpreter to ignore style elements, or write a reader macro to do it yourself. That is the beauty of lisp :)
    - ezy 11y ago
      This is overblown. The lisp is not "rendered", it is executed. Any language that can implement a recursive-descent parser/generator could be the basis for this -- it does not require lisp or lisp macros. Think about what a render would have to do, and you realize that the model of using embedded rewrite rules (macros) might be slightly more convenient, but not a really a distinct advantage over executing code which renders or outputs instructions to render later. The problem is most definitely not that you have to output an intermediate language, the problem is that HTML/CSS sucks. It is originally designed around presenting static text documents, and the committees involved were not smart enough to figure out a way to depart from that over a decade ago when pixels became important to the web.
saiko-chriskun 11y ago
<img id=animal src="my_kitten.jpg"> :: 35 chars [:image {:id "animal" :src "my_kitten.jpg"}] :: 44 chars To me they look practically identical.
- reagency 11y ago
  And with a few trivial bits of syntactic sugar, they get even closer.
lewisl9029 11y ago
> much more readable. I think this is more of a side-effect of familiarity rather than any inherent differences in readability between the two forms. Lisps do tend to look foreign to most people because their first languages usually have C-like syntax, and Lisp vs C is a much more dramatic difference than say Python vs C. Being able to write code that also happens to be valid data structures has some very tangible benefits though. For instance, in the HTML example, you can replace the strings or keywords in it with variables and it will be evaluated and output into the final HTML. You can also take that HTML element, pass it into any number of map, filter, reduce functions and programmatically transform it in literally any way you want. This means when you write HTML this way, you can use ClojureScript as your template language, and I think it's safe to say that ClojureScript is a much more powerful and well-designed language than any template language out there designed for HTML.

Thumbs up for actually giving an example! Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable.

deleted 11y ago

[deleted]

wz1000 11y ago

> Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable. That is only because this is Lisp that generates HTML. Also, in the example you had given, there are no closing tags. Closing tags are just superfluous visual clutter and are not actually needed. To take an example from http://c2.com/cgi/wiki?LispVsXml http://c2.com/cgi/wiki?LispVsXml This XML <dictionary> <email>electronic mail</email> <html>hypertext transport language</html> <xml>extensible markup language</xml> </dictionary> can become (dictionary (e-mail "electronic mail") (html "hypertext transport language") (xml "extensible markup language")) As you can see, all the superfluousness of the XML syntax is lost and reduced to its bare minimum.

founderling 11y ago
That is only because this is Lisp that generates HTML. Ok, so it is not the way you initially stated '<img id=animal src="my_kitten.jpg"> becomes (html [:image {:id "animal" :src "my_kitten.jpg"}])'. You rather showed an example of how to create html elements programmatically. Then you should compare it to JS: Your ClojureScript: (html [:image {:id "animal" :src "my_kitten.jpg"}]) My JS: html("image",{id:"animal",src:"my_kitten.jpg"}) If we use a function html(elementType,properties) that creates an element. Looks pretty nice to me.
- wz1000 11y ago
  Yes, my second example which translated XML to equivalent Lisp would be better at illustrating my point. With a Lisp, you don't need HTML as there is no distinction between code and data. Your Lisp is rendered and displayed on screen. It doesn't emit an intermediary language. How do you programmatically manipulate this "data"? Within Lisp itself. Lisp acts as both HTML and JavaScript. Lisp programmers regularly do this with the power of Lisp macros. I suggest you read the "Lisp vs XML" page I linked to in order to understand this better. Lisp directly exposes its syntax tree to the programmer and allows them to manipulate it to their liking.
  - founderling 11y ago
    Lisp acts as both HTML and JavaScript So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure. I like the content/presentation/behavior separation from a developers point of view and from a users point of view. As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely. As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
    - wz1000 11y ago
      > So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure. No, only thing that goes away the cognitive burden of keeping in mind the original HTML, CSS and the JS representation/modifications of HTML and the interaction of all three. As many websites are currently designed, content if often loaded and inserted into the HTML by JS. The separation of concerns enforced by this system is extremely blurry. You could also tell the interpreter to not evaluate macros and just display the content as is. > As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely. You can do all three in the same language and still maintain separation of concerns, like is done in most other languages and with native apps. > As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background. Again, you could tell the interpreter to ignore style elements, or write a reader macro to do it yourself. That is the beauty of lisp :)
  - ezy 11y ago
    This is overblown. The lisp is not "rendered", it is executed. Any language that can implement a recursive-descent parser/generator could be the basis for this -- it does not require lisp or lisp macros. Think about what a render would have to do, and you realize that the model of using embedded rewrite rules (macros) might be slightly more convenient, but not a really a distinct advantage over executing code which renders or outputs instructions to render later. The problem is most definitely not that you have to output an intermediate language, the problem is that HTML/CSS sucks. It is originally designed around presenting static text documents, and the committees involved were not smart enough to figure out a way to depart from that over a decade ago when pixels became important to the web.

saiko-chriskun 11y ago

<img id=animal src="my_kitten.jpg"> :: 35 chars [:image {:id "animal" :src "my_kitten.jpg"}] :: 44 chars To me they look practically identical.

reagency 11y ago
And with a few trivial bits of syntactic sugar, they get even closer.

lewisl9029 11y ago

> much more readable. I think this is more of a side-effect of familiarity rather than any inherent differences in readability between the two forms. Lisps do tend to look foreign to most people because their first languages usually have C-like syntax, and Lisp vs C is a much more dramatic difference than say Python vs C. Being able to write code that also happens to be valid data structures has some very tangible benefits though. For instance, in the HTML example, you can replace the strings or keywords in it with variables and it will be evaluated and output into the final HTML. You can also take that HTML element, pass it into any number of map, filter, reduce functions and programmatically transform it in literally any way you want. This means when you write HTML this way, you can use ClojureScript as your template language, and I think it's safe to say that ClojureScript is a much more powerful and well-designed language than any template language out there designed for HTML.