Is abstraction overrated in programming? Chess, interviews and OOP • Hacker News Board

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

#41

Post by wellpast » Mon, Jan 01, 2018, 10:57 PM UTC

agarden wrote: post #36

wellpast wrote: post #30

I can relate to the pain of going through an interview knowing that the interviewer is expecting a specific approach/answer (an OO answer!) that my hard-won experience has already long ruled out. And morals and/or my sense of identity — and/or a fear that the Gods are watching — refuses to allow me to play the interviewer’s game (at my own practical loss).

I don't quite understand. If I were interviewing the OP and asked this chess question, then got his answer presented much like it was on Quora ("Well, the thing to understand about representing a chess board is that if you want to build a usable chess engine, the size of chess board representation is a critical constraint..."), I would be impressed. Hire that guy. He understands that the important thing is to figure…

I agree w/ you. So in that sense it’s not truly at my loss—that part I was being (somewhat) rhetorical about.

However it has definitely been the case where I’ve contended with some Senior Engineer who has found the light in OO programming, inheritance, Template Method, etc, etc and no amount of dialectic will change his mind.

This programmer often doesn’t see the severe impedance that his OO code, his type hierarchies, etc are causing to agile delivery of the new and newer software. How do you show an OO-religionist...the light, so to speak? These quesitions are not easy to get into a lab and give him the hard numbers.

Just an example here: Matrix algebra is easiest done with first-class matrix abstractions. So my compeer puts everything into some other abstraction. And I say, look, look how much easier it is to do our work when our data is modeled differently? And he says “that’s not easier” — okay, you are objectively right, but your peer doesn’t “see it” or refuses to see it, or what, I don’t know— but this is almost de facto industry situation—you can’t prove that your ergonomics are better because your peer doesn’t even speak in proofs anyway.

Now I could go find another job but my equity is actually worth something here (it really is), so I put up with it. But it’s frustrating nevertheless-and having a better abstraction only costs my coworker to learn something. It’s not going to make my equity any less valuable—might make it more valuable, if anything.

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

#42

Post by seanmcdirmid » Mon, Jan 01, 2018, 10:58 PM UTC

macintux wrote: post #39

Veedrac wrote: post #11

Earlier quoted context omitted.

IMO, the key issue is to differentiate between abstractions in language-space and abstractions in problem-space. Turning a chess board into an object is language-space, since it affects vocabulary; writing a function to count the pawns is problem-space, since it defines a step towards the problem one wants to solve. Nobody programs without problem-space abstractions any more; this is effectively what you get with fun…

> If they did, Haskell programmers would be so much higher productivity than C programmers that the latter would be simply competed out of the market. That implies a much smarter market than I believe exists. I think it’s possible (not arguing it’s true) that Haskell is dramatically better yet entrenched interests (e.g., managers afraid of not being able to find programmers, and programmers afraid of being obsoleted)…

I’m pretty sure most of the Haskell crowd doesn’t believe this. There are benefits to learning, thinking in, and using Haskell, but raw easily measured productivity increases isn’t one of them (nor is it for almost any other programming language).

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

#43

Post by qznc » Mon, Jan 01, 2018, 10:58 PM UTC

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

Yes. A similar way to argue is Liskov's substitution principle [0]. It is easy to come up with properties that always hold for bishops, but not for queens. For example, bishops never move from black to white fields or vice versa.

[0] https://en.wikipedia.org/wiki/Liskov_substitution_principle

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

#44

Post by wellpast » Mon, Jan 01, 2018, 11:00 PM UTC

seanmcdirmid wrote: post #40

wellpast wrote: post #33

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/purpose—there is no such thing as a universally/generally good abstraction. And often a “great” abstraction will hurt your performance — so then is it so great? But setting aside performance concerns, when we speak of a “good” abstraction we are usual…

Great abstractions are not always algebraic. Words and vocabulary are incredibly successful as abstractions, as are ontologies. In fact, an entire programming paradigm has been constructed around such abstractions and has been reasonably successful.

Words and vocabulary aren’t enough. Not the colloquial/dictionary sense, at least.

So if we’re talking about “facts” in an “ontology” — these are still (they must be if they are going to be processed by a machine) concrete formalisms - that’s what I mean by algebras.

If we are not machine-processing these ontologies but just printing them out for users, then I don’t count that. Because we’re not really programming over those abstractions. We’re just giving them back to the humans.

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

#45

Post by qznc » Mon, Jan 01, 2018, 11:01 PM UTC

petters wrote: post #28

Why do all the boards need to be kept in memory during the search?

Not really necessary, but the primary goal is to make the search fast. Storing the boards elsewhere would probably be slower.

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

#46

Post by seanmcdirmid » Mon, Jan 01, 2018, 11:06 PM UTC

wellpast wrote: post #44

seanmcdirmid wrote: post #40

Earlier quoted context omitted.

Great abstractions are not always algebraic. Words and vocabulary are incredibly successful as abstractions, as are ontologies. In fact, an entire programming paradigm has been constructed around such abstractions and has been reasonably successful.

Words and vocabulary aren’t enough. Not the colloquial/dictionary sense, at least. So if we’re talking about “facts” in an “ontology” — these are still (they must be if they are going to be processed by a machine) concrete formalisms - that’s what I mean by algebras. If we are not machine-processing these ontologies but just printing them out for users, then I don’t count that. Because we’re not really programming ov…

Instructing someone how to do something and the computer how to do it is basically the same thing. Yes, humans have more latitude in how they follow instructions, but the same skills ofnabsteaction are applied. The whole point about OOP is that you could still weild abstractions without being a mathematician.

Now, how often do people learn chess algebraically?

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

#47

Post by chrisweekly » Mon, Jan 01, 2018, 11:18 PM UTC

wellpast wrote: post #33

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/purpose—there is no such thing as a universally/generally good abstraction. And often a “great” abstraction will hurt your performance — so then is it so great? But setting aside performance concerns, when we speak of a “good” abstraction we are usual…

>"The CPU does not care about your abstractions. Abstractions are entirely wrt the human dealing with them."

Yes!

>"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson, preface to [SICP](http://mitpress.mit.edu/sicp/full-text/sicp/book/node3.html)

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

#48

Post by inopinatus » Mon, Jan 01, 2018, 11:26 PM UTC

smallnamespace wrote: post #15

johnfn wrote: post #13

The OP has translated the interviewers question of "design a readable and maintainable abstraction for a chessboard" into "design the most space-optimized chessboard possible", then wonders why the interviewer doesn't like his solution.

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.

GP is correct. The Quora answer has a false dilemma that you've just perpetuated here, viz. that an OO program cannot use a compact representation. But there are standard patterns for using a compact representation of data for domain-model objects.

The article's author isn't just unaware of them, they've written a petulant, arrogant article demonstrating their own lack of experience and adaptability.

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

#49

Post by inopinatus » Mon, Jan 01, 2018, 11:42 PM UTC

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.

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

#50

Post by lozenge » Mon, Jan 01, 2018, 11:43 PM UTC

smallnamespace wrote: post #15

johnfn wrote: post #13

The OP has translated the interviewers question of "design a readable and maintainable abstraction for a chessboard" into "design the most space-optimized chessboard possible", then wonders why the interviewer doesn't like his solution.

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.