3 ms·
Do you look at the code / line count when you open a project like this? I have this "hard time" imagining what the X thousands lines of code do. Even more whe
by swah 2y ago
Do you look at the code / line count when you open a project like this?
I have this "hard time" imagining what the X thousands lines of code do.
Even more when the piece of software claims to be simple. I would have to devote months to really understand it, I guess, and "cure" this "superficialitis" (tendency to think everything is 50 lines of code)
I guess compilers are the only "kind" of project I can imagine a few complex parts.
- ehutch79 2y agoI just looked at the code. It's mostly just handling events and conditions a driver would need to handle just to be a functional driver. I don't think you could write any driver in 50 lines of code?
- cqqxo4zV46cp 2y agoThis has “I could build Slack in a weekend” energy.
- swah 2y agoYes, this is what I mean, how to get better at this etc.
- exe34 2y agoThe best way to cure this is to write something in 50 lines to show the world how it's done, and wager a large donation to e.g. the trump election campaign if you leave a public ticket unfixed for more than a week. As soon as you try to interface with other people's workflows and needs, the 50 lines turn into thousands very quickly.
- naikrovek 2y ago“The devil is in the details”, as they say.
- Aurornis 2y ago> I would have to devote months to really understand it, I guess, and "cure" this "superficialitis" (tendency to think everything is 50 lines of code) You wouldn’t have to spend months understanding it, but you also wouldn’t be able to glance at the code for 5 minutes and understand everything that needs to happen. Anything that handles driver or system level operations and deals with audio will get complex quickly. What happens when the input device gets unplugged? The output device disconnects? User changes from speakers to AirPods? How do you handle situations where the input and output sample rate are different? What about when something backs up and a buffer overflows? Or underflows? What mechanism do you use for handling user setting changes? The list of situations you have to handle goes on and on. The core concept is simple, but there are so many things to do that the code base will naturally become bigger than the 50 lines of code you’re imagining.
- duped 2y ago> I guess compilers are the only "kind" of project I can imagine a few complex parts. What's so hard about a compiler? You read some files, split into tokens, sort into a tree, and then walk the tree and write some instructions to disk at each node. Can be done in a couple hundred lines of code. (\s: the point is that all software gets complicated, and a few thousand lines is not a lot of code)
- 1123581321 2y agoSkimming or folding to only show the names of the functions might make it easier to grok. For example, there are about 75 OSStatus messages this driver supports. There are a ton of case statements; each one represents a situation that must be supported. 3500 lines goes quickly when you divide it by a few hundred situations/statuses. As comments in another discussion tree have said, it's a shame that macOS doesn't provide some of this natively. If it did then this would probably be higher level code and shorter. Knowing where the boundary lies between the system and the application is part of having an understanding of why all this was written. I wouldn't feel bad about this; it's just a domain knowledge thing. Be excited by the opportunity to learn with a toy project or a deep code review!
- meindnoch 2y agoA large amount of the code is the C boilerplate for implementing the object graph needed by audio system. You'll see that basically every function is a huge switch-case.