4 ms·

Pick any program outside of the homework range, any program of 200+ lines, and it's not going to meet a standard of elegance. That's because, as the artic

Pick any program outside of the homework range, any program of 200+ lines, and it's not going to meet a standard of elegance. That's because, as the article says, smallness is usually presented as an integral part of elegant code. 200+ lines of code is not small, by definition. 200+ lines of code also look like a jumble in any language (especially when you don't know the language well, but even when you know the language very well), unless you take the time to pick it apart and understand it. I think the main problem is this: you can't judge elegance from merely glancing over code. You have to understand it to judge whether it is beautiful. Unfortunately, because all those small examples have primed us to equate smallness with beauty, any larger program is swiftly deemed ugly. This takes conscious effort to overcome: large programs can be beautiful, but they require you to discover the beauty. It won't be obvious.

drostie 15y ago
I don't know. I composed a lazy-evaluation library called promises.js for an ongoing project which I call "ducky": https://github.com/drostie/ducky/ https://github.com/drostie/ducky/ Now, it's 277 SLOC by GitHub's reckoning, and it solves a really esoteric problem (providing a language to wrap asynchronous calls in, so that you can write asynchronous code synchronously). The problem wouldn't even be particularly clear if you didn't know something about Node.js and how the API is set up. In that sense maybe you're right. But there's another sense in which you're maybe not right. Perhaps this is just me feeling too much fatherly affection for my code, but I like to think that even if you were baffled by the expected use of the project, you could still break promises.js into chunks (in fact, in the source it's done for you) which helps you understand what each of these methods is, and what it does, and how to use it to accomplish some bizarre and esoteric goal. So it's semantically ugly in a deep sense -- "what the hell is this doing, why am I reading this code" -- if you do not take the time to 'discover the beauty', to use your words. But it's semantically pretty in a much less profound sense; the code is pretty straightforward to look through, and the higher-order ideas are built straight out of lower-order ideas, which are clearly partitioned off, and so forth.

drostie 15y ago

I don't know. I composed a lazy-evaluation library called promises.js for an ongoing project which I call "ducky": https://github.com/drostie/ducky/ https://github.com/drostie/ducky/ Now, it's 277 SLOC by GitHub's reckoning, and it solves a really esoteric problem (providing a language to wrap asynchronous calls in, so that you can write asynchronous code synchronously). The problem wouldn't even be particularly clear if you didn't know something about Node.js and how the API is set up. In that sense maybe you're right. But there's another sense in which you're maybe not right. Perhaps this is just me feeling too much fatherly affection for my code, but I like to think that even if you were baffled by the expected use of the project, you could still break promises.js into chunks (in fact, in the source it's done for you) which helps you understand what each of these methods is, and what it does, and how to use it to accomplish some bizarre and esoteric goal. So it's semantically ugly in a deep sense -- "what the hell is this doing, why am I reading this code" -- if you do not take the time to 'discover the beauty', to use your words. But it's semantically pretty in a much less profound sense; the code is pretty straightforward to look through, and the higher-order ideas are built straight out of lower-order ideas, which are clearly partitioned off, and so forth.