> See, this is a mistake. Abstraction is not an end in itself; it's there to make life easier and to make things easier to undestand.
This idea is often repeated in programmer's forums, yet I think it's simply not true. Abstraction is not there to make things easier to understand, it is there to empower you _after_ you understand the abstraction. It is there to pack the knowledge you _already have_ after working with some system, and being able to port it to similar systems.
Let's take math as an example. Understanding the "+" operator is much harder than understanding that if you have two apples and you get another one, then you have three apples. However, once you grasp the "+" operator, you can quickly solve a bunch of related problems where the "+" operator applies.
This does not mean that I disagree with the rest of your comment though. Java's (classical) means of expressing abstractions are fairly limited - basically, you need _interfaces_ for everything. In most cases, this leads to a lot of cognitive overhead that obscures the essence of the abstraction being used.
A simple example of this problem is the lack of function values and lambda types (pre jdk8). Due to these missing features, people expressed the same abstractions by defining interfaces that define some method, and then providing implementations as anonymous classes. That is, instead of defining a function type and then just implementing it, you now have an interface and weird class declarations in your code. To the untrained eye, this is much harder to understand. As a result, some of the programmer's cognitive effort is now spent on this, and hence it becomes harder to understand the more useful part of the code (which is likely some kind of abstraction).
Just to shed some more light into this, consider Haskell's _monads_. Monads are very hard abstractions to grasp. They are much harder to understand than just "doing whatever you want to do and call it a day". However, they become extremely useful once you understand the abstraction and become available to use it without the cognitive overhead.
> Abstraction is not there to make things easier to understand, it is there to empower you _after_ you understand the abstraction. It is there to pack the knowledge you _already have_ after working with some system, and being able to port it to similar systems.
I think some abstractions exist for either reason, and some for both reasons, but either way thanks for saying it this way - you definitely put it better than I did.
This idea is often repeated in programmer's forums, yet I think it's simply not true. Abstraction is not there to make things easier to understand, it is there to empower you _after_ you understand the abstraction. It is there to pack the knowledge you _already have_ after working with some system, and being able to port it to similar systems.
Let's take math as an example. Understanding the "+" operator is much harder than understanding that if you have two apples and you get another one, then you have three apples. However, once you grasp the "+" operator, you can quickly solve a bunch of related problems where the "+" operator applies.
This does not mean that I disagree with the rest of your comment though. Java's (classical) means of expressing abstractions are fairly limited - basically, you need _interfaces_ for everything. In most cases, this leads to a lot of cognitive overhead that obscures the essence of the abstraction being used.
A simple example of this problem is the lack of function values and lambda types (pre jdk8). Due to these missing features, people expressed the same abstractions by defining interfaces that define some method, and then providing implementations as anonymous classes. That is, instead of defining a function type and then just implementing it, you now have an interface and weird class declarations in your code. To the untrained eye, this is much harder to understand. As a result, some of the programmer's cognitive effort is now spent on this, and hence it becomes harder to understand the more useful part of the code (which is likely some kind of abstraction).
Just to shed some more light into this, consider Haskell's _monads_. Monads are very hard abstractions to grasp. They are much harder to understand than just "doing whatever you want to do and call it a day". However, they become extremely useful once you understand the abstraction and become available to use it without the cognitive overhead.