Hacker News Reader

I felt that your comment speaks to me - I had a similar understanding a couple of years ago. In their book "Growing Object Oriented Software, Guided by Tests", Nat Pryce and Steve Freeman describe values and objects, *(Values in the sense of Value Objects in Evans' DDD)

> The confusion is, that both concepts are implemented by the same language construct: Classes

This made me think. In C# this statement is somewhat untrue, since you have structs that have value semantics (value equality). But why are there no other concepts within the language that help you from reinventing the pattern wheel?

For example, I had seen the singleton pattern quite frequently in a codebase I worked on, with the label leaking into the class name. But why is it that you have to write:

    public class DatabaseConnectionSingleton { ... }

and then deal with all the static stuff (i.e. x.Instance()) rather than

    public singleton DatabaseConnection { ... }

Like this, you could easliy use standard stuff:

    new DatabaseConnection()

and the runtime would simply return the same instance. This would keep people from reinventing the mechanism. Like IoC / DI built into your language...

[1] http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...

> Yes, every language has 'patterns', but we call those linguistic structure, syntax, or grammar. "Design patterns" refers to something else, (or if it doesn't, it is just a confusing domain-specific renaming of the above.) The problem with design patterns is that they are ostensibly solved problems, and thus people shouldn't be implementing them except pedagogically.

Well, except that the whole reason for documentation of design pattern implementations is that, in the languages for which they are documented, they generally do not admit of a reusable library implementation because of limitations in the abstractions available in the language. That's why people (slightly inaccurately) say that certain languages (Lisps are frequently cited here) don't need design patterns -- the kinds of things documented as design patterns with implementation recipes for Java/C++-like languages can often be implemented in library code in lisps (to a certain extent this is also true of many dynamic OO languages, like Ruby, and sometimes in static functional languages, like Haskell), so the kind of recipe-style presentation and fill-in-the-blanks implementations seen in Java/C++ patterns just aren't applicable in some other languages.

(Sure, you can address design patterns by building each one into the language individually, the way you discuss with arrays, and that will shift which patterns the language needs at the expense of a bigger base language. You get more bang for the buck building languages which are expressive enough to allow you to reusably implement a broad array of "patterns", so you instead of implementation recipes you just need libraries with API documentation.)

I think part of this problem is that people want to invent compact, 'small' languages, and leave the rest to libraries. This kind of thinking is what makes it hard to move up, because it is just a variation on "our language is ASM, if you want fancy stuff, just write it as a library in ASM."

Language design should be about saving the end programmer from having to do extra work, not minimizing your core language and deferring the savings for later. Of course, there is some push-and-pull here, because we want to make languages small so that they are comprehensible. So what we want are the smallest possible languages that can express a broad array of powerful abstractions with minimal effort.

This is why I hate the "no language is the best" line of thought. (Which is similar to "ever language uses design patterns.") There is no theoretical reason why there can't be a best language. All we have is a history of languages that suck to look at. You can't infer that all possible languages suck at something from our short history of terribleness. It is 2015. What kind of languages will people be using in 4015? How about 14015? Are they going to be saying "It doesn't matter what language you use?"

It's interesting to switch your example to "Hash Table" instead of "Array". C is the language I'm most familiar with, and lacks one as part of the core language. So in fact, C essentially does say "Oh, just use the (associative) array pattern here. Start by rolling your own..."

Does this mean that a design pattern is not an absolute, but relative to a language? Or does it mean that there is no clear distinction between syntax and pattern? I don't think that being one excludes being the other.

We build arrays into the language so that they are easy to recognize and the pattern becomes a primitive tool. If you have to keep rolling your own, you'll never get past that. It will never become primitive, and you will stagnate. That is what those who object to design patterns object to: by thinking of them as elements of design -- the work of day-to-day programmers -- we won't provide linguistic abstractions that allow them to become primitive tools.

Rather than fearing that naming a concept will cause stagnation, I think the opposite: the failure to have a "shorthand" for a commonly used feature means it will continually be reinvented. Once named, the concept can be pushed down to syntax while remaining a design pattern.

The surprise (to me) is that the gulf between being part of the language and being an easy to add library is so great. Why is there no standard hash table that gets used in C? Why is there such a difference between core and non-core? I don't know what it is, but don't think it's for lack of syntax.

>Rather than fearing that naming a concept will cause stagnation, I think the opposite: the failure to have a "shorthand" for a commonly used feature means it will continually be reinvented. Once named, the concept can be pushed down to syntax while remaining a design pattern.

This is exactly the problem with design patterns. Once you recognize a design pattern, you should abstract it away and just use it from a library. Sometimes that is very hard to do. (E.g., Model-View-Controller.) But just because it is hard doesn't mean it is impossible. That kind of activity is a prime measure of success in computer science.

Of course, we have the internet, but we still don't write languages that expect to pull needed tools from the internet in a smart way. You have to manually look for a library and include it yourself. When you write some code, it isn't being compared against a database of online code with your IDE telling you "Hey, someone else wrote something like this and it runs way faster and uses less text, check it out maybe?"

This is really just an extension of the scotsman argument.

For one, many people really do regularly relearn the benefits of arrays. To the point that maybe it should get more discussion.

For two, not everything can be a linguistic structure/syntax/grammar. Often they are pretty good highlevel descriptions of what is intended. Implementation left to the reader.

Which is ultimately the problem. Two implementations of the visitor pattern may have made different trade offs for what they are doing. Same for many other patterns. Singleton is often itself used as a tradeoff in terms of flexibility.

Now, I fully agree that when used without thinking/acknowledging the tradeoffs, they lead to issues. They are not unique here. Consider actors. Arguably the vogue pattern for the popular crowd nowdays. Can you honestly tell me the vanilla actor is a solid win?

>not everything can be a linguistic structure/syntax/grammar.

Says who? Why should I believe this?

Says experience. Tritely, why should I believe the contrary? I've certainly seen it tried enough. Yet to work.

There is also the parallel to spoken languages. Where there are pretty good patterns of speach for making different points. Why haven't all of those been converted to simply an atomic linguistic structure.

Experience would have told you that human flight was impossible just 110 years ago. The reason you should believe the contrary is because it is an open world, and there is not proof that you are correct.

>There is also the parallel to spoken languages. Where there are pretty good patterns of speach for making different points.

And programming is largely a domain specific task today, so you could have pretty good patterns for it.

But anyway, that parallel expresses a better point: language is extensible. If you have something in another spoken language to express, you can certainly do it in any other language. You just can't maximize terseness everywhere, which is not what we're using to measure how good a language is. The measure for this is terseness in proportion to usage, which doesn't conflict that rule. Especially if you can control terseness dynamically.

And, for the longest time, banking on a miracle flying device would have been a terrible idea.

Language is less extensible and more just plain mutable. Consider the phrase "firing rate" when applied to an archer. Something tells me this mutability is not a selling point around here.

Indeed, there are many "mechanic" patterns (e.g. Singleton) which are just documented workarounds for flaws in popular programming languages, more precisely in their type systems.

However, this is only half of the story.

There are also "real" patterns (e.g. Facade) which describe by what criteria you should structure your code in what circumstances. These can't be directly translated into a language feature, library or framework, as they still require human judgement on the details. One might disregard these patterns as "soft" or "too imprecise", but I think these are the real patterns. These helped me more than any of these mechanic patterns.

> Yes, every language has 'patterns', but we call those linguistic structure, syntax, or grammar.

The higher level of linguistic structure, syntax or grammar is the 'idiom', and idioms are a small step below the 'pattern'. So I think there are differences there.

Arrays are a datastructure, not a design pattern, but allocating an array, populating it, using it to recall its contents and finally destroying it could be called a pattern (or an idiom, if you prefer).

Idioms are always language-specific. The word idiom essentially means "a peculiarity of language" or "a phrasing that wouldn't work elsewhere." But we're being vague here anyway, because 'pattern' is a vague word. Everything is a pattern. Data structures are a structured pattern of data.

Whether you choose to implement something as an array or as a hash table is a "design pattern": a pattern invoked by a designer to solve a problem. You don't have to use a singleton pattern or a visitor pattern. You choose to as a consideration of your design. But you shouldn't have to roll your own code to make that design work, because we have a name for it and we know what you're talking about. It should be in a library or in the language. (Which, in my opinion, is a farcical distinction: languages and libraries should always be considered together at all levels, including in language design.)