Live data from Hacker News

Is abstraction overrated in programming? Chess, interviews and OOP

quora.com

131–140 of 149 posts

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

#131
post #129
post #34

Earlier quoted context omitted.

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?

Why would that matter? The bitboard representation allows for multiple pawns per column.

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

#132
post #115

Earlier quoted context omitted.

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?

Candidate on the spectrum is less suitable for position that requires communication with customer or other people, that is under stress/pressure, that requires you to interpret ambiguous analysis, cooperate with other departments independently and such.

On the other hand he/she can provide a deeper insight into your work AND be able to communicate. People on the spectrum with a special interest in computers tend to speak like they program a computer: simple, succinctly, efficient.

Another plus side: a worker on the spectrum will most likely not be able to lie to you and will often be completely honest.

Does it really matter, if he/she can't look you in the eye or can't understand the social hierarchy and games played in the office?

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

#133

Earlier quoted context omitted.

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 ?

It's delegation.

Look at page 96 of this PDF file: https://kotlinlang.org/docs/kotlin-docs.pdf

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

#134
post #129
post #34

Earlier quoted context omitted.

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?

A 64bit data type means one bit per field. It is not 8bit per pawn. It does not distinguish between pawns.

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

#135
post #120
post #113

Earlier quoted context omitted.

The point of abstraction is to not be tied to Bitboard--or any concrete representation whatsoever. Chess 2.0 changing its rules is exactly what can be protected against.

Yes in theory. In practice, if code uses a Queen object, you put costly indirections in front of the Bitboard and thus already lost performance.

You assume a Queen object and also some compiler details. These might be in practice relevant some of the time but (a) how often, really? And (b) are those forced decisions or decisions of convenience and momentum?

Fwiw, as soon as you say “object” I’m betting you’re taking on expensive, unnecessary OO mental modeling.

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

#136
post #115

Earlier quoted context omitted.

Candidate on the spectrum is less suitable for position that requires communication with customer or other people, that is under stress/pressure, that requires you to interpret ambiguous analysis, cooperate with other departments independently and such.

On the other hand he/she can provide a deeper insight into your work AND be able to communicate. People on the spectrum with a special interest in computers tend to speak like they program a computer: simple, succinctly, efficient. Another plus side: a worker on the spectrum will most likely not be able to lie to you and will often be completely honest. Does it really matter, if he/she can't look you in the eye or ca…

No they do not speak efficiently and they do to listen efficiently. That is very core of their communication problems. And they are able to lie and they are easy to misinterpret the situation (e.g. their honesty is often not accurate representation of reality).

> Does it really matter, if he/she can't look you in the eye or can't understand the social hierarchy and games played in the office?

No it does not matter whether they look it the eye. Many of them can do that tho. Yes, it does matter that their communication toward junior or customer communicate disdain and lack of regards, to the point where juniors were afraid to speak or have ideas, despite them not really wanting to cause that. It does matter that they confuse own preferences with objectively better. Inability to imagine themselves in shoes of someone else leads to unwanted unfairness.

It does matter that others are suddenly required to put up with insults and have to send a lot of time learning how to communicate and solving problems for that person. All those being symptoms of autism.

Yes, if other collegues have high social skills a lot of that can be mitigated. But when it is not the case, the communication can become quite toxic.

I worked with people on spectrum and they were benefit to the team. But the framing in which they "don't play politics" and thus it is all sun and roses is not accurate. It is naive. You have to learn to predict problems and have to spend additional time to solve them. And you have to put them on position that is not freaking set up to fail.

People with autism suffer from consequences of all that and should be helped. So does often those around them.

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

#137

Earlier quoted context omitted.

No, my observation has nothing to do with composition vs/ inheritance. It's about defining what a class IS vs/ what a class HAS.

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…

People are overthinking this.

In practice inheritance is a very special case of composition that is only advantageous in a very narrow set of usecases. Basically almost never.

In fact the number of usecases is so low that I would prefer that modern languages just omit it entirely because the added value is incredibly tiny compared to the cost of confused developers.

The primary difference between an interface and inheritance is that with inheritance you do not have to implement every method and can use the default implementation of the base class.

Example:

    class Piece {
        int x
        int y
        boolean validMove(int newX, int newY) {
            return false;     
        }
    }

    class Queen extends Piece {
        boolean validMove(int newX, int newY)
        //we use the default implementation
    }
Is equivalent to this

    interface IPiece {
         boolean validMove(int newX, int newY);
    }

    class Piece() implements IPiece {
        int x
        int y
        boolean validMove(int newX, int newY) {
            return false;     
        }
    }

    class Queen implements IPiece {
        Piece piece;
        boolean validMove(int newX, int newY) {
            //we use the default implementation
            return piece.validMove(newX, newY);
        }
    }
Inheritance doesn't actually offer any code reuse. All it does is choose the default implementation of the parent class. If you have dozens of polymorphic functions in a class and only want to change 3 it might be convenient. I would question why you need so much polymorphism to warrant a special language feature. C and Rust developers are fine without it. Functional programmers are fine without it. But for some reason in OOP you need it everywhere and are actually worse off because it's overused.

Modern language designers, please do not implement inheritance of classes in your new languages!

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

#138

Earlier quoted context omitted.

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

Your taxonomy is not useful.

Of course ECS has an object system, it simulates objects. Know of any program whatsoever that simulates stuff without having a stuff system? Does that mean it is Stuff Oriented?

By bundling ECS in the OOP umbrella term, you trivialize the fundamental differences between ECS and class/object hierarchies found in older game engines and Qt, and you water down the "OOP" term to the point of meaninglessness. You wouldn't be the first one to do so.

Anyway, ECS wasn't my main point. My main point was, and remains, when someone mentions "OOP" in Hacker News or /r/programming, unless mentioned otherwise they mean C++/Java most of the time. The most notable exception are discussions over the meaning of "OOP".

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

#139

Earlier quoted context omitted.

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

> The concept of instancing is inappropriate to most situations.

At the application level, maybe. At the library level, this can easily kill reuse. See Lex/Yacc. They used to assume a program would only have one parser. Then some naive developer tried to parse both JSON and Lua tables in the same program. Oops.

Another example: standard libraries (including home grown ones). They instantiate everywhere: arrays, hash tables, file descriptors…

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

#140

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…

People are overthinking this. In practice inheritance is a very special case of composition that is only advantageous in a very narrow set of usecases. Basically almost never. In fact the number of usecases is so low that I would prefer that modern languages just omit it entirely because the added value is incredibly tiny compared to the cost of confused developers. The primary difference between an interface and inh…

> In practice inheritance is a very special case of composition that is only advantageous in a very narrow set of usecases.

You are confused. See my other message below where I show that composition and inheritance are not mutually exclusive (and arguably, the best of both worlds is using inheritance via composition).

Post reply on HN