Molly Rocket

Regarding the speed, meow_hash is certainly performant, but when hashing a single file, b3sum actually seems to be faster, perhaps due to using more threads. Could meow_hash be made even faster by running more operations in parallel? time ~/.cargo/bin/b3sum ubuntu-19.10-beta-desktop-amd64.iso 0899b731b6b57d75a65273fe29d54802653b3bbe3bae6732140c487c4f0ece71 ubuntu-19.10-beta-desktop-amd64.iso real 0m0,180s user 0m1,735s sys 0m0,092s time meow_example ubuntu-19.10-beta-desktop-amd64.iso meow_example 0.5/calico - basic usage example of the Meow hash (C) Copyright 2018-2019 by Molly Rocket, Inc. (https://mollyrocket.com) See https://mollyrocket.com/meowhash for details. Hash of "ubuntu-19.10-beta-desktop-amd64.iso": E5CC524A-522BDE7E-ED34A277-5C7D73AF real 0m0,766s user 0m0,119s sys 0m0,645s

Personally, Prolog was the biggest "woah" moment for me in learning programming languages. If anybody wants a challenging and enlightening programming exercise, I recommend writing your own prolog[esque] interpreter. Surprisingly it still has not been used much in games (well, actually not that surprising given how time consuming and risky it is). I made a stab at [1] but ended up taking more time than I had budget for. One thing I suspect may be using it is the game 1935 [2], although they are vague on the details. [1] https://www.youtube.com/watch?v=2EHKDP2_ky0 [2] https://mollyrocket.com/news_0023.html

I think there is a growing rebellion against the kind of software development "best practices" that result in the kind of problems noted in the article. I see senior developers in the game industry coming out against sacred principles like object orientation and function size limits. A few examples: Casey Muratori on "Compression Oriented Programming": https://mollyrocket.com/casey/stream_0019.html John Carmack on inlined code: http://number-none.com/blow/john_carmack_on_inlined_code.html Mike Acton on "Data-Oriented Design and C++" [video]: https://www.youtube.com/watch?v=rX0ItVEVjHc Jonathan Blow on Software Quality [video]: https://www.youtube.com/watch?v=k56wra39lwA

The right answer for a API to draw a line like you describe is to provide every possible way to draw a line since you never know which one the user wants to use. Granularity is one of the general five properties of every good API, of course it is not always good to provide all possible ways since it hurts compactness. The best I have ever heared about API design was a talk from Casey Muratori: http://mollyrocket.com/casey/stream_0028.html

You might enjoy this: http://mollyrocket.com/casey/stream_0019.html I think the problem is that OOP is automatically considered "virtuous", despite the context. There's nothing wrong with the single responsibility principle and what not, but there is something wrong with thinking that classes and objects are always the best way to approach a problem. Java ends up being the target of jokes because by forcing everything into classes/objects even when it doesn't make sense, it leads to cartooned versions of those ideas.

It's funny. He gives an example of how by grouping data and functions that operate on that data (in a class) is a great example of COP and different from OOP...: http://mollyrocket.com/casey/stream_0019.html I can only conclude that he spent ten years in the world of toy class-oriented "oop", premature oversized architecture and other nonsense that follow from going from "have no idea about the code/function; will model as strict class hierarchy" -- rather than doing the sane thing BDD/TDD/throw-away prototyping -- followed by refactoring / reimplementation. It makes for a great sound-bite -- but he's kind of attacking "straw-man" OOP.

If you're in a position where you need something to listen to while driving or public transportation, I recommend The Jeff and Casey Show: http://mollyrocket.com/jacs/ It's quite fun. I would describe it as two experienced programmers who are goofy, grumpy, and opinionated, shooting the shit.

The Jeff and Casey show is probably my favorite: http://mollyrocket.com/jacs/index.html. It's hosted by the owner/founder of Rad Game Tools and one of their (now ex-) programmers (who has recently had minor fame as the host of handmade hero). Typically the episodes aren't about programming, although they do frequently discuss tech topics.

The programmer behind this, Casey Muratori, has been helping out Jonathan Blow (Braid) on his new game, The Witness, and blogging about it. For the more experienced game devs out there, the series is a fantastic read: http://mollyrocket.com/casey/ (starting post 6). Many of the insights apply to software engineering in general, not just game dev.

Designing and Evaluating Reusable Components by Casey Muratori. Slides PDF and audio track available here: http://mollyrocket.com/9438 This is a talk about the practical realities of integrating with APIs over the lifetime of a project. In particular, it presents an insightful list of pitfalls API designers often fall into that hamper integration, and it suggests ways to avoid those pitfalls. Sadly, a decade or so later, many of us are still making the same basic mistakes. If this talk were better known, perhaps we wouldn’t be, so it gets my vote.

Here's a fantastic presentation about API design: http://mollyrocket.com/873

The original announcement post of Meow Hash from 2018 at https://mollyrocket.com/meowhash said: > […] we wanted a fast, non-cryptographic hash for use in change detection and deduplication. and > To our surprise, we found a lack of published, well-optimized, large-data hash functions. Most hash work seems to focus on small input sizes (for things like dictionary lookup) or on cryptographic quality. and also > The Meow hash is not designed for cryptography and therefore we make no claims about its security. Assume it is completely insecure. I found it confusing then that the cryptanalysis of Meow Hash posted here said: > The creators make a few security claims; we will break them all. In particular, we present three main attacks […] But then looking at the Meow Hash GitHub repo I see in the README: > Due to recent discoveries by Peter Schmidt-Nielsen, we have decided to reclassify Meow hash 0.5/calico from level 3 to level 1. This means that we recommend not to use this hash for message authentication codes, or for hash tables in scenarios where collision induced denial-of-service attacks are a concern. > We have seen no evidence that the hash is unfit for non-adversarial/non-cryptographic purposes, and continue to believe that it is amongst the best in this regard. > For level 3/MAC capabilities consider migrating to SipHash. Do not migrate to any hash not advertising MAC capabilities as these are almost certainly much weaker than Meow 0.5. If the performance of…

No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs. The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor). Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics. I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html.

