Stefanos Evangelatos

Carmack also used to have some really insightful articles on AltDevBlog. I recently read his one on functional programming and thought it was very well thought out. This site had nice re-uploads for the some of the articles. You can maybe google around and find more [0] http://sevangelatos.com/tag/john-carmack/

One of the best post on FP I read was John Carmack's realisation that FP had a strong place in any code base [0]. It's a really valuable lesson to keep most function as pure and stateless, but transformation of the existing state. Build your entire codebase around this idea and frankly, abstraction will take care of itself. [0] http://www.sevangelatos.com/john-carmack-on/

I suspect fewer than you think. At least in FAANG code. Google chrome has had a fair few CVEs over the years despite having a lot of the worlds best security researchers working full time looking for security vulnerabilities. I think someone has tried reading the compiler warnings. There’s an old story about John carmack running a new static analysis tool on the quake3 source code. The code worked well. The tool apparently found a huge list of issues in the code - including a massive pile of real bugs. Then he tried another static analysis tool and it found more real bugs. And so on. The story is well worth a read. This is a great takeaway: > This seems to imply that if you have a large enough codebase, any class of error that is syntactically legal probably exists there. C++ is really hard to do “right”, at any scale in a real team. http://www.sevangelatos.com/john-carmack-on-static-code-analysis/

This is a tour de force, and it accomplishes the goal of enabling FP using the Go syntax and toolchain. But code written using this library is no longer Go: most Go programmers can't grok it, and it's awkward to call normal Go libraries because there's no way to know if that function you're calling is pure. If your goal is to "make it easy and fun to write maintainable and testable code in golang" by making pure functions first-class, is there another way to do that without inventing a new language? From experience and inspired by Carmack's classic essay on FP in C++[1], I tend toward a functional style: minimize state, treat locals as const, avoid non-const globals, enable parallelism by isolating state. Go makes it easy to write static analysis tools, so go vet could be augmented to, for example, keep track of which functions are pure, and show some yellow underlines at those places where input parameters are mutated. I'd use something like that. [1] http://sevangelatos.com/john-carmack-on/

As a mobile dev for games/apps I like to have as many versions of devices as possible, newest one if possible. However, the older phones/tablets/devices are best to start and do most of the development on, somewhat like making sure a game runs on an older PC or laptop. If you tune your app to the lower end (older) devices, scaling up is easier than scaling down. If all you have is the latest devices it will lead to bloated apps and slow games. Similar to how John Carmack does parallel implementations and starts with the lower end renderers in game engine design [1]. > However, some of my most effective uses of this strategy have been more aggressive. Over the years, I have done a number of hardware acceleration conversions from software rendering engines. In the old days, I would basically start from scratch, first implementing the environment rendering, then the characters, then the special effects. There were always lots of little features that got forgotten, and comparing against the original meant playing through the game on two systems at once. > The last two times I did this, I got the software rendering code running on the new platform first, so everything could be tested out at low frame rates, then implemented the hardware accelerated version in parallel, setting things up so you could instantly switch between the two at any time. For a mobile OpenGL ES application being developed on a windows simulator, I opened a completely separate window for the…

A similar, more concrete approach is parallel implementations, as written about by John Carmack[0]. I suppose the main difference is that parallel implementation has you very explicitly and intentionally leave the "old stuff" around until you're ready to flip the switch. I've used this approach in large-scale refactorings very successfully. One of the benefits is that you get to compare the new vs old implementation quickly and easily, and it lets you raise questions about the old implementation; every time I've done this I've found real, production-impacting bugs because the old system was exhibiting behaviors that didn't match the new system, and it turned out they weren't intentional! [0] http://sevangelatos.com/john-carmack-on-parallel-implementations/

It is a static analyzer built into Microsoft Visual Studio: https://learn.microsoft.com/en-us/cpp/build/reference/analyze-code-ana… The only reason I know about it is that John Carmack rated it highly: http://www.sevangelatos.com/john-carmack-on-static-code-analysis/

No, my argument is that TS makes writing code easier and that easier does not equal to quality [0]. I have been writing code for more than 20 years. Personally, TS doesn't impress me. This is not meant as a criticism. Personally, I have found functional programming to be revelatory. I am shocked that is as been around as long as it has and that our schools don't teach it (or just mention it) and the majority of people in our industry as resistant to it. "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn’t convenient." -- John Carmack [1] [0] "Simple Made Easy" Rich Hickey https://www.youtube.com/watch?v=LKtk3HCgTa8 [1] "John Carmack on Functional Programming in C++" http://sevangelatos.com/john-carmack-on/

I read the book (which is only 200 pages, a lot skimmable, and free online even (edit: used to be, now parts on the manning site are garbled)) and liked it. Presented it to some coworkers once, and described how I used the method pretty successfully for a few actual work items. Because the work environment used Perforce, not everything was done as micro commits, but still. One task was small, it was to delete a secret token from a hardcoded XML config file and instead have it be consumed by calling out to a new secrets server some other team had setup. Nodes were things like "Read the doc for this new service", "Unblock the MVN issue preventing setting it up locally", "Set it up locally", "Store the token locally", "Store the token to the production cluster", "Identify all consumer(s) of the token", "Update the consumers to pull from the server", "Remove the token from the XML". Another slightly larger task was to refactor/fix a migration framework someone who had left the company wrote to migrate version-by-version doing all components at each version at once, instead of component-by-component doing all versions for just it at once. Without Mikado it probably would have been one giant commit, with Mikado it was 3 with everything working at each step. (If we used git probably could have been more.) And the migration bugs basically went away after that, so that was nice. The method is something I think about when things start to feel uncertain or hairy, but I try to avoid…