[HN Gopher] Ask HN: What's the best source code you've read?
___________________________________________________________________
Ask HN: What's the best source code you've read?
What did you read that was really eye opening in some way? Please
provide a link, if possible.
Author : KennyFromIT
Score : 114 points
Date : 2022-09-10 18:57 UTC (4 hours ago)
| Teknoman117 wrote:
| I'm probably biased, but I particularly enjoyed going through mpv
| - https://github.com/mpv-player/mpv
|
| I always found much of the FFmpeg API very unintuitive and much
| of what I now know about it I learned from reading through mpv.
| Hardware accelerated encode/decode, etc.
| fiatjaf wrote:
| https://github.com/ElementsProject/lightning
| db48x wrote:
| I haven't read all of it, but the Principia source code has a
| comprehensive units system and makes effective use of Unicode:
| https://github.com/mockingbirdnest/Principia/
|
| https://github.com/mockingbirdnest/Principia/blob/master/ast...
| is a decent example of both: // We compute the
| mean rate (slope) of the mean anomaly M(t), the mean //
| argument of latitude u(t), and the longitude of the ascending
| node O(t). ... Product<Angle, Square<Time>>
| S_Mt_dt; Product<Angle, Square<Time>> S_ut_dt;
| Product<Angle, Square<Time>> S_Ot_dt; ... S_Mt_dt
| += (Mt + previous_Mt) / 2 * dt; S_ut_dt += (ut +
| previous_ut) / 2 * dt; S_Ot_dt += (Ot + previous_Ot) / 2
| * dt; ... anomalistic_period_ = 2 * p * Radian *
| Dt3 / (12 * S_Mt_dt); nodal_period_ = 2 * p * Radian *
| Dt3 / (12 * S_ut_dt); nodal_precession_ = 12 * S_Ot_dt /
| Dt3;
|
| The advantages are concise notation plus compile-time guarantees
| that the units work out. I don't care much for C# in general (or
| C++ for that matter), but I like the results here.
|
| Sounding out the Greek names occasionally used as release names
| is always fun too.
| lampshades wrote:
| C#?
| db48x wrote:
| Much of it is in C# so that it can be run inside KSP.
| drewg123 wrote:
| The {BSD/OS, Free and Net}BSD sources in the mid-90s, coming from
| Linux and a source license for a commercial unix, both of which
| were mostly undocumented and didn't have any version control. The
| commercial unix was really grody, with lots of copy/paste of the
| same function with different bugs each time, and comments with
| bug numbers that meant nothing to us and didn't explain a thing.
|
| The BSD sources were sanely laid out, documented and had a
| beautiful coding style that made the code easy to read. Free- and
| NetBSD even had version control.
| orthoxerox wrote:
| Redis. After struggling with extending QBE I thought that was how
| C was written in general, but Redis restored my optimism.
| mcculley wrote:
| I don't know if it was the best, but one of the codebases that
| really helped me out in the mid-90s was XEmacs. It was portable
| to many kinds of systems and had lots of features that most
| applications never have to worry about (e.g., an embedded
| interpreter). I also got value out of GNU Emacs but XEmacs tried
| harder to be a good citizen on the X desktop and there were lots
| of lessons learned in there that I was able to leverage for the
| applications I was building at the time.
| r3trohack3r wrote:
| I like the redis source code and WebTorrent
|
| https://github.com/webtorrent/webtorrent
|
| https://github.com/redis/redis
| choletentent wrote:
| Lua [1]. [1] https://github.com/lua/lua
| mccorrinall wrote:
| Shodan. I used its codebase to learn python and recommend it
| everyone else.
| walthamstow wrote:
| Got a link? I'm not familiar with Shodan and I've done some
| searching but not found anything immediately obvious
| mccorrinall wrote:
| https://github.com/achillean/shodan-python
| prezjordan wrote:
| Contrarian answer: Conway's Game of Life in Dyalog APL
| https://www.youtube.com/watch?v=a9xAKttWgP4
|
| It feels like the logical end state of "clever" code, for better
| or for worse. Or, alternatively, what happens when a standard
| library is gigantic but each keyword is 1-2 characters.
| JohnHaugeland wrote:
| my favorite of his videos is the sudoku solver:
| https://www.youtube.com/watch?v=DmT80OseAGs
| btilly wrote:
| Not exactly source code, but the
| https://frinklang.org/frinkdata/units.txt is the most fascinating
| configuration file I've ever read. It is also the only one that I
| occasionally re-read just to enjoy the commentary on the
| standards organizations that are responsible for some of the
| complexity.
| omn1 wrote:
| ripgrep by BurntSushi (https://github.com/BurntSushi/ripgrep)
| inDigiNeous wrote:
| Well, eye opening was the C++ source code I was able to work with
| at a previous company, they were an automotive HMI developer
| company. They had really strict and well planned code structure
| that just hit a chord with me.
|
| Can't provide source though on that one, as it's a propietary
| engine. Recently I've enjoyed reading the source code to Sokol,
| lot's of really good decisions there and I love the minimal C
| -style structure:
|
| https://github.com/floooh/sokol
| Bolkan wrote:
| Nix source code is also a pleasure to read through. I was
| surprised that c++ could be so beautiful and well written.
| jmconfuzeus wrote:
| Ruby's Sinatra.
|
| I read it before learning Ruby but surprisingly, the code made
| sense even though I didn't know the language.
| dataflow wrote:
| If you're looking for C, ReactOS. Example:
| https://doxygen.reactos.org/d3/d60/ntoskrnl_2io_2iomgr_2file...
| reacharavindh wrote:
| While at Grad school, before taking a course on Systems
| programming, I spent a few days reading through Redis source
| code. It felt almost like poetry.. I haven't had that level of
| motivation or time to read open source code like that again.. so
| there may be better examples.. but this was my best...
| johndoe0815 wrote:
| Maybe not revolutionary, but I think this article about static
| binary translation is a great introduction to the topic:
|
| http://www.gtoal.com/sbt/
|
| (see also the "Virtual Machines" book by Smith and Nair, ISBN-13
| 978-1558609105, if you are interested in this topic).
|
| I can also recommend John Lions' "Commentary on the Sixth Edition
| Unix Operating System" - https://warsus.github.io/lions-/,
| Douglas Comer's Xinu (https://xinu.cs.purdue.edu) as well as
| Niklaus Wirth's "Compiler Construction"
| (https://people.inf.ethz.ch/wirth/CompilerConstruction/Compil...)
| and Project Oberon (http://www.projectoberon.com).
| thefz wrote:
| I don't know if it is the most elegant, or concise, or l33t, but
| I am in love with Polly https://github.com/App-vNext/Polly
| halftrolling wrote:
| Briefly used Polly at $OLDJOB and it has "Java" library vibes
| for me. Being on Node at work these days, I wish more libraries
| carried this quality.
| dhosek wrote:
| Nobody has mentioned Knuth's corpus of work in Pascal-Web for the
| TeX ecosystem. This is code written for an era where there wasn't
| an ecosystem of libraries for common tasks and even things like
| being able to access a file in random access order couldn't be
| counted on. Even 7-bit ASCII couldn't be counted on as a given
| (EBCDIC-based IBM mainframes were a significant element of the
| computing landscape still).
|
| Against all that, Knuth wrote code that could be ported to other
| systems (I first used TeX on an IBM mainframe running VM/CMS,
| then later on a VAX minicomputer running VMS, then on a PC with
| DOS, PC with OS/2, PC with Windows and now a Mac with OS X/MacOS.
| His presentation of code and internal documentation intermingled
| is something which I could see still being useful now, although
| sadly, literate programming seems all but dead now. I still go
| back to Knuth's code to understand how to solve some problems on
| occasion even though it's about 30 years since I last wrote a
| line of Pascal.
| db48x wrote:
| I second the nomination. I too have found the TeX Book to be
| very readable.
| MeyerK wrote:
| All of the PC/GEOS source code...
| https://github.com/bluewaysw/pcgeos
| zonetti wrote:
| Peter Norvig's spell checker: https://norvig.com/spell-
| correct.html
| emmelaich wrote:
| All Norvig's code is nice to read and also often enlightening.
| _mhr_ wrote:
| His Lis.py is also wonderful.
| aestetix wrote:
| Duff's device.
| lioeters wrote:
| A few that come to mind..
|
| Hand-written compiler for WebAssembly Text format to binary -
| https://raw.githubusercontent.com/stagas/wat-compiler/main/s...
|
| Gameboy emulator implemented in C, that also runs in the browser
| - https://github.com/binji/binjgb
|
| QuickJS Javascript Engine - https://github.com/bellard/quickjs
|
| The TypeScript language and compiler -
| https://github.com/microsoft/TypeScript
| Cieplak wrote:
| I quite like the FreeBSD src tree, as it comprises both the
| system kernel as well as the userland applications. The folders
| are organized similarly to the OS file system hierarchy, which I
| find helpful for navigating the source tree. I found it
| accessible to slowly learn how various parts of the OS work under
| the hood and compound my knowledge faster due to less context
| shifting, since it's self-contained in one source tree.
|
| https://github.com/freebsd/freebsd-src
| ranger_danger wrote:
| Not the code itself but the BeOS/Haiku system API is the best OS
| interface I've seen. So much nicer than Win32 or MacOS APIs.
| agumonkey wrote:
| I like Piumarta's code
| https://piumarta.com/software/maru/maru-2.4/
|
| bsd code is clean
|
| minikanren
|
| some old lisp (le lisp or eulisp I forgot)
| juancn wrote:
| One of the most surprisingly clear code bases is LLVM. It's an
| old complex beast, yet it's organized beautifully.
|
| I mean, it has a lot of essential complexity but little
| accidental complexity.
|
| That's usually what I strive for when coding. Complexity is
| sometimes unavoidable, that's fine, that's why it's essential.
| However, avoidable complexity should be... well... avoided.
| tester756 wrote:
| chirau wrote:
| Why? If you don't mind me asking.
| omaranto wrote:
| Probably to keep people from asking that it be rewritten in
| Rust.
| tester756 wrote:
| Rust is the only language out of those hyped that actually
| made me excited because it brings interesting features.
|
| Additionally out of the box you have one cli with compiler,
| package management, etc. instead of 30 choices to pick from
|
| C++ for me is just: terrible compilation times, 17 ways to
| achieve one goal, not strong ecosystem
|
| Generally not the nicest developer experience in compare to
| e.g C# or apparently Rust.
|
| I'd feel more motivated to jump into LLVM code base it that
| was written in Rust because I don't think C++ is the future
| - which is sad, because C++ has a lot of cool jobs now.
| sodapopcan wrote:
| [deleted]
| lagrange77 wrote:
| > a lot of essential complexity but little accidental
| complexity
|
| Nice one. I'll copy that.
| bla3 wrote:
| That's from "The mythical man-month". Old, and some parts are
| obsolete, but still worth a read as it does have a bunch of
| good insights.
| mianos wrote:
| I have not read it in a while but it would be interesting
| to debate what essays are no longer relevant. I'll be
| grabbing it off the shelf next to my original copy of the
| Byte issue on C mentioned yesterday and having a look for
| expired relevancy.
| suprfnk wrote:
| You might be interested in reading the paper, No Silver
| Bullet, in which Fred Brooks coined these terms:
|
| http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
| kragen wrote:
| Didn't he copy them from Aristotle?
| bonzini wrote:
| The idea of essence and accident comes from Aristotle,
| while essential and accidental complexity is new by
| Brooks.
| vkazanov wrote:
| Postgres code is very good, redis as well. Some of the core parts
| of Linux also totally worth learning from.
|
| I also remember how Qt UI code and docs were a revelation after
| the nightmare of win32 and related frameworks.
|
| Bellard's original Tinycc was very entertaining and took a while
| to digest.
|
| Most old and well-maintained projects are worth learning from.
|
| Apart from some local tips and tricks what is more important is
| understanding that there's nothing special about other people's
| code.
| hahnchen wrote:
| Which part of linux core? I've been wanting to but I don't know
| how/where to start
| suprjami wrote:
| I enjoyed reading the VFS layer down into the NFS client file
| ops and then the RPCs created from them. (skip the RPC state
| machine)
|
| An easier entry point might be the ethtool_ops in an earlier
| Intel network driver like e1000.
| klabb3 wrote:
| Redis used to be fantastic, I felt like I could read C without
| being particularly versed in it. I don't know if that's true
| anymore.
| halftrolling wrote:
| Was reading it the other day for shiggles. I'll second you and
| say "it still is."
| cammikebrown wrote:
| Quake
| Inviz wrote:
| Nginx felt pretty good
| fisherjeff wrote:
| cperciva writes easily the most approachable, understandable code
| I've ever come across, e.g.:
|
| https://github.com/tarsnap/kivaloo
| throwaway892238 wrote:
| I thought I wrote good Perl code until I read the Perl core
| modules. Like night and day.
|
| Busybox and uClibc are great examples of efficient C code. I
| submitted a feature, and they basically rewrote it to be less
| crap, and that taught me a ton.
|
| Hard to know what good Python code is. Everyone seems to use some
| framework that fundamentally changes how you write apps. "best
| source code" is probably just what's best for that specific kind
| of work.
| yjftsjthsd-h wrote:
| > the Perl core modules
|
| Likewise I've head good things about the Python standard
| library; I _suspect_ this works for many languages.
| smrtinsert wrote:
| I remember liking the java sdk java source. Great small focused
| functions and nice use of newlines. You could tell the developers
| were forged in an era without syntax highlighting and large
| horizontal screens. Extremely scannable.
| Tao3300 wrote:
| Yes! A fellow square! It's almost always a pleasant surprise to
| dig in and see how parts of java are actually implemented.
| halftrolling wrote:
| The Java standard library will forever be my baseline for
| "good." Perhaps the C# beats it, but then the overall ecosystem
| of third-party libraries is such that it isn't worth the slight
| improvements in design.
|
| Node, by comparison, is a ghetto.
| marginalia_nu wrote:
| Boolean.getBoolean("true");
| elromulous wrote:
| Idk about the best, but, this[1] implementation of hierarchical
| state machines is beautiful. It uses a few different template
| metaprogramming tricks to resolve state transitions at compile
| time! It's truly beautiful.
|
| [1] https://accu.org/journals/overload/12/64/heinzmann_252/
| badinsie wrote:
| Bitcoin
| shp0ngle wrote:
| That's absolutely not true.
|
| Bitcoin the app is often mixing several layers of abstractions
| and several usage patterns together.
|
| Is it for actually keeping track of money? Is it for APIs? is
| it for end users, or for servers? Is it CLI or a GUI app?
|
| And it's in C++, which is almost never readable.
|
| And of course they have their weird names for everything (all
| the ScriptSigs etc), and the OP script which is at the same
| time too complex and too simple.
|
| It's surprisingly robust and it survived a lot, sure; I don't
| take it down on that level; but the code even today got baggage
| of all the weird decisions Satoshi did when he made it.
|
| It's really not "good code" IMO.
|
| Although they have improved it a _lot_ in last few years, I
| will give them that. It was worse...
| RustyRussell wrote:
| Yes, I would second this. It's hard to rewrite, but needs it
| in many places that I've read (in particular, the code to
| detect BIP9 etc soft fork activation is horrible).
|
| To be fair, the slow polishing of a thousand hands continues.
| libsecp256k1 is tested to a level few if any FOSS libraries
| achieve, for example.
| monster_group wrote:
| Of course the one I wrote few months ago! When I re-read it today
| I realize how good I was at foreseeing all the problems that
| would eventually arise. The code has descriptive comments that
| explain not just what the code is doing but what it is supposed
| to do. I was very impressed with not just 100% line coverage but
| also complete branch coverage by rock solid unit tests. Sorry
| can't share the link because code is proprietary.
| valdect wrote:
| leveldb https://github.com/google/leveldb
| pandler wrote:
| I will always have a soft spot in my heart for Django, the python
| web framework, even though I don't use it anymore.
| https://www.djangoproject.com/
|
| When I was still learning to code, I spent hours and hours and
| hours poking around the Django source code. In particular I was
| fascinated by the metaprogramming used in the Model and Query
| objects, and I ended up learning a ton about how Python works
| under the hood.
| pbhowmic wrote:
| I feel much the same about django rest framework
| throwawayacc2 wrote:
| It's not the best, far from it, but it was fascinating to me so I
| will share.
|
| I used to work for a large newspaper. Engineering wasn't the
| focus of the business, it was only a means to an end, it was just
| something they needed to have a competitive website. As a result,
| the churn rate was very high. But more interesting there was also
| a very high return rate. Engineers would come and go and return
| and leave again all the time.
|
| As a result, the code base was a path work of various engineers
| with various skill level, different directions by different heads
| of engineering, repurposed old projects, legacy code and last
| minute additions by urgent request from the editors, among
| others.
|
| The part I was most familiar with was what I can only describe as
| a sort of next.js but unlike it, it wasn't planned or designed
| but rather it sort of grew organically over the years.
|
| The fascinating thing to me was precisely this phenomenon. Some
| projects have a clear design and purpose and are built so from
| the start. Sort of like a building or a mechanical clock.
|
| Others just evolve over time, they change, mutate, evolve,
| incorporate other bits. More like a biological organism or
| perhaps nature taking back a derelict settlement.
|
| At first as you can imagine it was difficult to wrap my head
| around it. But in time, I started to see the beauty in it. It had
| historical bits. There was code written in 2010 that ran in 2020.
| Others you could tell little habits of the writer. Not everything
| gets stamped out by the linter. There was this guy who wrote
| "class ClassName extends React["Component"]" - I have no idea why
| but I would run into code written by him and immediately
| recognise, ah yes, that's that guy.
|
| It's certainly not an example of a good code base, but to me was
| interesting being able to see the code as a living organism with
| a history and fingerprints of it's creators rather than a well
| designed machine.
| aerovistae wrote:
| The book "A Deepness in the Sky" features people living on an
| ship whose operating system is thousands of years old. One of
| the main characters is considered a software archaeologist of
| sorts - he's an engineer, but in a sense also a historical
| researcher.
|
| I can't emphasize enough that this notion is only a side point
| in the story and not a main aspect of the plot, sadly, so I
| wouldn't go reading it in hopes of hearing more. (Although it
| is a great book regardless.)
|
| I have often considered trying to write a scifi novel centered
| around this idea because I find it so fascinating.
| kragen wrote:
| DRMaciver wrote a novella about it. _Programmer at large_ ,
| it's called. Largely about cultural variation in gender and
| sex norms.
|
| https://www.drmaciver.com/category/programmer-at-large/
| (down)
|
| https://archiveofourown.org/works/9233966/chapters/20941043
| edfletcher_t137 wrote:
| The "software archeologist" idea has lived rent free in my
| head ever since I read the novel nearly twenty years ago.
| It's an absolutely fascinating premise, one I can most
| definitely see being viable to grow into a fully-fledged
| novel. I would definitely read that.
| latexr wrote:
| > I can't emphasize enough that this notion is only a side
| point in the story and not a main aspect of the plot
|
| Is it sprinkled throughout the story, or a mostly
| uninterrupted block of text? As in: is there an easily
| findable chunk of the book one could read for that idea
| alone? If so and you could provide a few keywords or a direct
| quote, I'd be interested in grabbing the book to read that.
| aerovistae wrote:
| I just went and glanced over the text by searching a pdf
| for a few key terms - no, it's really just sprinkled. The
| idea doesn't get much attention and is mostly mentioned in
| passing.
| CPLX wrote:
| Interesting to note that you're basically describing the
| concept of common law.
| aerovistae wrote:
| That actually _is_ interesting to note. I hadn 't thought
| of that.
| dumpsterlid wrote:
| Sounds like the codebase really was a living thing in a sense
| bfung wrote:
| Since diving into stable diffusion, I found the original code not
| very well organized not factored.
|
| Then trying and looking at https://github.com/geohot/tinygrad
| which can implement SD, it's really well written and ideas well
| organized, concise, and it works on multiple platforms well.
| revskill wrote:
| async.auto is simply mind blowing to me.
| [deleted]
| pamoroso wrote:
| The 8086 Assembly source code of the MikeOS operating system is
| remarkably readable and easy to understand for such low-level
| software http://mikeos.sourceforge.net
| decoy98 wrote:
| Angular code is pretty complex but well organized. I still have
| yet to understand most of it.
| miiiiiike wrote:
| It's not too bad, you just need to know TypeScript.. And not
| like "I know TypeScript." on a resume, I mean "I know
| TypeScript(tm)."
| halftrolling wrote:
| For Angular, I think the "problem" lies in the level of
| abstraction. AngularJS was a "Spring / Java" answer to web
| applications with Angular following the paradigm but
| introducing reactivity to the system. Not "wrong" per-se, the
| quality of code is great and so I could recommend it at a
| tactical level of "good code" but at the strategic it feels
| off.
| shp0ngle wrote:
| I am definitely biased, but in general I like go source code?
| Meaning golang itself, and the standard library
|
| every time I am not fully sure what some function from golang std
| library does, I just click away to its source code and it's quite
| clear
| jeroenhd wrote:
| My favourite is SerenityOS:
| https://github.com/SerenityOS/serenity
|
| Not only is the code itself structured much more pleasantly than
| I ever suspected possible in C++, huge parts of it were also
| recorded while they were being written (see
| https://www.youtube.com/c/AndreasKling) so you can see and hear
| the process that led to the final product.
|
| Some of the code is quite gnarly, which is to be expected from a
| repo containing an entire operating system, containing everything
| from the kernel to a bespoke web browser.
|
| However, as SerenityOS isn't trying to be a UNIX clone, its C++
| oriented APIs are a nice breath of fresh air compared to the
| barebones C that Linux and friends use.
| halftrolling wrote:
| My own - hell is other people's code.
| blowski wrote:
| The 7th circle of hell is my own from 3 months ago. I can't
| even blame someone else for the tragedy.
| halftrolling wrote:
| At 15+ years of coding, I feel the greatest issue jumping
| across projects I've done (of a recent vintage) is getting
| into the paradigm.
|
| I have a differing framework to an SPA, to an API, and to
| personal utility scripts. Amplified by adding in co-workers
| and contributors.
|
| The Golden Question becomes how to communicate philosophy to
| a broad and diverse audience, be it co-workers or open-
| source.
| marginalia_nu wrote:
| I think my code is regressing:
|
| C++ from 14 years ago:
|
| https://github.com/vlofgren/tunguska/blob/master/tunguska_3c.
| ..
|
| A career of Java development later, and the code I wrote
| yesterday looks like this:
|
| https://git.marginalia.nu/marginalia/marginalia.nu/src/commi.
| ..
|
| My old code was so tidy. Can't believe I wrote code like
| that. Although back then I think I mostly used vim. Not
| having any sort of IDE tooling does sort of tend to force you
| to be a lot clearer about what you do.
| hunterb123 wrote:
| I have the exact same sentiment.
|
| My code looks like a poem, others looks like chicken scratch.
| halftrolling wrote:
| As my name implies - I'm half-serious in my sentiment. I've
| found many-to-most projects I've come across have personally-
| inconsistent conventions at a function level not to mention
| strategic architecture.
|
| There is good code from other - but I feel many lack
| discipline in their initial approach and long term
| maintenance. In things as banal as variables. Not as a nit-
| pick but as a way of life.
|
| It seems... concerning.
| marginalia_nu wrote:
| Haha, mine sure as hell isn't.
|
| Whenever I try to polish some piece of code into some
| immaculate crystal it only takes a short while before I go and
| make some change to it and then it looks like crap again.
|
| I try to keep it at a level where it doesn't get too out of
| hand it can't be refactored in an afternoon, while at the same
| time refraining from masturbatory polish.
| mav88 wrote:
| I have a soft spot for Musl libc just for how clear it is
| considering it's one of the most widely used libraries in
| containers and has to perform well in the real world.
|
| https://musl.libc.org/
| suprjami wrote:
| This is the first thing that came to my mind as well.
|
| I've said on here before, it takes real talent to write code
| which is this legible while still being small and efficient.
| Nican wrote:
| I had quite some pleasure working with the Source Engine gameplay
| code. (Some 10 years ago now)
|
| https://github.com/ValveSoftware/source-sdk-2013
|
| It is not that the quality of the code is high, but just that it
| is well organized, and everything seems like it was written by a
| beginner. That makes it wonderfully easy to read and follow the
| logic.
|
| Since have played around with the Source Engine, I follow the
| KISS principle with coding with high priority. Rarely trying to
| be clever, or try to over-do abstractions.
| CraigJPerry wrote:
| Poul-Henning Kamp was on a FreeBSD podcast (~15 years ago) and
| did an approachable walkthrough of the performance considerations
| he made when he created varnish. It stoked some serious curiosity
| in me, i was working on a system that heavily cached IO in
| userspace (and paid LOTS of money to do so - we're talking 100s
| of nodes) and here he was saying things like (i'm paraphrasing
| here) it's pretty dumb to cache your data from disk in userspace.
| One thing led to another and i scored a nice bonus that year. By
| the end of that year i had learned about (and put to good use)
| techniques like IRQ pinning and of course understanding the
| caching tunables in the linux VFS layer. I can't find the podcast
| to link to but this document is pretty much on the money for what
| i remember hearing https://varnish-
| cache.org/docs/trunk/phk/notes.html
|
| Another one is the Postfix codebase by Wietse Venema. It was
| notable because it's basically had the square root of 0
| vulnerabilities despite being written in C and being one of, if
| not the most popularly deployed MTAs in the world (so basically a
| constant target for hack attempts - contemporary products like
| Exchange were basically a laughing stock for vulns in that time
| period). Anyway, the architecture of that codebase is bordering
| on beautiful. It's a total goldmine.
|
| Bonus - a popular code base that made my eyes bleed, nginx. I
| think it's basically been re-written today but the earliest
| versions of it were horrible to read. It was fast back then but
| it was like some sick twisted joke of how to write code. This is
| not to take away from whoever created it, they still created a
| monumental shockwave when they released nginx, it was far more
| performant that anything else.
| [deleted]
| colejhudson wrote:
| Was this [0] the podcast by chance? Seems to fit the bill.
|
| [0]: http://bsdtalk.blogspot.com/2006/10/bsdtalk072-interview-
| wit...
| CraigJPerry wrote:
| That's the one I'm sure
| lossolo wrote:
| dchest wrote:
| The early Go standard library (before it was hyper-optimized.)
| blowski wrote:
| That's a fascinating observation. Do you think code inherently
| gets "worse" as it becomes more "optimised"?
| marginalia_nu wrote:
| If you plot difficulty to read against optimization, I'd
| expect to find a u-shape relation between the two.
|
| When code is easy to read, it's easy to find and clean up
| redundant operations, which naturally makes it faster.
|
| On the other end there's some optimizations that require
| dealing with lower abstraction levels and additional special
| cases.
| dchest wrote:
| Yes, as it becomes more complicated, catching more edge
| cases, it becomes less readable.
|
| On the other hand, as the compiler improved, some parts of it
| became more readable (e.g not manually unrolling loops,
| avoiding manual inlining, introducing bit-manipulation
| functions into the library instead of repeating them
| everywhere).
|
| Unfortunately, it's unavoidable -- faster code is usually
| longer and more complicated.
| shp0ngle wrote:
| They still try to document all the optimisations very
| thoroughly.
| chess_buster wrote:
| Smalltalk 80s entire source code.
| jraph wrote:
| The NetSurf web browser, and its modular parts (in C).
|
| Quite simple and straightforward, and very modular. For a
| browser.
|
| https://www.netsurf-browser.org/
|
| https://source.netsurf-browser.org/
___________________________________________________________________
(page generated 2022-09-10 23:00 UTC)