TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Is abstraction overrated in programming? Chess, interviews and OOP

95 点作者 toAnswerIt超过 7 年前

20 条评论

JoeAltmaier超过 7 年前
Reminds me of an old contest - the 8 Queens problem, posed by Byte Magazine in the &#x27;80s as a programming contest.<p>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.<p>I&#x27;d dismissed that solution as inefficient from the start. Since only one queen can be in each column, I represented the board as an 8-element array with each element containing the row number of the queen in that column.<p>My 2nd insight was, only one queen can be in each row, so the elements of the board array were simply the numbers 1..8. The search consisted of permuting the digits, then testing for diagonals e.g. test pairs to verify abs(difference) != abs(i1-i2). That is, their row numbers were not the same as the difference between their column indexes.<p>Finally, when permuting, you could test the elements as you went and trim the permutation tree drastically if you found a failure. No sense permuting the right-most elements of the array if there&#x27;s already a diagonal conflict in the digits placed so far.<p>The whole thing ran in trivial time. The contest winners ran in hours or days (this was all in BASIC on &lt;1Mhz processors back then). Made me wish I&#x27;d actually entered the contest. But I didn&#x27;t bother, I guessed many people would have found the same solution.
评论 #16048995 未加载
评论 #16048226 未加载
hota_mazi超过 7 年前
It seems nuts to me that anyone would expect the Queen class to extend Bishop just because they happen to move diagonally. A Queen &quot;IS NOT A&quot; Bishop.<p>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).
评论 #16048528 未加载
评论 #16051961 未加载
评论 #16048987 未加载
johnfn超过 7 年前
The OP has translated the interviewers question of &quot;design a readable and maintainable abstraction for a chessboard&quot; into &quot;design the most space-optimized chessboard possible&quot;, then wonders why the interviewer doesn&#x27;t like his solution.
评论 #16048144 未加载
评论 #16048391 未加载
评论 #16048198 未加载
评论 #16048280 未加载
评论 #16048151 未加载
Chriky超过 7 年前
Is this for real? The solution he proposes is <i>specific to Chess</i>!<p>I mean, does this guy really think the company cares about efficiently representing chess game states??<p>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
评论 #16049170 未加载
评论 #16049059 未加载
评论 #16048713 未加载
simonhamp超过 7 年前
Don’t design the abstraction; derive the abstraction from your design if&#x2F;as it naturally becomes apparent.<p>That way you’ll end up with something that works much sooner, instead of getting caught up in designing layers of abstraction.
jstimpfle超过 7 年前
I have no idea what abstraction actually is. It seems to me it&#x27;s never abstraction unless it leads to complicated designs for the simplest problems. I&#x27;ve been accused of hating abstraction because I wrote in C instead and programmed out my own concepts -- instead of just using a ready-made framework with ill-fitting ones (Qt in that case).<p>A much better term than abstraction to me is &quot;semantic compression&quot; (got that from Casey Muratori of Handmade Hero). This basically means factoring out common bits with the goal to express the solution with the least amount of repetition (while of course taking care not to factor out parts which are only coincidentally common. I figure that&#x27;s the &quot;semantic&quot; part).<p>To do semantic compression you need abstraction, but not pointless abstraction -- just the right amount.
评论 #16048045 未加载
评论 #16048029 未加载
评论 #16048430 未加载
评论 #16048332 未加载
评论 #16048154 未加载
评论 #16048118 未加载
coldcode超过 7 年前
Understanding the problem &gt; 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&#x27;t start there then no abstraction will ever save you.
评论 #16049235 未加载
wellpast超过 7 年前
I can relate to the pain of going through an interview knowing that the interviewer is expecting a specific approach&#x2F;answer (an <i>OO</i> answer!) that my hard-won experience has already long ruled out. And morals and&#x2F;or my sense of identity — and&#x2F;or a fear that the Gods are watching — refuses to allow me to play the interviewer’s game (at my own practical loss).
评论 #16048444 未加载
cglouch超过 7 年前
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):<p><a href="https:&#x2F;&#x2F;github.com&#x2F;cglouch&#x2F;snakefish" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cglouch&#x2F;snakefish</a><p>(I cheated a little by not implementing castling &#x2F; en-passant since it&#x27;s a pain, and my engine is still really slow, but hey it works!)
评论 #16049198 未加载
tel超过 7 年前
The Bitboard is very abstract. The interface it instantiates will likely not let leak it’s concise internal representation and will discuss the operations on the game state at a domain level. This is abstraction.<p>So this is a failure of OO abstraction. Why? OO abstraction is really complex and makes many forced moves that provide little value here. Inheritance and a focus on “nouns” makes idiomatic code highly specialized to certain domain models. Unfortunately, these are rarely useful.
评论 #16048445 未加载
wellpast超过 7 年前
The CPU does not care about your abstractions. Abstractions are entirely wrt the human dealing with them. A good abstraction is only “good” with respect to some context&#x2F;purpose—there is no such thing as a universally&#x2F;generally good abstraction. And often a “great” abstraction will hurt your performance — so then is it so great?<p>But setting aside performance concerns, when we speak of a “good” abstraction we are usually (or should be) saying this is good for some <i>purpose</i>—good for readability, for example.<p>But even better—or of utmost importance in the real world-is this: is the abstraction under question “good for business”? And that is entirely asking this: does the abstraction allow for rapidly <i>acting</i> on business ideas, creativity, needs, etc.<p>However, I believe that once the context is fixed&#x2F;agreed upon, that there is an objective answer to which of this or that abstraction is better. However experience in the practical world of today’s software development painfully has shown me that the “better” abstractions are harder to come by...and when “found”, don’t tend to stick. This is because most practitioners don’t have the ability to produce powerful algebraic systems (which is what “good” abstractions are—“alegebras” over a business domain) because practitioners are generally not mathematicians, even have a philistine dislike&#x2F;disdain for powerful systems if they have a whiff of mathematical-like power to them at all.<p>In this sense one could argue for an abstraction being “good” with respect to the social context in which they are operated in (i.e., if your team members don’t understand how to correctly wield an abstraction, is that abstraction good?) However I don’t like these kinds of arguments bc a lesser system is still capped in its power even if all its users understand it.<p>There are limits in what you can do with, say, Euclidean Geometry, even if it is much simpler to understand than other Gemotries. An often retort to this is No it isn’t. But that usually comes form perspectives with limited imagination. That said, many businesses are fine and thrive with limited imaginations.
评论 #16048613 未加载
评论 #16048491 未加载
评论 #16048506 未加载
ZirconiumX超过 7 年前
My opinion is that this post reaches the same conclusion as I would, but I disagree with the logic behind it.<p>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).<p>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.
valuearb超过 7 年前
“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&#x27;t need an object model to simply reuse some functions to calculate legal moves given a position. Just a few global functions.”<p>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 state, or their moves to streams to play remotely?<p>All of these things can be done procedurally, but they also fit nicely into an OO design.
评论 #16048817 未加载
评论 #16048790 未加载
payne92超过 7 年前
Oh Dear Lord.<p>Programming IS abstraction.<p>In fact, that&#x27;s pretty much ALL programming is: using, defining, and implementing abstractions.
评论 #16048004 未加载
评论 #16047957 未加载
_yawn超过 7 年前
The whole point of abstract data types is to separate implementation from interface in order to allow a change in representation.<p>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.<p>Abstraction does not hinder ideas like the bitboard, it enables them. Both the interviewer and the interviewee are missing the point.
c22超过 7 年前
I don&#x27;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).
评论 #16049077 未加载
评论 #16048871 未加载
jancsika超过 7 年前
The class-based solution provides more information about the developer&#x27;s approach than the single struct for the BitBoard.<p>For example, where would the equivalent of &quot;findMoves&quot; be declared in the latter case? Is the bitmath abstracted out into a set of helpers, or is it done in one big function?
petters超过 7 年前
Why do all the boards need to be kept in memory during the search?
评论 #16051655 未加载
评论 #16048541 未加载
moomin超过 7 年前
I’m a bit concerned with the bitboard representation. What happens when a pawn takes another piece?<p>Edit: The above is what I would say if someone presented this approach in an interview.
评论 #16048410 未加载
评论 #16048311 未加载
fastcum超过 7 年前
for the ones interested here is a great resource list about bitboards in chess <a href="https:&#x2F;&#x2F;chessprogramming.wikispaces.com&#x2F;Bitboards" rel="nofollow">https:&#x2F;&#x2F;chessprogramming.wikispaces.com&#x2F;Bitboards</a>