6 ms·

sure, because Sure, because this (taken from React's JSX example page): <DashboardUnit data-index="2"> <h1>Scores</h1> <Scoreboard className="r

sure, because Sure, because this (taken from React's JSX example page): <DashboardUnit data-index="2"> <h1>Scores</h1> <Scoreboard className="results" scores={gameScores} /> </DashboardUnit>; is more readable than this: [dashboard-unit {:data-index 2} [:h1 "Scores"] [scoreboard {:class-name "results" :scores game-scores]] Please tell me more about Lisp readability.

lostmyoldone 8y ago
I don't really see how JSX informs us about readability of s-expression vis-à-vis Python et al. Disregarding that, and in my opinion, properly formatted JSX might be a bit worse then s-expr for shorter stretches of code, but if/when you have a longer stretch, the visual symmetry in JSX would seem to tip the scale the other way. If there is a point to JSX, I would claim it's mostly that it looks different than the surrounding code that is the point, as it potentially makes it easier to parse and to clearly separate roles between code and design. While I'm frankly not a fan of either of the above-mentioned, I do find some of the arguments around the brilliance of s-expr to be perplexing. The most confusing argument is the one that s-expressions are good because everything looks the same, which to me sound like arguing that the best way to paint is to only use one color, which I vehemently disagree with. I think the easiest explanation of this conundrum boils down to a rather simple fact. Visual regularity is as confusing to some, as the lack of it is to others. People are different, sometimes shockingly so.
- mschaef 8y ago
  > The most confusing argument is the one that s-expressions are good because everything looks the same, which to me sound like arguing that the best way to paint is to only use one color, which I vehemently disagree with. The point of the syntax isn't necessarily that everything looks the same, it's more around why that's the case and what other properties it enables. In other words, if a homogeneous (and arguably less convenient) syntax is the downside, it's important to consider the upside too. This still not make it 'better' enough for to want to use, but maybe will shed some light on why reasonable people might think differently. The core concept behind Lisp syntax is that Lisp has a handful of core data structures, and the user syntax of the language is defined directly in terms of those structures. Clojure uses sequences, vectors, hashes to do things like represent blocks of code, argument lists, and type declarations. The structures used for this are the same as the structures uses in user code, and what you type in to the keyboard when you program are the normal textual serializations of these structures. So this gives a couple of benefits: 1) The character sequences used to represent the language are easy to parse in a structural way without a whole bunch of parsing logic. A structural editor for Lisp doesn't necessarily need as complete a grammar or parser to enable the structural features as does a language like Java, Scala, C, etc. 2) It's easier to generate or manipulate code. Most famously, this enables things like macros. Macros and code transformations are absolutely possible in languages like Java and the JS ecosystem, but less commonly used and more expensive to develop. There are many other examples of where these properties come in handy, but JSX turns out to be a reasonable illustration of why these are useful. Adding something like JSX to Javascript requires an explicit preprocessing state. Then, it also requires specific editor support to deal with the modified syntax. Once all that's done, what you have is a wrapper around 'React.createElement'. It says a lot about the value of application-specific syntax that people are willing to pay those costs to get a certain syntax, but the Clojure/Lisp approach (hiccup for markup) reduces the costs and makes that kind of thing significantly easier to do. Whether or not that's the tradeoff you choose to make is one thing, but there are reasons to make it.
doteka 8y ago
For someone familiar with HTML/XML, so any developer in the last 30 years, yes it is. Your point being? I like the ideas behind clojure, I really do. I even wrote a non-trivial personal project with it. However, coming back to that code after two months was basically like the plot of Memento. I ended up rewriting it in JavaScript instead.
- iLemming 8y ago
  My point being is: people often complain about readability of Clojure and Lisps in general without even giving it a heartfelt attempt. They complain about parentheses (which becomes a non-issue within literally hours after learning structured editing idioms). It's a matter of familiarity. Some prefer semicolons and other "visual garbage" in their code, I like minimalism and structure. No other language can retain readability on different screens like Clojure can. Even reading it in a narrow screen of a mobile phone - it would wrap, but still retain its readability. Good luck trying that with literally any other (non-lispy) language.
- profalseidol 8y ago
  Almost anything (if not all) requires one to put in years of practice before one is adept. "a" non-trivial "personal" project probably won't cut it. Comparing that to your 30 years practice of XML is not at all useful.
  - doteka 8y ago
    I didn't say anywhere I have 30 years of experience with XML. What I said is, EVERYONE is familiar with the syntax. JSX is especially suited for expressing HTML because it is, in fact, almost HTML. As to your other point - maybe. I'm not seeing anywhere near enough potential payoff to invest years into it, though. Also, I'd argue that makes it a terribly impractical language if you're interested in getting work done. To clarify, I don't agree one needs years to become competent in clojure. But if one did, that just makes it a worse value proposition.
    - profalseidol 8y ago
stickfigure 8y ago
I genuinely can't tell if you're being sarcastic. The JSX looks immediately intelligible to me because I'm used to looking at HTML. The Clojure looks unfamiliar but it's not so strange that I can't imagine it feeling just as natural a way to represent the same data structure. It would just take a little while to get used to. The major issue I suppose is that this example is supposed to render to XML, which is closer to JSX than Clojure. But by that standard Vue (or XSLT) is even closer. I've done a little professional work in Clojure and wasn't a huge fan, but it didn't seem particularly bad (syntactically). It just seemed like something you had to get used to.
- iLemming 8y ago
  > The Clojure looks unfamiliar That's my point. It is simply "unfamiliar" to majority of developers who have never tried Lisps. And a lot of people throw baseless claims it to be "less readable" without even given it a try. A few years ago plain English to me was "unreadable". But I have learned the language. And look, today I can even make comments on HN. I guess it's a good thing I haven't dismissed the language because I was unfamiliar with it.
gpderetta 8y ago
Basically damnation with faint praise?

lostmyoldone 8y ago

I don't really see how JSX informs us about readability of s-expression vis-à-vis Python et al. Disregarding that, and in my opinion, properly formatted JSX might be a bit worse then s-expr for shorter stretches of code, but if/when you have a longer stretch, the visual symmetry in JSX would seem to tip the scale the other way. If there is a point to JSX, I would claim it's mostly that it looks different than the surrounding code that is the point, as it potentially makes it easier to parse and to clearly separate roles between code and design. While I'm frankly not a fan of either of the above-mentioned, I do find some of the arguments around the brilliance of s-expr to be perplexing. The most confusing argument is the one that s-expressions are good because everything looks the same, which to me sound like arguing that the best way to paint is to only use one color, which I vehemently disagree with. I think the easiest explanation of this conundrum boils down to a rather simple fact. Visual regularity is as confusing to some, as the lack of it is to others. People are different, sometimes shockingly so.

mschaef 8y ago
> The most confusing argument is the one that s-expressions are good because everything looks the same, which to me sound like arguing that the best way to paint is to only use one color, which I vehemently disagree with. The point of the syntax isn't necessarily that everything looks the same, it's more around why that's the case and what other properties it enables. In other words, if a homogeneous (and arguably less convenient) syntax is the downside, it's important to consider the upside too. This still not make it 'better' enough for to want to use, but maybe will shed some light on why reasonable people might think differently. The core concept behind Lisp syntax is that Lisp has a handful of core data structures, and the user syntax of the language is defined directly in terms of those structures. Clojure uses sequences, vectors, hashes to do things like represent blocks of code, argument lists, and type declarations. The structures used for this are the same as the structures uses in user code, and what you type in to the keyboard when you program are the normal textual serializations of these structures. So this gives a couple of benefits: 1) The character sequences used to represent the language are easy to parse in a structural way without a whole bunch of parsing logic. A structural editor for Lisp doesn't necessarily need as complete a grammar or parser to enable the structural features as does a language like Java, Scala, C, etc. 2) It's easier to generate or manipulate code. Most famously, this enables things like macros. Macros and code transformations are absolutely possible in languages like Java and the JS ecosystem, but less commonly used and more expensive to develop. There are many other examples of where these properties come in handy, but JSX turns out to be a reasonable illustration of why these are useful. Adding something like JSX to Javascript requires an explicit preprocessing state. Then, it also requires specific editor support to deal with the modified syntax. Once all that's done, what you have is a wrapper around 'React.createElement'. It says a lot about the value of application-specific syntax that people are willing to pay those costs to get a certain syntax, but the Clojure/Lisp approach (hiccup for markup) reduces the costs and makes that kind of thing significantly easier to do. Whether or not that's the tradeoff you choose to make is one thing, but there are reasons to make it.

