221–230 of 278 posts
- (BOOL) doYouKnowTheMuffinMan:(TheMuffinMan *)theMuffinMan;
Also, lots of the Objective-C runtime code was clear enough to explain concepts like ARC hacks well enough that I could learn about and give a talk on the Objective-C runtime with a month’s notice.
Earlier quoted context omitted.
The Windows API was very ugly... not to mention unnecessarily complicated. It does not belong in this thread.
I have quite opposite opinion backed by real life experience. As an author of Sciter Engine that works on Windows, MacOS and Linux/GTK I have first hand experience working with all three API sets. Windows API is the most logical, complete and stable API among all others. It has everything that you really need to create performant and manageable UI. MacOS is good but less good. It uses reference counting (which is not…
it seems that in real life, a really high-quality codebase is hard to come by I think a common misconception amongst mid-experienced programmers is that they confuse look with quality. Reading clean written code gives you a feeling of control and also the feeling that someone must have thought about that program. It's reassuring. You have in front of you a code that gives you trust. When in fact, that code can be com…
Perhaps I'm jaded, but I notice that all the examples given here are developer tools or otherwise things with well scoped functional inputs and outputs (e.g. ffmpeg). Anyone have an example of a consumer application that has a good codebase? Chromium, GitLab, OpenOffice, etc? I feel like such applications inherently have more spaghetti because the human problems they're aiming to solve are less concretly scoped. Even…
I actually find Chromium to be a lot more approachable than I assumed it would be. Have only really checked out the layout / graphics part of Blink, but it’s laid out pretty intuitively. But yeah, Postgres also gets my vote. I guess there’s a bit of a bias there because devs are likely to read the code of the tools they use; either to track downs bug or just to understand how it works.
Earlier quoted context omitted.
Any PHP framework is a case of inner-platform: https://en.wikipedia.org/wiki/Inner-platform_effect PHP already is the "framework" and every time you load a page it's executing the script from scratch. You're wasting a lot of time loading a framework to handle control flow for your program which doesn't have any control flow in the first place.
I'm not a PHP dev, but I've dabbled. And I'm not sure I follow. How is it a framework for frameworks sake? I take that to mean it's pointless/not useful. Whereas I'd say Laravel and it's ecosystem are far more productive and time saving than simply using just PHP. It's the opposite of wasting time. From their github repo[0] Laravel has: - Simple, fast routing engine. - Powerful dependency injection container. - Multi…
https://youtu.be/o_TH-Y78tt4 starting at around 10:30 he gets into what I was getting at.
> Whereas I'd say Laravel and it's ecosystem are far more productive and time saving than simply using just PHP.
I'm not arguing a time thing.
I'm arguing that a framework that forces its architecture onto your domain model is fundamentally broken by design. My domain should drive architecture choices and the framework should let me augment that with well worn libraries and modular patterns.
Laravels architecture works for one thing: web sites. And for that, you're better off using WordPress.
Laravel is better than older frameworks, like say, code igniter but it still fights you every step of the way if you want to step outside the box.
Earlier quoted context omitted.
I'm mega curious about this > ...like lpszFileName (lpsz = long pointer to a zero terminated string) I remember those. AIUI hungarian gives you some kind of typing. The typing is done by humans using the names. The humans have to get it right; they are the typecheckers. The first thing I'd do is offload the typechecking onto an automatic framework - the idea of letting people do a computer's job is madness. It would…
> So where is the flaw in my thinking The codebase has 34 years worth of code written already, 100 million LOC or more if you count Office, VS etc. The cost of typechecking is trivial but the cost of rewriting this much code to be consistent with any new convention is in the hundreds of millions of dollars. This legacy cost then of course becomes higher every year...
Earlier quoted context omitted.
I have quite opposite opinion backed by real life experience. As an author of Sciter Engine that works on Windows, MacOS and Linux/GTK I have first hand experience working with all three API sets. Windows API is the most logical, complete and stable API among all others. It has everything that you really need to create performant and manageable UI. MacOS is good but less good. It uses reference counting (which is not…
macOS has had automatic retain counting for the last decade. You have to remember your weak/strong for cycles but that's all. It's preferable over garbage collection because there are no unexpected pauses/memory scans and it's deterministic.
See also [1] Interesting Codebases: https://news.ycombinator.com/item?id=15371597 [2] Show HN: Awesome-code-reading - A curated list of high-quality codebases to read https://news.ycombinator.com/item?id=18293159
Earlier quoted context omitted.
I'm mega curious about this > ...like lpszFileName (lpsz = long pointer to a zero terminated string) I remember those. AIUI hungarian gives you some kind of typing. The typing is done by humans using the names. The humans have to get it right; they are the typecheckers. The first thing I'd do is offload the typechecking onto an automatic framework - the idea of letting people do a computer's job is madness. It would…
> So where is the flaw in my thinking The codebase has 34 years worth of code written already, 100 million LOC or more if you count Office, VS etc. The cost of typechecking is trivial but the cost of rewriting this much code to be consistent with any new convention is in the hundreds of millions of dollars. This legacy cost then of course becomes higher every year...
And this absolutely misses the vital point that typechecking can be offloaded from the human to an automated typechecker, so why wasn't it?
"The cost of typechecking is trivial" - not if it's done by humans.