Power of static typing, that it allows one to develop complex programs faster and better, not slower.
Ask HN: Concepts that clicked only years after you first encountered them?
101–110 of 946 posts
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#102object oriented programming.
i must have encountered it during my computer science classes and i certainly did some form of oo programming with LPC in MUDs, but only when i was programming modules in Pike for the Roxen webserver, it really clicked how oo programming worked.
in Roxen each http request causes a request object to be instantiated which lives for the lifetime of the request. further, each Roxen module gets instantiated as an object for the lifetime of the server process. the request object would call module objects to process the request. the modules would make changes to the request object which would produce the response to the http request, whereas storing data in a module object caused it to be persistent.
i have been working on this for a while when one morning i woke up with a literal eureka moment as i realized how objects and encapsulation worked.
this happened a few decades ago and it was the most clear moment of this kind that i can still remember.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#103Steely Dan
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#104Earlier 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…
This is the way, but it’s tough to sell “we’re not going to unit test this part” in a professional setting where there are incentives to look more responsible than thou, directors are looking at unit test coverage reports, etc.
Yeah I have no qualms about writing mostly-BS unit tests when the existing structure of a project makes it infeasible to write good ones. When in Rome! But when I'm starting from scratch or have a chance to do refactoring, I move toward the "functional core" approach as much as possible.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#105Earlier quoted context omitted.
This seems totally orthogonal to me. Using a totally non-OOP functional style, you can either instantiate state within a function or pass it in from the calling context, which is the same trade-off that dependency injection targets.
If you work on a legacy code base with tens of many millions of lines of code, the non-OOP will be a better code base. My opinion.
I wasn't disagreeing (or agreeing) with that opinion. It's just orthogonal to whether or not dependency injection is a useful approach.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#106Earlier quoted context omitted.
Always amuses me when I see tests spin up a http server, just to call a function.
Sorry, I probably wasn't clear. I wasn't spinning up the server itself, just testing the endpoints via their functions. Though this likely falls more under integration vs unit tests. As for unit tests... I mostly add them to projects with something egregious happens or a very hard bug to spot can occur - just to prevent anyone else from foot gunning themselves (here be dragons or whatever).
You were clear. I was agreeing with you.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#107Earlier quoted context omitted.
Always amuses me when I see tests spin up a http server, just to call a function.
What specifically amuses you? Todays http servers may have any number of request altering/enhancing "middleware" calls between the incoming request and the actual business logic/function. How do you ensure that your api works as designed if you only test (pure) business functions? Or do you re-create the middleware chain of functions manually for you test?
/api/foo -> fooApi()
You don't need to test the call to /api/foo, you only need to test the call to fooApi(). It doesn't/shouldn't require a http server to do that. Just call the function directly.
If you want to test that /api/foo exists, that is essentially a different test and only requires a mock version of fooApi(), because you've already tested fooApi() separately above.
The benefit of this approach is that your tests run a lot faster (and easier) not having to spin up an entire http server, just to test the function.
As for the middleware... that is also tested separately from the business logic. You don't want to tie your business logic to the middleware, now do you? That creates a whole dependency chain that is even harder to test.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#108Formal logic.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#109Power of static typing, that it allows one to develop complex programs faster and better, not slower.
I think the develop faster thing is a poor argument for static typing. The refactoring piece of the equation is the most important to me. Static types provide confidence (and speed) while making sweeping changes to code.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#110It 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 letting it manage its own state it all just clicked. I started with this massively complex functional-like system that managed four or five different motions, but once it was broken into objects most of the code just fell off and it became a nice clean system.
I was super proud of it at the time, but it's pretty bad by my current standards.