Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

In functional style, you'd probably have a table mapping machine instruction type to a function. These days, even Java (since version 8) supports that, and it roughly compiles down to the same thing (due to how Java implements lambdas).

This case sounds simple, but I still expect the functional approach to save you from a lot of line noise coming from Java class bureaucracy. But in more complex cases, it may be a difference between a couple dozen lines and a couple dozen files.

View on HN

On the other hand, the OOP approach allows you to add printing the function name (for disassembly views), metadata attributes about what flags are affected, clock cycles, etc. You could argue that each of those could be separate tables. Funny how it comes back to the array-of-structs vs struct-of-arrays design question, or maybe I'm just seeing that everywhere because of thinking about Mike Acton's Data Oriented Programming talk.

Clojure. Clojure is extremely data oriented.

I think the most of the data-oriented-programming stuff referenced nowadays are not about conceptual data (how humans understand it), but data in the hardware (how machines understand it). In that regard, in Lisp you can’t really control memory allocation/alignment as flexible as C/C++, (due to its conceptual assumptions with data), so I don’t know how you would do DOP well in Lisp:

(although it might sometimes serve well as a configuration language alongside high-performance C++ code like in gamedev...)

Those are two different kinds of programming, which unfortunately get similar labels.

The C++/gamedev "data-oriented programming" is about structuring your in a way that's friendly to CPU cache. It turns the programmer-friendly abstractions inside-out in order to make execution as efficient as possible.

The Clojure/Lisp/functional "data-oriented programming" is about building your (programmer-level) abstractions around basic data structures like lists and maps. It's meant to simplify your code and make it more robust.

The two "data-oriented programming" paradigms are pretty much opposites in every way except the name. They both focus on data, but the resulting data structures are vastly different.

Actual Lisp implementations need to interface to the C/C++ side, thus they have non-standard / quasi-standard ways to deal with raw/foreign memory and with C types.

I'm... not sure how we went from replacing a function-like object with a function to adding disassembly and clock cycles. Am I missing some context here?

Can't edit or delete anymore so replying to myself. I confused the subthreads and thought this was still the "interview quesiton" part. Obviously the assembly/clock cycles are relevant to the phaedrus's example.

You get that with Java 8 and later because you can just define a FunctionalInterface and then use a mapping table to function-to-use and it gets really compact. If you want to decorate arbitrary functions that should be fairly trivial too.

Wrote something small like that for a random data generator for an in-house properties tester in Java a short while back. It makes it easier, in my opinion, when you have all the code available in a single screen than if it’s spread out.

Reply on news.ycombinator.com