Live data from Hacker News

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

news.ycombinator.com

51–60 of 162 posts

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

#51

Are books still state of the art in 2017? I would assume all the best knowledge could be found online for free by now.

A book can be coherent and curated in a way that a collection of posts by different authors cannot be.

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

#52
A Mentoring Course in Smalltalk[0]. I was really surprised, after reading and really loving Design Patterns, that there was still so much to say about OO design.

I did love Design Patterns a lot though. Purely Functional Data Structures by Chris Okasaki was also really useful for Haskell, as was Real World Haskell.

Programming Prolog probably had a bigger influence on my Prolog than the other books, even though I read Art of Prolog and Prolog Programming in Depth first. Especially the latest edition, it's a really beautiful book.

[0]: http://www.lulu.com/us/en/shop/andres-valloud/a-mentoring-co...

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

#53

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'm nearing 50 so I'm hardly a youth.

http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong.

See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Resulting in code that I, for one, would rather not work with.

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

#54

Earlier quoted context omitted.

> Design patterns exist because common solutions to problems exist, not because OO has serious problems Implementation-recipe design patterns only need to exist (or, rather, only need to be part of the active, day-to-day awareness of more than a small number of programmers per language) when the target language does not support implementing the common solutions as reusable code modules because doing so would require…

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

In early Java versions, functions were not objects, and therefore could not be passed as parameters. So you needed patterns such as Command or Observer. In Javascript, for example, you wouldn't need them. More recent versions of Java, with the introduction of lambdas for example, are also reducing the need for these patterns.

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

#55

Are books still state of the art in 2017? I would assume all the best knowledge could be found online for free by now.

Online resources are often shallow in content. I prefer to deep dive into a topic and truly learn it inside and out by reading a good book. Blogs and tutorials don't give you that deep insight.

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

#56

Earlier quoted context omitted.

> Design patterns exist because common solutions to problems exist, not because OO has serious problems Implementation-recipe design patterns only need to exist (or, rather, only need to be part of the active, day-to-day awareness of more than a small number of programmers per language) when the target language does not support implementing the common solutions as reusable code modules because doing so would require…

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

I'm not the person you asked, and not a patterns expert, but will try to answer, using the Template Method Pattern (a GoF book pattern) [1] as an example:

- In Java [2] or C++, to implement that pattern, you may have to define an abstract class, or a class with some abstract and some concrete methods, and subclass it, and in the subclass, redefine some of the abstract methods (of the superclass) concretely. (Maybe interfaces can be used here instead of abstract classes/methods - in Java. Haven't used Java for a while, so not sure right now.)

- In Python, you can just do:

def transform(input, output):

    # Code here to read data from input, transform it, and 
    # write the transformed data to output.
Now let's say the code in the transform function does input.read() and output.write() (with maybe some way to indicate when the end of input is reached, like the null string is used in Python). In other words, methods like those of Python file objects are used for reading and writing. Given all this, you can now pass objects of any types as arguments for the input and output parameters, as long as they implement a read and a write method respectively, and the code will just work.

This has been described as "smooth seamless polymorphism" in Python. It's also known as duck typing.

https://en.wikipedia.org/wiki/Duck_typing

[1] The Template Method Pattern is one of the ways in which frameworks (as opposed to libraries) are implemented. The abstract methods of the framework are implemented concretely by your code that the framework then calls, using the Hollywood principle - Don't call me, I'll call you, a.k.a. Inversion of Control (IoC).

https://en.wikipedia.org/wiki/Template_method_pattern

https://en.wikipedia.org/wiki/Inversion_of_control

[2] Note that what I wrote is based on knowledge of older versions of Java - newer versions may have features that make the pattern simpler to implement, maybe without abstract classes/methods.

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

#57
post #43

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.

Ditto for both books, though I prefer The Effective Engineer to The Pragmatic Programmer. I found that quite a bit of the tactical advice in TPP is already standard practice (e.g. "always use source control"). Comparatively, TEE has more of an emphasis on project planning and team/company health, and I found that more useful for my work.

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

#58
post #19

Of lesser-known books, Avdi Grimm's "Confident Ruby": http://www.confidentruby.com/ Learning Ruby itself was a huge influence to me; hadn't considered that a language should be designed to make programmers "happy", as Matz said. "Confident Ruby" was one of several books that had this human-happiness focus. "Confident" is broken down into patterns, many of which can be found in books like Sandi Metz's POODR, but as a…

Avdi is a phenomenal teacher in my opinion and doesn't get the airtime he deserves. If you use ruby in any capacity, I highly recommend subscribing to his Ruby Tapas.

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

#60
How To Write Unmaintainable Code by Roedy Green.

The best way to write better code is to avoid writing it badly in the first place. But you need to know how to write bad code to write code better than it. Definitely a different way of learning how to write good code, also a good laugh for anyone in industry.

Post reply on HN