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

Is abstraction overrated in programming? Chess, interviews and OOP

quora.com

Post reply on HN
Print view View original

101–110 of 149 posts

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#101

Post by fastcum »

cdevs wrote: post #23
moomin wrote: post #16

I’m a bit concerned with the bitboard representation. What happens when a pawn takes another piece? Edit: The above is what I would say if someone presented this approach in an interview.

I'd like to see the rest of this implemented. What does this global functions look like? Are they swamped with if statements "I hope not" or are you storing some game logic in structs to replace polymorphism. I don't disagree with with the compact pawn struct as a starting point but to further prove your point I would love to see the rest / pseudo code.

stockfish is an open source chess engine that uses BitBoards https://github.com/official-stockfish/Stockfish/

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#102

Post by zephyrfalcon »

valuearb wrote: post #55
mnm1 wrote: post #31

Earlier quoted context omitted.

Oh please. As if the interviewer's next question wouldn't be "make it faster/more efficient" anyway. The interviewer is the problem here because he wants to build a chess game in an extremely stupid way using OOP for no other reason than to use OOP. I'd say most applications of OOP fail in similar ways in real life, creating monsters of complexity where simplicity could have existed. The author should consider himsel…

The interviewer gave the OP a simple question that could be answered within a short time to gauge how well they understood OO design, and OP specifically implemented it in a way to frustrate them. So again, whose the idiot? If OP wanted to crush the question, they could quickly answer it by saying this is how you could implement using classes and inheritance, now let me explain why OO is a poor solution for this spec…

It does not mention how the question was put, and in which context. If it was clear from the start that the OP was expected to use OO, then it would not be smart to start with the bitboard implementation and then continue to argue about it. ... But if the question simply was, "how would you design a chess game", with no other context, then it would be reasonable to assume that the interviewer would want to hear your best solution... and for that he chose the non-OO bitboard version, based on his previous experience with chess engines.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#103

Post by ZirconiumX »

My opinion is that this post reaches the same conclusion as I would, but I disagree with the logic behind it.

In a modern, state of the art chess program that uses alpha-beta with a branching factor b and depth d, you will have at most d boards allocated, or even 1 board allocated. Neither of those figures approach b^d. That makes board size largely irrelevant, except for the amount of memory copying needed, which for a d-board approach would be b^d copies (a single board approach would only mutate that board).

EDIT: One major issue I just noticed with the article is that the two differing implementations are not apples-to-apples equivalent. One uses bitboards, based around manipulation of bits, and another one is akin to representing the board with an array.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#104

Post by ZirconiumX »

lozenge wrote: post #50
smallnamespace wrote: post #15

Earlier quoted context omitted.

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.

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 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.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#105

Post by inopinatus »

loup-vaillant wrote: post #99
inopinatus wrote: post #89

Earlier quoted context omitted.

A variant of the flyweight pattern using contextual identity. All board representation remains a bunch of uint64_t, all messages sent to boards result in bit manipulation (i.e. not massive duplication of objects), and you instantiate the piece objects once per game. There's simply no need for "instantiate all the things" approach assumed in the Quora answer. That is OO at its most naive. OOP is messaging, encapsulati…

I have the sinking feeling that your first paragraph is probably what the original author had in mind all along… He advocated for a representation of the entire board, and that's apparently what you would do as well. I originally though you were advocating for a representation of each piece on the board, were "messages" were "sent" to individual pieces, not the entire board. I was curious about how you'd map that int…

I am. You should definitely be able to send messages to piece objects. That's not incompatible with the Board object having a bitboard for its internal representation of board configuration. The piece objects have contextual identity based on the board configuration. Hint: they don't have positional state.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#106

Post by seanmcdirmid »

loup-vaillant wrote: post #96
seanmcdirmid wrote: post #80

Earlier quoted context omitted.

Competent entity systems are OOP, entity is synonymous with object (bring out some other object-like system, and a theasurus is usually used to find another word for object). You just don’t use classes, but there have been plenty of classless OOP systems since the Treaty of Orlando. Anything with a nounish tint will lean more OO than functional (of course, taxonomies are never perfect). Objects have always been about…

First, let us agree on what OOP might even mean. http://loup-vaillant.fr/articles/taboo-oo http://loup-vaillant.fr/articles/deaths-of-oop

I prefer the Treaty of Orlando, which is much more inclusive, and underlies our entire community.

http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla...

It is scary that the broad definition given in the 80s has been supplanted by a narrow “java or C++” definition today. If that what you mean by it, then no we aren’t talking about the same thing. I’ve built plenty of OO systems that don’t correspond to that definition at all, and at any rate, were still considered OO systems by the OO community (at least by the people who attend ECOOP and OOPSLA).

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#107

Post by _yawn »

The whole point of abstract data types is to separate implementation from interface in order to allow a change in representation.

The point is to allow programming things like the AI algorithm without caring at all about if the board is represented with a hash map, nested arrays, or a bitboard. In all cases, all the AI cares about is move generation, not internal representation.

Abstraction does not hinder ideas like the bitboard, it enables them. Both the interviewer and the interviewee are missing the point.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#108

Post by dbenhur »

inopinatus wrote: post #49
Chriky wrote: post #32

Is this for real? The solution he proposes is specific to Chess ! I mean, does this guy really think the company cares about efficiently representing chess game states?? Obviously, obviously, OBVIOUSLY, the Chess aspects of this question are irrelevant. What they are trying to find out if how well you will work on their actual codebase, which is presumably not comprised of global functions operating on bitfields

The guy is openly arguing with an interviewer after taking a question too literally. I suspect my interview impressions would've included "candidate may be on the spectrum". However, this entire thesis is founded on a false dilemma, because you can write an OO domain model with a compact representation.

If you aren't argu^H^H^H^Hdiscusing with the interviewer, you're doing it wrong. If that results in unfavourable evaluation, that's good data for you whether you should take that job.

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#109

Post by c22 »

Const-me wrote: post #81
c22 wrote: post #24

I don't know why he wants to waste so much space with twelve unsigned longs when he can do it in eight (one for each piece and two more masks for color).

I don’t know why would you both want to waste so much space? A cell is either empty, or contains one of the 12 figures. To store 13 values, you need 4 bits per cell i.e. 256 bits for the complete board. That’s 4 unsigned longs.

Color is still binary and there are at most 32 pieces on the board, so why not 3 bits per cell and a 32 bit lookup for color? Only 224 bits!

Re: Is abstraction overrated in programming? Chess, interviews and OOP

#110

Post by mikekchar »

hota_mazi wrote: post #85
jgalt212 wrote: post #70

Earlier quoted context omitted.

composition over inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance

No, my observation has nothing to do with composition vs/ inheritance. It's about defining what a class IS vs/ what a class HAS.

It's hard to ask this question without sounding snarky, but I hope you will understand that I'm seriously curious to hear what you think.

> No, my observation has nothing to do with composition vs/ inheritance.

> It's about defining what a class IS vs/ what a class HAS.

What do you feel is the difference between these two sentences? In other words, why is inheritance vs composition not the same as what a class is vs what a class has?

Post reply on HN