Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on inlined code (2014)

number-none.com

Post reply on HN
Print view View original

291–300 of 402 posts

Re: John Carmack on inlined code (2014)

#291

Post by ninetyninenine »

pragma_x wrote: post #237
wmanley wrote: post #79

Earlier quoted context omitted.

Here's the link where he discusses functional programming style: https://web.archive.org/web/20170116040923/http://gamasutra.... He does not say that that his email is completely outdated - he just says that calling pure functions is exempt from the inlining rule. He's not off writing pure FP now. His approach is still deeply pragmatic. In the link above he discusses degrees of function purity. "Pure FP" has a whole…

Thank you for this. I appreciate that this (classic) article lays bare the essence of FP without the usual pomp and "use Lisp/Scheme/Haskell already" rhetoric. My takeaway is that FP is mostly about using functions w/o side effects (pure), which can be achieved in any programming language provided you're diligent about it.

No functional programming is about programming as if your code is a math equation.

In math people never use procedures. They write definitions in math in terms of formulas and expressions.

If you can get everything to fit on one line in your programming. Then you are doing functional programming.

The lack of side effects, lack of mutation and high modularity are the beneficial outcome of fp, it is not the core of what you're doing. The core of what you're doing is your defining your program as a formula/equation/expression rather then a list of procedures or steps. Of course, why you would write your program this way is because of the beneficial outcomes.

By coincidence if you write your code in a way where you just account for the side effects like deliberately avoiding mutation, IO and side effects... then your program will become isomorphic to a mathematical function. So it goes both ways.

Another thing you will note and most people don't get this is that for loops don't exist in FP. The fundamental unit of "looping" in fp is always done with recursion, just like how they would do it in mathematical expressions.

Re: John Carmack on inlined code (2014)

#292

Post by mgsouth »

randomdata wrote: post #214
mgsouth wrote: post #76

Earlier quoted context omitted.

What do you use unit tests for, other than verifying implementation details? Perhaps we have a difference in definition. To me, a unit test for a function such as "parse_news_email" would explore variations in parameters and states. Because of combinatorial explosion, that often means at least some white-box testing. I'm not going to generate random subjects and senders, and received-froms, I'm going to target based…

Unit tests are for documenting the API contract for the user. You are going to target based on what you are willing to forevermore commit to for those who will use what you have created. Indeed, what happens when two messages come in with the same message ID is something the user needs to be aware of and how it functions needs to remain stable no matter what you do behind the scenes in the future, so you would absolu…

We're in general agreement about the purpose of unit tests. I disagree on a couple of points.

Tests do not document the API. No test is complete, and for that reason alone can't completely document anything. For example, a good API might specify that "the sender must be non-null, and must be valid per RFC blah." There's no way to test that inclusively, to check all possible inputs. You can't use the test cases to deduce "we must meet RFC blah." You might suspect it, but you'd be risking undefined behavior it you stray from input that doesn't exactly match the test cases. And before anyone objects "the API docs can be incomplete too," well, that true. But the point is that a written API has vastly more descriptive power than a set of test cases. (The same applies to "self-documenting code". Bah humbug.) There's also the objection "but you can't guarentee cases you don't test!" Also true. That's reality. _You can never test all your intended behavior._ You pick your test cases to do the best you can, and change your cases as problems pop up.

The other thing I would shy away from is including throwaway tests in the framework. Throwaways are a thing, developers use them all the time, but don't make them unwanted stepchildren--poorly (incompletely?) designed, slapped together, limited scope, confusing for another developer (including time-traveling self) to wade through and decide whether this is a real failure or just bogus test. They're tech debt. Less frequently used tests are another matter. For example, release-engineering tests that only get run against release candidates. But these should be just as much real, set in stone, as any other deliverable.

Which I guess is a third viewpoint nuance difference. I treat tests as being part of the package just as much as any other deliverable. They morph and shift as APIs change, or dependencies mutate, or bugs are found. They aren't something that can be put to the side and left to vegetate.

