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

141–149 of 149 posts

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

#141

Post by jstimpfle »

loup-vaillant wrote: post #139
jstimpfle wrote: post #126

Earlier quoted context omitted.

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…

Sure, there are exceptions. The other side goes the same way: If it's not a static resource, don't make it a global...

> arrays, hash tables, file descriptors

Most arrays / hashtables in my own use are actually static resources as well...

File descriptors, same thing. They are (or correspond to) a process-wide resource managed by the OS. Most maintainable way is to manage them in a global pool.

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

#142

Post by terminalcommand »

watwut wrote: post #136
terminalcommand wrote: post #132

Earlier quoted context omitted.

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

I did not know about your experiences, it comes very strange to me that people on the spectrum can lie. But I can imagine that some people on the spectrum can.

Maybe there is a difference between Autism and Aspergers? Many people on the tech scene start programming at an early age and are obsessed with computers at some point in their lives. Thus many of us at least can relate to people with Aspergers.

Nevertheless, I still think an interviewer should note that the candidate is stubborn or pretentious, rather than just writing "on the spectrum". As you've there could be people on the milder side on the spectrum who could work really well.

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

#143

Post by dragonwriter »

watwut wrote: post #115
fjdfhdjldj wrote: post #83

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.

> Candidate on the spectrum is less suitable for position that requires communication with customer or other people

A candidate with certain communication skills deficits is less suitable for those positions; while that may correlate to some degree with being on the spectrum, it neither necessarily implies nor is necessarily implies by being on the spectrum, and while an interviewer hopefully is qualified to assess that kind of a deficit, they probably aren't qualified to make an ASD diagnosis.

Further, while it's absolutely legal to discriminate on skills, doing so on actual or perceived medical condition is more legally troublesome. So, it's far better all around for the interviewer to confine themselves to observed facts and assessments that are both relevant and that they are qualified to make, rather than playing psychiatrist.

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

#144

Post by eiffel31 »

hota_mazi wrote: post #133
eiffel31 wrote: post #130

Earlier quoted context omitted.

> 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

Thank you, wish Java had this :'(

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

#145

Post by watwut »

terminalcommand wrote: post #142
watwut wrote: post #136

Earlier quoted context omitted.

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

I did not know about your experiences, it comes very strange to me that people on the spectrum can lie. But I can imagine that some people on the spectrum can. Maybe there is a difference between Autism and Aspergers? Many people on the tech scene start programming at an early age and are obsessed with computers at some point in their lives. Thus many of us at least can relate to people with Aspergers. Nevertheless,…

Asperger is now officially just mild Autism. Of course, they can lie, through it is harder for them to lie convincibly.

> Many people on the tech scene start programming at an early age

That has absolutely nothing to do with anything except right kind of adults around..

> and are obsessed with computers at some point in their lives

Sure, just like people in other professions get obsessed over this or that at some point in their lives. And it is not nearly the same as when someone with autism displays that symptome. Healthy person obsession is much different and causes way less difficulties to that person.

> Nevertheless, I still think an interviewer should note that the candidate is stubborn or pretentious, rather than just writing "on the spectrum".

The two are not the same tho.

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

#146

Post by loup-vaillant »

jstimpfle wrote: post #141
loup-vaillant wrote: post #139

Earlier quoted context omitted.

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

Sure, there are exceptions. The other side goes the same way: If it's not a static resource, don't make it a global... > arrays, hash tables, file descriptors Most arrays / hashtables in my own use are actually static resources as well... File descriptors, same thing. They are (or correspond to) a process-wide resource managed by the OS. Most maintainable way is to manage them in a global pool.

I feel we are not talking about the same thing.

There's no question you instantiate a substantial number of arrays and hash tables in your program. Maybe most of them are global variables, but you still spawn several instances of arrays and hash tables. You do not have a single giant array and a single giant hash table, you have several of them.

Same thing with parsers. Lex/Yacc used to allow only one parser of any kind in the whole program. But if you want to parse 2 languages, you need 2 parsers. Of course, you'd need only one parser per language, and perhaps those two parsers parser's state will be stored in global/static variables. You still instantiated 2 parsers.

At least that's how I understand "instantiation".

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

#147

Post by mikekchar »

hota_mazi wrote: post #140
imtringued wrote: post #137

Earlier quoted context omitted.

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

Edit: Sigh... This message is badly written, mainly because I confused your point :-) I'm not quite sure why I was thinking you were arguing that it was not an ISA relationship. In any case, removing my addled brain from the equation is probably useful -- you can probably figure out that there is more than one way to look at this. And while you clearly think that your way is correct, it is useful to view it from other perspectives.

While it is interesting to see your viewpoint, you may also consider that not everybody will see it the same way that you do. For example, why do you suppose that inheritance via composition makes it not an ISA relationship? Is a Swiss Army knife a screwdriver? You may say "no", but others may say "yes" -- it is a screwdriver by way of containing a screwdriver. You can verify this usage of the language simply by listening to sales pitches for the crap they sell on the shopping channel :-) ISA and HASA do not necessarily need to be exclusive properties.

It's easy to get wrapped up in your own definitions of things and to block out how others may view the universe. This is precisely why I originally asked the question. I appreciated the enlightenment. I hope that the above will help you achieve the same.

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

#148

Post by JoshuaDavid »

c22 wrote: post #109
Const-me wrote: post #81

Earlier quoted context omitted.

I don’t know why would you both want to waste so much space? A cell is either empty, or contains one of the 12 figures. To store 13 values, you need 4 bits per cell i.e. 256 bits for the complete board. That’s 4 unsigned longs.

Color is still binary and there are at most 32 pieces on the board, so why not 3 bits per cell and a 32 bit lookup for color? Only 224 bits!

If you're going to go that far, you might as well use 64 bits to say whether each square contains a piece. There are a maximum of 32 pieces, and for each (potentially) occupied square there are 12 possibilities for what might be there (not counting "nothing" as a possibility in a square since that's already covered by the 64 bits indicating whether each square is occupied), which can be represented in 4 bits per square. So that's 64 bits to say which squares have pieces, plus 32 * 4 = 128 bits to say what is in each occupied square, for a total of 192 bits to store the chessboard.

You can take it even further, too. For the 32 possibly occupied spaces, you can encode what is in them as a 32 digit base 12 integer, then convert to binary, which is guaranteed to fit in 115 bits. So you can get away with 115 + 64 = 179 bits.

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

#149

Post by hota_mazi »

mikekchar wrote: post #147
hota_mazi wrote: post #140

Earlier quoted context omitted.

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

Edit: Sigh... This message is badly written, mainly because I confused your point :-) I'm not quite sure why I was thinking you were arguing that it was not an ISA relationship. In any case, removing my addled brain from the equation is probably useful -- you can probably figure out that there is more than one way to look at this. And while you clearly think that your way is correct, it is useful to view it from othe…

> For example, why do you suppose that inheritance via composition makes it not an ISA relationship?

I don't. My other message [1] clearly states:

    class A(b: B) : B by b // IS_A via composition
My point is that inheritance can be achieved in many different ways, composition being one of them.

Inheritance is an architecture concept, composition is a mechanism which can be used to implement inheritance. They are complementary.

[1] https://news.ycombinator.com/item?id=16050458

Post reply on HN