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

121–130 of 149 posts

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

#121

Post by rrobukef »

loup-vaillant wrote: post #82
inopinatus wrote: post #48

Earlier quoted context omitted.

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.

I'm interested. Care to elaborate how an OO approach could yield a compact representation in this particular case?

A facade wrapping the representation would sufficiently transform the paradigm?

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

#122

Post by seanmcdirmid »

loup-vaillant wrote: post #117
seanmcdirmid wrote: post #106

Earlier quoted context omitted.

I prefer the Treaty of Orlando, which is much more inclusive, and underlies our entire community. http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla... It is scary that the broad definition given in the 80s has been supplanted by a narrow “java or C++” definition today. If that what you mean by it, then no we aren’t talking about the same thing. I’ve built plenty of OO systems that don’t correspond to that…

When I see "OOP" in a forum today, I assume it means the narrow "Java or C++". And I think that more than 90% of the time, I'm right. If you want to use a different, perhaps better, definition, the onus is on you to mention that you don't talk about the same thing as everyone else.

So in your view, Self isn’t OO? There is a rich diversity in the object community, there always has been.

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

#123

Post by lozenge »

petters wrote: post #28

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

Having read a python implementation of bitboards in the thread, I believe it's for search pruning. If you search many of the boards after three moves, then there will be some duplicates. Preferably each board should only be evaluated (for which player it favours) once and that can be done by storing them in a hash table or similar structure, which requires storing the board.

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

#124

Post by loup-vaillant »

seanmcdirmid wrote: post #122
loup-vaillant wrote: post #117

Earlier quoted context omitted.

When I see "OOP" in a forum today, I assume it means the narrow "Java or C++". And I think that more than 90% of the time, I'm right. If you want to use a different, perhaps better, definition, the onus is on you to mention that you don't talk about the same thing as everyone else.

So in your view, Self isn’t OO? There is a rich diversity in the object community, there always has been.

I didn't say that. Obviously, if you're talking about OO and mention Self in the same sentence, then you mean OO to encompass prototypes. But if you do not mention Self, don't be surprised when most people think you meant C++/Java.

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

#125

Post by loup-vaillant »

jstimpfle wrote: post #119
dragonwriter wrote: post #112

Earlier quoted context omitted.

> 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. Often, because the assumption that it can exist only once is wrong ; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which c…

> Often, because the assumption that it can exist only once is wrong; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which covers all of your examples. The key here is how to understand the word "can". It's "only" a design decision! Of course you can do almost anything on a computer. However, most programs don't make sense with two sound modules or netw…

Most VR games make sense with 2 displays (Headset + screen), and 2 sound systems (binaural for the headset + stereo for the audience). You'd likely know that from the outset, though.

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

#126

Post by jstimpfle »

loup-vaillant wrote: post #125
jstimpfle wrote: post #119

Earlier quoted context omitted.

> Often, because the assumption that it can exist only once is wrong; this is particularly true of instances of some descriptive class of interface to an external hardware resource, which covers all of your examples. The key here is how to understand the word "can". It's "only" a design decision! Of course you can do almost anything on a computer. However, most programs don't make sense with two sound modules or netw…

Most VR games make sense with 2 displays (Headset + screen), and 2 sound systems (binaural for the headset + stereo for the audience). You'd likely know that from the outset, though.

Yes - and for each of these examples, there would likely be still a single "object instance" managing these devices (e.g. "Display" module). Or two entirely different modules ("Headset" module + "Screen" module), again each having only a single "instance".

The concept of instancing is inappropriate to most situations. The things that we have more than one ("dynamically many") instances from are typically dead data, but then again these are typically managed in a single pool. (That's "tables", again).

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

#127

Post by wbkang »

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

It is reasonable for implementation re-use (subclassing) but it flunks the subtyping aspect.

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

#128

Post by seanmcdirmid »

loup-vaillant wrote: post #124
seanmcdirmid wrote: post #122

Earlier quoted context omitted.

So in your view, Self isn’t OO? There is a rich diversity in the object community, there always has been.

I didn't say that. Obviously, if you're talking about OO and mention Self in the same sentence, then you mean OO to encompass prototypes. But if you do not mention Self, don't be surprised when most people think you meant C++/Java.

We aren’t really arguing about that though. When people exclame that OOP is dead, they use Java/C++ as their strawmen, but that doesn’t mean objects are intrinsically flawed or really dead. It’s like declaring you hate FP because Haskell isn’t to your liking.

My original comment was that ECS is just another kind of object system. It has objects, it conforms to ontological object thinking, why would that not be OOP? Just because it isn’t Java/C++? Or would you argue that OOD and OOP are separate things?

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

#129

Post by moomin »

qznc wrote: post #34
moomin wrote: post #16

I’m a bit concerned with the bitboard representation. What happens when a pawn takes another piece? Edit: The above is what I would say if someone presented this approach in an interview.

Let's say black pawn takes the white queen: Unset the bit representing this black pawn, set the bit where the black pawn is now, set the white queen long to zero. One load and two write operations to memory. The bit fiddling is probably neglible in terms of time on a modern CPU.

So here's the second question I'd ask: what happens if there was already a black pawn on the white queen's column?

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

#130

Post by eiffel31 »

hota_mazi wrote: post #114
mikekchar wrote: post #110

Earlier quoted context omitted.

It's hard to ask this question without sounding snarky, but I hope you will understand that I'm seriously curious to hear what you think. > No, my observation has nothing to do with composition vs/ inheritance. > It's about defining what a class IS vs/ what a class HAS. What do you feel is the difference between these two sentences? In other words, why is inheritance vs composition not the same as what a class is vs…

These concepts are orthogonal. I can use composition and inheritance to define an IS_A relationship and I can use them to define a HAS_A relationship. For example, in Kotlin: class A : B // IS_A via inheritance class A(b: B) { // HAS_A via composition class A(b: B) : B by b // IS_A via composition

> class A(b: B) : B by b // IS_A via composition

I couldn't find the "B by b" syntax from the Kotlin docs, can you tell me that this does ?

Post reply on HN