Talks that changed the way I think about programming • Hacker News Board

Re: Talks that changed the way I think about programming

#91

Post by lj3 » Thu, Dec 08, 2016, 8:11 PM UTC

heisenbit wrote: post #86

SonicSoul wrote: post #56

tried listening to why OOP is bad and it was painful. 10 minutes in and 0 insights. He kept saying things like "encapsulation doesn't work" and then moving on. Not willing to stay another 20 min to find out why.

Mixed feelings about the talk. Encapsulation and breaking encapsulation can be key. I started in networking and had the clean OSI/ISO stack pictures in my mind. Then looking at the management plane of a network stack TCP protocol, the transport layer details and a few other telco network stacks I started understanding the really interesting bits happen at the edges where the layers meet. Some applications cut across…

There are three talks, actually. Here are the other two.

Object-Oriented Programming is Embarrassing: 4 Short Examples[0]

Object-Oriented Programming is Garbage: 3800 SLOC example[1]

[0]: https://www.youtube.com/watch?v=IRTfhkiAqPw [1]: https://www.youtube.com/watch?v=V6VP-2aIcSc

Re: Talks that changed the way I think about programming

#92

Post by jstimpfle » Thu, Dec 08, 2016, 8:59 PM UTC

lojack wrote: post #90

jstimpfle wrote: post #84

Earlier quoted context omitted.

Solution to what? I think you are missing the context of his statement here. Inlining functionality to very large procedures has the advantage that it makes obvious that there are no moving parts. You look at a few lines and know exactly the execution context. This improves readability a lot. Maybe just try it before calling it a nightmare. Most things in life have pros and cons, the difficulty is to decide what to d…

> Maybe just try it before calling it a nightmare. I spent the first ~5 years of my career writing code in this fashion. I actually agreed with most of the talk, but this section was a big sticking point with me. Inlining functionality to large procedures has the disadvantage that you need to understand the entire procedure to know what the function does. It also has the disadvantage that you need to test the permuta…

Thanks for clearing up. He did address the "understanding the entire procedure to know what the function does" part by light use of code comments.

