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

91–100 of 149 posts

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

#91

Post by inopinatus »

fjdfhdjldj wrote: post #83
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.

sorry for going off-topic but I couldn't shake out of the back of mind. you said "candidate may be on the spectrum", do you discriminate against people based on their medical conditions?

Actually the opposite. Best practice is to correct for them once you realise they may be affecting someone's interview performance. As represented, this interviewer failed to do so.

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

#92

Post by loup-vaillant »

flavio81 wrote: post #75
loup-vaillant wrote: post #68

Earlier quoted context omitted.

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.

As a long time FP advocate, I know. Instantiation just happens to be one of the things OOP claimed, for a time, to be the sole purveyor of.

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

#93

Post by jstimpfle »

dragonwriter wrote: post #86
jstimpfle wrote: post #77

Earlier quoted context omitted.

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

> The only argument against globals is testing No, the newer argument against globals is testing, but that's mostly a side effect of the older issue, that globals limit composability/reusability, which was the main objection to globals before TDD became a popular religion.

The "reusability" argument is just as wrong... True reusability (without any changes) is not possible in most cases anyway, and furthermore I don't see a reason why surrounding some static object (which can only exist once in a program, like a sound module, a network module, etc) with braces and a "class" keyword would somehow increase this vague idea of reusability.

It's only a syntactic change. It's not changing what should actually happen. It's just making it less readable. How in the world can that be an improvement on any frontier?

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

#94

Post by mratzloff »

cglouch wrote: post #19

in case anyone was curious how a bitboard chess engine works, I wrote one from scratch in python and included a writeup describing my general approach (mostly focused on the move generation aspect): https://github.com/cglouch/snakefish (I cheated a little by not implementing castling / en-passant since it's a pain, and my engine is still really slow, but hey it works!)

That was really interesting. Thanks for sharing!

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

#95

Post by loup-vaillant »

jstimpfle wrote: post #77
loup-vaillant wrote: post #68

Earlier quoted context omitted.

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…

Of course, I would use a global whenever appropriate. But I would try and limit the number of entry points to that global (for instance by limiting its scope, or putting a big fat comment about how we're supposed to use it), so I don't end up making implicit data dependencies spaghetti.

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

#96

Post by loup-vaillant »

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

Earlier quoted context omitted.

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

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

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

#97

Post by ZirconiumX »

coldcode wrote: post #4

Understanding the problem > any abstraction you pick without understanding the problem first. In this case chess was a terrible choice for an interview. In chess the biggest issue is tree size. If you don't start there then no abstraction will ever save you.

I'm going to disagree with you here. In chess the problem is not about reducing the tree size: you can get a "tree" by picking random moves. The problem is about reducing the tree size intelligently.

My chess program - Dorpsgek - has an 800 byte board structure (though I recently reduced that to about 400). It uses techniques that the computer chess community considered to be impractical. But still it works, and it works because the space that I use per board contains very useful information, such as attacks to a given square.

The advantage that bitboards give are not space by any meaningful quantity - for an alpha-beta search of depth d with a branching factor of b you will allocate at most d boards - or even 1 board - at any given node, not b^d boards. The advantages that bitboards give are speed and information density.

And to anybody who thinks that a bitboard approach is not sufficiently generic for different board sizes, wrap the bitboard using an arbitrary size bit set and the problem is essentially solved.

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

#98

Post by jstimpfle »

loup-vaillant wrote: post #95
jstimpfle wrote: post #77

Earlier quoted context omitted.

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

Of course, I would use a global whenever appropriate. But I would try and limit the number of entry points to that global (for instance by limiting its scope, or putting a big fat comment about how we're supposed to use it), so I don't end up making implicit data dependencies spaghetti.

One should always avoid unnecessary dependencies. But I don't use special syntax or complicated scope rules to achieve that. This only makes the code more complex.

No -- I just don't depend. I don't reference the global where it's not needed. Simple :-)

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

#99

Post by loup-vaillant »

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

Earlier quoted context omitted.

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

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 interface to a compact representation.

Post reply on HN