4 ms·

> It is plain to any developer False. I am a developer. It is readable to me. > I think in this case it falls on you to explain why you think it isn't Why c

by geocar 7y ago

> It is plain to any developer False. I am a developer. It is readable to me. > I think in this case it falls on you to explain why you think it isn't Why code isn't unreadable? What a silly question! You simply don't know how to read it. If you do not know Java, you might say all Java code is unreadable. Why would you expect any other language to be different?

deleted 7y ago
- bakul 7y ago
  If you are interested, try something like this to start making sense of the code: cc -E m.c | indent | grep -v INDENT | less and separately read k.h for typedefs etc.
- geocar 7y ago
  Sure. The variables x,y,z are used to describe the first, second and third arguments. This is a common convention, so you get used to it. tX, tA and ta are type enums. A1(f,b) is just a 1-ary function f with the body b; A2 2-ary, and A3 3-ary. A_(f...) is a list of A (box) objects; literally (A[])({f1, f2, ... fn}) to avoid an extra definition. atnv is a mnemonic for allocate of (t)ype, le(n)gth, (v)alues. This is not dissimilar from Arthur's ktn(t,n) function, except it also fills the buffer with the values (memcpy). These are allocation wrappers for the rest of the interpreter. I've tried to write some about why this style is better on HN previously: - https://news.ycombinator.com/item?id=10876975 https://news.ycombinator.com/item?id=10876975 - https://news.ycombinator.com/item?id=8476294 https://news.ycombinator.com/item?id=8476294 and I'm used to a certain amount of abuse from people who think I'm "trolling" because I have adopted a similar style for my own work: - https://github.com/geocar/dash/blob/master/d.c#L63 https://github.com/geocar/dash/blob/master/d.c#L63 - https://github.com/geocar/con/blob/master/con.c https://github.com/geocar/con/blob/master/con.c I don't let it bother me though. Occasionally you meet people who can be convinced to take a certain leap of faith, and then you get to have very interesting conversations about making software that you can't have otherwise. Perhaps you've heard this said of other things as well: That learning lisp makes you a better programmer even if you do not use lisp. This thing here, is kind of like that.
  - tsimionescu 7y ago
    I've read and appreciate your previous posts. They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand. On the other hand, I think that there are two aspects of this style that need to be separated - the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. There is something else to the style that might be applied to get those, and perhaps that would be more important to teach than the ability to read 'notation-like' code (for lack of a better name). I do understand the claim that the identifier style is what helps you understand and review the code much better, so it may be an enabler.
    - geocar 7y ago
      Thanks for giving this an actual shot. I appreciate it's alien tech, but it's something I've grown quite fond of over the last few years and I enjoy talking about it. > They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand. Oh they're not the only one. Look at maths papers from the last ten years versus just twenty years ago: So much more verbose! So hostile to brevity! The benefit to a good notation is keeping in your head the solution. The downside to a good notation is that it keeps people from contributing to the solution that don't understand the notation. My conjecture: People who can't learn the notation can't contribute for other reasons. My second conjecture: This shit isn't as hard as people think it is. > the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. This is not true! When I wrote the first kOS kernel, I wrote it with newlines and tabs because I didn't know any better. When I rewrote it in this style, I noticed a lot of code duplication that I could only see because the kernel now fit on a screen. This made my program smaller (original kernel was around 50kb the new one was around 30kb) which left more room in cache for programs making them faster as well. I was also able to see bugs that were only visible because I could see the caller and the callee at the same time and correct them. It all adds up! Since then, I've had numerous opportunities to see similar effects in other programs. Learning how to use notation has made me a better programmer.
saagarjha 7y ago
You're a bit off, because this is C and I know how to write it. I can read and write English pretty well, too, but I have come across literature that is unreadable in that language as well.
- smcl 7y ago
  Your comment about this being like unreadable English is very astute and got me thinking. To me if someone says "m.c" is nice and readable, it's a bit like someone claiming Finnegan's Wake is. For anyone who is not aware, this is what Finnegan's Wake looks like: """ riverrun, past Eve and Adams, from swerve of shore to bend of bay, brings us by a commodius vicus of recirculation back to Howth, Castle and Environs. Sir Tristram, violer d'amores, fr'over the short sea, had passencore rearrived from North Armorica on this side the scraggy isthmus of Europe Minor to wielderfight his penisolate war; nor had topsawyer's rocks by the stream Oconee exaggerated themselse to Laurens County's giorgios while they went doublin their mumper all the time.... """ The difference is that I don't think anyone makes the claim that Finnegan's Wake is readable or easy to work with. Everyone's pretty much agreed that this is a very unusual style that takes an enormous amount of time and effort to appreciate and understand. The style is fine, if it's someone's "thing" then great, more power to them. But what gets me is people pointing to this style of coding and feigning ignorance or surprise that others could find it troublesome and making a big point of saying "Well it's easy for me, I guess you're just not smart" when confronted about it
  - geocar 7y ago
    > But what gets me is people pointing to this style of coding and feigning ignorance or surprise that others could find it troublesome and making a big point of saying "Well it's easy for me, I guess you're just not smart" when confronted about it Hey listen, I understand that other people find it troublesome. The thing is that I think it's something people can learn if they want, and I think there are benefits to doing so. I only object to the label "it's unreadable" because it demands the author (or someone else) make it "readable" to cure, when the right fix is to fix the programmer: to give them the experiences needed to be able to read it. That's admittedly not very easy for the novice reader- certainly it would be much better for them to write less dense and use a smaller vocabulary, and that's why, just with English, we start novice readers with less dense study materials that utilise a smaller vocabulary. However it's a mistake to think that just because business English is a bit more dense than Goodnight Moon, that it's unreadable, and it's a worse one to think its lack of accessibility is without some value to the writer. I should think people should want to seek out that value in exactly the same way.
