Ask HN: What's the best source code you've read?
Please provide a link, if possible.
Please provide a link, if possible.
Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.
It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.
Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.
Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.
There were 7 registers to play with. AX, BX, CX, DX, SI, DI, and occasionally BP. MS-DOS had no rules about frame pointer although later Borland would prefer it was kept to a standard use so that exceptions can be handled.
It would have run faster in 32 bit. Many fewer cross products for multiply and faster convergence for division and sqrt, plus just fewer registers needed. But updating the entry and exit code may have been the largest win. By the mid 1990s the FPU was moving onto the CPU chips even at the low end so the main goal would have been stability and backwards compatibility.
I wrote assembly code for many machines before and after that. In the early days such careful juggling of registers was routine. I generally wrote my algorithms in Pascal (later in Modula or Ada and by Borland days, in C++) and then hand compiled down to assembly. That separation of algorithm and coding stopped it getting too tangled.
Thanks for the shout out! These days I write System Verilog (algorithms modelled with C++) for hardware projects, and Julia for the pure software.
Would it be possible to release this bit of the library, if not the whole thing (for any definition you like of "whole thing") à la Movie Maker (https://twitter.com/foone/status/1511808848729804803)?
More specifically there are two components to this question - it being OK for the code to be released, and the code itself being available to be released :). I'm specifically asking after the former; if noone knows where the code actually is right now, well, it can be dug out later.
Some sites probably also have versions for download without the registration requirement
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.
It seems alive and well in the data-science community to me. Look at jupyter notebooks if you aren't aware of what I am talking about.
Where significant parts of the display remain out of sync with said global state?
Have you seen actual literate programming documents? The Noweb tool’s page has examples.
Your stuck on Knuth's definition of literate programming but this is better than that
⸻
1. My very first exposure was DEK’s article “TeX and Metafont” in a copy of Dr Dobb’s Journal that was part of a trove my brothers got a hold of—and then in 1984 seeing someone in the IIT computer lab paging through a copy of The TeXbook, so when I found out that UIC had just installed TeX on their mainframe, I was one of the first people to use it there.
Probably the biggest mistake was the choice to abandon the idea of having a LaTeX 3 version with its implicit breaking of backwards compatibility. Backwards compatibility means that there’s a tangle of fragility that only grows with time which is part of why the error messages are so frequently bad. Changes are a fraught proposition. This is part of what inspired my decision to start work on finl.
A simple syntax like noweb and a LSP dispatcher which only handles the noweb syntax elements and dispatches both text and code chunks to respective back ends; the LP LSP Server tangles the code chunks and presents the tangled code to the code specific LSP servers and does the mapping forth and back of the position-in-nw vs position-in-$code while passing all other communication through.
especially now that we have DAP something like this would really make sense, wouldn't it?
Not to dismiss the mountain of work people have put into it, but it feels very hacked together and clunky rather than a shining achievement.
The original bug against Typescript was opened in 2016 as well: https://github.com/microsoft/TypeScript/issues/11274
I intend to make a post about my experience.
"The TeXbook" is the user manual for TeX. It is not the same thing as the book containing the (literate-program) source code for TeX, which is called "TeX: the program".
(Both are excellent, but in quite different ways, and someone looking for interesting code to read would likely be disappointed by the TeXbook, which doesn't contain that.)
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.
An easier entry point might be the ethtool_ops in an earlier Intel network driver like e1000.
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.
Nice one. I'll copy that.
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 Ω(t).
…
Product<Angle, Square<Time>> ʃ_Mt_dt;
Product<Angle, Square<Time>> ʃ_ut_dt;
Product<Angle, Square<Time>> ʃ_Ωt_dt;
…
ʃ_Mt_dt += (Mt + previous_Mt) / 2 * dt;
ʃ_ut_dt += (ut + previous_ut) / 2 * dt;
ʃ_Ωt_dt += (Ωt + previous_Ωt) / 2 * dt;
…
anomalistic_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_Mt_dt);
nodal_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_ut_dt);
nodal_precession_ = 12 * ʃ_Ωt_dt / Δt³;
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.
I love the use of mathematical glyphs in math code, too, much more readable, _if_ it's readable.
sigh.
Of course, this only works if your editor supports this and you are using a language similar to Julia. But there are two more general methods that are applicable everywhere. The first was mentioned by db48x: I have customized my Xmodmap file so that greek letters and a few typographic characters I use often can be typed using AltGr combinations. (Unfortunately, this is much more complicated if you use Windows.)
Secondly, I heavily use Espanso [1], so that I can easily type complicated letters/sequences (e.g., my email address) for which it would be too overkill to assign an AltGr keybinding.
Finally, in Emacs and Kitty (my terminal emulator) there is a keybinding that asks for the name of an Unicode symbol and enters it. (In Emacs it's C-x 8 <Enter>, in Kitty Shift+Ctrl+u.)
From the point of view of my workflow, the problem of quickly typing Unicode characters is completely solved.
Your OS keyboard layout, at least on Linux, can be customized to include any characters you type frequently. I haven’t gone very deep down this rabbit–hole, but I have turned on some options that make nice quotation marks (“‘«»’”), em–dashes (“–”), ellipses (“…”) and a number of other characters (“²³½⅓¼≠±÷∞×” and so on) readily available with a compose key. I also put arrows on the numberpad, of course (“↙↓↘←↔→↖↑↗⇙⇓⇘⇐⇔⇒⇖⇑⇗”). Very useful for talking about menu items, like File → Save As (it has actually startled people when I can type things like that fluently in conversation).
My editor of choice is Emacs, which has a built–in way to select characters by name. Typing `C-x 8 <RET>` prompts for a character name, with fuzzy searching and autocompletion. It also recently gained a similar facility for Emoji, which is more focused around the visual appearance. `C-x 8 e e` opens it. `C-x 8 e s` lets you search by name.
Between your keyboard layout and your editor’s search capabilities and custom keybindings you can do anything.
It looks like it's mostly just a C# wrapper around the C++?
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.
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.
These days I work largely in a cloud / devops role, and I can't even begin to list everything that I ought to be using but can't because there aren't enough hours in the day to keep up with all of the new developments. That's within a single language, a single web framework, and a single cloud provider!
I see projects where architecture astronauts stitch together multiple clouds, multiple languages, and some random junk on-prem that was installed over a decade ago by someone who has passed away since then. Within the expected lifetime of such a system, you'll need a software archaeologist to figure it out!
https://www.drmaciver.com/category/programmer-at-large/ (down)
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.
One funny detail I remember is a throw–away line where someone rapidly keys in “a column of text”. If you’re paying attention you can combine that with names like Pham, Vinh, Nau, and Qung Ho, the rarity of the red–headed gene, and the descriptions of some traders from the far end of human space you can reconstruct how things went after Humanity reached the stars.
Living codebases that have such old roots but have seen gradual maintenance and refactoring such that the whole thing didn't degenerate into spaghetti deserve a lot of respect in my opinion.
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.
Opening random file on github: django.core.serializers.python https://github.com/django/django/blob/main/django/core/seria...
- function name doesn't match pep8
- name doesn't match its behavior
- docstring is trying to explain what it does instead of proper function name, see 2
- 60 line for cycle
- what does d mean in for d in object_list? perhaps d as an object/instance/item? Good luck remembering that when you reach end of this for 60 lines later
- using comments instead of functions
- Handle M2M relations could be replaced with handle_m2m_relations(...)
- Handle FK fields could be replaced with handle_fk_fields(...)
- and so on ..
- using/catching generic exceptions
- using isinstance instead of proper polymorphism
- **options
And I've seen way worse things inside django than this. Please don't recommend django. PleasePython is easy to write but writing it "right", in a way that doesn't compromise performance, is a thing.
At work, another team introduced automated CVE scanning to fulfill a contractual obligation to do so. When they asked me to implement this on my team's Django project, I said "well alright, as long as it doesn't constantly break the build because of some obscure false positive CVE".
Within a week, the CI job was broken because of 5 "CVE"s. 4 were false positives for our project and 1 was a configuration error by the other team.
Just to let you know to take "number of CVEs" with a large grain of salt.
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.
Peter did done great ground work here and as things transitioned to neural nets, also peter appears randomly in my Chromecast with some nice photos he took lol
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.
[0]: http://bsdtalk.blogspot.com/2006/10/bsdtalk072-interview-wit...
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.
So many developers are afraid of their code being described that way. People are weird.
I'm starting to have the opinion that you shouldn't give software architects the title of software architect because they'll feel as if they're not doing their job if things are simple rather than architecty.
I say that because a software architect is really just a developer with broad scope, but I suspect most of the software architects I know would be offended by that description (I myself hold the title software architect).
(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).
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:
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.
In the same vein, John Scholes' collection of APL code in the Dfns workspace[0] is positively wonderful to read through. I think it's probably one of the finest repositories of annotated code ever assembled.
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.
For some reason the 2nd and subsequent editions of the O'Reilly Perl book completely altered the layout and presentation that Larry Wall had set up. The first edition of Programming Perl is the most *lucid* programming book I've ever read.
Likewise I've head good things about the Python standard library; I suspect this works for many languages.
--- start quote ---
/* From Department of the Army's authoritative study: "Effects of
Nuclear Weapons", footnote 3 to section 1.45, available at:
http://www.fourmilab.ch/etexts/www/effects/
"The majority of the experimental and theoretical values of the
explosive energy released by TNT range from 900 to 1,100 calories per
gram. At one time, there was some uncertainty as to whether the term
"kiloton" of TNT referred to a short kiloton (2 x 10^6 pounds), a
metric kiloton (2.205 x 10^6 pounds), or a long kiloton (2.24 x 10^6
pounds). In order to avoid ambiguity, it was agreed that the term
"kiloton" would refer to the release of 10^12 calories of explosive
energy. This is equivalent to 1 short kiloton of TNT if the energy
release is 1,102 calories per gram or to 1 long kiloton if the energy
is 984 calories per gram of TNT."
So, evidently they don't quite specify which ton is required...
--- end quote ---And it goes on
https://github.com/microsoft/TypeScript/blob/main/src/compil...
They have done a lot of work on structure and documentation, since the docs are auto-generated.
I have taken a lot of inspiration from them.
The Adobe APIs[2] were also excellent, but I'm not sure they are open for browsing, anymore.
[0] https://github.com/apple/swift
I've said on here before, it takes real talent to write code which is this legible while still being small and efficient.
There are programs and programmers that impress me, and once in a while I'll come across an interesting algorithm, but I can't really think of any code that is anything more than just code.
It's either too simple to do anything I'm interested in, too full of ugly hacks like most large programs, or deals with math and algorithms way above my understanding, to the point where I probably haven't even tried to read it.
Some of most memorable bits or code for me are the examples for frameworks and libraries, but those are more impressive for the code that isn't there, rather than the code that is.
I love declarative work(Not so much pure functional, but things like CSS and CAD constraints where a solver figures out how to make your intent happen) but again, that's notable for the code that isn't there.
I also really like hardware workarounds. It's so cool to be able to have software that runs fine on bad hardware. It's not that common, but occasionally you can pull it off in a reliable way that really is just as effective as using better hardware. Seeing pure code replace hardware is kind of like a further development of replacing mechanical stuff with solid state chips.
I really just don't care about code itself very much. I don't want to write bad code, but I only care about good code in as much as it will actually benefit the project. Once it's good enough, features or architecture improvements or unit tests or something might be more important, and interesting or clever code might bring the project down.
If I'm reading your code, I'm probably either adding to it and complaining that it doesn't have an API hook already there, or fixing a bug.
If I'm using but not reading your code I'm probably happily assuming it's great, if it's a popular trusted thing.
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
https://docs.racket-lang.org/generator/index.html
Can't find source code online. I browsed the code in emacs with racket-xp-mode go to definition after installing it via raco pkg install. Could probably use DrRacket instead of emacs/racket-xp-mode.
I had to read the source code to find out what the specific names of the proto creators, accessor, mutator functions would be.
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.
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.
Quite simple and straightforward, and very modular. For a browser.
The kernel abstractions that allow for portability make the code quite easy to read. Back in the day, I was able to write a file system from scratch by just reading the code of other file systems. The build system is also pretty amazing (allowing you to cross build the whole OS for any hardware target from many other OSes) and not too hard to follow. The source tree is structured in a way that makes a lot of sense (IMHO better than FreeBSD).
The best - it compiled to the sane hex file.
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.
> Not having any sort of IDE tooling does sort of tend to force you to be a lot clearer about what you do.
True, but then I wouldn't be able to play whack-a-mole with pointer symbols during weird code-pairing exercises.
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.
My code looks like a poem, others looks like chicken scratch.
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.
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.
Similar with Notch's Left4KDead, which implemented a fun zombie game for a Java small-code competition. A mirror of the original source is here (https://github.com/codingcampbell/Left-4k-Dead). I rewrote it in JavaScript as a Chrome App, in the process refactoring for readability (and sacrificing some of the code's beauty). https://github.com/sowbug/ChromeLeft4kDead
A mistake i see many engineers commit is obsess over their code and how "pretty" it is. What they seem to forget is that code is only read when it isn't doing what it's supposed to do. Granted when you do have to read it there are good and bad examples, but the question you should ask yourself is not "how can I make this code easier to read?" But "how can I make sure noone has to read this code". The code that performs this job is not always pretty. If it is impossible to make the code bulletproof then the best bet is usually to just make it really simple. Good code is nonexistent and if it has to exist it is boring.
Node, by comparison, is a ghetto.
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
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.
The libVF.io iommu setup code is a good example and inspires me to think that system-glue code doesn't need to be gross or impenetrable: https://github.com/Arc-Compute/LibVF.IO/blob/master/src/libv...
Another one I've appreciated reading (and learned more about 2d graphics from) is Pixie, a 2d graphics library written in Nim. It's strongly affected how I write similar code.
Here's the implementation of a fair subset of SVG paths: https://github.com/treeform/pixie/blob/master/src/pixie/path...
And one last one for basic algorithms which I'd use to teach intro to data structures any day: https://github.com/nim-lang/Nim/blob/version-1-6/lib/pure/al...
Of course Knuth's original code is still some of the best classic code. K&R's original C book is a classic.
(edited formatting and tweak descriptions)
[0] https://github.com/postgres/postgres/blob/master/src/backend...
Example (config file, but the entire codebase is like that): https://imgur.com/UnIUZmZ
I think it's awesome and I'm trying to do this too. It is a great trick that forces you
to re-read your comments and be as clear as you can. Also, you take the time to find
synonyms and look for typos. Overall it's a great way to learn how to be thorough.I've also seen a talk at CppCon (2019 I think) that spoke somewhat negatively about the code base. Can't find the reference, sorry.
Blew my mind reading through it, honestly. Just perfect.
I read it before learning Ruby but surprisingly, the code made sense even though I didn't know the language.
bsd code is clean
minikanren
some old lisp (le lisp or eulisp I forgot)
Yes, you are right. It is empty. The best code there is - is the code you did not had to write. It have no bugs, no latency. I am not being sarcastic here. I truly think that less code is better.
Beautiful c code. As a 30+ year programmer, one new thing really stuck with me. He wrote all comments as sentences: first letter capital, finish with a “.”.
It’s a very simple code-base in many ways. At the time it was 10k lines of mostly short pure functions.
The code examples were also really nice and explained a lot about how to work with SVG.
I owe some Thanks to Mike Bostok and his fellow developers.
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.
That compiler served as the blueprint for Borland tools.
philippe@fullpower.com
> That compiler served as the blueprint for Borland tools.
When I was disassembling Turbo Pascal more than 20 years ago, I saw the similarities between the two, especially the scanner and parser where pretty much in line with the source code of Niklaus Wirth [1]. Even some of the global variables were the same. Back then I figured that since the source code of Niklaus Wirth was originally in Pascal, Anders Hejlsberg was actually "the Pascal Compiler" for the z80 (and later x86) translating the Pascal source into assembly. For me it seemed that Anders had a very good hand for register allocation, I remember the disassembly of Turbo Pascal was full of tricks, simply fantastic and elegant!
Here is one version Niklaus Wirth Pascal Compiler: [1] https://www.cs.hs-rm.de/~weber/comp/pascals3.html
C4 and its follow-up C4x86:
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.
It's a good way to document old hardware with emulation code.
Wt[0] source code is also good.
The problem with a reactive layout is that, if you're not going to just ask the user how they want to display things, you need to both read their mind and get it right 100% of the time.
Nobody can do that, so your web site shifts into mobile mode when I only give it half of my 3' display.
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…
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.