Live data from Hacker News

Talks that changed the way I think about programming

opowell.com

81–90 of 103 posts

Re: Talks that changed the way I think about programming

#81

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.

I vehemently disagree with you. He goes about in a very structured and objective style and you can also tell he has decades of experience to make informed statements. I think it's super interesting.

It might be not much news when you consider only the title statement, but it's the reasoning that talks are watched for, right?

Re: Talks that changed the way I think about programming

#82
post #14

The theological second half of this is bizarre - I've never heard of this being considered a "problem", heaven (in the Christian tradition) is not a hall of fame that one nominates figures for. And the Mormon tradition of proxy-baptising people who are dead and never showed any sign of adherence to their tenets is highly questionable.

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…

Thank you for clarifying. It seems like there is an unfair share of negative perceptions compared to other religions just because it's only ~200 years old.

Although I'm not a member, I lived in a 90% Mormon city for a few years and was made to feel very welcome and accepted.

Re: Talks that changed the way I think about programming

#83

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.

Watching his solution was the most painful part. His solution is to remove functions and put everything inline, and adding comments in the place of function names. To me, this sounds like a testing nightmare. It also sounds like a readability and maintainability nightmare.

Re: Talks that changed the way I think about programming

#84
post #83

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.

Watching his solution was the most painful part. His solution is to remove functions and put everything inline, and adding comments in the place of function names. To me, this sounds like a testing nightmare. It also sounds like a readability and maintainability nightmare.

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 do in which situations. Don't take anything too seriously or idealistically. Try to understand from the perspective of an honest presenter and apply your own judgement.

Re: Talks that changed the way I think about programming

#86

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 the layers.

He got some good points in his analysis with respect to fine granular OO design. The reasoning around the need to break encapsulation was illustrative. If objects are too small they will have a lot of surface area and their interconnection is hard to reason about. In OO programs control flow is not easily graspable from reading code. If the object graph is a tangled mess then the team will have an exciting time.

Pulling out the program flow into a large procedural piece of code can look attractive. In my experience such pieces of code incidentally are found in ..Service ..Manager classes the speaker is not so fond of. At times this may be a clearer and more effective approach than managing the object graph and distributing logic to messages. But going to procedures of several hundred lines is imho going to far.

When I think about it then software needs to be testable. If the objects are too trivial and a lot of logic is in their interconnection graph then the risk increases that the important bits are not tested - after all we got close to 100% coverage. But it is still possible to build the graph and test it in a meaningful way. Being OO I can instrument it too with test frameworks. That seems less the case with a longer piece of linear code.

Re: Talks that changed the way I think about programming

#87
post #27

These talks are a little skewed to the game/high performance programming side of the art, but still very interesting in general. Of the ones I've already seen I really like Mike Acton's talk. Since this has become such a nice thread some additions I'd add: * Sandi Metz going through the Gilded Rose or "All the small things" https://www.youtube.com/watch?v=8bZh5LMaSmE I already subscribed to her programming style and…

> 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?

Re: Talks that changed the way I think about programming

#88

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?

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

tl;dr Some Mormon leaders say it's incompatible with scripture, though the LDS church hasn't never said anything official.

Re: Talks that changed the way I think about programming

#89
post #9

This one by Bret Victor (or any of his other talks, really) also come to mind: https://vimeo.com/36579366

Yeah.

Firstly, maybe lastly, the conclusion of this video is real powerful stuff. I cannot pinpoint it's philosophical anchoring or origin. The same message was at the end of the iconic documentary about Jodorowskis Dune.

But

I have been trying to mentally operationalize the advice and ideas here, but found it really dificult and abstract.

Obviously an incredible lecture that deserves its own category.

Re: Talks that changed the way I think about programming

#90
post #83

Earlier quoted context omitted.

Watching his solution was the most painful part. His solution is to remove functions and put everything inline, and adding comments in the place of function names. To me, this sounds like a testing nightmare. It also sounds like a readability and maintainability nightmare.

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 permutation of every branch within that function in order to fully test the function. That's an order of magnitude more work. Don't even get me started on his stance on TDD (and how correlating it to the failure of OOP makes no sense at all).

And, yes, I understand that there can be pros. I've made my stance on the cons very clear, and I strongly feel as though they outweigh the pros. Does it make the moving parts more obvious? Probably sometimes. If you can't come up with good names, and your functions are small enough to begin with, probably. Better naming -- which the presenter addresses -- IMO does a much better job solving this though. His solution is to stop trying to name things, mine is to spend more time coming up with better names.

Post reply on HN