5 ms·

> The repository[0] for J is just as unreadable People who can read this find it readable. I think it's a mistake to think that because you can't read the cod

by geocar 6y ago

> The repository[0] for J is just as unreadable People who can read this find it readable. I think it's a mistake to think that because you can't read the code, that it is the code that is somehow unreadable, instead of a language you simply haven't learned to read. > I don’t know how a project is managed like this. It's not dissimilar to working with any proprietary programming language: You have to learn how to read and write this language. The fact that we can use an existing language's compiler can be confusing to people who don't know that language very well, but if you approach it from the perspective of a new (proprietary) language, using an existing language's compiler can be a great way to leverage the benefits of that existing language.

MontyCarloHall 6y ago
>People who can read this find it readable. > I think it's a mistake to think that because you can't read the code, that it is the code that is somehow unreadable, instead of a language you simply haven't learned to read. The same could be said about Brainfuck. With enough effort people can learn to read almost anything; that doesn’t mean that everything is equally readable.
- bidirectional 6y ago
  Brainfuck is so simple that it is trivial to read. The problem there is a semantic one rather than a syntactic one, you cannot build any abstractions. J-style C has all the semantic expressiveness of C, and chooses a terse, but fairly uniform style.
AshamedCaptain 6y ago
> I think it's a mistake to think that because you can't read the code, that it is the code that is somehow unreadable, instead of a language you simply haven't learned to read. This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. It's not like it is complicated because it is written in a structurally different language, nor will you actually leverage any benefit from learning this language. It's just obfuscated under the guise of abbreviation.
- avmich 6y ago
  > This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. Yes, but for this case adding whitespace actually decreases readability. At least if you know Whitney's hate of scrolling.
- geocar 6y ago
  > This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. I disagree wholeheartedly. Whitespace tends to move code further away from the code that uses it; scrolling and tab-flipping requires the developer hold that code in their head where it is most likely to degrade. It is much much better to make them remember as little as possible. It also helps reuse: If you don't scroll, you can see more code, so you can see if something is a good candidate for abstracting, just because you can see them doing the same thing. Macros like this help with that, and so they aren't "meaningless". Less whitespace helps with that, and so it actually improves readability (to those who have to read it!). The trade-off is that you can't hire someone with "C" on their CV and expect them to be productive on their first day, but in a complex codebase, this might not be possible for other reasons.
  - AshamedCaptain 6y ago
    I have a hard time believing that increasing the size of your terminal "helps reuse". First, I do not agree that working memory is any significant limit when analyzing code, specially because one of the first steps is going to create the mental abstraction that allows you to, precisaly, understand the code. The density of that abstraction is definitely uncorrelated to the amount of whitespace. Thus, scrolling is only going to be an issue for the first couple of reads. Second, say your patented steganography mechanism manages to fit 3x the amount of "code" in the same terminal size (and I am being generous). Is this going to increase "code reuse" by any significant amount?
    - geocar 6y ago
      > one of the first steps is going to create the mental abstraction that allows you to, precisaly, understand the code. Precisely. Now a short program is "short enough" that you can convince yourself it is correct; That is to say, I'm sure you can imagine writing "hello world" without making a mistake, and that there is some threshold of program length where your confidence in error-free programming will be lost. For every seeing-programmer I have ever met, and I suspect strongly all seeing-programmers, that length is measured in "source-code pixels". Not lines, or characters, but literal field of view. Smaller screen? More bugs. Where you are forced to deal with your application in terms of the mental abstraction, rather than what the code actually says it does, it is simply because that code is off-screen, and that mental abstraction is a sieve: If you had any true confidence in it, you would not believe that program length correlates with bugs. > scrolling is only going to be an issue for the first couple of reads. I've worked on codebases large enough that they've taken a few years to read fully, and codebases changing so quickly that there's no point to learn everything. Sometimes you can read a program, and sometimes you can't, but when you can't, the damage that scrolling does seems infinitely worse. > Is this going to increase "code reuse" by any significant amount? Yes, and usually by a factor of a thousand or more.

by geocar 6y ago

MontyCarloHall 6y ago

>People who can read this find it readable. > I think it's a mistake to think that because you can't read the code, that it is the code that is somehow unreadable, instead of a language you simply haven't learned to read. The same could be said about Brainfuck. With enough effort people can learn to read almost anything; that doesn’t mean that everything is equally readable.

bidirectional 6y ago
Brainfuck is so simple that it is trivial to read. The problem there is a semantic one rather than a syntactic one, you cannot build any abstractions. J-style C has all the semantic expressiveness of C, and chooses a terse, but fairly uniform style.

AshamedCaptain 6y ago

> I think it's a mistake to think that because you can't read the code, that it is the code that is somehow unreadable, instead of a language you simply haven't learned to read. This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. It's not like it is complicated because it is written in a structurally different language, nor will you actually leverage any benefit from learning this language. It's just obfuscated under the guise of abbreviation.

avmich 6y ago
> This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. Yes, but for this case adding whitespace actually decreases readability. At least if you know Whitney's hate of scrolling.
geocar 6y ago
> This argument is significantly weakened when simply removing the meaningless macros and adding whitespace improves readability. I disagree wholeheartedly. Whitespace tends to move code further away from the code that uses it; scrolling and tab-flipping requires the developer hold that code in their head where it is most likely to degrade. It is much much better to make them remember as little as possible. It also helps reuse: If you don't scroll, you can see more code, so you can see if something is a good candidate for abstracting, just because you can see them doing the same thing. Macros like this help with that, and so they aren't "meaningless". Less whitespace helps with that, and so it actually improves readability (to those who have to read it!). The trade-off is that you can't hire someone with "C" on their CV and expect them to be productive on their first day, but in a complex codebase, this might not be possible for other reasons.
- AshamedCaptain 6y ago
  I have a hard time believing that increasing the size of your terminal "helps reuse". First, I do not agree that working memory is any significant limit when analyzing code, specially because one of the first steps is going to create the mental abstraction that allows you to, precisaly, understand the code. The density of that abstraction is definitely uncorrelated to the amount of whitespace. Thus, scrolling is only going to be an issue for the first couple of reads. Second, say your patented steganography mechanism manages to fit 3x the amount of "code" in the same terminal size (and I am being generous). Is this going to increase "code reuse" by any significant amount?
  - geocar 6y ago
    > one of the first steps is going to create the mental abstraction that allows you to, precisaly, understand the code. Precisely. Now a short program is "short enough" that you can convince yourself it is correct; That is to say, I'm sure you can imagine writing "hello world" without making a mistake, and that there is some threshold of program length where your confidence in error-free programming will be lost. For every seeing-programmer I have ever met, and I suspect strongly all seeing-programmers, that length is measured in "source-code pixels". Not lines, or characters, but literal field of view. Smaller screen? More bugs. Where you are forced to deal with your application in terms of the mental abstraction, rather than what the code actually says it does, it is simply because that code is off-screen, and that mental abstraction is a sieve: If you had any true confidence in it, you would not believe that program length correlates with bugs. > scrolling is only going to be an issue for the first couple of reads. I've worked on codebases large enough that they've taken a few years to read fully, and codebases changing so quickly that there's no point to learn everything. Sometimes you can read a program, and sometimes you can't, but when you can't, the damage that scrolling does seems infinitely worse. > Is this going to increase "code reuse" by any significant amount? Yes, and usually by a factor of a thousand or more.