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

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

#141

Post by gnaritas » Tue, Jul 25, 2017, 5:36 PM UTC

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…

Functional languages have a different set of patterns.

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

#142

Post by gnaritas » Tue, Jul 25, 2017, 5:39 PM UTC

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.

And yet Lisp, the language that can abstract anything, still has design patterns because there's no such thing as a language without patterns that are useful to solve common problems.

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

#143

Post by kazinator » Tue, Jul 25, 2017, 6:06 PM UTC

gnaritas wrote: post #138

kazinator wrote: post #42

Earlier quoted context omitted.

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 des…

> Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you. True but equally sad that you must use Lisp to hide ugly Lisp because naked lambda's are so ugly. Yet the point remains, whether hidden behind a macro or not, design patterns still exist in Lisp and every other language and always will.

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.

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

#144

Post by kazinator » Tue, Jul 25, 2017, 6:10 PM UTC

icebraining wrote: post #117

kazinator wrote: post #74

Earlier quoted context omitted.

OO doesn't have serious problems. Crap implementation of OO bolted onto Algol derivatives has problems.

Yeah, OO as commonly used is not the OO as originally envisioned and implemented: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

Speak of the devil; I just got +10 points an a "necromancer badge" for this:

https://stackoverflow.com/questions/327955/does-functional-p...

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

#145

Post by gnaritas » Tue, Jul 25, 2017, 6:29 PM UTC

kazinator wrote: post #143

gnaritas wrote: post #138

Earlier quoted context omitted.

> Every time you pass a "naked" lambda somewhere, you're potentially missing the opportunity to have a macro there do that for you. True but equally sad that you must use Lisp to hide ugly Lisp because naked lambda's are so ugly. Yet the point remains, whether hidden behind a macro or not, design patterns still exist in Lisp and every other language and always will.

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 special forms in order to feel idiomatic.

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

#146

Post by btschaegg » Tue, Jul 25, 2017, 8:06 PM UTC

kazinator wrote: post #74

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.

OO doesn't have serious problems. Crap implementation of OO bolted onto Algol derivatives has problems.

That was also the impression I got on this issue; however nowadays I'm usually less frustrated with what the respective languages provide and more with what people use them for.

C++ since 11, C# since ~5 and Java 9 for example have actually introduced very useful tools¹ that would allow people to write much more readable code - yet there's always someone who insists that anything beyond the C++98-style is somehow evil and inherently unreliable.

¹Yes, they're by no means perfect, but they introduce are a lot of low-hanging fruit when it comes to improving code quality - if one decides to use them...

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

#147

Post by btilly » Tue, Jul 25, 2017, 8:09 PM UTC

gnaritas wrote: post #137

btilly wrote: post #53

Earlier quoted context omitted.

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. Result…

Yegge critiquing OO for verbosity, that's a hoot; talk about the pot calling the kettle black.

But only a person as verbose as Yegge can really on about Java at sufficient length to do the topic justice.

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

#148

Post by beagle3 » Tue, Jul 25, 2017, 10:09 PM UTC

Essays, not books, but ... everything Ken Iverson wrote:

The Description of Finite Sequential Processes http://www.jsoftware.com/papers/DFSP.htm (see e.g. the concrete implementation of the Simplex algorithm , the hamming code corrector). It shows that, with the right primitives and notation, a lot of things are simple and elegant. It's not an necessarily an easy read (depending on your math level and background), but it is a very rewarding one.

Notation as a tool of thought http://www.jsoftware.com/papers/tot.htm - a longer introduction.

Bottom line: a different take on abstraction. It makes a huge difference when you peel most abstraction layers.

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

#149

Post by vram22 » Tue, Jul 25, 2017, 11:09 PM UTC

mikekchar wrote: post #103

abecedarius wrote: post #13

Thinking Forth; Software Tools; SICP; Abstraction and Specification in Program Development; Essentials of Programming Languages; Paradigms of AI Programming; I'd like to list something about OO too, but no book I know really measures up to learning from other programmers. But there's Mark S. Miller's thesis Robust Composition. (in roughly chronological order. As you can see from the chronology, it took me a long time…

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 side). But I remember liking the language. I don't think I have read Thinking Forth.

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

#150

Post by gnaritas » Tue, Jul 25, 2017, 11:19 PM UTC

btilly wrote: post #147

gnaritas wrote: post #137

Earlier quoted context omitted.

Yegge critiquing OO for verbosity, that's a hoot; talk about the pot calling the kettle black.

But only a person as verbose as Yegge can really on about Java at sufficient length to do the topic justice.

You mean misrepresent the topic and play off bad programming as if OO were the problem; you can write shitty code in any language in any paradigm. Java was verbose because it was Java and it lacked many features other language had to remove that verbosity; it wasn't verbose because it was OO. Yegge was spewing shit for traffic at the time, nothing more, his critiques were baseless.