Ask HN: What source code is worth studying?

Looking at their GitHub now I must admit that the source code and comments look pretty good.

Here is a link to cpython 2.7 libraries: http://hg.python.org/cpython/file/70274d53c1dd/Lib

Those that are implemented in C are in the "Modules" folder from the top level.

I think you [OP] will get the most benefit from reading libraries that you use often because it will give you some direction.

If there are 3rd party libraries you use heavily those will be interesting too.

It is very very difficult to just pick up megabytes of code and start reading them and find it useful. You will be able to pick up style and conventions but not really high-level engineering decisions.

My suggestion is to take software that you use regularly and run it through a debugger. Since you use it you know the problem domain. And with the debugger the code you're reading gets real context. I've done this with Git for example.

And also look at the design documents for big OSS projects.

It got better when I remembered we're a Matasano client so I shouldn't feel so guilty about harassing them. But it's an awesome free thing they're doing, so I still do feel a little guilty.

However, I've noticed over this same time period that these screeners stumble into the office for a follow-up interview like giant toddlers: disheveled, incoherent, and totally self-involved. I wish this stereotype of the socially-awkward-yet-brilliant hacker would die in flames because it is not reality (or at best 2% of the community). Instead, this cultural delusion is convincing the socially awkward masses to seek out a job that is mostly about working closely with others, communicating constantly, and continuous compromise.

I have children in their 20's and I've seen how hard it can be to find your calling in life, but just because 99% of douche-bags earn a spot on reality tv that doesn't mean all stereotypes are true. Don't choose a job that you think fits your personality but that actually requires you to behave differently because you'll be miserable.

Anyway, illegal is illegal, and copy-pasting from Tarsnap would be illegal. I didn't know Tarsnap was under a restrictive license. It's a shame that people will have to be so careful when learning from Tarsnap, as it's a paragon of modern C best practices, but maybe the license is shrewd.

Though I wish the mentality of "my competitors might steal the code!" will die its deserved death, since evidence thus far suggests it's just paranoia. For example, the codecombat guys open sourced everything and have been fine: https://news.ycombinator.com/item?id=7015126 (But of course that's easy for me to say when I have no competitors to worry about!)

Or you mean trying to find long repeat sequences that are slightly mutated in a way that is low-entropy?

One good example of the problem with his "technical" works and his lack of actual experience with the things he likes to talk about so much, is that he makes and promotes outrageously incorrect claims like:

https://en.wikipedia.org/wiki/Linus's_Law

"Given enough eyeballs, all bugs are shallow."

When in fact:

Given ANY number of eye, "all" bugs are NOT shallow.

Some bugs are NEVER "shallow".

And only a FEW eyes are qualified to see some bugs, while MANY eyes are totally unqualified, including his own:

His mouth is certainly not qualified to make sweeping generalizations about "all" bugs, given his lack of experience as a programmer, and his spectacular public failure at auditing code in his pathetic attempt to discredit the now-exonerated scientists whose code predicted global warming (described below).

Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software.

"Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software, because you can license much proprietary source code, and some proprietary source code is available for you to read and audit for free, under licenses like Microsoft's "Shared Source" license.

https://en.wikipedia.org/wiki/Shared_source

And qualified eye balls are NOT FREE, and usually very busy being well paid to look at much more interesting things than poorly written buggy code like OpenSSL. I doubt that Eric Raymond has contributed any of the profits from his books or VA Linux stocks to Theo De Raadt or anyone else who actually takes the long time and tedious effort to actually audit code.

Wikipedia points out:

>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".

And then there's the fact that Eric Raymond had the nerve to name and blame the "law" on Linus instead of taking "credit" for it himself.

And of course he also has the nerve to attempt to defend his "law", after we've just gone through three HUGE security holes in open source software that would have been discovered long ago, if only "Linus's Law" were true. On his blog, he constructs a straw man argument that "proprietary software is worse than open source software", which does not in any way support his claim about "all bugs being shallow".

http://esr.ibiblio.org/?p=5665

Nor does he address many of the valid points that people raise, in the wikipedia article itself I just quoted, or that people raised in response to his blog posting.

To quote Theo De Raadt: “My favorite part of the “many eyes” argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code.”

The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompeten...

3.0 out of 5 stars Autohagiography with some programming tips, December 24, 2003 By A Customer

The writing style of this book tends to hurt the reading experience, as Raymond trumpets his own minor achievments in the free software community. The work feels like it needed one more rewrite before being released to the public: some related sources Raymond hadn't yet read at the time of writing, and some of his advice gets repetitive.

The exposition itself is not up to par with The Elements of Programming Style. Raymond tries to give a list of programming rules or principles to follow, but it reads more like a list of slogans that should be taken as axioms. While The Elements of Programming Style itself had a list of rules, the rules were well woven with each other, well defended, and they were used as a means of conveying a larger story. In Raymond's case, he relies upon the slogans in absence of such a story.

Thus, the book ends up more like a list of random unrelated tips. Some very profound, like his writings on threads (which he acknowleges Mark M. Miller for his help). Others are very shallow and pointless in a book that supposes to call itself about "Art." Some of the pieces appear only to function to attack Windows, and sometimes the information about Windows is embarassingly inaccurate.

One final criticism is that Raymond does not understand object-oriented programming very well and misses the point in several cases. You just need to see the popularity of Python, Java, C# (Mono), OO Perl and C++ in the Linux world to see that Raymond is off base calling OO a failed experiment. In fact, with almost any matter of opinion in the book you can feel Raymond's bias and be hit in the face with misinformation or dull false dilemmas.

However, given this book's many flaws, I rate this 3 stars instead of 2 stars because it also has valuable information from the many contributors, some of them Gods in the Unix world. These contributors often even disagree with Raymond, or point out other interesting tidbits. For these tips alone, it is worth checking out this book, though I would not recommend you buy it.

To get the true Unix programming philosophy, I recommend Software Tools, by Kernighan and Plauger. It's somewhat dated, and I recommend the Ratfor version of it, but that single book has became very influencial as I grow as a Unix programmer.

[...]

One of the problems with this book is the overly partisan tone it takes - one gets the impression that absolutely nothing Microsoft has ever done is of value, but the other major desktop PC OSes (Apple, Linux) represent different forms of perfection. (At home, I run Mac OSX, RedHat Linux and Windows, and have a reasonable sense of their relative strengths and weaknesses.)

So, be warned: Art of Unix Programming paints a one sided picture. The author is a well-known figure in the open source community, one of its fiercest advocates, and one of Microsoft's most vocal critics, so it might seem to strange to wish for less anti-Microsoft spin from this source. After all, the Raymond brand certainly carries with it an obligatory expectation of Windows-bashing, doesn't it?

One of the only Windows design decision which Raymond doesn't condemn is the (now discontinued) .ini file format. Even the thorough-going support for object-orientation in Windows is given short-shrift: after explaining the many horrors of object-oriented programming (according to Raymond), Unix-programmers are praised as "tend[ing] to share an instinctive sense of these problems." This section ([...]) is particularly illustrative of the one-sided approach that Raymond takes.

[...]

His comments about the Windows registry were a bit distressing, though -- not because they're negative, which I consider fine. Rather, it was obvious he&#x...