Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Patterns – A comprehensible guide

github.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Design Patterns – A comprehensible guide

#101

Post by js8 »

mbrock wrote: post #98
js8 wrote: post #93

Earlier quoted context omitted.

I think formalization and abstraction are two different things, and you conflate them in your comment. Formalization, in my view, is about "knowing what you are talking about". So you have a perfectly defined set of basic operations on the concepts you use, and you know what you can do with them and what happens if you do; you cannot cheat by making stuff up as you go along. On the other hand, abstraction deals with…

I was using abstraction in the sense of "lambda abstraction", like a formally specified function with parameters. Well, I had to remind myself what the actual design patterns "movement" is, and I get the impression that it's a dead movement with no development since the classic book and a very limited influence. It seems that maybe the bigger problem is that there is no "theory of software" aside from a few interesti…

After few years of skepticism, I got convinced that pure functional programming (ala Haskell) is the right path forward. (What convinced me was that you can do the same things as in Lisp, with type checking, see http://www.haskellforall.com/2012/06/you-could-have-invented... and more recently http://www.haskellforall.com/2016/12/dhall-non-turing-comple... .)

I think having very strong foundations is very comforting, and the separation of side effects (and introducing them into the type system) has important consequences for composability. But it is still hard and work in progress.

One of the more subtle criticism I have of the classic design patterns is that they often rely on interfaces as descriptions of objects (in the general sense). But it is a very weak description, and indeed, the most useful type classes (which is comparable to interface) in Haskell actually also have laws (not expressible in the type system, for better or worse) that describe behavior. This was a point made by Erik Meijer, that really, you want to describe the objects (that your abstractions can work with) with the laws governing them, not interfaces.

So yes, I think the type classes with laws that are commonly used in Haskell (which is actually pretty much application of mathematical concepts) are the way forward, because they are both better defined and more fruitful (thanks to being explicit about laws) than design patterns.

In particular, I suspect the whole field of group theory is still waiting to be discovered by programmers; I had this idea of looking at error handling and recovery, or transactional processing, as a group operations within a certain subgroup (of valid system states). So no operation or empty transaction is a neutral element, and recovery from action or transaction rollback are inverse elements in some group. I am not yet clear whether this is helpful or trivial, and I am not really sure how to proceed with it. But Monoid abstractions are already quite used in Haskell, so why not Group ones?

Re: Design Patterns – A comprehensible guide

#102

Post by thom »

js8 wrote: post #91
thom wrote: post #72

Earlier quoted context omitted.

But you don't _talk_ exclusively in formalisms to other mathemeticians, do you? You don't immediately jump into a specific form of calculus upon first hearing of a concrete real world problem? And I'm not saying React itself is a pattern. I'm saying if you wanted to create your own React-like framework, or to communicate the design decisions and mechanisms that make it different from other frameworks, there is value…

> But you don't _talk_ exclusively in formalisms to other mathemeticians, do you? In informal setting (like lecture or workshop), maybe not. But when publishing, you always talk in concepts that are defined formally. That doesn't mean that you use formal language all the time, but every time you introduce some definition or term, it is understood (obvious) that you could provide completely formal definition. Also, ha…

I guess I just don't inhabit this world where there is nothing more to software design than reading and writing code. I write comments, I read readmes and documentation, and I find shared, human descriptions of larger granularity design abstractions useful. ¯\_(ツ)_/¯

Re: Design Patterns – A comprehensible guide

#103

Post by js8 »

thom wrote: post #102
js8 wrote: post #91

Earlier quoted context omitted.

> But you don't _talk_ exclusively in formalisms to other mathemeticians, do you? In informal setting (like lecture or workshop), maybe not. But when publishing, you always talk in concepts that are defined formally. That doesn't mean that you use formal language all the time, but every time you introduce some definition or term, it is understood (obvious) that you could provide completely formal definition. Also, ha…

I guess I just don't inhabit this world where there is nothing more to software design than reading and writing code. I write comments, I read readmes and documentation, and I find shared, human descriptions of larger granularity design abstractions useful. ¯\_(ツ)_/¯

> I write comments, I read readmes and documentation, and I find shared, human descriptions of larger granularity design abstractions useful.

Oh, I have nothing against that, except the word "shared". I just don't think that "design patterns" (from the GoF book) helpfully contribute to that. In practice, it really depends what you want or don't want to gloss over as a technical detail, and just saying "there is this pattern" doesn't give you enough flexibility to do it.

What I am saying there is a trade off - if you decide to name something, you should define it well enough not to be misunderstood. If you can't or don't want to define it well enough, better not name it at all (except maybe temporarily), just describe your intuitions/feelings about it. The authors of "design patterns" seem to be oblivious to this trade off (although I think it wasn't really their fault that the names for patterns got so popular, I think they just wanted to have fancy chapter titles).

It's interesting though. When I describe how something works or should work, I use terms like "client", "server", "memory", "unique random number", "sort by", "find maximum", "queue", "remote call", "common API" etc. But I never found a compelling reason to describe things in names of (standard) design patterns. Why are not these terms considered to be design patterns? In my opinion, it is because the design patterns tend to be overly specific in some ways (talking about class/interface relations) without adding enough substance to be meaningful on their own.

So I don't find them useful to describe design (overly specific), nor I find them useful to describe code (not formal enough). They are just kind of slippery for both use cases.

Re: Design Patterns – A comprehensible guide

#104

Post by kazinator »

js8 wrote: post #101
mbrock wrote: post #98

Earlier quoted context omitted.

I was using abstraction in the sense of "lambda abstraction", like a formally specified function with parameters. Well, I had to remind myself what the actual design patterns "movement" is, and I get the impression that it's a dead movement with no development since the classic book and a very limited influence. It seems that maybe the bigger problem is that there is no "theory of software" aside from a few interesti…

After few years of skepticism, I got convinced that pure functional programming (ala Haskell) is the right path forward. (What convinced me was that you can do the same things as in Lisp, with type checking, see http://www.haskellforall.com/2012/06/you-could-have-invented... and more recently http://www.haskellforall.com/2016/12/dhall-non-turing-comple... .) I think having very strong foundations is very comforting,…

> You can do the same things as in Lisp, with type checking

Can't easily do even simple things like variable argument functions, or polymorphic lists (required for representing source code for macro programming).

Lisp has loops, variable assignment, stateful objects of various types and so on. Also, strict evaluation for straightforward, deterministic sequencing.

Re: Design Patterns – A comprehensible guide

#105

Post by js8 »

kazinator wrote: post #104
js8 wrote: post #101

Earlier quoted context omitted.

After few years of skepticism, I got convinced that pure functional programming (ala Haskell) is the right path forward. (What convinced me was that you can do the same things as in Lisp, with type checking, see http://www.haskellforall.com/2012/06/you-could-have-invented... and more recently http://www.haskellforall.com/2016/12/dhall-non-turing-comple... .) I think having very strong foundations is very comforting,…

> You can do the same things as in Lisp, with type checking Can't easily do even simple things like variable argument functions, or polymorphic lists (required for representing source code for macro programming). Lisp has loops, variable assignment, stateful objects of various types and so on. Also, strict evaluation for straightforward, deterministic sequencing.

I only touched that point but as I said - I used to think the same, but then I actually studied it and changed my mind. You can do all that in Haskell too, including interpreting homoiconic code and build DSLs (which was my main point), and it's all built on the more solid foundations with integrated static type checking. It just works quite differently.

Re: Design Patterns – A comprehensible guide

#106

Post by kazinator »

js8 wrote: post #105
kazinator wrote: post #104

Earlier quoted context omitted.

> You can do the same things as in Lisp, with type checking Can't easily do even simple things like variable argument functions, or polymorphic lists (required for representing source code for macro programming). Lisp has loops, variable assignment, stateful objects of various types and so on. Also, strict evaluation for straightforward, deterministic sequencing.

I only touched that point but as I said - I used to think the same, but then I actually studied it and changed my mind. You can do all that in Haskell too, including interpreting homoiconic code and build DSLs (which was my main point), and it's all built on the more solid foundations with integrated static type checking. It just works quite differently.

I didn't mean to imply that Haskell isn't Turing complete, of course.

Re: Design Patterns – A comprehensible guide

#107

Post by js8 »

kazinator wrote: post #106
js8 wrote: post #105

Earlier quoted context omitted.

I only touched that point but as I said - I used to think the same, but then I actually studied it and changed my mind. You can do all that in Haskell too, including interpreting homoiconic code and build DSLs (which was my main point), and it's all built on the more solid foundations with integrated static type checking. It just works quite differently.

I didn't mean to imply that Haskell isn't Turing complete, of course.

It's not about that. Haskell has tools to do all that, and they are better. You can write imperatively in Haskell, you can write strictly or lazily in Haskell, you can have dynamic types in Haskell. There is actually more choice.

However, one (unfortunately) needs to study it to see it. I like Lisp, but curiously enough, it has its limits too.

Re: Design Patterns – A comprehensible guide

#108

Post by cessor »

kdevrou wrote: post #87
cessor wrote: post #80

Earlier quoted context omitted.

> "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" I often asked myself this question! Why do I have to say public class DatabaseConnectionSingleton { public static DatabaseConnectionSingleton getInstance (){ ... }; } and then get an object using: var db = DatabaseConnectionSingleton.getInstance(); Why can't I say public singleton Database…

Just one of many reasons that Scala is such an attractive option for Java developers: // There is only one object DatabaseConnectionConnor {}

It's true that other languages often don't require certain patterns. Strategy and Visitor are often unnecessary when a programming language has functions as first class citizens.

I found that it often helps to remember that the GoF book was written about object oriented patterns with C++.

Re: Design Patterns – A comprehensible guide

#109

Post by thealistra »

qznc wrote: post #75
dack wrote: post #42

Earlier quoted context omitted.

I'm not sure what you mean by parallel class hierarchies. I use a factory if I have a class that needs to be able to make an instance of some other class, but shouldn't know about how to construct it (i.e. it doesn't need to know about the dependencies that other class might need to function).

I also do not understand "parallel class hierarchies". Here is another use case for a factory: Building an AST data structure in a compiler. There are nodes to represent Constants, Addition, FunctionCalls, etc and you have to build a tree structure, which represents a program. Now consider the case, where you build the addition of two constants ("36 + 6"). Using constructors, it could like like: new Add(new Const("36…

To be a cool compiler, you don't want to optimize this in the AST building phase. The user may be running in a mode of printing the AST only, to e.g. implement their own autocompletion. This code obfuscates the truth by doing this.

I remember that at some point gcc -O 0 was doing exactly that and it is pretty irritating if you write a decompiler and want to test it. Fortunately clang does it properly.

Re: Design Patterns – A comprehensible guide

#110

Post by mbrock »

js8 wrote: post #101
mbrock wrote: post #98

Earlier quoted context omitted.

I was using abstraction in the sense of "lambda abstraction", like a formally specified function with parameters. Well, I had to remind myself what the actual design patterns "movement" is, and I get the impression that it's a dead movement with no development since the classic book and a very limited influence. It seems that maybe the bigger problem is that there is no "theory of software" aside from a few interesti…

After few years of skepticism, I got convinced that pure functional programming (ala Haskell) is the right path forward. (What convinced me was that you can do the same things as in Lisp, with type checking, see http://www.haskellforall.com/2012/06/you-could-have-invented... and more recently http://www.haskellforall.com/2016/12/dhall-non-turing-comple... .) I think having very strong foundations is very comforting,…

I'm super interested in all that stuff, but I also feel that it's not for everybody. Like just yesterday I saw someone on the Rust subreddit who mentioned that they think Haskell is cool but it tends towards too high abstraction levels for their taste, which I totally understand.
Post reply on HN