3 ms·

Java (like many other languages of that generation) suffers from a lack of idiomatic 1:1 visibility. Whenever you split something up in Java it litters a namesp

by usrusr 8y ago

Java (like many other languages of that generation) suffers from a lack of idiomatic 1:1 visibility. Whenever you split something up in Java it litters a namespace that is much bigger than necessary. Even private is too big when the class is full of tiny methods most of which most will never be meaningful to any of their peers except for that one call site. Sure, you can create inner function objects and with 8+ it's not even completely weird anymore, but that's still a far cry from the nested functions goodness of Pascal style "structured programming".

TeMPOraL 8y ago
Agreed. I don't remember much from my brief exposure to Pascal years ago, but spending a good chunk of my programming years in Common Lisp has spoiled me; the simple ability to nest functions is something I sorely missed when working on Java codebases.
deleted 8y ago
[deleted]
mrgriffin 8y ago
One of my favorite features of Haskell is that I can use where to write the auxiliary function definitions after the code that use them, but keep them scoped inside of a single function. A relatively bad example here: https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker
- yawaramin 8y ago
  Bindings in the `where` clause can still access names in the main binding: https://wiki.haskell.org/Let_vs._Where#Advantages_of_where https://wiki.haskell.org/Let_vs._Where#Advantages_of_where This runs the risk of strongly coupling them to the main binding and making them less reusable. IMHO strong coupling where two bindings are aware of each others' internals should be avoided.
  - cannabis_sam 8y ago
    Like your link says: doesn’t lambda lifting solve that problem? That’s what I always do if I want to move an auxillary function to the top-level for reusing elsewhere.
    - yawaramin 8y ago
      Indeed, I also prefer lifting, especially internally inside a module. It jives with the idea of loose coupling, strong cohesion.

by usrusr 8y ago

TeMPOraL 8y ago

Agreed. I don't remember much from my brief exposure to Pascal years ago, but spending a good chunk of my programming years in Common Lisp has spoiled me; the simple ability to nest functions is something I sorely missed when working on Java codebases.

deleted 8y ago

[deleted]

mrgriffin 8y ago

One of my favorite features of Haskell is that I can use where to write the auxiliary function definitions after the code that use them, but keep them scoped inside of a single function. A relatively bad example here: https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker

yawaramin 8y ago
Bindings in the `where` clause can still access names in the main binding: https://wiki.haskell.org/Let_vs._Where#Advantages_of_where https://wiki.haskell.org/Let_vs._Where#Advantages_of_where This runs the risk of strongly coupling them to the main binding and making them less reusable. IMHO strong coupling where two bindings are aware of each others' internals should be avoided.
- cannabis_sam 8y ago
  Like your link says: doesn’t lambda lifting solve that problem? That’s what I always do if I want to move an auxillary function to the top-level for reusing elsewhere.
  - yawaramin 8y ago
    Indeed, I also prefer lifting, especially internally inside a module. It jives with the idea of loose coupling, strong cohesion.