5 ms·

I believe another major issue arises in the form of the design of these new API's are not designed using the historical knowledge that got us here. It seems to

I believe another major issue arises in the form of the design of these new API's are not designed using the historical knowledge that got us here. It seems to me at least that every 10 years or so a new group of fresh grads enter the workforce and by sheer will (and all nighters) recreate different forms of the same solutions to familiar problems. Meanwhile, the previous designers and implementors seem to fade (who knows where they end up?) and the normal evolution we should be seeing in our API's, frameworks, and collective knowledge simply inches (is that too generous?) along. We are giving different names to original ideas. For example, I have read (sorry, I can't find the links) recently where others have published on interesting new design patterns only to find out they are essentially renamed versions of the original GoF patterns. The same challenges exist and we are seeing someone else's take on the solution and it feels too familiar because they look at what's out there and provide only a marginal variation on a theme. I believe this partly explains this "been there, done that" that we're seeing these days.

nickbauman 11y ago
Traditional OOP/Imperative programming tends to encourage this "reinvention". Where the old guard goes? I think programmers age out when they see the same "trend" for the 3rd time and decide they need to get off the hamster wheel and go into management. GoF patterns make sense if your language is statically typed and OO and you don't have real data abstraction. To be fair, most OOP practitioners don't even know what "data abstraction" means: this is what is meant by "it's better to have 100 functions that work on one datastructure than 10 functions that work on 10 different datastructure. The latter is OO, the former is FP.
- edejong 11y ago
  Your first paragraph makes some sense, but I truly disagree with your second. Good OOP design is very similar, if not identical, to good FP design. For example: - The iterator pattern: is essential to more abstract FP, see for instance 'the essence of the iterator pattern: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf' https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.... The iterator as a stream is a coinductive data structure and a such a fundamental structure in FP. Also note that transformations on iterators are applicative. Then, look at many of the other GoF structures: the visitor pattern, which is very similar to recursive algorithms on trees. The adapter is basically applicative, the Factory is difficult, but could be seen as a coinductive structure. Also, one should note that in (modern) proper OOP, composition is your most important tool. This is very similar to composition of functions.
  - nickbauman 11y ago
    You picked an especially bad pattern for your proof. Iterators aren't inherently functional. In the imperative world they needlessly maintain state and are by nature one giant side effect. Data abstraction doesn't even require an iterator "pattern" to achieve iteration, that's the whole point of data abstraction that a "pattern" isn't required but merely a "concept". In Clojure, for example, the concept is a sequence which has stateless traversal. That paper you quote even makes the distinction between the separate approaches taken from functional versus imperative.
    - paulddraper 11y ago
      Think C++ iterators. Those maintain state, but not mutable state. You have full control over the iteration,. but everything is immutable and thread-safe.
mtkd 11y ago
Anyone around over 20 years or more will likely agree. It's not a bad thing in my view. Watching an inexperienced and enthusiastic team lurch forward with some new hotness, often different angles on old problems, is one of the things that keeps me interested. That pioneering community mature and start recognising the similarity of their deeper issues with more classical computation problems. Then they start to investigate earlier thinking and solutions - or engaging older developers with wider knowledge. But they almost always add something in the early stages as they were not prejudiced by legacy solutions. Rails was a good example of this - it massively changed a lot of thinking in good ways. Many people I met in the early days of Rails went on to need outputs from earlier generations - niche languages, classical data structures, lexers, low level debuggers etc. - the very things they thought they were disrupting. Older developers are not immune to this - I've sketched out some complicated (to me) data requirement on a whiteboard, with some loose thinking on how we might solve it, only to be informed it's a classical problem with a standard solution pattern developed by someone in Greece 2000 years ago.
- jakub_g 11y ago
  > someone in Greece 2000 years ago not sure if it's a hyperbole, but it gave me a good laugh :)
- iamwil 11y ago
  curious. What was the classical problem?
  - evv555 11y ago
    https://en.wikipedia.org/wiki/Problem_of_universals https://en.wikipedia.org/wiki/Problem_of_universals
  - snoman 11y ago
    I've been in a situation that could have been described exactly that way, and in my case it was the Sieve of Eratosthenes.
- tydok 11y ago
aledalgrande 11y ago
I think this is also due to the fact that, no matter what is taught in coding schools or universities, you cannot fully understand a pattern until you've seen it working in real apps, with real use cases, and your mind grasped the whys on top of the hows.
taneq 11y ago
> Meanwhile, the previous designers and implementors seem to fade (who knows where they end up?) 'Promoted' to management, due to the all-pervasive and asinine perception that the only way to recognize a highly skilled technical person is to waste their time with bossing other people around.

nickbauman 11y ago

Traditional OOP/Imperative programming tends to encourage this "reinvention". Where the old guard goes? I think programmers age out when they see the same "trend" for the 3rd time and decide they need to get off the hamster wheel and go into management. GoF patterns make sense if your language is statically typed and OO and you don't have real data abstraction. To be fair, most OOP practitioners don't even know what "data abstraction" means: this is what is meant by "it's better to have 100 functions that work on one datastructure than 10 functions that work on 10 different datastructure. The latter is OO, the former is FP.

edejong 11y ago
Your first paragraph makes some sense, but I truly disagree with your second. Good OOP design is very similar, if not identical, to good FP design. For example: - The iterator pattern: is essential to more abstract FP, see for instance 'the essence of the iterator pattern: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf' https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.... The iterator as a stream is a coinductive data structure and a such a fundamental structure in FP. Also note that transformations on iterators are applicative. Then, look at many of the other GoF structures: the visitor pattern, which is very similar to recursive algorithms on trees. The adapter is basically applicative, the Factory is difficult, but could be seen as a coinductive structure. Also, one should note that in (modern) proper OOP, composition is your most important tool. This is very similar to composition of functions.
- nickbauman 11y ago
  You picked an especially bad pattern for your proof. Iterators aren't inherently functional. In the imperative world they needlessly maintain state and are by nature one giant side effect. Data abstraction doesn't even require an iterator "pattern" to achieve iteration, that's the whole point of data abstraction that a "pattern" isn't required but merely a "concept". In Clojure, for example, the concept is a sequence which has stateless traversal. That paper you quote even makes the distinction between the separate approaches taken from functional versus imperative.
  - paulddraper 11y ago
    Think C++ iterators. Those maintain state, but not mutable state. You have full control over the iteration,. but everything is immutable and thread-safe.

mtkd 11y ago

Anyone around over 20 years or more will likely agree. It's not a bad thing in my view. Watching an inexperienced and enthusiastic team lurch forward with some new hotness, often different angles on old problems, is one of the things that keeps me interested. That pioneering community mature and start recognising the similarity of their deeper issues with more classical computation problems. Then they start to investigate earlier thinking and solutions - or engaging older developers with wider knowledge. But they almost always add something in the early stages as they were not prejudiced by legacy solutions. Rails was a good example of this - it massively changed a lot of thinking in good ways. Many people I met in the early days of Rails went on to need outputs from earlier generations - niche languages, classical data structures, lexers, low level debuggers etc. - the very things they thought they were disrupting. Older developers are not immune to this - I've sketched out some complicated (to me) data requirement on a whiteboard, with some loose thinking on how we might solve it, only to be informed it's a classical problem with a standard solution pattern developed by someone in Greece 2000 years ago.

jakub_g 11y ago
> someone in Greece 2000 years ago not sure if it's a hyperbole, but it gave me a good laugh :)
iamwil 11y ago
curious. What was the classical problem?
- evv555 11y ago
  https://en.wikipedia.org/wiki/Problem_of_universals https://en.wikipedia.org/wiki/Problem_of_universals
- snoman 11y ago
  I've been in a situation that could have been described exactly that way, and in my case it was the Sieve of Eratosthenes.
tydok 11y ago

aledalgrande 11y ago

I think this is also due to the fact that, no matter what is taught in coding schools or universities, you cannot fully understand a pattern until you've seen it working in real apps, with real use cases, and your mind grasped the whys on top of the hows.

taneq 11y ago

> Meanwhile, the previous designers and implementors seem to fade (who knows where they end up?) 'Promoted' to management, due to the all-pervasive and asinine perception that the only way to recognize a highly skilled technical person is to waste their time with bossing other people around.