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

61–70 of 149 posts

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

#61

Post by christophilus »

fjdfhdjldj wrote: post #58
inopinatus wrote: post #49

Earlier quoted context omitted.

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.

why the onus is not on the interviewer? Why is he bringing up chess if he just wants OO answers? Aren't there better problems to pose more suited for testing OO knowledge? Bitboard is a standard way of writing chess engines. I think most would agree that a good programmer is one that seeks the best solution, not one that follows dogmatically his preconceived ideas.

Yeah. Based on the HN comments, I went into this article expecting it to be an uninformed tirade. I came away from the article thinking, "I'd hire that guy immediately."

The interviewers are definitely using the wrong problem if they're trying to test knowledge of OOP.

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

#62

Post by christophilus »

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

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

#63

Post by fjdfhdjldj »

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.

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.

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

#64

Post by christophilus »

fjsolwmv wrote: post #52
alerighi wrote: post #20

Earlier quoted context omitted.

That is entirely subjective. I am more comfortable reasoning with bits than with object. I also think optimization matters, if you can reduce the memory consumption with a simple and elegant solution, why not ?

How would you build a GUI for your bits-based chessboard?

Trivially, you'd iterate i from 0-63 and then do 10 bit checks per value of i in order to determine what piece, if any, is on tile i. You could probably optimize it further, but that'd be hella fast on any device I can think of, and would take very little code to implement.

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

#65

Post by Silhouette »

fjsolwmv wrote: post #51
Silhouette wrote: post #25

Earlier quoted context omitted.

It's a poor choice of scenario for an interview, because no-one who knew anything about writing chess software would ever write that sort of OO code. If the point was to test for an understanding of OO design, wouldn't it be a good idea to provide a problem where OO design was appropriate?

OO is for large problems, not 30-line whiteboard able problems. That's the challenge.

Is there any reason to believe that code using efficient data representations like bitboards can't scale just as well, if not better, than OO versions full of classes?

Or that the interface to use that code would be harder to understand or maintain?

If not, why mandate the use of OO at all, and if it's OO you want to test, why not pick a better example where it might actually make sense?

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

#66

Post by valuearb »

christophilus wrote: post #60
valuearb wrote: post #57

Earlier quoted context omitted.

You use OO because your interviewer wants an example that demonstrates you understand it. Secondly, OO is more easily extensible. If the company wants the game to support other size boards, bit wise storage has to be ripped out. 90% of the work in 90% of the jobs is writing clear, easily maintainable and extensible code, not maximizing performance. Frankly, if I interview someone who answers a question like OP, i pas…

Except, this is not premature optimization. Chess programs are a domain the author is familiar with. He goes out of his way to explain why-- based on his experience-- chess code should be written with space-optimization in mind. Secondly, if you want to support non-standard boards, his solution requires a small tweak (depending on the language): long -> bigint and some parameter to denote board size.

Yea, you are describing code that’s more difficult to enhance and maintain.

Your pieces and board objects can have serialize/deserialize methods that write/read them to/from bitboards for most efficient storage for whatever variant of chess you want, while still having your code in an OO design that’s easier to understand and extend. And allow you to demonstrate the skills the gdmn interviewer wanted you to demonstrate, which is the actual point of the excercise!

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

#67

Post by valuearb »

jstimpfle wrote: post #56
valuearb wrote: post #53

“But first of all, the OO inheritance here is irrelevant. The queen is the only piece which actually “inherits” properties from other pieces! We don't need an object model to simply reuse some functions to calculate legal moves given a position. Just a few global functions.” Don’t all pieces have a location? Aren’t all pieces movable? Might we want to display pieces? Do we want to journal them to files to save game s…

> Don’t all pieces have a location? Make a table containing locations for each piece. > Aren’t all pieces movable? Make a function ("procedure") that moves a piece (e.g. edits the location table). > Might we want to display pieces? Make a render function (e.g. gets a piece type and a position) > Do we want to journal them to files to save game state, or their moves to streams to play remotely? Write serialization and…

People who say this apparently have an inordinate love of switch statements.

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

#68

Post by loup-vaillant »

fjdfhdjldj wrote: post #54
valuearb wrote: post #53

“But first of all, the OO inheritance here is irrelevant. The queen is the only piece which actually “inherits” properties from other pieces! We don't need an object model to simply reuse some functions to calculate legal moves given a position. Just a few global functions.” Don’t all pieces have a location? Aren’t all pieces movable? Might we want to display pieces? Do we want to journal them to files to save game s…

but then why use OO? what does OO offer that this method does not? In fact one could argue that this method offers better decoupling since it separates the rendering from the game Data.

OO is better because bundling data and code together is better, because code is data, and I have no idea what I'm babbling about.

The real advantage of OOP, as used today in Java/C++, is instantiation. Instead of having procedures working on global variables, you have procedure working on local variables, including complex data structures.

Instantiation took some time to get widespread adoption. Originally, even local variables were actually global, scoped variables, thus forbidding even recursive calls (see earlier versions of FORTRAN). Programming languages since use a stack to instantiate their local variables (and return pointers), thus enabling recursion. The instantiation of more complex data structures (arrays, user defined structs…) followed.

Ironically, instantiation took some time to become ubiquitous in the C language even though it fully supported it from the very beginning, with a stack and user-defined compound types. Case in point: Lex/Yacc, which use global names (and state) by default.

Now however, instantiation is so pervasive (global variables are assumed evil by default), that we don't even call it OO any more. We just call it good practice.

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

#69

Post by inopinatus »

fjdfhdjldj wrote: post #58
inopinatus wrote: post #49

Earlier quoted context omitted.

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.

why the onus is not on the interviewer? Why is he bringing up chess if he just wants OO answers? Aren't there better problems to pose more suited for testing OO knowledge? Bitboard is a standard way of writing chess engines. I think most would agree that a good programmer is one that seeks the best solution, not one that follows dogmatically his preconceived ideas.

Because you can write an OO domain model using a bitboard representation. It's an opportunity to demonstrate advanced OO knowledge, which this Quora answer most definitely fails at.

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

#70

Post by jgalt212 »

hota_mazi wrote: post #27

It seems nuts to me that anyone would expect the Queen class to extend Bishop just because they happen to move diagonally. A Queen "IS NOT A" Bishop. If anything, specify traits that define the movement of the pieces and have each piece extend that trait (with the Queen extending both CAN_MOVE_DIAGONALLY and CAN_MOVE_LATERALLY).

composition over inheritance

https://en.wikipedia.org/wiki/Composition_over_inheritance

Post reply on HN