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

Ask HN: What books had the greatest effect on how you structure your code?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 162 posts

Re: Ask HN: What books had the greatest effect on how you structure your code?

#151

Post by gnaritas »

Ace17 wrote: post #87
brucephillips wrote: post #39

Earlier quoted context omitted.

Can you provide an example of how a language like C++ or Java would require a "design pattern" when another language wouldn't?

The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. So if you're using a functional langage, there's a good chance you're wondering why consider both of the above as "design patterns", as you're seing them as basic things, and the com…

> The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement).

The visitor pattern addresses doing multiple dispatch in a single dispatch language.

> The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects.

BTW, that's not really true; first class functions are not a replacement for commands. Commands are about turning behavior into state so it can be stored and executed, potentially replayed for example, at a later time. Commands aren't just functions, even languages that have first class functions still use the OO command pattern when doing things that benefit from command patterns.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#152

Post by dragonwriter »

gnaritas wrote: post #151
Ace17 wrote: post #87

Earlier quoted context omitted.

The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. So if you're using a functional langage, there's a good chance you're wondering why consider both of the above as "design patterns", as you're seing them as basic things, and the com…

> The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The visitor pattern addresses doing multiple dispatch in a single dispatch language. > The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. BTW, that's not really true; first class functions are not a replacement for commands. Comman…

> Commands are about turning behavior into state so it can be stored and executed, potentially replayed for example, at a later time.

