Hacker News new | ask | show | jobs
by smallnamespace 3095 days ago
Or maybe the OP understood that everyone who has ever implemented a chessboard are also building chess engines where memory efficiency and speed actually matter a lot.

It's the interviewers who are ignorant here, they took a real problem and translated it badly into a toy problem. Then they failed to realize what they did.

2 comments

They could be building an online social game site, or implementing a UI but using an existing AI. In which case the OO version will be easier to code, understand, render, and render history in chess notation. The only thing his methods is good for is implementing an AI and serialization.
I think the author's approach is data-centric rather than object-centric.

His methods would be easy to persist: write the longs to a file. Easy to render: based on bit positions, draw a piece. Easy to understand. I looked at it and immediately knew what was happening (which almost never happens when I have to look at a massive class hierarchy). History would be trivial with his approach: since it's space-efficient, you could literally store the bit-space for each previous board configuration or if you wanted to optimize more, you could store a simple sequence of moves.

I highly disagree. Implementing an AI requires being able to work effectively in chess notation. Either you can choose long algebraic notation, which is pure squares (which can be encoded/decoded into a move type) or short algebraic notation, which requires knowing piece types (which is an AND between a bit representing the square and piece type bitboards) and being able to differentiate between multiple attacks to a square (which is an AND between the move square and attacks by other pieces of the same type).

This is complicated by the two approaches not being apples-to-apples, however.

why? the bitBoard describes the full game state, your renderer can use the data to draw the board for seamless decoupling.

I don't see how the history would make any difference?

bitshifting might be a bit hard for newer programmers but it's abstracted under global functions.

GP is correct. The Quora answer has a false dilemma that you've just perpetuated here, viz. that an OO program cannot use a compact representation. But there are standard patterns for using a compact representation of data for domain-model objects.

The article's author isn't just unaware of them, they've written a petulant, arrogant article demonstrating their own lack of experience and adaptability.

I'm interested. Care to elaborate how an OO approach could yield a compact representation in this particular case?
A facade wrapping the representation would sufficiently transform the paradigm?