Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Concepts that clicked only years after you first encountered them?

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 946 posts

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#181

Post by sureglymop »

zabzonk wrote: post #121
rolenthedeep wrote: post #110

It took me an embarrassing amount of time to fully grok what object oriented programming really means. It's one thing to have someone tell you what an object is, but it's another thing entirely to build a fully object oriented system. I remember what made it click: I was designing an animation system, which had a bunch of different interdependent moving parts. Once I started treating each part like an object and lett…

I've always found OO programming completely natural. n fact, it's the only kind of programming i've ever really done - create a structure with data members, and then create functions to work on that structure. you can (and should) do this in low-level languages such as C and assembler. Of course, if you want to go the whole polymorphic route, i'd suggest using something like c++, but the key ideas are really structur…

I've always had a hard time because I was thinking.. why would I carry the performance hit of instantiating objects for a bunch of stuff?

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#182

Post by mrloba »

adlpz wrote: post #41
monero-xmr wrote: post #23

Earlier quoted context omitted.

Another solution is to eliminate classes and only use structs or similar plain objects. Makes mocking and testing functions much easier. At this point I see no reason for OOP whatsoever and consider it a big mistake.

I agree with OOP not being needed at all, but I don't agree on this being an alternative to dependency injection. However you structure it, there will always be "glue code" that ties the nice inmutable code with the outside-interacting bits, and if you want to unit test those, dependency injection (with functions or state, not classes or instances) is still the way to go.

True, but there might not be a big need for unit testing the glue code. By its very name it doesn't contain much logic to test. Integration tests are more valuable in this case.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#183

Post by LAC-Tech »

I'm currently doing a dive into classic distributed systems papers, mainly from the 70s (actor model, logical clocks, that kind of stuff).

I'd "understood" the concepts before, but now because I am:

- brushing up on my math to understand every equation or proof they drop in there

- reading them in combination with applied stuff that uses the same concepts, ie the "designing data intensive applications book"

- reading over them slowly, I want my fundamentals to be strong and etched into my head

Things are clicking in a way they never did before.

TL;DR - studying compsci concepts, slowly, from multiple angles (completely mathematical to practical engineering) is just a different level of understanding from doing one or assuming your mind will bridge the gap.

YMMV.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#184

Post by clarkdale »

hospadar wrote: post #154

Voltage and amperage for me, years after a college electronics course and a childhood of soldering kits I finally started to get it. I was always tripped up with analogies about how it's like water in a pipe or something, which can be useful, but aren't quite right.

I would love to hear this in a way other than water in various sized pipes.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#185

Post by dymk »

everybodyknows wrote: post #14
bsuvc wrote: post #2

Unit testing and using dependency injection to write test-able code. I'm not sure if it was years, but it wasn't immediate. I just didn't understand why dependency injection was good at first, and not just someone's weird personal code style choice. I thought it was just people being "Enterprisey" which I'd encountered many times over the years. Once I committed to unit testing, I realized how necessary it is. Unfort…

> dependency injection The term is unfamiliar to me -- is it related to "fault injection"?

You'd do fault injection by injecting dependencies that respond with / throw faults.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#186

Post by marmetio »

fooblaster wrote: post #57
ergonaught wrote: post #3

Basic music theory. Almost no one I encountered bothered to actually explain anything. They simply regurgitated things and I guess expected me to somehow intuitively understand something or other.

Any good resources that do it the right way?

I've been using Punkademic and I'm very happy with it.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#187

Post by Cyph0n »

delecti wrote: post #139
sanderjd wrote: post #85

Earlier quoted context omitted.

Yep, I think mocks are mostly a smell. The "functional core" of a module should be entirely or almost entirely unit testable with (possibly fake) dependencies passed in. The glue code ("imperative shell") should be tested at a higher level - "integration" or "end to end" or whatever you want to call it - which looks at the externally observable effects of running the code (database changes or API responses or whateve…

How are mocks a smell if "unit testable with (possibly fake) dependencies" is okay? That's what mocks are. Or do you mean specifically "expecting" interactions with those mocks? Because I agree that's usually not that valuable.

Fakes are not mocks. A fake is an actual implementation of the dependency that runs in-process/in-memory. This means that, unlike with mocks, your test code does not dictate the behavior/outputs of the dependency.

Ideally, service/library owners would write and maintain the fake to ensure that it stays in sync as changes are made to the actual service.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#188

Post by richardw »

djmips wrote: post #90

One of the big aha moments which clicked for me only fairly recently was staring at some physics equations my own internalized realization that light doesn't experience time and then I had to tell everyone haha - but that one eureka moment unlocked a whole lot of understanding and certainly a lot more questions. This of course was after all the schooling and physics where it somehow sailed over my head the whole time…

I was going to put this as mine. It’s astounding how important this is.

I woke up at 2am with the intuition that light was like a lightning strike across spacetime, with no time and no distance between the emitter and absorber.

Why and how, though. What are the fully-baked implications.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#189

Post by theptip »

Domain Driven Design. The book by Eric Evans lays out a bunch of concepts and as a developer that had not owned the architecture of a big domain, it was hard for me to see exactly where they fit. But after reading the book a couple times, and then encountering a few tricky domain modeling challenges, I started to see where these patterns add value. Also, as I started trying to describe the cohesive domain architecture of the system to a growing engineering organization, I also clicked on the advantage of having a standardized set of terminology for the problem, rather than inventing your own. It's nice to be able to link to an existing explanation of what a Repository is for, instead of having to name and document your own ad-hoc architectural patterns (or more likely, end up with you ad-hoc architecture being under-documented).

Things like Repositories, Aggregates, Bounded Contexts, and so on are going to be a net drag on your system if you only have a few 100 kloc of code in a monolith. But they really start to shine as you grow beyond that. Bounded Contexts in particular are a gem of an idea, so good that Uber re-discovered them in their microservices design: https://www.uber.com/blog/microservice-architecture/.

(Edited to clarify the book author)

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#190

Post by jethkl »

The axiom of choice, Tychonoff's theorem, and the open mapping theorem [0, 1, 2]. Each one took me, in my view, much too long to grasp.

[0] https://en.wikipedia.org/wiki/Axiom_of_choice

[1] https://en.wikipedia.org/wiki/Tychonoff%27s_theorem

[2] https://en.wikipedia.org/wiki/Open_mapping_theorem_(function...

Post reply on HN