4 ms·

> Unfortunately Java’s structure seduces the unwary programmer into excessive abstraction. Between demanding a class for everything and enforcing all types at c

> Unfortunately Java’s structure seduces the unwary programmer into excessive abstraction. Between demanding a class for everything and enforcing all types at compile time, it encourages you to lay down layer after layer of formalism in class and interface declarations. To me, it's not really about "seduction", it's about inviting the programmer to abstract away with tools that are heavily unfit for the job. If your only means of abstraction is a class, everything starts to look like a method call. That's why I enjoy Common Lisp's ability to create macros on multiple stages of the language's operation: reading code, compiling code, substituting function calls. These make it possible to introduce new syntax where necessary, which in turn makes the code shorter, and to write compile-time optimizations that do not get in the way of the main function bodies.

FpUser 6y ago
The abstraction is abstraction. It does not matter how it is implemented. Might as well do 100 levels of function pointers or simple nested calls with no classes at all. I think the author's main idea is that your methods should carry some weight and be long enough so you can visually trace the logic. Do not write functions that do nothing but multiply 2 numbers.
- phoe-krk 6y ago
  I can agree with the second paragraph but I disagree with: > The abstraction is abstraction. It does not matter how it is implemented. To me, it does matter. A good abstraction should not get in the programmer's way. This directly depends on making the language's syntax support the abstraction in question. This, in turn, depends on the macro system of the language or lack thereof. Finally, that is a question of the given language's expressiveness, or lack thereof.
  - FpUser 6y ago
    You can have all the expressiveness in the world and still write those 3 liners. Or you can have plain functions and still write decent code with abstractions where needed. Basically good master will try to make decent job with any instrument and bad one will mess up everything disregarding the tools given. Of course on its own more expressive languages make job easier to write and read. Not denying that part.
    - phoe-krk 6y ago
      Yes. That is the part that I agree with.
  - lmm 6y ago
    You don't need macros, you just need a language that isn't awful. Plenty of languages make writing a plain datastructure and values of that datastructure easy, make "good code" just as concise as - if not more concise than - "bad code".
  - ajuc 6y ago
    Abstraction is good when it lets you not thing about something and still understand how the system works. Abstraction cost is that the system becomes more complex overall. Good abstraction makes the system easier to reason about and leaks rarely, so you rarely have to think about the insides. But all abstractions leak under some circumstances. If you have 100 layers of abstractions at any given moment some layer leaks and you're constantly fighting the system without being able to understand how the whole thing should work. Language syntax only helps by removing the need for some abstractions by including them in the language.
- aidenn0 6y ago
  > Do not write functions that do nothing but multiply 2 numbers. Maybe I'm missing something, but doesn't Java already have a function that multiplies 2 numbers, as well as a fancy infix notation for calling said function?

FpUser 6y ago

The abstraction is abstraction. It does not matter how it is implemented. Might as well do 100 levels of function pointers or simple nested calls with no classes at all. I think the author's main idea is that your methods should carry some weight and be long enough so you can visually trace the logic. Do not write functions that do nothing but multiply 2 numbers.

phoe-krk 6y ago
I can agree with the second paragraph but I disagree with: > The abstraction is abstraction. It does not matter how it is implemented. To me, it does matter. A good abstraction should not get in the programmer's way. This directly depends on making the language's syntax support the abstraction in question. This, in turn, depends on the macro system of the language or lack thereof. Finally, that is a question of the given language's expressiveness, or lack thereof.
- FpUser 6y ago
  You can have all the expressiveness in the world and still write those 3 liners. Or you can have plain functions and still write decent code with abstractions where needed. Basically good master will try to make decent job with any instrument and bad one will mess up everything disregarding the tools given. Of course on its own more expressive languages make job easier to write and read. Not denying that part.
  - phoe-krk 6y ago
    Yes. That is the part that I agree with.
- lmm 6y ago
  You don't need macros, you just need a language that isn't awful. Plenty of languages make writing a plain datastructure and values of that datastructure easy, make "good code" just as concise as - if not more concise than - "bad code".
- ajuc 6y ago
  Abstraction is good when it lets you not thing about something and still understand how the system works. Abstraction cost is that the system becomes more complex overall. Good abstraction makes the system easier to reason about and leaks rarely, so you rarely have to think about the insides. But all abstractions leak under some circumstances. If you have 100 layers of abstractions at any given moment some layer leaks and you're constantly fighting the system without being able to understand how the whole thing should work. Language syntax only helps by removing the need for some abstractions by including them in the language.
aidenn0 6y ago
> Do not write functions that do nothing but multiply 2 numbers. Maybe I'm missing something, but doesn't Java already have a function that multiplies 2 numbers, as well as a fancy infix notation for calling said function?