13 ms·

From the project: ... rth,←' A zs;A rs=scl(r.v(0));rr##mf(zs,rs,p);if(c==1){z.v=zs.v;R;}\',nl rth,←' array v=array(z.s,zs.v.type());v(0)=zs.v(0);\',nl

by natch 10y ago

From the project: ... rth,←' A zs;A rs=scl(r.v(0));rr##mf(zs,rs,p);if(c==1){z.v=zs.v;R;}\',nl rth,←' array v=array(z.s,zs.v.type());v(0)=zs.v(0);\',nl rth,←' DO(c-1,rs.v=r.v(i+1);rr##mf(zs,rs,p);v(i+1)=zs.v(0))z.v=v;)\',nl rth,←' DL(zz,if(rr##scl){rr##df(z,l,r,p);R;}\',nl ... No. And commit messages like "Hopefully that does it." No again.

RodgerTheGreat 10y ago
Are you going to articulate your objection to that code or just sneer at it unconstructively?
dang 10y ago
Snarky dismissals are not ok on Hacker News, especially not when they're advocating an entirely conventional and dare I say middlebrow position. When faced with something unconventional, the reaction we're hoping for from HN users is first to pause—and then to reflect. If after pausing and reflecting you want to argue that the conventional position is right, you'll be able to do that thoughtfully and with some sense of nuance.
- foxhill 10y ago
  in defence of the parent's snarkiness, this code is disgusting. imagine being presented with this and tasked with maintaining this. or adding a language feature. i'm certain the author could do it without much effort, but this code is as short as to be obfuscated - i have had more understanding from ioccc entries than this. code exists as a common language for humans to understand and collaborate. this code is nightmare-ish.
  - dang 10y ago
    There are quite a few assumptions in your comment that you could investigate if you wanted to. That might be more interesting than just being disgusted.
    - computerex 10y ago
      Why don't you just point those assumptions out? I haven't the slightest clue what "assumptions" you are talking about and how to go about investigating them. The code is disgusting, not a single variable has a meaningful name.
      - arcfide 10y ago
        They have exceptionally meaningful names, they're just not English ones.
        Obi_Juan_Kenobi 10y ago
        Sorry, could you provide a quick/rough English translation of one of those lines? I'm unfamiliar with APL or how Chinese characters are written with Latin symbols, so it would be useful for 'seeing' the syntax.
        arcfide 10y ago
        I can provide even better. If you look at the Publications: https://github.com/arcfide/Co-dfns#publications https://github.com/arcfide/Co-dfns#publications You can read the "Key" paper that walks you through one of the core data structures in the compiler and how it works. If you see the "rn" binding in the compiler code in "e.cd" you'll see that code put into the first compiler pass of the project. If you want to see more than that, I can email you a copy of an updated version of that paper which is currently under review (not likely to see publishing this round). It includes descriptions of the implementations of the "lf" and "fe" compiler passes.
      - dang 10y ago
        One assumption is that code should make sense to anyone who doesn't know the language it's written in. We wouldn't apply that to C, or to English for that matter, so why APL? Another assumption is that short variable names always make a program more obscure. Another assumption is that concision makes a program less readable. This assumption runs so deep that it's hard to even see it, but consider: one concise line of code is harder to read than one verbose line, but much easier to read than a million verbose lines. That is, in the time it would take me to understand a million lines of verbose code, I could learn the language of a concise program from scratch, work with its short (and at first obscure) codebase long enough to understand it, and still have orders of magnitude to spare. At some point on the code size curve, the tradeoffs change dramatically. I don't know the OP's program but I can tell you that the APL culture is a mature, sophisticated, and beautiful approach to programming that occupies a different local optimum than most programmers are used to. To react to this not just with disagreement but outrage ("disgusting"!) is quite interesting. There's something threatening about encountering an approach to one's area of expertise that is so radically different, based on such different assumptions, as to be outright alien. Our reflex is to dismiss it forcefully. But if you can catch yourself doing that and stay with the unfamiliar long enough to get over the "disgust" response, the reward is magical.
  - geocar 10y ago
    In defense of the code: It disgusts you. I find it very pleasant to read. That means it is not disgusting. I wouldn't ordinarily want to make this personal. But you, who cannot be bothered with grammar, punctuation, or the shift key, want to make a statement about this code. You must understand it is a personal statement more about yourself than the code you are looking at. Here is someone who does something you admit you cannot do, and you say don't do that! Don't do the things I cannot do! What a missed opportunity! If I see someone do something I cannot do I say how do you do that? Why do you do that?
- deleted 10y ago
  [deleted]
- natch 10y ago
  Point taken.
deleted 10y ago
[deleted]
nickpsecurity 10y ago
I was tempted to agree after a glance at this thread but thought this looked like APL. Checking on the project confirmed it's an APL variant. APL is some weird-looking stuff I've never even tried to learn as I believed I didn't need it in place of languages + libraries that do similar jobs well with familiarity. The previous threads on HN about APL had similarly-weird code that the APL vets showing up thought was anywhere from fine to beautiful. This tells me we can't judge the quality of APL-like code unless we've dug into that paradigm and know what good, APL-like code looks like. Like other paradigms that are really different. Are your an experienced user of array-oriented, programming languages? If so, what specific things about the code were bad other than the shortened names someone else mentioned?
- arcfide 10y ago
  Did the above code snippet remind you of APL or was it something else? This is actually a bit of an important "research" oriented question to me and is actually relevant to the design of the Co-dfns compiler.
  - nickpsecurity 10y ago
    Remember I said I don't do APL. It reminded me of things I've seen in APL-oriented submissions or comments. All of it looked equally ugly to the uninitiated. The main point is that I couldn't tell the difference between a bad or good example since I don't do APL. So, dang's point stands that we shouldn't be quick to dismiss it without evidence it's bad. That's a decent point in general but especially for stuff really outside the norm such as APL-derived languages.
    - arcfide 10y ago
      So, as I mention above, part of the intentional design of that code snippet is to "feel" like APL. The fact that you went to that somehow is a good thing, actually. While it might have seemed as equally ugly, if it felt in the same "class" as APL, that's at least in the right direction, because as a part of the design of the style of this code, it is to mirror the semantic and stylistic densities of APL to improve the reading transition between APL code and C-style code.
arcfide 10y ago
Don't complain that Chinese is ugly and unreadable just because you speak English as your native tongue. Technically, the above is a snippet of C++ put into an APL variable "rth" but there's so much more to it than that, and so much more to the design that you're missing. The design and choice of aesthetic in the compiler is a very intentional one that is arguably one of the main issues that has caused me to rewrite the compiler so many times over the years and has lead to this massive code adjustment. There are very good reasons that the compiler is written in the style that it is, and you cannot compare it to other project's style guides. Keep in mind that this compiler is designed to run natively on the GPU in a fully data-parallel fashion. One major issue that I had to address, and I discuss a little bit in a thread above, is the idea of the malleability of the code base. It's critically important to this project that I be able to adapt and alter the compiler rapidly. For example, I recently had to rewrite the entire backend due to a shift in some underlying core technology. This shift lead to a shrinkage of about 2000 lines of code because the underlying supporting libraries were a better fit to what I needed than what I was using previous to this. But I might not have been willing or able to make this change if I didn't have confidence that the rewrite would be swift and fast. Indeed, it took only two months to rewrite the backend from scratch, add more new features, improve robustness, and so forth. The code also got cleaner. This obsessive need to be highly adaptable leads me to the desire to have exceptionally "disposable" code. The cost for replacing or deleting code should be as low as possible. This has a few follow ups. In order to achieve the above, I need to ensure that I understand the ramifications of deleting code as readily as possible as quickly as possible. This basically means that I need to be able to squeeze as much of the compiler into my head as possible, and what doesn't fit, I need to be able to "see" and "read" as quickly and as readily as possible. The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any jumps, paging, scrolling or any movement. It means that I can completely understand the ramifications of any edit I make in nearly complete detail without any dereferencing or indirection. There are one or two places where there are some helper utilities which are on a different page, but these are part of the "domain vocabulary" which is basically in my mental cache any time I'm working with that code. I keep these "helpers" to a minimum, so that they can fit with anything else I want and not waste mental space in my head. Too many helpers leads to a failure to understand the complete macro picture and thus defeats my ability to delete code. In order to make the code more readable, it has to be highly consistent and idiomatic. I take this to an extreme level. This code is highly regular and predictable, to an almost obsessive degree. I do this by enforcing a style discipline on the code that allows me to eliminate the use of a host of abstractions, further paring down the complexity of the programming language in which I'm working and allowing me to think in the same mental plane at all times. The idea of semantic density is critical to this point. The semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols. This means that the cadence when reading the code is maintained. The "universal" naming scheme allows me to take any given name and know exactly its purpose, parentage, place, and use in the compiler without adding any additional cognitive overhead of inheritance syntax, datatypes, classes, or anything more than a name. The C++ code above is written the way it is to allow it to stylistically align with the semantic density of the APL code. This means that I can jump between the runtime and the compiler portions of the code with minimal mental shifts between the two, because the style and approach are similar. The code can be "read" in much the same way with minimal change. I am intentionally prioritizing internal semantic and stylistic consistency over satisfying the popular expectations of how C or APL code should look. I believe the internal consistency within the project contributes more strongly to the day-to-day readability and hackability of the project. Furthermore, I strongly restrict my use of programming languages features. This simplifies self-hosting, but it is primarily a means of maintaining stylistic and cognitive power. Since I know how I need to think about my problem "compilation on the GPU" in order to make it go, I can restrict myself to a paradigm that only allows me to think in this way. I choose a paradigm that is also exceptionally expressive to allow me to be productive as well. By selecting the right core paradigm, I can eschew further programmatic abstractions since they contribute nothing and only cost something. One way in which I do this is to write the core of the compiler with only one or two syntactical conventions, and only one main programming method: function composition. The entire core of the compiler is a single points-free (almost), data-flow, data parallel expression. Names provide the anchor points of the "macro" level ideas, but the language is expressive enough that I need very few other anchor points. Instead, I use only function composition over the core primitives with a syntax known as "trains" to create the mental effect of working with normal expressions when in reality I create new functions with every line in the core compiler (which is 90 lines or so). By restricting myself to only writing in this style, the mental effect works. If I had to switch between expression level and trains/points-free style in the code, it would be much less readable. But because I can now treat my points-free programs as regular expressions for all intents and purposes, it actually simplifies my cognitive load, as there is only one thing to think about: function composition.
libeclipse 10y ago
There's a lot of people jumping on the bandwagon of down-voting anyone who dares to criticise the code, but I'm going to give it a go anyway. There's a reason why readable and beautiful code is favoured: it's so that anyone else that opens the source and tries to understand it doesn't have a difficult time, and therefore, anyone that tries to contribute doesn't have a difficult time either. Looking at the project's Github page, I can see that there's no contributor even coming anywhere close to the project owner. Whether that's because of the obscurity of the codebase or for another reason, I can't comment. However, it does stand that the project owner is the only real contributor, and so the minimum that he himself has to consider is if he can understand the code. Having said that, looking at the code does make me cringe. I'm sorry if that offends anyone but it is what it is: the code is not very nice to look at. It seems as though it has been engineered to be as obfuscated and shrunken as possible, without any regard for readability. I mean just the file names themselves: was there really any need for single-letters? Now the author claims that (and a lot of other people agree with him on this) it is not for the purpose of what I outlined above, but rather, as mentioned before, so that he can understand it all easily and rapidly modify it. Whether or not that's the case I do invite you to consider the fact that the post that we are all replying to is somewhat bragging about the extremely small size of the codebase. Personally, I think this sort of code would fit in rather well on a code-golfing forum or something similar, not on a production system. Then again, it is a personal project so ¯\_(ツ)_/¯
- dang 10y ago
  > There's a lot of people jumping on the bandwagon of down-voting anyone who dares to criticise the code Please omit such offensive/defensive rhetoric from your posts to HN. It adds no information and is bad for conversation. The problem here isn't "daring" to criticize, it's rejecting the unfamiliar. This is like traveling to a new country and complaining because they cook everything wrong and say everything wrong. Unfamiliarity is relative—it's not a property of the thing you're reacting to. Same with readability: it's relative to the reader. In some contexts this is obvious. If you don't know German, you wouldn't reject a German text as unreadable or poorly written. But in other contexts, when we unconsciously assume or were taught that there's only one valid way to do something, we react with shock and distaste at work that violates known conventions. Such work may in fact be organized around different conventions for reasons we don't yet see. Good conversation across such boundaries requires a bit of distance from our own assumptions. Programming is like the world of art this way. There are countless examples in art history of sharp departures from convention provoking shock and distaste, and people saying things like "There's a reason why readable and beautiful [art] is favoured". Riot police famously had to be called to the early shows of the Impressionists, yet the beauty of their paintings is obvious to us now.

by natch 10y ago

RodgerTheGreat 10y ago

Are you going to articulate your objection to that code or just sneer at it unconstructively?

dang 10y ago

Snarky dismissals are not ok on Hacker News, especially not when they're advocating an entirely conventional and dare I say middlebrow position. When faced with something unconventional, the reaction we're hoping for from HN users is first to pause—and then to reflect. If after pausing and reflecting you want to argue that the conventional position is right, you'll be able to do that thoughtfully and with some sense of nuance.

foxhill 10y ago
in defence of the parent's snarkiness, this code is disgusting. imagine being presented with this and tasked with maintaining this. or adding a language feature. i'm certain the author could do it without much effort, but this code is as short as to be obfuscated - i have had more understanding from ioccc entries than this. code exists as a common language for humans to understand and collaborate. this code is nightmare-ish.
- dang 10y ago
  There are quite a few assumptions in your comment that you could investigate if you wanted to. That might be more interesting than just being disgusted.
  - computerex 10y ago
    Why don't you just point those assumptions out? I haven't the slightest clue what "assumptions" you are talking about and how to go about investigating them. The code is disgusting, not a single variable has a meaningful name.
    - arcfide 10y ago
      They have exceptionally meaningful names, they're just not English ones.
      - Obi_Juan_Kenobi 10y ago
        Sorry, could you provide a quick/rough English translation of one of those lines? I'm unfamiliar with APL or how Chinese characters are written with Latin symbols, so it would be useful for 'seeing' the syntax.
        arcfide 10y ago
        I can provide even better. If you look at the Publications: https://github.com/arcfide/Co-dfns#publications https://github.com/arcfide/Co-dfns#publications You can read the "Key" paper that walks you through one of the core data structures in the compiler and how it works. If you see the "rn" binding in the compiler code in "e.cd" you'll see that code put into the first compiler pass of the project. If you want to see more than that, I can email you a copy of an updated version of that paper which is currently under review (not likely to see publishing this round). It includes descriptions of the implementations of the "lf" and "fe" compiler passes.
    - dang 10y ago
      One assumption is that code should make sense to anyone who doesn't know the language it's written in. We wouldn't apply that to C, or to English for that matter, so why APL? Another assumption is that short variable names always make a program more obscure. Another assumption is that concision makes a program less readable. This assumption runs so deep that it's hard to even see it, but consider: one concise line of code is harder to read than one verbose line, but much easier to read than a million verbose lines. That is, in the time it would take me to understand a million lines of verbose code, I could learn the language of a concise program from scratch, work with its short (and at first obscure) codebase long enough to understand it, and still have orders of magnitude to spare. At some point on the code size curve, the tradeoffs change dramatically. I don't know the OP's program but I can tell you that the APL culture is a mature, sophisticated, and beautiful approach to programming that occupies a different local optimum than most programmers are used to. To react to this not just with disagreement but outrage ("disgusting"!) is quite interesting. There's something threatening about encountering an approach to one's area of expertise that is so radically different, based on such different assumptions, as to be outright alien. Our reflex is to dismiss it forcefully. But if you can catch yourself doing that and stay with the unfamiliar long enough to get over the "disgust" response, the reward is magical.
- geocar 10y ago
  In defense of the code: It disgusts you. I find it very pleasant to read. That means it is not disgusting. I wouldn't ordinarily want to make this personal. But you, who cannot be bothered with grammar, punctuation, or the shift key, want to make a statement about this code. You must understand it is a personal statement more about yourself than the code you are looking at. Here is someone who does something you admit you cannot do, and you say don't do that! Don't do the things I cannot do! What a missed opportunity! If I see someone do something I cannot do I say how do you do that? Why do you do that?
deleted 10y ago
[deleted]
natch 10y ago
Point taken.

deleted 10y ago

[deleted]

nickpsecurity 10y ago

I was tempted to agree after a glance at this thread but thought this looked like APL. Checking on the project confirmed it's an APL variant. APL is some weird-looking stuff I've never even tried to learn as I believed I didn't need it in place of languages + libraries that do similar jobs well with familiarity. The previous threads on HN about APL had similarly-weird code that the APL vets showing up thought was anywhere from fine to beautiful. This tells me we can't judge the quality of APL-like code unless we've dug into that paradigm and know what good, APL-like code looks like. Like other paradigms that are really different. Are your an experienced user of array-oriented, programming languages? If so, what specific things about the code were bad other than the shortened names someone else mentioned?

arcfide 10y ago
Did the above code snippet remind you of APL or was it something else? This is actually a bit of an important "research" oriented question to me and is actually relevant to the design of the Co-dfns compiler.
- nickpsecurity 10y ago
  Remember I said I don't do APL. It reminded me of things I've seen in APL-oriented submissions or comments. All of it looked equally ugly to the uninitiated. The main point is that I couldn't tell the difference between a bad or good example since I don't do APL. So, dang's point stands that we shouldn't be quick to dismiss it without evidence it's bad. That's a decent point in general but especially for stuff really outside the norm such as APL-derived languages.
  - arcfide 10y ago
    So, as I mention above, part of the intentional design of that code snippet is to "feel" like APL. The fact that you went to that somehow is a good thing, actually. While it might have seemed as equally ugly, if it felt in the same "class" as APL, that's at least in the right direction, because as a part of the design of the style of this code, it is to mirror the semantic and stylistic densities of APL to improve the reading transition between APL code and C-style code.

arcfide 10y ago

Don't complain that Chinese is ugly and unreadable just because you speak English as your native tongue. Technically, the above is a snippet of C++ put into an APL variable "rth" but there's so much more to it than that, and so much more to the design that you're missing. The design and choice of aesthetic in the compiler is a very intentional one that is arguably one of the main issues that has caused me to rewrite the compiler so many times over the years and has lead to this massive code adjustment. There are very good reasons that the compiler is written in the style that it is, and you cannot compare it to other project's style guides. Keep in mind that this compiler is designed to run natively on the GPU in a fully data-parallel fashion. One major issue that I had to address, and I discuss a little bit in a thread above, is the idea of the malleability of the code base. It's critically important to this project that I be able to adapt and alter the compiler rapidly. For example, I recently had to rewrite the entire backend due to a shift in some underlying core technology. This shift lead to a shrinkage of about 2000 lines of code because the underlying supporting libraries were a better fit to what I needed than what I was using previous to this. But I might not have been willing or able to make this change if I didn't have confidence that the rewrite would be swift and fast. Indeed, it took only two months to rewrite the backend from scratch, add more new features, improve robustness, and so forth. The code also got cleaner. This obsessive need to be highly adaptable leads me to the desire to have exceptionally "disposable" code. The cost for replacing or deleting code should be as low as possible. This has a few follow ups. In order to achieve the above, I need to ensure that I understand the ramifications of deleting code as readily as possible as quickly as possible. This basically means that I need to be able to squeeze as much of the compiler into my head as possible, and what doesn't fit, I need to be able to "see" and "read" as quickly and as readily as possible. The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any jumps, paging, scrolling or any movement. It means that I can completely understand the ramifications of any edit I make in nearly complete detail without any dereferencing or indirection. There are one or two places where there are some helper utilities which are on a different page, but these are part of the "domain vocabulary" which is basically in my mental cache any time I'm working with that code. I keep these "helpers" to a minimum, so that they can fit with anything else I want and not waste mental space in my head. Too many helpers leads to a failure to understand the complete macro picture and thus defeats my ability to delete code. In order to make the code more readable, it has to be highly consistent and idiomatic. I take this to an extreme level. This code is highly regular and predictable, to an almost obsessive degree. I do this by enforcing a style discipline on the code that allows me to eliminate the use of a host of abstractions, further paring down the complexity of the programming language in which I'm working and allowing me to think in the same mental plane at all times. The idea of semantic density is critical to this point. The semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols. This means that the cadence when reading the code is maintained. The "universal" naming scheme allows me to take any given name and know exactly its purpose, parentage, place, and use in the compiler without adding any additional cognitive overhead of inheritance syntax, datatypes, classes, or anything more than a name. The C++ code above is written the way it is to allow it to stylistically align with the semantic density of the APL code. This means that I can jump between the runtime and the compiler portions of the code with minimal mental shifts between the two, because the style and approach are similar. The code can be "read" in much the same way with minimal change. I am intentionally prioritizing internal semantic and stylistic consistency over satisfying the popular expectations of how C or APL code should look. I believe the internal consistency within the project contributes more strongly to the day-to-day readability and hackability of the project. Furthermore, I strongly restrict my use of programming languages features. This simplifies self-hosting, but it is primarily a means of maintaining stylistic and cognitive power. Since I know how I need to think about my problem "compilation on the GPU" in order to make it go, I can restrict myself to a paradigm that only allows me to think in this way. I choose a paradigm that is also exceptionally expressive to allow me to be productive as well. By selecting the right core paradigm, I can eschew further programmatic abstractions since they contribute nothing and only cost something. One way in which I do this is to write the core of the compiler with only one or two syntactical conventions, and only one main programming method: function composition. The entire core of the compiler is a single points-free (almost), data-flow, data parallel expression. Names provide the anchor points of the "macro" level ideas, but the language is expressive enough that I need very few other anchor points. Instead, I use only function composition over the core primitives with a syntax known as "trains" to create the mental effect of working with normal expressions when in reality I create new functions with every line in the core compiler (which is 90 lines or so). By restricting myself to only writing in this style, the mental effect works. If I had to switch between expression level and trains/points-free style in the code, it would be much less readable. But because I can now treat my points-free programs as regular expressions for all intents and purposes, it actually simplifies my cognitive load, as there is only one thing to think about: function composition.

libeclipse 10y ago

There's a lot of people jumping on the bandwagon of down-voting anyone who dares to criticise the code, but I'm going to give it a go anyway. There's a reason why readable and beautiful code is favoured: it's so that anyone else that opens the source and tries to understand it doesn't have a difficult time, and therefore, anyone that tries to contribute doesn't have a difficult time either. Looking at the project's Github page, I can see that there's no contributor even coming anywhere close to the project owner. Whether that's because of the obscurity of the codebase or for another reason, I can't comment. However, it does stand that the project owner is the only real contributor, and so the minimum that he himself has to consider is if he can understand the code. Having said that, looking at the code does make me cringe. I'm sorry if that offends anyone but it is what it is: the code is not very nice to look at. It seems as though it has been engineered to be as obfuscated and shrunken as possible, without any regard for readability. I mean just the file names themselves: was there really any need for single-letters? Now the author claims that (and a lot of other people agree with him on this) it is not for the purpose of what I outlined above, but rather, as mentioned before, so that he can understand it all easily and rapidly modify it. Whether or not that's the case I do invite you to consider the fact that the post that we are all replying to is somewhat bragging about the extremely small size of the codebase. Personally, I think this sort of code would fit in rather well on a code-golfing forum or something similar, not on a production system. Then again, it is a personal project so ¯\_(ツ)_/¯

dang 10y ago
> There's a lot of people jumping on the bandwagon of down-voting anyone who dares to criticise the code Please omit such offensive/defensive rhetoric from your posts to HN. It adds no information and is bad for conversation. The problem here isn't "daring" to criticize, it's rejecting the unfamiliar. This is like traveling to a new country and complaining because they cook everything wrong and say everything wrong. Unfamiliarity is relative—it's not a property of the thing you're reacting to. Same with readability: it's relative to the reader. In some contexts this is obvious. If you don't know German, you wouldn't reject a German text as unreadable or poorly written. But in other contexts, when we unconsciously assume or were taught that there's only one valid way to do something, we react with shock and distaste at work that violates known conventions. Such work may in fact be organized around different conventions for reasons we don't yet see. Good conversation across such boundaries requires a bit of distance from our own assumptions. Programming is like the world of art this way. There are countless examples in art history of sharp departures from convention provoking shock and distaste, and people saying things like "There's a reason why readable and beautiful [art] is favoured". Riot police famously had to be called to the early shows of the Impressionists, yet the beauty of their paintings is obvious to us now.