First-class functions plus partial application do that trivially. (First-class functions provide the ability to store a generic command, partial application let's you get a specific instance with local state that can be “replayed” against a different external state object.)

Re: Ask HN: What books had the greatest effect on how you structure your code?

#153

Post by gnaritas »

dragonwriter wrote: post #152
gnaritas wrote: post #151

Earlier quoted context omitted.

> The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The visitor pattern addresses doing multiple dispatch in a single dispatch language. > The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. BTW, that's not really true; first class functions are not a replacement for commands. Comman…

> Commands are about turning behavior into state so it can be stored and executed, potentially replayed for example, at a later time. First-class functions plus partial application do that trivially. (First-class functions provide the ability to store a generic command, partial application let's you get a specific instance with local state that can be “replayed” against a different external state object.)

Again, you're missing the point of the command pattern. It is not replaceable by a first class function. I'm well aware of what first class functions are, what they can and can't do, and yes in the most trivial cases at run-time only where only a single action is required of the command, they can be used instead of a command pattern.

Many times commands come with multiple actions, to allow execution and rollback, require being able to be serialized to disk to database and replayed later, or are used to better organize and plug in extension commands to large code bases. None of these cases are amenable to first class functions.

The command pattern isn't just a hack around not having first class functions, we still use command even when first class functions are available. You aren't going to extend Photoshop with a new filter using a first class function; you're going to write a plugin which is a command pattern for filter execution.

Stop trying to tell me what first class functions can do, I'm fully aware, I use them every day and have for nearly 20 years. You aren't talking to some kid who never heard of functional programming.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#154

Post by abecedarius »

vram22 wrote: post #149
mikekchar wrote: post #103

Earlier quoted context omitted.

Here I was thinking, "I was never really influenced by books. I just read and wrote a lot of code." But you've reminded me that it's just wrong. Thinking Forth. Nearly 35 years later it still probably dominates my approach. Edit: Just realised that it is available under a CC license: http://thinking-forth.sourceforge.net/

>Thinking Forth. Nearly 35 years later it still probably dominates my approach. That's interesting. Can you elaborate on why you think it dominates your approach? I'm interested because I had read a good amount of Starting Forth by Leo Brodie some years ago, and liked the language, and had played around with it a bit (only got access to a Forth system for a short time, so could not go deeply into it, on the practical…

For me the biggest influences underemphasized in other sources are to be alert for relentless simplification, for 'mechanical sympathy', for ways changing your problem could make it much simpler to solve -- and that there's an agility in using a simpler programming system like a Forth which you grok and can change as you need to, which can sometimes outweigh the leverage of a big one that comes with lots of stuff already done for you. These are useful points of view even with Forth being almost never the most practical tool now. Its day was already passing when I learned it in the 80s.

Also, though I don't think this was quite in the book, it helped lead me to the idea of refactoring and its synergy with automated testing almost a decade before the idea started spreading.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#155

Post by chinhodado »

Denzel wrote: post #78
blub wrote: post #68

Earlier quoted context omitted.

Code complete is a classic. Clean code will teach you how writing 3 line functions is a best practice. It's an overhyped, overrated book which is more damaging than helpful and one of the very few I couldn't stand to read until the end due to the authors' dogmatic views.

That's interesting, I had the complete opposite reaction to clean code. As a person that recommends this book, with full heart, to every developer, I'd like to hear any details you could spare re: why you believe it's damaging? Maybe you can provide some examples of well-written codebases and why you believe they're such? And maybe you could comment on why you feel Clean Code's principles harm readability with some e…

The problem with Clean Code is, just as the post you replied on said, it's very dogmatic. A problem I often see people who quote Clean Code do is that they take its principles to the extreme.

An example is tons of tiny methods of 1-3 lines each. Sure splitting up methods is good practice but it's painful to read code where you continuously have to "go to definition". There is an article written about this by John Carmack here http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Another example is the "comment are a failure" mindset. Sure I don't need comments that say this code is doing an addition between two numbers, but a piece of code doing some complex business logic definitely benefits from a comment explaining what the hell it's doing. No amount of function-splitting and function-naming can replace such comments. Yet all too often people who read Clean Code treat comments as some sort of abominations that has to be avoided at all cost.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#156

Post by kbp »

gnaritas wrote: post #145
kazinator wrote: post #143

Earlier quoted context omitted.

Lambdas aren't "ugly"; they are sometimes just a mechanism that is not directly relevant to the problem domain: the "how" part of the solution, rather than "what". The point isn't to hide the lambdas, but to hide the "how", which might or might not use lambdas. The "how" could instead open-code the procedure that would have otherwise called the lambdas; then the material just becomes embedded forms in the inline code…

Lets not kid ourselves, hiding lambda's is one of the primary uses of macros in Lisp (obviously not the only). Yes, you're hiding the "how", we don't disagree there, but my point was that such syntactic abstraction is only necessary in Lisp because it's so ugly to directly use lambda. Compare to Smalltalk which uses naked lambda's everywhere because they're nice looking as is and don't need to be hidden away by speci…

> Lets not kid ourselves, hiding lambda's is one of the primary uses of macros in Lisp (obviously not the only). Yes, you're hiding the "how", we don't disagree there, but my point was that such syntactic abstraction is only necessary in Lisp because it's so ugly to directly use lambda. Compare to Smalltalk which uses naked lambda's everywhere because they're nice looking as is and don't need to be hidden away by special forms in order to feel idiomatic.

Hiding lambdas with macros isn't really that common in my experience. The "how" being hidden is much more often (ultimately) IF, LET, BLOCK, and GO. Of course, higher order functions could often be used instead, but they're generally not.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#157

Post by Ace17 »

gnaritas wrote: post #151
Ace17 wrote: post #87

Earlier quoted context omitted.

The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. So if you're using a functional langage, there's a good chance you're wondering why consider both of the above as "design patterns", as you're seing them as basic things, and the com…

> The Visitor pattern mostly addresses the shortcomings of the type system (i.e no "match" statement). The visitor pattern addresses doing multiple dispatch in a single dispatch language. > The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects. BTW, that's not really true; first class functions are not a replacement for commands. Comman…

> > The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects.

> BTW, that's not really true; first class functions are not a replacement for commands.

Please note that you're extrapolating from my post: this isn't what I said.

We still need this pattern: there's no way you're going to implement "undo" using only first-class functions, and I'm well aware of that.

In some specific situations, though, we don't need it anymore, like when connecting a GUI "save" button to a "document.save" function.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#158

Post by mikekchar »

abecedarius wrote: post #154
vram22 wrote: post #149

Earlier quoted context omitted.

>Thinking Forth. Nearly 35 years later it still probably dominates my approach. That's interesting. Can you elaborate on why you think it dominates your approach? I'm interested because I had read a good amount of Starting Forth by Leo Brodie some years ago, and liked the language, and had played around with it a bit (only got access to a Forth system for a short time, so could not go deeply into it, on the practical…

For me the biggest influences underemphasized in other sources are to be alert for relentless simplification, for 'mechanical sympathy', for ways changing your problem could make it much simpler to solve -- and that there's an agility in using a simpler programming system like a Forth which you grok and can change as you need to, which can sometimes outweigh the leverage of a big one that comes with lots of stuff alr…

Yes, this is pretty much the same as me. The focus of Thinking Forth (as much as I remember it -- I should re-read it now that I can download it) is about creating small words that you can compose. The idea was that you could interactively tests the words as you were writing the code. FORTH is a bit like Smalltalk in that the environment is always loaded, so you're always jumping in and out of the editor to try things.

Later when I learned about refactoring and TDD, it felt really natural. Until now I hadn't made the connection, but it was exactly the same thing I was doing when I was writing FORTH code.

I also program everything bottom up, rather than top down. I'm pretty sure this is from the influence Thinking Forth had on me as a programmer. I'll make a mental sketch of how things will fit together overall, pick a spot, drill down and then start building the pieces I'm going to need. I refactor as I go. Finally I plug everything together. This also leads me to do subsystem decomposition very, very late in the process. Only after I've built the pieces do I start thinking about where they should ultimately end up. This makes refactoring a lot easier: first when you are building the pieces because you don't have to jump through hoops to get at things, and second when you are assembling because the pieces will naturally fall into places based on what data they interact with. If you have problems understanding where a piece should go, then it's a good indication that you have more refactoring to do.

Some people hate the way I do evolutionary design :-) It works for me, though.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#159

Post by gauravhp »

leksak wrote: post #82

Game Programming Patterns - without a doubt. Own it in print, but usually only read it online. To me it's a more exciting read than the GoF book http://gameprogrammingpatterns.com/contents.html

Thanks for providing online version. Where I am staying I cannot purchase most of these books mentioned in this thread.

Re: Ask HN: What books had the greatest effect on how you structure your code?

#160

Post by abecedarius »

mikekchar wrote: post #158
abecedarius wrote: post #154

Earlier quoted context omitted.

For me the biggest influences underemphasized in other sources are to be alert for relentless simplification, for 'mechanical sympathy', for ways changing your problem could make it much simpler to solve -- and that there's an agility in using a simpler programming system like a Forth which you grok and can change as you need to, which can sometimes outweigh the leverage of a big one that comes with lots of stuff alr…

Yes, this is pretty much the same as me. The focus of Thinking Forth (as much as I remember it -- I should re-read it now that I can download it) is about creating small words that you can compose. The idea was that you could interactively tests the words as you were writing the code. FORTH is a bit like Smalltalk in that the environment is always loaded, so you're always jumping in and out of the editor to try thing…

Good points. Another influence I think it had: an attitude like "what one fool can do, another can". While this doesn't directly affect how you organize programs, it can arm you against cargo-culting what you read elsewhere. You do have to watch out for culting up Forth!
Post reply on HN