Comment by johndubchak | Hacker News Reader

Comment by johndubchak | Hacker News Reader

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.

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.

curious. What was the classical problem?

https://en.wikipedia.org/wiki/Problem_of_universals

I've been in a situation that could have been described exactly that way, and in my case it was the Sieve of Eratosthenes.

> someone in Greece 2000 years ago

not sure if it's a hyperbole, but it gave me a good laugh :)

> someone in Greece 2000 years ago

How the Ancient Greeks Invented Programming http://www.infoq.com/presentations/Philosophy-Programming

Summary:

Matt Butcher explores the philosophical systems devised by Plato and Aristotle, showing how Plato laid the foundations for what is now OOP, while Aristotle’s dynamic model is at the core of FP.

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.

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.... 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.

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.

Think C++ iterators. Those maintain state, but not mutable state.

You have full control over the iteration,. but everything is immutable and thread-safe.

> 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.

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.

Reply on news.ycombinator.com