inmorco 7y ago
Readability is defined by the fact that anyone who understands the language shouldn't need to "know how to read it". Conventions, style, standards, etc are explicitly created for the purpose of lowering the barrier to entry for understanding and maintaining a piece of code. The maximum number of potential users who can quickly interpret and be productive with said code is the purpose of the concept of readability. Unless you are claiming a specific advantage for the stylistic choices over simply taking more care to write more conventionally readable code, I don't understand your objection to the term unreadable. "unreadable" in common parlance of the software world is not taken to mean literally impossible to parse but simply, not optimised for ease accessibility for the maximum number of people in the shortest amount of time. I'm afraid that means that the fact there is debate over this to such an extreme suggests this is at the very least, not very readable. As with everything, there is a balance required. Unreasonable lengths should not have to be undertaken to maximise code readability. I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in readability? What is gained for such a potential expense?
- geocar 7y ago
  > Readability is defined by the fact that anyone who understands the language shouldn't need to "know how to read it". Perhaps then this isn't C, but a language compatible with (at least a few) C compilers. This language is something you can learn to read as effortlessly as you read other languages (perhaps more so), you simply haven't learned how to read this yet. If you want to suggest readability is defined in that way and no other, how can someone who does not know this language make a statement about its readability? I'm not sure I'm convinced with this line of thinking, because it's incredibly exclusionary, just watch: > I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in [me being unable to read it]? What is gained for such a potential expense? Why would anyone want your input on something you do not understand? Why would anyone write in Chinese if you cannot understand Chinese? What is the point in this kind of definition of "readability"? Does that make sense? Surely it's much more useful to talk instead about what the capability of the programmer is that can read and write and maintain code written this way, instead of the possible missed opportunities of the programmer that cannot?

by geocar 7y ago

deleted 7y ago

bakul 7y ago
If you are interested, try something like this to start making sense of the code: cc -E m.c | indent | grep -v INDENT | less and separately read k.h for typedefs etc.
geocar 7y ago
Sure. The variables x,y,z are used to describe the first, second and third arguments. This is a common convention, so you get used to it. tX, tA and ta are type enums. A1(f,b) is just a 1-ary function f with the body b; A2 2-ary, and A3 3-ary. A_(f...) is a list of A (box) objects; literally (A[])({f1, f2, ... fn}) to avoid an extra definition. atnv is a mnemonic for allocate of (t)ype, le(n)gth, (v)alues. This is not dissimilar from Arthur's ktn(t,n) function, except it also fills the buffer with the values (memcpy). These are allocation wrappers for the rest of the interpreter. I've tried to write some about why this style is better on HN previously: - https://news.ycombinator.com/item?id=10876975 https://news.ycombinator.com/item?id=10876975 - https://news.ycombinator.com/item?id=8476294 https://news.ycombinator.com/item?id=8476294 and I'm used to a certain amount of abuse from people who think I'm "trolling" because I have adopted a similar style for my own work: - https://github.com/geocar/dash/blob/master/d.c#L63 https://github.com/geocar/dash/blob/master/d.c#L63 - https://github.com/geocar/con/blob/master/con.c https://github.com/geocar/con/blob/master/con.c I don't let it bother me though. Occasionally you meet people who can be convinced to take a certain leap of faith, and then you get to have very interesting conversations about making software that you can't have otherwise. Perhaps you've heard this said of other things as well: That learning lisp makes you a better programmer even if you do not use lisp. This thing here, is kind of like that.
- tsimionescu 7y ago
  I've read and appreciate your previous posts. They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand. On the other hand, I think that there are two aspects of this style that need to be separated - the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. There is something else to the style that might be applied to get those, and perhaps that would be more important to teach than the ability to read 'notation-like' code (for lack of a better name). I do understand the claim that the identifier style is what helps you understand and review the code much better, so it may be an enabler.
  - geocar 7y ago
    Thanks for giving this an actual shot. I appreciate it's alien tech, but it's something I've grown quite fond of over the last few years and I enjoy talking about it. > They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand. Oh they're not the only one. Look at maths papers from the last ten years versus just twenty years ago: So much more verbose! So hostile to brevity! The benefit to a good notation is keeping in your head the solution. The downside to a good notation is that it keeps people from contributing to the solution that don't understand the notation. My conjecture: People who can't learn the notation can't contribute for other reasons. My second conjecture: This shit isn't as hard as people think it is. > the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. This is not true! When I wrote the first kOS kernel, I wrote it with newlines and tabs because I didn't know any better. When I rewrote it in this style, I noticed a lot of code duplication that I could only see because the kernel now fit on a screen. This made my program smaller (original kernel was around 50kb the new one was around 30kb) which left more room in cache for programs making them faster as well. I was also able to see bugs that were only visible because I could see the caller and the callee at the same time and correct them. It all adds up! Since then, I've had numerous opportunities to see similar effects in other programs. Learning how to use notation has made me a better programmer.

