[jstimpfle]

I have no idea what abstraction actually is. It seems to me it's never abstraction unless it leads to complicated designs for the simplest problems. I'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).

A much better term than abstraction to me is "semantic compression" (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's the "semantic" part).

To do semantic compression you need abstraction, but not pointless abstraction -- just the right amount.

[Veedrac]

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 functions and libraries. When someone uses a prebuilt tangent function, that's working in problem-space.

Language-space abstractions don't pull the same weight. 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. Instead we see marginal benefits against marginal costs, and the gamut of C, C++, Go, Haskell, Python, Javascript, etc. are, if not equally good, at least sufficiently similar that there is genuine debate.

If in doubt, abstract the problem. If you do an abstraction and don't have less work to do afterwards, maybe you've abstracted the wrong thing.

[macintux]

> 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) block the logical conclusion.

[seanmcdirmid]

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

[mabbo]

Abstraction, to me, is not about reducing lines of code but reducing cognitive load by hiding complexity. I don't need to know what kind of list, or how the list is implemented, I just need to know it's a list of some sort and has the usual list interface.

For example, I recently needed to randomly reorder a collection of objects, weighting some of them more heavily than others such that 'heavier' objects are more likely to come first. My first implementation was a mess, and was hard to test. So I created an abstract data structure that allowed inserts with weights and polls for a random value, applying the weighting. My business logic could use that abstract thing presuming it worked. The tricky part was hidden, and the code was cleaner.

In the case of the article, the abstraction the interviewer wants doesn't actually make the code clearer. It's just looking for checking off check boxes that the candidate wrote the word 'class' and jumped through the hoops the way the interviewer expected.

[yason]

Abstraction is a tool to help in your thinking. The abstractions that are useful or needed depend on what you're doing. An abstraction is basically a license to not care about the details once you have sufficient proof that you can do so within relevant limits.

All work has abstractions, even physical work. Consider a hand saw. In detail, its operation and efficiency relies on the teeth, their angle and sharpness in relation to what you're sawing. But the abstraction is that you can take a hand saw, place it onto a tree branch or wooden plank, and start moving it back and forth until the cut is complete. Surely some of the teeth will be worse than others and eventually they will be so blunt that the abstraction fails and you cannot complete the cut until you sharpen the saw. But in the average, the abstraction of sawing works for hours and hours, generally days and days, in a row.

Having such an abstraction elevates our thinking to consider different ways to cut wood, make joints, fitting ends, etc. That is all possible only because of the abstraction of how a saw works: it frees you from thinking about how the saw operates while using it and using those mental cycles to think about what you want to saw and how.

Programming is the same. There are abstractions for modelling the problem, there are abstractions for building the program, there are abstractions for data presentation and flow, and the whole computer you're using is a huge stack of abstractions so that when you press 'b' the letter will appear on your screen as 'b' no matter what the hardware and system your computer is running.

Sometimes —— actually more often than not —— abstractions are an easy way to add useless complexity. It usually happens when you don't yet know how to solve a problem, so you first abstract it to finish something else and effectively post-pone the hard problem further. The problem is you can do it again, and then again.

When you finally do get around to solving the big problem you already have an interconnected mesh of various abstractions and mechanisms in place —— those that you concocted at the time you were still guessing what the solution might look like —— and you have to retrofit the correct solution on top of those.

Ideally you would've solved the hard part first at which point you'd already know which abstractions, if any, you will need to efficiently express the problem and the solution in simple and understandable terms.

[qznc]

Instead of "semantic compression" I use "chunking". https://en.wikipedia.org/wiki/Chunking_(psychology)

[JepZ]

Well, I think the lack of a definition for what is meant by abstract or abstraction is critical. For example there is some discussion of an abstract base class but the article keeps missing that in Object Oriented Programming the term abstract class exists. It describes an 'incomplete' class which cannot be used to instantiate objects but can be used to hold common behavior.

http://www.javacoffeebreak.com/faq/faq0084.html

[johnwatson11218]

what about just calling it "slang"?