Live data from Hacker News

Nobody's just reading your code

akkartik.name

61–70 of 188 posts

Re: Nobody's just reading your code

#61
post #50

I had to use a js library for something today. npm install downloaded 113 new packages. I'm not even a javascript programmer; I'm saddled with being "full-stack" I'm supposed to read all that every time I need a new library? Or write it myself, when I have absolutely no idea how to build something that complicated, if I had time, negating the whole point of OSS in the first place?

OP makes no prescription about reading code. It merely points out what successful attempts to understand strange codebases have in common, and discusses what writers can do to help readers succeed.

(I proof-read drafts of OP. And I have made prescriptions about reading code. But that's a separate story.)

Re: Nobody's just reading your code

#62
This is a bit western centric maybe, because I see Chinese developers reading tons of code, to the point that I receive an incredible amount of Redis PRs about conceptual bugs that can never happen in practice, since some Chinese developer is reading the code and doing the math in her/his head.

Re: Nobody's just reading your code

#63
post #2

One of the things that sets a good programmer apart is the willingness to fearlessly dig into someone else's code. I've heard it said before that you're responsible for every line of code you ship to your users. It follows that you shouldn't treat your dependencies as black boxes. Getting a stack trace that's 3 or 4 levels deep in Django/React/ ? Dig under the covers and understand what's happening. Include that info…

Really good programmer is imo set apart by ability to decide when to dig into others code and when not.

Re: Nobody's just reading your code

#64
post #54
post #53

Earlier quoted context omitted.

7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.

This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.

That's a last resort, but it's important to remember that the option is on the table.

Then consider ditching this dependency (either by switching to a different one or with your own code) if the maintainers are not active enough.

Re: Nobody's just reading your code

#65
post #60

In a similar vein, I often wonder just how many people actually check cryptographic algorithms. We'd all probably agree that it is good not to roll your own crypto algorithms, or even in implementation of known crypto such as AES. But how many experts in the world are there for AES and secure hashing? A lot of the major MD5 and SHA1 work all came from Marc Stevens' team. How many experts are there in this field, real…

I'm far from an expert in cryptography but I've had to dig into OpenSSL's codebase on more that one occasion and every time it left me with a deep sense of uneasiness. It's really not what I would deem good code: too many macros, too many potentially confusing API conventions (inconsistent return values in case of error, unclear resource lifetimes, ...), not enough comments and documentation...

It's not the worst C codebase I've ever seen (far from it) but for something as critical I'd put the bar very high it terms of code quality and OpenSSL doesn't even come close.

Re: Nobody's just reading your code

#66
If you want to exercise reading concise and easily understandable standard C code, grab a toy project from suckless.org. Even though I write my code more defensively in some ways, that stuff is really straightforward to hack on.

Re: Nobody's just reading your code

#67
Reading code just for fun was a thing in the early and mid years of UNIX (eg., 7th edition or System V). People eagerly passed around faint 10th generation photocopies of Lion's printout of and commentary[1] on the UNIX source code. The annual USENIX conference had a popular short course in which they went through the entire UNIX kernel line by line. Why was that a thing back then and not now? Certainly UNIX was an amazing piece of work, but there are amazing works today -- the modern browser for example.

I think that the difference is that the totality of the UNIX kernel was comprehensible for a single mind. The UNIX kernel in 1983 was less than 20,000 lines of code, almost all in C, and more than 75% was not machine-dependent.[2] The amazing software of today, something worthy of reading for fun, is literally millions of lines of code, written in multiple languages you don't know, and evolving so fast that whatever you read might be completely different a few months later. There's no joy in knowing a tiny part of that. It would be like reading 10 pages from the middle of a novel, a novel so big that you know you'll never finish it.

[1] https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...

[2] https://en.wikipedia.org/wiki/History_of_Unix#1980s

Re: Nobody's just reading your code

#68
I read the source code for the libs all the time, mostly to see what methods and properties they expose. I learn something new every time. This is JavaScript/NodeJS. I don't miss compiled .dll's

Re: Nobody's just reading your code

#69
I love to dig through peoples code. Unfortunately I know myself enough to know that it can be a giant time sink if I let myself go.

In swedish there's a phrase called "snöa in", to get snowed in literally, and that's what happens to me.

So after enough years in the biz I try to hold myself back from this habit.

Re: Nobody's just reading your code

#70
post #21

One of the reasons I love golang* is how the entire source code for the standard library is just a few easy clicks away from the documentation on how to use it. As an example: When I want to do something and the interfaces I'm seeing provide friction (XML parsing not /quite/ handling normal, slightly incorrect, HTML) I can get a better idea of what the library is doing behind the scenes. I got an example of how to us…

> One of the reasons I love golang* is how the entire source code for the standard library is just a few easy clicks away from the documentation on how to use it.

Not just a few clicks. In my editor, I just navigate into /usr/lib/go/src/ which is where my distribution (Arch) puts the stdlib sources. For example, /usr/lib/go/src/io/pipe.go for the implementation of io.Pipe() which I was looking at the other day.

Post reply on HN