My code is more readable for me than yours. That’s just how it is. While the JavaScript CoffeeScript compiles looks decent, it’s still not mine.
That would change if you practiced reading other peoples' code. When I see my code, I often think, "yeah, I wrote this" because I know how I name things, but other than that, my code looks like everyone else's code. I know this because I based my style on what other people do, rather than just inventing my own. (At work, people like to write Python likeItsJavaOrSomething, and I refuse to follow that convention. While ugly, it doesn't make the code amazingly hard to read. You get used to it with practice.)
Now, compiler output is another thing, but c'mon. Sometimes I have to figure out what the computer is doing by reading memory dumps in gdb or the assembly output of gcc -O3. Complaining about the output of a JavaScript compiler is just silly; do it more and you'll figure it out. Programming is all pattern recognition, and if you can't understand patterns in the output of your toolchain, then you aren't using the tools enough.
People also like to complain about things like GHC's type inference errors or Perl's "confess" dumps. I personally have no problem extracting the information I need from them. I write a lot of programs and they fail a lot, so I've gotten good at reading the debug messages. Instead of saying, "this is too hard", try harder, and soon your life will be much better.
> That would change if you practiced reading other peoples' code.
I'm really active on github, and actually read the source code of a lot of projects instead of reading books, and contribute to a bunch of them too. Quite assuming of you to assume I don't.
My code, since I wrote it, will always be easier to understand because I dealt with every problem--not because of the style.
I totally agree with you there. There is something totally different about reviewing someone else's code versus reading your own. Because even if you wrote it a long time ago, it's still easy to reverse-engineer the purpose of everything you did.
That would change if you practiced reading other peoples' code. When I see my code, I often think, "yeah, I wrote this" because I know how I name things, but other than that, my code looks like everyone else's code. I know this because I based my style on what other people do, rather than just inventing my own. (At work, people like to write Python likeItsJavaOrSomething, and I refuse to follow that convention. While ugly, it doesn't make the code amazingly hard to read. You get used to it with practice.)
Now, compiler output is another thing, but c'mon. Sometimes I have to figure out what the computer is doing by reading memory dumps in gdb or the assembly output of gcc -O3. Complaining about the output of a JavaScript compiler is just silly; do it more and you'll figure it out. Programming is all pattern recognition, and if you can't understand patterns in the output of your toolchain, then you aren't using the tools enough.
People also like to complain about things like GHC's type inference errors or Perl's "confess" dumps. I personally have no problem extracting the information I need from them. I write a lot of programs and they fail a lot, so I've gotten good at reading the debug messages. Instead of saying, "this is too hard", try harder, and soon your life will be much better.