> This coding style is standard practice for Win32 API development. Do you have a public style guide that indicates this? I worked at Microsoft, and while there are teams that (very unfortunately) went with this "diamond" style of error handling, code written in the CNF (Cutler Normal Form) style, such as the kernel code, use gotos and a central cleanup point at the end of the function, which is also the same style used by the Linux kernel: https://github.com/torvalds/linux/blob/master/Documentation/process/co… The "diamond" style hinders readability, especially when you have many levels of indentation). While it may be a practice adopted by many people, that is does not necessarily mean that it is good style. Even Steve McConnell's Code Complete, a book published by Microsoft Press, recommends early returns over deeply nested if statements for error handling: https://books.google.com/books?id=LpVCAwAAQBAJ&lpg=PA764&ots=G… Unfortunately, the Win32 API is full of technical debt, many of which cannot be repaid due to backwards compatibility reasons. Given it is likely most application code written against Win32 is in C++, the ideal approach would be to follow an object-oriented style and use destructors and RAII rather than cleanup functions, but that is not the world we live in. The design of the Win32 API should not be used as guidelines for good coding…

Polynomial splines are pretty shitty compared to rational splines for animation and modeling, but they both have the problem of non-constant speed. It gets much worse with higher degree curves. You fix that by letting the animator separately specify a scalar speed curve so he can control where things speed up and down. To make this curve be natural to manipulate, it must be specified relative to an arc length parameterization. You can sometimes profitably combine the arc length reparameterization curve and the pre-integrated user-specified speed remapping into a single remapping curve that's baked out to disk, so the run-time curve evaluator only has to deal with a single level of parameter remapping on top of the raw spline. This is just a fact of life with splines. They have non-uniform speed in their raw form and you have to deal with it. It's also why quaternion slerping being constant angular speed isn't a real advantage over lerp-and-normalize because they both trace out the same path and often you'll want to overlay a speed curve anyway (and lerp-and-normalize's speed is only barely non-uniform). Evaluate-and-normalize is the way to go for quaternions. It works great for multi-way skeletal animation blending and higher-order rotation interpolation (just do the spline evaluation in R^4 and project back onto the unit sphere). Casey has an old email that goes into some of this: http://mollyrocket.com/911.txt

Can you elaborate on what it fails? https://mollyrocket.com/meowhash claims: > It cleanly passes every test in smhasher

Meow hash claims 3-4x faster hashing over this, still passes smhasher, and is a few years old. https://mollyrocket.com/meowhash And there are a bunch of other good suggestions here in the comments looking at around the same 50-60gb/sec speed

Unsure about the Q.Score, but for large data, MeowHash appears to also be a solid choice for non-cryptographic hashing: https://mollyrocket.com/meowhash A comparison that a user ran vs. xxHash: https://www.reddit.com/r/programming/comments/9pr5ir/meow_hash_a_noncr…

This is not a gimmick haha. Read my comment from earlier in this thread: Casey is really well known in the gaming community - https://mollyrocket.com/casey/about.html Through Handmade Con, he's also interviewed many other creators like Jonathan Blow and Edmund Mcmillen. He also contributed to Blow's recent game, The Witness (specifically the movement system and the world editor). This is a really good series by an experienced game developer that's basically free (or at least the Zed Shaw model of pay to download but free to view).

He also has some pretty cool articles on finding all walkable areas of the map ("walk_monster.cpp")and how he improved the grass planting system: https://mollyrocket.com/casey/stream_0006.html https://mollyrocket.com/casey/stream_0015.html

2 years is nothing for a video game project. Also, keep in mind he's only working on it while he's streaming, which is 5 hours a week (max. sometimes, it's less). He's also been making a game he intends to sell for money for the past 2 years (1935[0]). [0]: https://mollyrocket.com/news_0023.html

Compression oriented programming - https://mollyrocket.com/casey/stream_0019.html

The common pattern he mentions reminds me of the concept of 'semantic compression' (one big function and lots of variables first, then break it up into structs, classes, functions, etc.) by Casey Muratori: https://mollyrocket.com/casey/stream_0019.html It's a very nice and natural way to write code to do it all horribly dirty and only when a sizeable portion if ready to start cleaning it up and making it look and read good. Both are basically "good comes from evolving/refining bad".

From my small experience with Elm all that boilerplate is nicely dealt by compression-oriented programming [1]. It is easy to move common code into helper function and Elm pure functional nature makes that rather maintainable. The hard part is to come up with good names for those helpers and avoid being too generic when refactoring code. [1] https://mollyrocket.com/casey/stream_0019.html

Not me personally but this got some traction twice on HN: https://mollyrocket.com/casey/stream_0029.html

As usual, the article grossly oversimplifies the position of the people in it, and the discussion on HN focuses on the gross oversimplifications. Better to hear it from the horse's mouth eg: https://www.youtube.com/watch?v=k56wra39lwA https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0020.html You might still disagree, but at least you'll have something coherent to disagree with.

This benefit of test-driven design is not obvious (at least it wasn't for me) until you really experience it. Several years back I wasn't aware of the concept of dependency injection, but independently discovered it while trying to unit test some error logging functionality. Previously I'd always used a global/singleton logger object. That always felt wrong, but I always assumed it was necessary until writing unit tests forced me to avoid that design. Also note that TDD is not the only way of getting this benefit. IMHO Paul Graham's essay Programming Bottom Up[1] and Casey Muratori's concept of 'compression-oriented programming'[2] both espouse this same idea of improving API design by "writing examples of their use." [1] http://www.paulgraham.com/progbot.html [2] https://mollyrocket.com/casey/stream_0019.html

Yep - that was a bit of an eye opener for me. He is a super smart guy but if you saw a snapshot of this game source your first reaction would be to suggest a series of (micro) improvements... He explains this style you mentioned here: https://mollyrocket.com/casey/stream_0019.html

With event framework,we should use little helper function to wrap each event type,at least that's what I have seen.Windows event tracing(ETW) comes to mind,one of the complex api written[1].I always thought that every application should make use of ETW infrastrucutre. Compared to perf_events or may be lttng in linux(I am not sure how difficult to integrate to perf_events).Currently there are good and easy framework for ETW in .net [2]. But once you integrate your app,your app suddenly gains performance tuning,debugging capability easily. I think this should hold true for any event framework!! [1]https://mollyrocket.com/casey/stream_0029.html [2]https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing.TraceEven…

The files on that page wouldn't load for me-- the podcast that's being drawn from is here, and the Direct2D portion is around the 1 hour mark: https://mollyrocket.com/jacs/jacs_0001_0050.html