Hacker News Reader

Isn't there a point where it's more desirable to have 'features' available through patterns, than through the language itself? The larger and more complex the language grows, the more cognitive overhead - so programmers of a hypothetical 'perfect' future language might still use patterns, simply so the language didn't grow out of reasonable proportions.

If code is data then in principle you could implement them as libraries rather than language extensions. I don't use lisp or haskell enough to know whether someone has already done this.

That said I'm also not convinced that it would help in many cases. What would you enforce about a wrapper for example other than it's constructed from one argument and returns a different type containing a reference to the original one? If you're not able to do that yourself then would a wrapper library really be any use?

That's basically the role of frameworks. Any web application I build is going to need at least some subset of functionality common to all web applications, and implementing everything from first principles is absurd, so I use a framework.

Someone else building something completely different with the same language doesn't need those things, so cooking my needs into the language itself is just going to add overhead or force unwanted design choices on to them, but there's probably a different framework for whatever they're doing too.

Clearly having a language that makes it easy to implement common solutions to problems is a good thing. I don't think this means we should stop studying those solutions though. To take a notorious example, visitor pattern is just a work around for the lack of multiple dispatch. However, I do not have enough fingers to count the number of times I've had to explain the benefits of multiple dispatch to people. And perversely I can say the same about the number of times I've heard people conflate multiple dispatch with functional programming! The truth is that sometimes I have an extensible group of types with relatively static operations, and sometimes I have a relatively static group of types with extensible operations. The techniques I employ to write generic code in both cases is different. Another great example is the reactor pattern (a la Douglas Schmidt), which many people view as being the cost of using Node, rather than being a very useful technique for controlling real time processing.

In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features.

I've heard people mention that a lot, but the only concrete example the ever give is "you don't need the strategy pattern because of first class functions", which is doesn't hold up when you examine it closely.

Serious question. How many of YC's startups implement their products in Lisp? Is it > 0? Why so few?

Seems to be a nonsequitur.

>I'm partial of the explanation of DP as missing language features.

It is a way to encode basic features in terms of simple standard building blocks: objects. However, I think that explaining everything in terms of objects is a terrible idea. Objects are extremely complex already, it is a bad idea to use them as a basic entity. Just compare lambda semantic rules (there are only three of them for untyped lambda calculus), and an object's semantic. Later is much more complex.

I think that the complexity of objects led to the complexity of patterns, making them verbose and ugly. Just compare visitor and pattern matching, or command and higher order function.

It is true that in more advanced languages having more features patterns become invisible, but I thing they also would become invisible if they were composed of more simple entities.

An object is literally an encapsulation of state. Imagine having 3 functions which do something with points on a graphical plane. The first 2 parameters in each function represent the x and y positions of the point. You can make an OO "class" by simply grouping those three functions. You can make an object by partially applying x and y to the three functions. You can "respond to messages" by calling those functions.

I agree with you that many OO languages add unnecessary syntax and lack features, but objects are not related. We need to encapsulate state and we like to group functions into cohesive modules that are related to the state that they are going to deal with. We do this whether we use object nomenclature or not.

> I'm partial of the explanation of DP as missing language features.

I find this argument to be rather disingenuous as it ignores the fundamental purpose of design patterns: communicate intent through a common language. I mean, 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism. Technically, they don't require anything more than what inheritance and polymorphism already offet, and the only difference is precisely why and how inheritance and polymorphism are used in a specific problem. I mean, what's the fundamental difference between a state pattern and a strategy patern? Hell, isn't the strategy pattern a rather direct use of polymorphism? Is the language even missing anything at all? Of course not, because the purpose of using design patterns is to communicate intent and describe precisely what was the problem and more importantly how it was solved.

The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Or direct expressions of those concepts? Communicating intent through a common language is all and good, but then why that language isn't formally encoded in the compiler?

> Is the language even missing anything at all?

This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem.

> The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword?

Because they add or take nothing from the language. Arguing for the needless addition of these keywords makes as much sense as arguing in favour of camelCase or polish notation or "m_" and "s_" prefixes. They add nothing to the language, they are redundant and they are used to convey meaning alone.

Therefore, what problem would be solved by adding useless keywords to a language, particularly when those making these claims come from a point of ignorance and lack of experience?

> This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem.

This makes no sense at all. Rather straigh-forward applications of polymorphism don't vanish if you call them by different names.

Keywords are of course secondary. Did you miss the "or direct expressions of those concepts" part? I was implying the existence of some boilerplate reducing syntax behind them. With the right features, most patterns vanish. For instance:

  // C++98
  class Adder {
  public:
      Adder(int inc) : _inc(inc) {}
      int const operator+(int n) { return n + _inc; }

  private:
      int _inc;
  };

  // C++11
  std::function(int(int)) adder(int inc) {
      return [=](int n) { return x + n; };
  }

  (* Ocaml *)
  let adder inc n = inc + n

  -- Haskell
  adder inc n = inc + n

Assuming currying is a good fit for your problem, you probably don't want to bother with factories, if you can use a language that supports currying directly. Same goes for other patterns: whichever you need suggest what language features you want.

Or you could be content with repeating the same kind of code over and over, but I'm not going to accuse you of such obvious stupidity.

> With the right features, most patterns vanish. For instance:

