Ask HN: What programming design pattern book has had the biggest impact on you?
11 comments
David Mamet's Masterclass on "Screenwriting". It is about screenwriting, but I transposed so much to programming and writing it's ridiculous.
The way to create characters, plot, or get ideas. The plot is one problem and characters solve it. One thing and one thing only. The job to be done [of a movie] is to entertain an audience, don't get gradiose or too tied to it.
As a programmer, I watched the videos and with every video, there was a clear application to programming and design.
Advice on writing, in general, and observing good products evolutions lead me to increase my effectiveness: not building the wrong thing, better scoping, solving the right problem. This leads to a lot of code not written, and reduces unnecessary complexity.
I have of course read some of the books you mention, but I find that simplifying things delays the need to resort to some patterns. You often find code that does practically nothing but filled with observers and borgs and factories and whatnot. It's useless and doesn't solve a problem. If it were a display of patterns skills, maybe, but that's why I did Judo and not Aikido. I like things that work in real life against actual problems, not imaginary or compliant adversaries.
The way to create characters, plot, or get ideas. The plot is one problem and characters solve it. One thing and one thing only. The job to be done [of a movie] is to entertain an audience, don't get gradiose or too tied to it.
As a programmer, I watched the videos and with every video, there was a clear application to programming and design.
Advice on writing, in general, and observing good products evolutions lead me to increase my effectiveness: not building the wrong thing, better scoping, solving the right problem. This leads to a lot of code not written, and reduces unnecessary complexity.
I have of course read some of the books you mention, but I find that simplifying things delays the need to resort to some patterns. You often find code that does practically nothing but filled with observers and borgs and factories and whatnot. It's useless and doesn't solve a problem. If it were a display of patterns skills, maybe, but that's why I did Judo and not Aikido. I like things that work in real life against actual problems, not imaginary or compliant adversaries.
Never been a huge Mamet fan, but so many people swear by his lectures that I think I might indulge over xmas break ;)
Screenwriting classics like "Save the Cat" and "The War of Art" contain very simple truths: there are rules to storytelling, honed over centuries of human experience and cultural evolution. Knowing when to follow the rules, and having the confidence to break them, is part of that journey, and can be applied to virtually any creative endeavor ;)
Screenwriting classics like "Save the Cat" and "The War of Art" contain very simple truths: there are rules to storytelling, honed over centuries of human experience and cultural evolution. Knowing when to follow the rules, and having the confidence to break them, is part of that journey, and can be applied to virtually any creative endeavor ;)
I saw some ads on screenwriting and thought that it would apply well to writing code, but I didn't go into them. Thanks for confirming that it does.
Which videos or Masterclass did you mean specifically?
Which videos or Masterclass did you mean specifically?
>Which videos or Masterclass did you mean specifically?
This one:
>David Mamet's Masterclass on "Screenwriting"
I watched Aaron Sorkin's one, not the same feeling. Sorkin wants dialogue to be smart and fast and impressive. He wants characters who speak similarly to his perception of his smart friends' conversations.
Building product with David Mamet's advice will get you product market fit.
Building product with Aaron Sorkin's advice will get you funding, then put you in jail.
This one:
>David Mamet's Masterclass on "Screenwriting"
I watched Aaron Sorkin's one, not the same feeling. Sorkin wants dialogue to be smart and fast and impressive. He wants characters who speak similarly to his perception of his smart friends' conversations.
Building product with David Mamet's advice will get you product market fit.
Building product with Aaron Sorkin's advice will get you funding, then put you in jail.
Ah, so this one: https://www.masterclass.com/classes/david-mamet-teaches-dram...
$200 is quite a steep commitment, but with this recommendation, I'll probably take it.
$200 is quite a steep commitment, but with this recommendation, I'll probably take it.
Contact information is in my profile. Please get in touch.
Thank you for this.
For the longest time I’ve been seeing the objects in my code as characters I. Stories, with messaging defining their relationships.
Will definitely check out the masterclass.
For the longest time I’ve been seeing the objects in my code as characters I. Stories, with messaging defining their relationships.
Will definitely check out the masterclass.
Short Answer : How to Design Programs (By: Sriram Krishnamurthi) http://htdp.org/2003-09-26/
Long Answer : Design Patterns are useful only in an OO Setting, its utility is gone if you look at Functional Languages. In FP you would have to consider more fundamental things than trying to cosmetically map a classical model to a domain, and then write bunch of code to retrofit that model.
Long Answer : Design Patterns are useful only in an OO Setting, its utility is gone if you look at Functional Languages. In FP you would have to consider more fundamental things than trying to cosmetically map a classical model to a domain, and then write bunch of code to retrofit that model.
Came here to mention HTDP.
Here's an anecdote. I have two friends who decided to take advantage of some COVID downtime to learn to code. I suggested they start by doing some HTDP, and they did. Now one is doing a bootcamp and the other is building his own apps. Both are doing Javascript, React, Ruby, a bunch of popular stuff.
I've interviewed and hired dozens of junior devs in my career, many of whom had already been on the job for a couple years. Most had only gone through a bootcamp. My two friends are far surpassing what any of those folks were capable of. They are able to understand these modern tools on a deeper level, not just copy-pasting or memorizing parts of an API.
I recommend it to anyone who wants to learn to code. Once you know fundamentally how to design functions, you can learn any of the trending technologies that might snag you a job. And you'll probably end up with higher quality, higher output, fewer bugs than your peers.
Here's an anecdote. I have two friends who decided to take advantage of some COVID downtime to learn to code. I suggested they start by doing some HTDP, and they did. Now one is doing a bootcamp and the other is building his own apps. Both are doing Javascript, React, Ruby, a bunch of popular stuff.
I've interviewed and hired dozens of junior devs in my career, many of whom had already been on the job for a couple years. Most had only gone through a bootcamp. My two friends are far surpassing what any of those folks were capable of. They are able to understand these modern tools on a deeper level, not just copy-pasting or memorizing parts of an API.
I recommend it to anyone who wants to learn to code. Once you know fundamentally how to design functions, you can learn any of the trending technologies that might snag you a job. And you'll probably end up with higher quality, higher output, fewer bugs than your peers.
I'm curious about your comment. I'm no longer a junior but I'm trying to invest more time into FP as I hear that it might make me a better problem solver. I see a lot of people recommending HTDP and SICP.
My question is, in your opinion what makes HTDP so good to make your friends learn unrelated things quicker than others? Do you think that is only a matter of designing functions or there's some other transferable skills too?
My question is, in your opinion what makes HTDP so good to make your friends learn unrelated things quicker than others? Do you think that is only a matter of designing functions or there's some other transferable skills too?
As a concrete example, not too long ago I saw an engineer spend a few days trying to use a React plugin for some UI thing. Another engineer eventually took it over and implemented the same UI thing from scratch, in about 50 lines of CSS and JS, in about 30 minutes. There were clearly two different approaches to the problem there!
What I see from many people (especially coming out of bootcamps) is that they learn one tool. They make one or two apps with it, the apps work fine, and so they believe they can do anything. That works great until they come up against something they haven't seen before. Once they do, they have no framework in their mind as to how they can move forward in solving the problem. All they know are those one or two tools. So if they can't find a plugin or something to copy/paste into those tools, they become lost.
HTDP is genius because it shows you how simple the fundamental process really is. They literally call it a "design recipe". It's basically understanding the shape of your data, defining inputs and outputs, and writing tests. With those ideas and some practice with that methodology, you can handle any situation that comes your way, forever.
It's not the junior engineers' fault, though. A lot of people in the industry speak in terms of tools. "We're looking for React people", etc. The idea that your skills are defined solely by the tools you know is widely accepted in startup circles. It's no wonder that bootcamps operate the way they do.
From what I have seen, the mythical "10x" programmers really do exist, and they're the ones who are really great at keeping it simple. They're not necessarily FP-oriented, just focused on writing simple code to accomplish a goal (and very good at it). HTDP is a great way to start down that path.
What I see from many people (especially coming out of bootcamps) is that they learn one tool. They make one or two apps with it, the apps work fine, and so they believe they can do anything. That works great until they come up against something they haven't seen before. Once they do, they have no framework in their mind as to how they can move forward in solving the problem. All they know are those one or two tools. So if they can't find a plugin or something to copy/paste into those tools, they become lost.
HTDP is genius because it shows you how simple the fundamental process really is. They literally call it a "design recipe". It's basically understanding the shape of your data, defining inputs and outputs, and writing tests. With those ideas and some practice with that methodology, you can handle any situation that comes your way, forever.
It's not the junior engineers' fault, though. A lot of people in the industry speak in terms of tools. "We're looking for React people", etc. The idea that your skills are defined solely by the tools you know is widely accepted in startup circles. It's no wonder that bootcamps operate the way they do.
From what I have seen, the mythical "10x" programmers really do exist, and they're the ones who are really great at keeping it simple. They're not necessarily FP-oriented, just focused on writing simple code to accomplish a goal (and very good at it). HTDP is a great way to start down that path.
Nice! Thanks a lot for that.
That really motivated me to check HTDP out!
That really motivated me to check HTDP out!
Link to the second and current edition: https://htdp.org/2018-01-06/Book/
I’ve always found it odd when people say there are no design patterns in FP. The same patterns do not translate, but different patterns exist, no?
New patterns emerge but not to solve the class of problems that Patterns solve. Many of the problems in OO, emerge due to OO's poor fit as a strategy to write software.
I’m very pro FP in general, but saying that its inherently more fit for writing software is a baseless claim. People are also unnecessarily harsh about OO, as if somehow the entire industry is operating orders of magnitude less efficiently then they would be if they just magically changed paradigm. FP has its own tradeoffs. Nothing is less trustworthy than a zealot who claims their religion is the one true answer.
Logic and software are fundamentally complex. Djikstra said that software is “radical novelty.” It exists at a scale beyond anything the human race has ever built before, that’s fairly inarguable. He was also very fond of imperative programming, and was able to formally verify his imperative programs. Check out his book, A Discipline of Programming, where he goes over the mathematical theory of a simple imperative language.
There’s nothing more “mathematically correct” about the lambda calculus vs. Turing machines. Both are equivalent models. Whether or not state is implicit or explicit, state and time are a part of computation.
Logic and software are fundamentally complex. Djikstra said that software is “radical novelty.” It exists at a scale beyond anything the human race has ever built before, that’s fairly inarguable. He was also very fond of imperative programming, and was able to formally verify his imperative programs. Check out his book, A Discipline of Programming, where he goes over the mathematical theory of a simple imperative language.
There’s nothing more “mathematically correct” about the lambda calculus vs. Turing machines. Both are equivalent models. Whether or not state is implicit or explicit, state and time are a part of computation.
I am not saying FP is a perfect fit, but since nothing ever is a atleast write something more reliable with less indirections.
I like FP for the simplicity of it, the problem with OO is overemphasis on structural design and frequent indirections to name every entity as a noun with its own set of Data structures and state maintenance routines.
To answer your question if Industry is operating less efficiently? Maybe but there is no empirical evidence for it.
Considering all things equal software is inherently complex and OO is a real world abstraction to solve the complexity, but we end up introducing more complexity than we start out to solve, which is why i consider going back to roots and try a different approach as OO didnt actually deliver on the promise.
Also thanks for the Book suggestion.
I like FP for the simplicity of it, the problem with OO is overemphasis on structural design and frequent indirections to name every entity as a noun with its own set of Data structures and state maintenance routines.
To answer your question if Industry is operating less efficiently? Maybe but there is no empirical evidence for it.
Considering all things equal software is inherently complex and OO is a real world abstraction to solve the complexity, but we end up introducing more complexity than we start out to solve, which is why i consider going back to roots and try a different approach as OO didnt actually deliver on the promise.
Also thanks for the Book suggestion.
Exactly. What's a monad, if not a design pattern.
Head First did it for me, visuals and the format of that book helped with such abstract and dry concepts.
I have found over recent years not having to dip into those concepts much, there are a lot of these patterns built into libraries and frameworks these days.
I have found over recent years not having to dip into those concepts much, there are a lot of these patterns built into libraries and frameworks these days.
They have a 2nd edition coming out this month https://www.oreilly.com/library/view/head-first-design/05960...
I would recommend picking up a free chapter of the old one to see if you like the style of presentation.
Personally I just love the way they present information.
I would recommend picking up a free chapter of the old one to see if you like the style of presentation.
Personally I just love the way they present information.
SICP is probably one of the only ones worth reading.
Others are just implementations of abstract ideas about how things belong and communicate.
Others are just implementations of abstract ideas about how things belong and communicate.
For me, nothing will replace the original GoF book:
"Design Patterns: Elements of Reusable Object-Oriented Software"
It's still worth reading. But I also recommend "Object-Oriented Analysis and Design with Applications" by Grady Booch. It's not strictly design patterns, but it's a classic that explores a lot of the fundamental concepts you'll need for DP.
Not a book. But if you are .NET / Azure centric I have found the team at MS Paterns and Practices to be very accessible ;)
http://aka.ms/mspnp
Game Programming Patterns is another resource that is quite clear
https://gameprogrammingpatterns.com/
http://aka.ms/mspnp
Game Programming Patterns is another resource that is quite clear
https://gameprogrammingpatterns.com/
Refactoring by Martin Fowler
Patterns of Software: Tales from the Software Community, by Richard Gabriel
Patterns of Enterprise Application Architecture
Spring of Java ORM is here,
ObjectiveSQL is an ORM framework in Java based on ActiveRecord pattern, which encourages rapid development and clean, codes with the least, and convention over configuration.
Features
1) With one annotation your Class has fully featured capabilities of SQL programming
2) Easy to relational(has_one, has_many, beglongs_to) querying and paged querying
3 Java expressions(arithmetic, comparison and logical) can be converted into SQL expression directly
ObjectiveSQL is an ORM framework in Java based on ActiveRecord pattern, which encourages rapid development and clean, codes with the least, and convention over configuration.
Features
1) With one annotation your Class has fully featured capabilities of SQL programming
2) Easy to relational(has_one, has_many, beglongs_to) querying and paged querying
3 Java expressions(arithmetic, comparison and logical) can be converted into SQL expression directly
I'm curious which of these or others have had the biggest impact on folks here, and which popular ones are worth skipping.