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

71–80 of 149 posts

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

#71

Post by perl4ever »

JoeAltmaier wrote: post #2

Reminds me of an old contest - the 8 Queens problem, posed by Byte Magazine in the '80s as a programming contest. All the solutions presented started by declaring an 8X8 board, with a 1 or 0 in each cell to represent a queen. Then there was some two-dimensional iteration over the board, testing if any queen was on the same row, column or diagonal as any other. I'd dismissed that solution as inefficient from the start…

I entered a programming contest once, where the task was to take some input and construct an optimal solution to a geometric problem. I got irritated at the rules not being clear and well thought out, and I wasn't smart enough to work out a good implementation of the real-world algorithm they were hoping contestants would come up with. So I wrote code to provide pretty much the stupidest (most trivial) possible solution that fulfilled the specific constraints for a valid output that were stated. Because entrants were scored on a combination of speed, code size, and quality, my entry came in a close second, because it was by far the smallest and fastest. I kicked myself for not trying harder to optimize the quality even a little bit above "braindead".

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

#72

Post by jstimpfle »

valuearb wrote: post #67
jstimpfle wrote: post #56

Earlier quoted context omitted.

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

Come on, please don't claim that you need to add more piece types independently so absolutely need virtual functions. That's hilarious for a chess game (and most other applications), but even if that was needed, one could still pass function pointers in those few places.

Anyway: No, they design their program to be efficient and readable. There is more often than not an alternative to switch statements: don't mix data of different types together. (Where by types I don't mean crazy artificial types built with a modern language -- but with regards to implementation of a functionality).

If this is about drawing chess pieces, you need only a single draw function for all of them. Just maintain a table that maps a piece to its material (sprite, mesh, whatever). Or alternatively, have a table that maps pieces to "types" and another static one that maps these types to materials. (Much better: Materialized type to simple enum. Can actually use this information, as opposed to overhyped static types).

More general answer: The best way to do it is usually not a switch statement but a data table. Because usually the switching is not about behaviour, but about data. (Not that switch statements are so bad).

Code gets so so simple, robust, and maintainable if developers are not preconcerned about static types, OO, and whatnot.

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

#73

Post by fjdfhdjldj »

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?

for each type of piece if the bit is set, draw the piece at that position.

if you click on a square and there is a piece in that square( there is a bit set in that position in any of the types), get the valid moves and draw them.

if then you click an empty valid space, render the piece moving.etc..

most of the details are usually hidden behind functions. You renderer should not care about the internal representation of your data.

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

#74

Post by Silhouette »

valuearb wrote: post #67
jstimpfle wrote: post #56

Earlier quoted context omitted.

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

I'm not sure why that's apparent, but even if it is, is there any reason to believe that switch statements (or pattern matching, or look-up tables, or other related language constructs) couldn't handle any plausible requirement in this case?

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

#75

Post by flavio81 »

loup-vaillant wrote: post #68
fjdfhdjldj wrote: post #54

Earlier quoted context omitted.

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 loc…

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

You can have the same in functional programming, by creating closures on demand.

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

#76

Post by loup-vaillant »

valuearb wrote: post #66
christophilus wrote: post #60

Earlier quoted context omitted.

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 g d mn interviewer wanted you to demonst…

I'd rather fail the interview than work for the one who failed me in this case.

Assuming I am asked to design something in a domain I am familiar with, where an OOP-looking solution is not a good approach, I will simply go with a good approach instead. If this triggers a discussion, wonderful. If the interviewer assumes I don't understand OOP, shame on them for not explicitly asking for an OOP design in the first place. And if the interviewer suggests I should go for an OOP design instead of my solution, I will contradict them on the spot —politely. I may comply for the sake of the exercise, but will repeat and insist that there are better approaches to this class of problems —politely.

More generally, I am highly sceptical of claims that OO designs are in general easier to understand, maintain, and extend (this includes this chess example, where I believe the bit-board approach is competitive even for variable board sizes). They're often not, if only because being OO for the sake of it tends to generate more code. More code to understand, more code to debug, more code to extend… you get the idea.

I also tend to believe OOP is not the best approach for most problem domains, possibly even including GUI (I have yet to study this in detail). I'd rather not work for shops that insist on using OOP everywhere.

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

#77

Post by jstimpfle »

loup-vaillant wrote: post #68
fjdfhdjldj wrote: post #54

Earlier quoted context omitted.

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 loc…

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

This is another one of my pet peeves... If it's global (a static resource), make it a global. Local variables for static resources make code so much less readable. The only argument against globals is testing, and that's only an argument because common OO languages have no support for resetting global "objects"! Solution: Just don't use OO syntax in the first place - it's wrong. Just write init() and exit() functions.

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

#78

Post by loup-vaillant »

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

> Is this for real? The solution he proposes is specific to Chess!

Some aspects of his solution aren't. He just took a holistic approach instead of the classic reductionistic/analogy-with-not-so-real-world one. Holistic approaches are applicable to much more than chess. Game engine for instance often benefit from Entity Component Systems, which are effectively in-memory domain specific databases, quite unlike OOP. More generally, the Data Oriented Design from Mike Acton is applicable in any setting where performance matters. Another example is functional programming, highly suited to data transformation and symbolic processing, such as found in compilers and interpreters (probably not he high-performance ones, though).

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

#79

Post by loup-vaillant »

inopinatus wrote: post #69
fjdfhdjldj wrote: post #58

Earlier quoted context omitted.

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.

I'm interested. Care to elaborate how this OO domain would look like?

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

#80

Post by seanmcdirmid »

loup-vaillant wrote: post #78
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

> Is this for real? The solution he proposes is specific to Chess! Some aspects of his solution aren't. He just took a holistic approach instead of the classic reductionistic/analogy-with-not-so-real-world one. Holistic approaches are applicable to much more than chess. Game engine for instance often benefit from Entity Component Systems, which are effectively in-memory domain specific databases, quite unlike OOP. Mo…

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 modeling and design, a way to talk about a problem using language that is more similar in how you might talk about it naturally. Object-thinking is much more important than anything else. There are many different ways to spin this, but most game engines and simulation environments benefit from this in spades (and have ever since Simula 2).

Post reply on HN