The thing is they don't. For example, a function pointer does not fill the need that strategy patterns fill. You look at a function pointer and you have no idea where and how and why it is supposed to be used, there is no type constraint, and there isn't even any way to track where how many different instances there are. A function pointer alone says nothing. Yet, specifying a common interface does, as well as implementing any concrete strategy. That's the whole point of using patterns.

Furthermore, design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve. You get a clear idea of how a data access module is designed if the designer states that he used active records or repositories, and if classes are named appropriately you can already form a clear mental model of what to expect and, more importantly, what you will can or may need to do to fix a bug or implement a feature.

Who ever said "the right features" were limited to function pointers? Who ever even talked about function pointers? My example didn't even use function pointers! Are your imagination so limited that you cannot think of language features that would reduce the need for any specific pattern? I just showed you one, dammit!

Let's step back a little:

> 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism.

Of course, inheritance and polymorphism are the only thing Java has! Or had, back in 1995. Hammer & nail. There are other ways of expressing those patterns, other ways of solving the same problems that do not require those patterns at all. You just need to wake the fuck up and realise OOP is not the only game in town.

> design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve.

I have yet to witness a single instance of that in my job, and I've seen loads. On the contrary, naming patterns often clouds the underlying concepts. A pet peeve of mine is the Singleton. It's overused for sure, but that also makes it one of the most widely understood patterns. Yet few seem to realise that singletons are nothing more than global variables with a couple bells and whistles. And since the thing is not called "global variable", it doesn't trigger the appropriate mental warnings.

What good are pattern names when programmers can't think clearly to begin with?

It's not just the conversations. Every time I saw a pattern name in real code, I could find a simpler way. I also saw misapplied patterns, like factories that actually were memory pools. Whoever did that didn't know what they were talking about, and patterns didn't save them.

I've read lots of your postings and I like them. I think you are a smart person and I realise that this topic is getting a bit frustrating. But because I think we're all talking past one another, I'll hopefully be able to clear up a few things.

Patterns of code exist. It's a mistake to look at the GoF pattern catalogue and think that it represents patterns that you should use in every situation (or even at all!). I remember hearing someone say one time that all programming should be made up of GoF patterns (touring complete??? ;-) ). Yes, it's absurd. Going all the way back to the original poor article, that's really the problem. People latch on to these ideas; they hear something and it sounds attractive; whatever. Poor programmers are poor programmers. I personally don't think they get worse having learned about patterns. It can help, but it's not the only thing you need by a long shot.

In FP there are lots of patterns. A Functor could be a pattern if anyone bothered to write it up in that fashion. It would make a very nice pattern. Applicative is a great example of a generated pattern -- it's a thing you would never actually design up front, but just pops out. Maybe/Option, Either, etc monads.... awesome patterns (again, if anyone decided to write them up in that fashion).

Let's go back to GoF patterns, maybe the Singleton. The Singleton is not a global variable with a couple of bells and whistles. That's a very popular, but misconstrued view. It's actually the bells and whistles that are the point of the Singleton. A Singleton is a method to ensure that something occurs at most one time in your system (potentially scoped). You use it when you have a piece of hardware that will crash if you initialise it twice. Or when you have to initialise a communications protocol exactly once. Or when you have a very expensive operation and you want to ensure that it only gets called once in a particular scope. Usually people use a global scope for their singletons -- because that's what they actually want. But it's not uncommon to scope singletons at a module level, or other kinds of scope. How do you usually implement a singleton? By providing a function in the scope you want that memoises a piece of data. Yeah, it's not rocket science. It's not supposed to be. It's just a technique. And if you don't write essentially the same code in non-object based langues to achieve the same result, I'll eat my hat (or at least I'll ask you how you would do it differently and then suggest that it might make a good pattern).

One of the weaknesses of the GoF book was that it wrote all the examples in similar languages. At the time, those were the languages that were relevant. Those were the languages that the authors were proficient in. It might surprise many people to know that the GoF was not the first publication on software patterns (not by a long shot). In fact the GoF was only interesting because they attempted to make a pattern catalogue -- a set of patterns that would be relevant to a certain kind of programming. That this is not the kind of programming you enjoy is completely irrelevant. There are other patterns. You can make other catalogues. That is the whole point.

And, you are correct. Patterns don't make a good programmer. But good programmers know programming techniques that are relevant to the style of programming that they use. How do they learn those techniques? How do they communicate where they are appropriate and where they are not? Back in my day we just said, "Here's a keyboard. Don't suck!" And then we'd look at their code and say, "You suck. Why can't you write code like mine?" I'm not really so happy to go back to those days.

The singleton thing is interesting, I admit I overlooked the scope thing. In practice though, I only ever used it to overcome a particular C++ deficiency: initialisation dependencies. C++ doesn't specify the order of initialisation across compilation units, so I can't just lean on constructors.

To ensure initialisation occurs only once, a static scope and a constructor are enough. And to ensure nobody else can spin up another instance, the constructor can be private, though I've never needed that. Anyway, for extra "clean" points, I tend to just expose the interface of the singleton as a set of global functions, doing whatever's necessary for the user to not having to think about initialisation or `get_instance()` at all.

If C++ could guaranteed the order of initialisation satisfies dependencies, we could shave a few lines off that pattern. (Whether this is a good idea is a separate issue.) My point was, each pattern has a corresponding language feature (or set thereof) that could make it less verbose.