doteka 8y ago

For someone familiar with HTML/XML, so any developer in the last 30 years, yes it is. Your point being? I like the ideas behind clojure, I really do. I even wrote a non-trivial personal project with it. However, coming back to that code after two months was basically like the plot of Memento. I ended up rewriting it in JavaScript instead.

iLemming 8y ago
My point being is: people often complain about readability of Clojure and Lisps in general without even giving it a heartfelt attempt. They complain about parentheses (which becomes a non-issue within literally hours after learning structured editing idioms). It's a matter of familiarity. Some prefer semicolons and other "visual garbage" in their code, I like minimalism and structure. No other language can retain readability on different screens like Clojure can. Even reading it in a narrow screen of a mobile phone - it would wrap, but still retain its readability. Good luck trying that with literally any other (non-lispy) language.
profalseidol 8y ago
Almost anything (if not all) requires one to put in years of practice before one is adept. "a" non-trivial "personal" project probably won't cut it. Comparing that to your 30 years practice of XML is not at all useful.
- doteka 8y ago
  I didn't say anywhere I have 30 years of experience with XML. What I said is, EVERYONE is familiar with the syntax. JSX is especially suited for expressing HTML because it is, in fact, almost HTML. As to your other point - maybe. I'm not seeing anywhere near enough potential payoff to invest years into it, though. Also, I'd argue that makes it a terribly impractical language if you're interested in getting work done. To clarify, I don't agree one needs years to become competent in clojure. But if one did, that just makes it a worse value proposition.
  - profalseidol 8y ago

stickfigure 8y ago

I genuinely can't tell if you're being sarcastic. The JSX looks immediately intelligible to me because I'm used to looking at HTML. The Clojure looks unfamiliar but it's not so strange that I can't imagine it feeling just as natural a way to represent the same data structure. It would just take a little while to get used to. The major issue I suppose is that this example is supposed to render to XML, which is closer to JSX than Clojure. But by that standard Vue (or XSLT) is even closer. I've done a little professional work in Clojure and wasn't a huge fan, but it didn't seem particularly bad (syntactically). It just seemed like something you had to get used to.

iLemming 8y ago
> The Clojure looks unfamiliar That's my point. It is simply "unfamiliar" to majority of developers who have never tried Lisps. And a lot of people throw baseless claims it to be "less readable" without even given it a try. A few years ago plain English to me was "unreadable". But I have learned the language. And look, today I can even make comments on HN. I guess it's a good thing I haven't dismissed the language because I was unfamiliar with it.

gpderetta 8y ago

Basically damnation with faint praise?