Personally I'm not much invested in testing (most of my programming is recreational) but I fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things. The two small ones have obviously more possible code paths since the smaller, driven function is not hidden in the driver function anymore, so can be called in ways that don't actually matter to the purpose of the program. (That's the authors point - he calls it "surface area").

Re: Talks that changed the way I think about programming

#93

Post by pmoriarty » Thu, Dec 08, 2016, 11:08 PM UTC

joaorico wrote: post #7

Alan Kay's intro quote is from this interview to Dr.Dobb's [0]. Here's some more context to that quote: "Binstock: Are you still programming? Kay: I was never a great programmer. That's what got me into making more powerful programming languages. I do two kinds of programming. I do what you could call metaprogramming, and programming as children from the age of 9 to 13 or 14 would do. I spend a lot of time thinking a…

"Kay: I was never a great programmer."

I wonder how Kay would score on sites like HackerRank, and how many companies today would pass him over because of that.

Re: Talks that changed the way I think about programming

#94

Post by chiefalchemist » Fri, Dec 09, 2016, 3:13 AM UTC

thristian wrote: post #26

I suspect a lot of these video are the most powerful when you encounter them at exactly the time you happen to be wrestling with those same ideas yourself. Every time I design software, I'm think back to Gary Bernhardt's "Boundaries" talk¹ and his practical, concrete suggestions for writing testable code. But I've never met anybody else who seemed as impressed as I was by the idea. ¹: https://www.destroyallsoftware.c…

Thx for this.

Re: Talks that changed the way I think about programming

#95

Post by chiefalchemist » Fri, Dec 09, 2016, 3:14 AM UTC

Szel wrote: post #87

vvanders wrote: post #71

Earlier quoted context omitted.

> These talks are a little skewed to the game/high performance programming side of the art, but still very interesting in general. I get the chance to interact with a pretty wide range of software engineers, the thing that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it(and have the time to exploit it). It's almost like they don't teach…

> that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it Could you point to some sources?

+1

Re: Talks that changed the way I think about programming

#96

Post by tinco » Fri, Dec 09, 2016, 12:28 PM UTC

Szel wrote: post #87

vvanders wrote: post #71

Earlier quoted context omitted.

> These talks are a little skewed to the game/high performance programming side of the art, but still very interesting in general. I get the chance to interact with a pretty wide range of software engineers, the thing that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it(and have the time to exploit it). It's almost like they don't teach…

> that constantly blows people's minds is how caches work and the fact that there's 10-50x performance waiting for you if know about it Could you point to some sources?

This is the paper people usually use to explain some of the performance benefits you could reap, besides the talk about row vs column based performance:

https://www.akkadia.org/drepper/cpumemory.pdf

Note that I wouldn't really recommend it unless you're really going to do low level programming for high performance. It's super long, explains all the details, if you've got a basic CS college education you should know most of it already anyway.

If you're just a web developer this won't actually help you as most of this improvements have already been done in the parts that matter (i.e. your database, your operating system, your interpreter and perhaps your application server).

Re: Talks that changed the way I think about programming

#97

Post by lojack » Fri, Dec 09, 2016, 1:44 PM UTC

jstimpfle wrote: post #92

lojack wrote: post #90

Earlier quoted context omitted.

> Maybe just try it before calling it a nightmare. I spent the first ~5 years of my career writing code in this fashion. I actually agreed with most of the talk, but this section was a big sticking point with me. Inlining functionality to large procedures has the disadvantage that you need to understand the entire procedure to know what the function does. It also has the disadvantage that you need to test the permuta…

Thanks for clearing up. He did address the "understanding the entire procedure to know what the function does" part by light use of code comments. Personally I'm not much invested in testing (most of my programming is recreational) but I fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things. The two small ones have obviously more possible code paths si…

> fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things

It's understandable how you wouldn't see this without testing experience. Wrote a quick gist to try to explain it as best as I could. https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37...

That's a trivial example using pseudocode. But, basically, you'll see that in the longer function example you need 10 test cases to cover all grounds, while in the method thats split apart you need 8. Realistically, I could have further split parseArguments up to simplify those test cases. It seems like a small change, but if you were to add an additional branch to the first method (an if statement) then you'd double the number of tests required. For the longer method thats 10 additional test cases, for the shorter method thats 2.

Re: Talks that changed the way I think about programming

#98

Post by Fuzzy_Logic » Fri, Dec 09, 2016, 2:39 PM UTC

nurettin wrote: post #72

Fuzzy_Logic wrote: post #60

Earlier quoted context omitted.

Mormon and long time lurker here. Just wanted to give clarity to this because it can be confusing. Mormons don't believe they are forcibly baptizing these people by proxy. They believe that everyone should have the opportunity to accept baptism and salvation through Jesus Christ, even if they did not receive the opportunity in the mortal stage of life: "Individuals can then choose to accept or reject what has been do…

Hi, sorry if this comes off as offensive, but is there a general consensus in mormonism about a gradual evolution of life on earth?

Sorry for the delayed response. As paulddraper there is no official doctrine on evolution, but Mormons do not believe in "Creatio ex nihilo" or that the creation of the earth was literally a seven day period. The "days" of the creation story are meant to mean periods of time, and we do not fully understand how God created the earth or that evolution was not necessarily a part of it. Mormons do not accept a lot of the "standard" Christian teachings on creation that actually stem from the Greek/Roman philosophical influence in early Christianity and not from scripture. Our official doctrine encourages us to seek to learn and understand the will and processes of God through science in addition to spiritual experiences.

"Latter-day Saints should strive to use both science and religion to extend knowledge and to build faith." "Is there any conflict between science and religion? There is no conflict in the mind of God, but often there is conflict in the minds of men." http://en.fairmormon.org/Mormonism_and_science/Are_they_comp...

More Sources: http://en.fairmormon.org/Mormonism_and_science/Evolution/Off... http://en.fairmormon.org/Mormon_view_of_the_creation

Re: Talks that changed the way I think about programming

#99

Post by jhayward » Fri, Dec 09, 2016, 3:11 PM UTC

pmoriarty wrote: post #93

joaorico wrote: post #7

Alan Kay's intro quote is from this interview to Dr.Dobb's [0]. Here's some more context to that quote: "Binstock: Are you still programming? Kay: I was never a great programmer. That's what got me into making more powerful programming languages. I do two kinds of programming. I do what you could call metaprogramming, and programming as children from the age of 9 to 13 or 14 would do. I spend a lot of time thinking a…

"Kay: I was never a great programmer." I wonder how Kay would score on sites like HackerRank, and how many companies today would pass him over because of that.

I wonder, if you had some impossible deadlines and a ton of code you had to write just to survive to the next funding round, would you want Alan Kay on your team? I say this with enormous respect and admiration for Kay, but there are horses for courses and groundbreaking ideas are not the same as shipping product.

Re: Talks that changed the way I think about programming

#100

Post by jstimpfle » Fri, Dec 09, 2016, 3:54 PM UTC

lojack wrote: post #97

jstimpfle wrote: post #92

Earlier quoted context omitted.

Thanks for clearing up. He did address the "understanding the entire procedure to know what the function does" part by light use of code comments. Personally I'm not much invested in testing (most of my programming is recreational) but I fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things. The two small ones have obviously more possible code paths si…

> fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things It's understandable how you wouldn't see this without testing experience. Wrote a quick gist to try to explain it as best as I could. https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37... That's a trivial example using pseudocode. But, basically, you'll see that in the longer function ex…

Realize that both implementations offer the same functionality. You could even say the implementations are basically identical, except for the fact that one gives more "calling surface". So it is is only the "ideal" of 100% branch coverage that misleads you into think you would need more tests.

The two branches of the big function don't interact in any way (they could also be paralleized), so 100% branch coverage has no benefit here.

In fact you need less tests with the big function if you don't know the context in which the functionality is used, since the surface area is smaller.

Another way to look at it is that 100% branch coverage only means all the branches in one isolated function are tested. However, the multiple-functions version calls other functions and the possible branches there are ignored. In other words the interaction with called functions is not tested.