Re: John Carmack on inlined code (2014)

#293

Post by jschrf »

tetha wrote: post #211
mihaic wrote: post #2

When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…

I had exactly this discussion today in an architectural discussion about an infrastructure extension today. As our newest team member noted, we planned to follow the reference architecture of a system in some places, and chose not to follow the reference architecture in other places. And this led to a really good discussion pulling the reference architecture of this system apart and understanding what it optimizes fo…

Your newest team member sounds like someone worth holding onto.

Re: John Carmack on inlined code (2014)

#294

Post by lcnPylGDnU4H9OF »

ryandrake wrote: post #130
spinningslate wrote: post #63

Earlier quoted context omitted.

This thread is a great illustration of the reality that there are no hard rules, judgement matters, and we don't always get things right. I'm pretty long-in-the-tooth and feel like I've gone through 3 stages in my career: 1. Junior dev where everything was new, and did "the simplest thing that could possibly work" because I wasn't capable of anything else (I was barely capable of the simple thing). 2. Mid-experience,…

We all go through that cycle. I think the key is to get yourself through that "complex = good" phase as quickly as possible so you do the least damage and don't end up in charge of projects while you're in it. Get your "Second System" (as Brooks[1] put it) out of the way as quick as you can, and move on to the more focused, wise phase. Don't let yourself fester in phase 2 and become (as Joel put it) an Architecture A…

Heh, I've read [2] before but another reading just now had this passage stand out:

> Another common thing Architecture Astronauts like to do is invent some new architecture and claim it solves something. Java, XML, Soap, XmlRpc, Hailstorm, .NET, Jini, oh lord I can’t keep up. And that’s just in the last 12 months!

> I’m not saying there’s anything wrong with these architectures… by no means. They are quite good architectures. What bugs me is the stupendous amount of millennial hype that surrounds them. Remember the Microsoft Dot Net white paper?

Nearly word-for-word the same thing could be said about JS frameworks less than 10 years ago.

Re: John Carmack on inlined code (2014)

#295

Post by kragen »

munificent wrote: post #290
kragen wrote: post #255

Earlier quoted context omitted.

You've seen games running at 120Hz and at 60Hz. The difference is obvious, isn't it? The difference between 24Hz and 60Hz is certainly obvious: that's the visual difference between movies and TV sitcoms. I can type about 90 words per minute on QWERTY, which is about 8 keystrokes per second. That means that the average interval between keystrokes is about 120 milliseconds, already significantly less than my 200-millis…

> You've seen games running at 120Hz and at 60Hz. The difference is obvious, isn't it? Honestly, I have not. I'm not much of a gamer, even though I used to be a game developer. Certainly the difference between 30Hz and 60Hz is noticeable. Maybe this is just because I'm old school but if it were me, I would absolutely prioritize low latency over high frame rate. When you played an early console game, the controls felt…

Oh! I assumed that because you were a famous game developer you would hang out with gamers who would proudly show off their 120Hz monitor setups.

I agree that low latency is more important than high frame rate, and I agree about the snappiness. But low jitter is even more important for that than low latency, and a sufficiently low frame rate imposes a minimum of jitter.

Music is even less tolerant of latency, and PCM measures its jitter tolerance in single-digit microseconds.

Re: John Carmack on inlined code (2014)

#296

Post by randomdata »

mgsouth wrote: post #292
randomdata wrote: post #214

Earlier quoted context omitted.

Unit tests are for documenting the API contract for the user. You are going to target based on what you are willing to forevermore commit to for those who will use what you have created. Indeed, what happens when two messages come in with the same message ID is something the user needs to be aware of and how it functions needs to remain stable no matter what you do behind the scenes in the future, so you would absolu…

We're in general agreement about the purpose of unit tests. I disagree on a couple of points. Tests do not document the API. No test is complete, and for that reason alone can't completely document anything. For example, a good API might specify that "the sender must be non-null, and must be valid per RFC blah." There's no way to test that inclusively, to check all possible inputs. You can't use the test cases to ded…