saagarjha 7y ago

You're a bit off, because this is C and I know how to write it. I can read and write English pretty well, too, but I have come across literature that is unreadable in that language as well.

smcl 7y ago
Your comment about this being like unreadable English is very astute and got me thinking. To me if someone says "m.c" is nice and readable, it's a bit like someone claiming Finnegan's Wake is. For anyone who is not aware, this is what Finnegan's Wake looks like: """ riverrun, past Eve and Adams, from swerve of shore to bend of bay, brings us by a commodius vicus of recirculation back to Howth, Castle and Environs. Sir Tristram, violer d'amores, fr'over the short sea, had passencore rearrived from North Armorica on this side the scraggy isthmus of Europe Minor to wielderfight his penisolate war; nor had topsawyer's rocks by the stream Oconee exaggerated themselse to Laurens County's giorgios while they went doublin their mumper all the time.... """ The difference is that I don't think anyone makes the claim that Finnegan's Wake is readable or easy to work with. Everyone's pretty much agreed that this is a very unusual style that takes an enormous amount of time and effort to appreciate and understand. The style is fine, if it's someone's "thing" then great, more power to them. But what gets me is people pointing to this style of coding and feigning ignorance or surprise that others could find it troublesome and making a big point of saying "Well it's easy for me, I guess you're just not smart" when confronted about it
- geocar 7y ago
  > But what gets me is people pointing to this style of coding and feigning ignorance or surprise that others could find it troublesome and making a big point of saying "Well it's easy for me, I guess you're just not smart" when confronted about it Hey listen, I understand that other people find it troublesome. The thing is that I think it's something people can learn if they want, and I think there are benefits to doing so. I only object to the label "it's unreadable" because it demands the author (or someone else) make it "readable" to cure, when the right fix is to fix the programmer: to give them the experiences needed to be able to read it. That's admittedly not very easy for the novice reader- certainly it would be much better for them to write less dense and use a smaller vocabulary, and that's why, just with English, we start novice readers with less dense study materials that utilise a smaller vocabulary. However it's a mistake to think that just because business English is a bit more dense than Goodnight Moon, that it's unreadable, and it's a worse one to think its lack of accessibility is without some value to the writer. I should think people should want to seek out that value in exactly the same way.

inmorco 7y ago

Readability is defined by the fact that anyone who understands the language shouldn't need to "know how to read it". Conventions, style, standards, etc are explicitly created for the purpose of lowering the barrier to entry for understanding and maintaining a piece of code. The maximum number of potential users who can quickly interpret and be productive with said code is the purpose of the concept of readability. Unless you are claiming a specific advantage for the stylistic choices over simply taking more care to write more conventionally readable code, I don't understand your objection to the term unreadable. "unreadable" in common parlance of the software world is not taken to mean literally impossible to parse but simply, not optimised for ease accessibility for the maximum number of people in the shortest amount of time. I'm afraid that means that the fact there is debate over this to such an extreme suggests this is at the very least, not very readable. As with everything, there is a balance required. Unreasonable lengths should not have to be undertaken to maximise code readability. I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in readability? What is gained for such a potential expense?

geocar 7y ago
> Readability is defined by the fact that anyone who understands the language shouldn't need to "know how to read it". Perhaps then this isn't C, but a language compatible with (at least a few) C compilers. This language is something you can learn to read as effortlessly as you read other languages (perhaps more so), you simply haven't learned how to read this yet. If you want to suggest readability is defined in that way and no other, how can someone who does not know this language make a statement about its readability? I'm not sure I'm convinced with this line of thinking, because it's incredibly exclusionary, just watch: > I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in [me being unable to read it]? What is gained for such a potential expense? Why would anyone want your input on something you do not understand? Why would anyone write in Chinese if you cannot understand Chinese? What is the point in this kind of definition of "readability"? Does that make sense? Surely it's much more useful to talk instead about what the capability of the programmer is that can read and write and maintain code written this way, instead of the possible missed opportunities of the programmer that cannot?