5 ms·

Favorites: - SQLAlchemy by Michael Bayer: https://www.aosabook.org/en/sqlalchemy.html https://www.aosabook.org/en/sqlalchemy.html (nice observation of core lan

by tony 7y ago

Favorites: - SQLAlchemy by Michael Bayer: https://www.aosabook.org/en/sqlalchemy.html https://www.aosabook.org/en/sqlalchemy.html (nice observation of core language on top of SQL, then the separate declarative/orm system) - LLVM by Chris Lattner: https://www.aosabook.org/en/llvm.html https://www.aosabook.org/en/llvm.html - Audacity by James Crook: https://www.aosabook.org/en/audacity.html https://www.aosabook.org/en/audacity.html (interesting mentionings of wxwigets) Note that pretty much everything in volume 1 and 2 is interesting, though! What would be nice to see, non-exhaustive: - Blender: Especially 2.80, an analysis of its GUI/widgets, integrated python scripting, and everything else (wiring into graphics cards, rendering, shapes). There's a lot of stuff that could be covered - Gimp / Inkscape / Krita - Saltstack / Ansible / Fabric or PyInvoke : These have nice abstractions on top of system functionality / programs and delivery magic that'd be fun to go into - GTK, QT - Tiling window managers, e.g. i3, swaywm, awesome - Wayland, Xorg - Kdevelop, VSCode, Atom, Electron - React, Vue, Angular (it'd be nce to see more js) - Android SDK - Unity3D SDK, Unreal SDK - .NET Core - black (python formatter), clang-format, prettier - docutils, sphinx, pandoc - systemd, mesa, cairo, pulseaudio - implementations of python (cpython), typescript, lua, luajit, haskell ghc, swift

leeoniya 7y ago
missing SQLite
- monocasa 7y ago
  The SQLite guys have unsurprisingly already done a really great job on that topic. https://www.sqlite.org/arch.html https://www.sqlite.org/arch.html
heyoni 7y ago
This book is such a gem. I really liked the one about async by Guido
persistent 7y ago
Really curious why you'd want to study these unless you already had strong fundamentals in application architecture and are not afraid to expose yourself to antipatterns. GIMP/GTK in particular are a cornucopia of terrible ideas stemming from ignorance and prejudice.
- slovenlyrobot 7y ago
  This wasn't necessarily the most constructive thing to say, but it unintentionally invites a silver lining: studying failure is the most effective route to success. This is as true in software as it is in operations, economics, finance or pretty much any other discipline.
  - koolba 7y ago
    Studying failure is better than not studying, but it can’t hold a candle to to studying success. As an extreme example, seeing ten spaghetti codebases does not teach you much more than the first. But expanding your mind by studying new patterns and paradigms, skillfully and elegantly woven, will build upon everything you’ve already mastered.
    - tempguy9999 7y ago
      Absolutely not true. I've learnt more from my failures than my successes. I'm more interested in other people's failures than their successes. Understanding why a conceptual error was ever allowed to be realised is very instructive and a very cheap lesson (if it's something you weren't involved in!). Seeing a clusterfuck of microservices blooming darkly in the midst of a project, watching time being wasted sorting it out every bloody time more code was checked in, sucking precious time from the rest of the projct - you can learn a lot immediately. Lesson: don't use them without good reason. Or seeing a function that takes a geographical area and returns a list of progressively larger areas that enclose it eg. give buenos aries, it returns argentina, south america, america, the world. But note that the function does not return its input (buenos aries) which caused every bloody call of that function to have extra code to add it back in because it was needed. Lesson 1: the output of a function like this is always likely to need its input for our app, so provide the input with the output. Lesson 2: If it's evident a function isn't quite adequate, provide a wrapper function that does what's needed so the users don't have to write workaround code every time. > skillfully and elegantly woven (giggle). Not on my planet!
- Dreami 7y ago
  Could you elaborate a bit? I don't know much of their code base (but I've used it as a user) and I'm curious as to what is done wrong.
Avamander 7y ago
- PostgreSQL
- rosser 7y ago
  It's not the same format, but here's a few slide decks from Bruce Momjian's site, describing PostgreSQL's internals: https://momjian.us/main/presentations/internals.html https://momjian.us/main/presentations/internals.html
lanstin 7y ago
Loved the bash one. Loved the time aspect to all the stories - early decisions and then the way they played out over time. Hard to sim various architectural decisions so a super informative read for both good and bad outcomes.
vicarrion 7y ago
Redis would also be nice

by tony 7y ago

leeoniya 7y ago

missing SQLite

monocasa 7y ago
The SQLite guys have unsurprisingly already done a really great job on that topic. https://www.sqlite.org/arch.html https://www.sqlite.org/arch.html

heyoni 7y ago

This book is such a gem. I really liked the one about async by Guido

persistent 7y ago

Really curious why you'd want to study these unless you already had strong fundamentals in application architecture and are not afraid to expose yourself to antipatterns. GIMP/GTK in particular are a cornucopia of terrible ideas stemming from ignorance and prejudice.

slovenlyrobot 7y ago
This wasn't necessarily the most constructive thing to say, but it unintentionally invites a silver lining: studying failure is the most effective route to success. This is as true in software as it is in operations, economics, finance or pretty much any other discipline.
- koolba 7y ago
  Studying failure is better than not studying, but it can’t hold a candle to to studying success. As an extreme example, seeing ten spaghetti codebases does not teach you much more than the first. But expanding your mind by studying new patterns and paradigms, skillfully and elegantly woven, will build upon everything you’ve already mastered.
  - tempguy9999 7y ago
    Absolutely not true. I've learnt more from my failures than my successes. I'm more interested in other people's failures than their successes. Understanding why a conceptual error was ever allowed to be realised is very instructive and a very cheap lesson (if it's something you weren't involved in!). Seeing a clusterfuck of microservices blooming darkly in the midst of a project, watching time being wasted sorting it out every bloody time more code was checked in, sucking precious time from the rest of the projct - you can learn a lot immediately. Lesson: don't use them without good reason. Or seeing a function that takes a geographical area and returns a list of progressively larger areas that enclose it eg. give buenos aries, it returns argentina, south america, america, the world. But note that the function does not return its input (buenos aries) which caused every bloody call of that function to have extra code to add it back in because it was needed. Lesson 1: the output of a function like this is always likely to need its input for our app, so provide the input with the output. Lesson 2: If it's evident a function isn't quite adequate, provide a wrapper function that does what's needed so the users don't have to write workaround code every time. > skillfully and elegantly woven (giggle). Not on my planet!
Dreami 7y ago
Could you elaborate a bit? I don't know much of their code base (but I've used it as a user) and I'm curious as to what is done wrong.

Avamander 7y ago

- PostgreSQL

rosser 7y ago
It's not the same format, but here's a few slide decks from Bruce Momjian's site, describing PostgreSQL's internals: https://momjian.us/main/presentations/internals.html https://momjian.us/main/presentations/internals.html

lanstin 7y ago

Loved the bash one. Loved the time aspect to all the stories - early decisions and then the way they played out over time. Hard to sim various architectural decisions so a super informative read for both good and bad outcomes.

vicarrion 7y ago

Redis would also be nice