> There's no way to test that inclusively, to check all possible inputs.

Which means the RFC claim is false and should not be asserted in the first place. The API may incidentally accept valid RFC input, but there is no way to know that it does for sure for all inputs. You might suspect it conforms to the RFC, but to claim that it does with certainty is incorrect. Only what is documented in the tests is known to be true.

Everything else is undefined behaviour. Even if you do happen to conform to an RFC in one version, without testing to verify that continues to hold true, it probably won’t.

This is exactly why unit tests are the expected documentation by users. It prevents you, the author, from make spurious claims. If you try, the computer will catch you in your lies.

> The other thing I would shy away from is including throwaway tests in the framework.

What does that mean? I suspect you are thinking of something completely different as this doesn't quite make sense with respect to what I said. It probably makes sense in another context, and if I have inferred that context correctly, I'd agree... But, again, untreated to our discussion.

Re: John Carmack on inlined code (2014)

#297

Post by pastaguy1 »

silisili wrote: post #45
JauntyHatAngle wrote: post #31

Earlier quoted context omitted.

I know it's overused, but I do find myself saying YAGNI to my junior devs more and more often, as I find they go off on a quest for the perfect abstraction and spend days yak shaving as a result.

Yes! I work with many folks objectively way younger and smarter than me. The two bad habits I try to break them of are abstractions and what ifs. They spend so much time chasing perfection that it negatively affects their output. Multiple times a day I find myself saying 'is that a realistic problem for our use case?' I don't blame them, it's admirable. But I feel like we need to teach YAGNI. Anymore I feel like a sa…

This isn't meant to be taken too literally or objectively, but I view YAGNI as almost a meta principle with respect to the other popular ones. It's like an admission that you won't always get them right, so in the words of Bukowski, "don't try".

Re: John Carmack on inlined code (2014)

#298

Post by rileymat2 »

davidw wrote: post #261
lifeisstillgood wrote: post #218

Earlier quoted context omitted.

I often Bang on about “software is a new form of literacy”. And this I feel is a classic example - software is a form of literacy that not only can be executed by a CPU but also at the same time is a way to transmit concepts from one humans head to another (just like writing) And so asking “will AI generated code help” is like asking “will AI generated blog spam help”? No - companies with GitHub copilot are basically…

> is a way to transmit concepts from one humans head to another (just like writing) That's almost its primary purpose in my opinion... the CPU does not care about Ruby vs Python vs Rust, it's just executing some binary code instructions. The code is so that other people can change and extend what the system is doing over time and share that with others.

I get your point, but often the binary code instructions between those is vastly different.

Re: John Carmack on inlined code (2014)

#299

Post by mgsouth »

ragnese wrote: post #128
mihaic wrote: post #2

When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used? I think the truth is that we just CAN'T scale that way with the current programming languages/models/…

We've been there, done that. CRUD apps on mainframes and minis had incredibly powerful and productive languages and frameworks (Quick, Quiz, QTP: you're remembered and missed.) Problem is, they were TUI (terminal UI), isolated, and extremely focused; i.e. limited. They functioned, but would be like straight-jackets to modern users.

(Speaking of... has anyone done a 80x24 TUI client for HN? That would be interesting to play with.)

Re: John Carmack on inlined code (2014)

#300

Post by EGreg »

low_tech_love wrote: post #256

Interesting: this is a 2014 post from Jonathan Blow reproducing a 2014 comment by John Carmack reproducing a 2007 e-mail by the same Carmack reproducing a 2006 conversation (I assume also via e-mail) he had with a Henry Spencer reproducing something else the same Spencer read a while ago and was trying to remember (possibly inaccurately?). I wonder what is the actual original source (from Saab, maybe?), and if this i…

Is this kind of like 300 was a movie about a Frank Miller novel about a Greek legend about the actual Battle of Thermopylae?
Post reply on HN