John Locke says, and Im paraphrasing:
Seperating something from all else that accompanies it in its real existence
I’m thinking primarily about the comp.sci angle for this question
A generalization/simplification so you can talk about something more broadly without getting into the weeds on irrelevant specifics.
Think of Parmesan cheese or Pecorino. Those are concrete, specific cheeses, but you can generalize to talk more broadly about what that class of thing of is like. “Hard cheese”, for example, is one way of moving from the concrete to abstract. You can talk about all hard cheeses generally knowing that substituting in a specific hard cheese like Parmesan will work (i.e. there’s an “is a” relationship like “Parmesan is a hard cheese”) – e.g. you can grate it; this is the basis of interfaces/class-based inheritance in CS. You make an abstract class or interface that specifies how you can interact with that class of thing and then any specific implementation that you make or encounter later can plug in where you’ve written code to work with the abstract idea.
Does that answer your question – at least for the CS side?
So an abstraction essentially an interface for dealing with a thing when the first principles of it are already encoded and embodied by the functionality it offers, that can be intuited to have implemented?
Like, it “takes care of” the why/how so you can focus on the what?
Edit- its funny you mention interface because that was like thr first word my brain was reaching for. Like the console on a car is an abstraction of various functions of a car, its an interface that lets you control the speed, windshield clarity/visibillity, communication to other cars of intentions, etc without needing to understand how any of it is programmed or implemented per se
More or less; the implementation doesn’t have to already exist when the abstraction is defined. You can make more implementations later. Consider the case of files – we used to read them mostly from tape, and then later floppy disks, HDDs, SSDs… now we’ve got NVME, and who knows what else in the future.
Usually an abstraction hides the details of how exactly some operation is performed so you can work at a higher level.
In the case of a file on a hard disk, you don’t need to think about how to move motors or interpret the pattern of oscillations of magnetic orientation on a metal plate to work with it. You work at a more abstract level that gives you methods like open and read and seek over a linear block of bytes. When you swap out the HDD for an SSD code that works with “files” still works even though at the low level there are no more motors and you’re dealing with electrical signals and flash memory chip controllers under the hood.
That same code will likely still work if we come up with some crazy 3D memory crystal technology that lets you fit petabytes in your pocket, or some bizarre biological computer that lets you encode data in DNA; as long as you can access it with
openandreadyou don’t have to care what’s going on under the hood… mostly.It is worth noting that a lot of abstractions are leaky. We try to paper over the differences so you don’t have to think about the full complexity of what’s going on, but sometimes you can’t quite get away from those details…
When you start looking at files in terms of operations like open, read, write, close… then you realize you can make things like network requests using the same interface. Network requests tend to fail unpredictably much more often than reads and writes from a local HDD or SSD though, so Network File Systems often have strange and annoying behaviors where that underlying reality causes problems with assumptions that seemed reasonable to the authors of software who thought they were working with local files… (If you’ve ever had your entire desktop freeze up because your organization set up /home as a network mount which became temporarily inaccessible, or run into
sudorefusing to operating on a file because the remote end does not have permission to access it… you’ve seen that leakiness in practice!)Also, Unix famously popularized the “everything is a file” idea – which works for way more things than you might expect. I can open a “file” on my computer and read a sequence of joystick positions back out of it as they’re generated in real time… but I can’t seek backwards or forwards. I can open files under
/sysor/procand write changes into “files” that immediately affect things like the maximum power that my GPU can use and affect running programs in complex ways! The OS exposes those operations through a file-like interface to make it easy for any tool that works with files to interact with.
In programming an abstraction is something the “hides” the implementation details and exposes something more “human friendly”. For example a file is an abstraction for the 0s and 1s on the disk.
