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

41–50 of 162 posts

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

#41

Post by danso »

caseysoftware wrote: post #35
artursapek wrote: post #25

Earlier quoted context omitted.

Ruby makes programmers happy while they're writing their sexy new code base. It makes them cry when it's time to refactor it.

I don't know why you're being voted down.. even Avdi Grimm supports that: http://www.virtuouscode.com/2015/08/11/what-its-like-to-come...

I didn't downvote but I suspect whoever did saw the GP comment as bashing Ruby and being off-topic, even though some of my comment talked about Ruby's philosophy as a whole (though I felt it was important to include the context in which Grimm's philosophy is grounded).

FWIW, I almost never use Ruby today, having switched to Python for both teaching and development purposes. That doesn't mean that learning Ruby didn't influence me. For starters, it taught me the dangers of giving programmers too much syntactic freedom :).

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

#42

Post by kazinator »

gnaritas wrote: post #21
jcmoscon wrote: post #15

On LISP, by Paul Graham. LISP was the second language I learned in college, but only after 6 years programming Java and C# that I came back and really learned LISP. It was when I realized that I was doing everything wrong. For example design patterns exists because OO has serious problems that we don't find in a functional programming language and you only see this when you understand both paradigms.

Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…

Design Patterns is about typing out boilerplate code by hand to solve a problem, because the language doesn't have the expressivity to encode the same solution directly.

When it does have the expressivity, the underlying rendering of the pattern hasn't gone away; just the manual boiler-plate for producing it.

For instance, if you're working in assembly language, then you might sometimes benefit from a "while loop design pattern" to keep your code clean. The while loop design pattern calls for some test code before a block which jumps past the block when the test is negative, and an unconditional backward branch at the end of the block back to that test expression.

The while loop doesn't go away when you use a higher level language. You just indicate that you would like that pattern, and the compiler spits it out for you, invisibly.

> Every time you pass a lambda to a higher order function you're using a strategy pattern.

Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you.

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

#43

Post by vram22 »

DanHulton wrote: post #6

Code Complete, Steve McConnell. http://www.stevemcconnell.com/cc.htm One of the best books on programming style and function, backed up with actual research for the recommendations.

Same opinion. I always recommend it to my programming students.

Also, The Pragmatic Programmer is good, for topics both about programming and beyond programming per se.

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

#45

Post by swift »

gnaritas wrote: post #21
jcmoscon wrote: post #15

On LISP, by Paul Graham. LISP was the second language I learned in college, but only after 6 years programming Java and C# that I came back and really learned LISP. It was when I realized that I was doing everything wrong. For example design patterns exists because OO has serious problems that we don't find in a functional programming language and you only see this when you understand both paradigms.

Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…

That's true. I think the GP's point was probably that some GoF patterns, specifically, just exist to work around language deficiencies. My go-to example for that is the visitor pattern; something that's trivial in Haskell or Lisp is ridiculously heavyweight in C++ or Java.

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

#48

Post by jdmichal »

sideshowb wrote: post #24
gnaritas wrote: post #21

Earlier quoted context omitted.

Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…

Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better or worse. It took me from understanding OO to understanding how to build large systems with OO, writing maintainable code and using proper encapsulation. A much deeper work than Code Complete (though the latter is worth reading too). I have used functional lang…

I don't think design patterns went out of fashion. I think the opposite happened -- they gained such mindshare that they became a solution looking for a problem for many people. That is, they forgot that design patterns are meant to solve problems, and that you should also only solve problems that actually exist. Instead we started getting things that resembled "Hello World Enterprise Edition" [0], which has been dubbed "lasagna code" -- lots of layers with a little bit of filling in each one.

[0] https://gist.github.com/lolzballs/2152bc0f31ee0286b722

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

#49

Post by kazinator »

btilly wrote: post #40
gnaritas wrote: post #21

Earlier quoted context omitted.

Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…

The parent comment is a variation of the well-known claim from http://wiki.c2.com/?DesignPatternsInDynamicProgramming which says that in a more powerful language, a variety of design patterns go away and become invisible. And Lisp in particular renders many common patterns irrelevant.

The irony is that the languages which are the targets of design patterns already encode considerable design patterns from a previous generation of language research.

Those languages are higher-level languages. A considerable number of design patterns disappears in them already.

In Java or C++, you have functions with parameters and local variables.

In assembly language, there is a "design pattern" of pushing words onto a stack to generate arguments, and moving the stack pointer to reserve a frame for local variables, and then unwinding these actions when the function returns. Also, saving certain registers and restoring them may be part of the pattern. This pattern can be supported with macros and pseudo-ops to varying degrees.

In these higher level language, this pattern disappears. The concept of parameters and local variables doesn't disappear, of course. Those things are just declared in a simple way.

The assembly language pattern for calling conventions is in fact a back-formation from higher level languages. It won't even occur to assembly language programmers until they think of their programs at a higher level, and translate from that to machine code.

Or: let's look at C++ vs C. In C++, there are declarative mechanisms which generate code that can be understood in terms of C. It captures coding patterns, such as ensuring that a structure is properly initialized when instantiated, and cleaned up on every exit path from a function.

Post reply on HN