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

it makes the code cleaner and testable.

But this makes testing A in isolation difficult. When testing A, you want to mock out B with an instance the test can manipulate.

So we want A to not create B, instead we want B to be "injected" into A. The general strategy of having B passed into A is called dependcy injection.

This way, your code isn't bound to a specific implementation.

Some DI frameworks even go so far and define all resources in a config file. This way you can switch out the implementation without a recompilation.

https://hasura.io/blog/build-fullstack-apps-nestjs-hasura-gr...

Dependency Injection solves the problem of when you want to create something, but THAT something also needs OTHER somethings, and so on.

In this example, think about a car.

A car might have many separate parts it needs:

  class Car {
    constructor(wheels: Wheels) {}
  }

  class Wheels {
    constructor(tires: Tires) {}
  }

  class Tires {
    constructor(rims: Rims, treads: Treads)
  }

  class Rims {
    constructor() {}
  }

  class Treads {
    constructor() {}
  }

  const car = new Car(new Wheels(new Tires(new Rims(), new Treads())))

With dependency injection, it allows you to register a sort of "automatic" system for constructing an instance of "new Foo()", that continues down the chain and fetches each piece.

  class NeedsACar {
    constructor(@Inject private car: Car) {}
  }

When you write tests, you can swap out which instance of the "@Injected" class is provided (the "Dependency") much easier.

If you've ever written a constructor for a class that has arguments (within the constructor signature) that are used by the instance of the class when instantiated then you have done dependency injection, or put more simply 'passing stuff in' which was eloquently stated in another comment on this thread.

When I code review, I try to make sure I call out "fake tests".

In many cases mocks are now over used where previously they were important in say 2008. Especially now with languages that support functions as objects, better generics, and other features which weren't common a while back. Likewise frameworks are and languages are generally way more testable now which means you're doing less backflips like static injecting wrappers for DateTime.now into libraries to make tests work. This further allows more contract and less implementation specific testing.

As with most things there is a lot of nuance/art to doing it well and smoothly

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.

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.

The abstract concept of OOP (messages between complex objects, as defined by Alan Kay) is an attempt at mimicking biological systems. Most modern languages implement data abstraction, but call it OOP, where they encapsulate some functionality with the data it operates on. Really helped with varying data formats in the AirForce in the 60s, apparently. There isn't anything wrong with this abstract concept either - it's a way of structuring a solution, with trade-offs.

Support for unit testing and mocking has little to do with OOP, and everything to do with the underling platform. Both C++ and Java, for example, do not have a special runtime mode where arbitrary replacement of code or data could occur. This is necessary for mocking functionality that is considered implementation detail and hidden by design. The hidden part is great for production code, not great for testing.

For example, if an object in java has a field like 'private final HttpClient client = new CurlBasedHttpClient();' this code is essentially untestable because there is no way in Java to tell the JVM "during testing, when this class instantiates an HttpClient, use my MockHttpClient".

Kotlin fixed some of that with MockK, which can mock the constructor of a Kotlin object, and you can return your mock implementation when the constructor is invoked.

Clearly, it's a platform issue. There could be a world where you could replace any object in the stdlib or any method or field with a mock version. JavaScript is much more flexible in that regard, which is why unit testing js code is much easier.

The root of it all stems from the fact that unit tests need to change some implementation details of the world around the object, but production code should not be able to, in order to get all the benefits of encapsulation.

If you get rid of modern OOP, you are swinging the pendulum in the opposite direction, where your tests are easy to write on any platform, because everything is open and easily accessible, but your code will suffer from issues that creep up when structures are open and easily accessible, such as increased coupling and reduced cohesion.

The few times I had to use Java afterwards I felt the same - all OOP features were unnecessary or at least didn't feel like the most straightforward approach. Nowadays I never use classes in Python, JS etc., it's just not needed - and in the case of Python it makes JSON insanely cumbersome.

Just vanilla C++ classes, and virtual interfaces if we need to mock things for unit tests.

No automatic wiring of the hierarchy.

>The best math textbook (Theory of Algebra) I ever read had little sections about the person who revealed a particular subject, why they were studying it, and how the subject is used.

I've found the best type of books provide motivation for concepts, how they have evolved, etc.

Take Computer Science for example, many of its concepts were area of research for decades but from a student's perspective it seems these concepts were always here instead of being constantly refined until the states they're now in.

Music theory is not inherently complex, but the notation adds incidental complexity -- it's sort of like the QWERTY keyboard; once you're stuck on a suboptimal way of doing things it's hard to move off.

Music theory is descriptive, not prescriptive. Is it any surprise that something we had to invent a whole new symbolic notation for is difficult to connect to concepts we can describe in natural language?

If you want to go really deep into the philosophy of music, to understand it from "first principles" so to speak, I highly recommend Leonard Bernstein's lecture series "The Unanswered Question" - https://en.wikipedia.org/wiki/The_Unanswered_Question_(lectu... (available on YouTube).

To paraphrase Bernstein's comment from his book "The Joy of Music": we need to stop comparing Beethoven to grassy fields and mountain streams. A "major seventh" or a "plagal cadance" are themselves the description of those qualities. By all means use music as metaphor, but when you're trying to describe it you're going to be using terms specific to its domain.

Reducible - FFTs the most ingenious algorithm ever https://youtu.be/h7apO7q16V0 Veritasium - The Most Important Algorithm of All Time https://youtu.be/nmgFG7PUHfo

To me, the issue with entropy is that it's initially presented without clear justification, so people don't know why it's important. Statistical mechanics made it clear to me that the state with the most entropy is the most likely to occur in equilibrium. (Statements about entropy representing "disorder" and whatnot in my opinion are handwavy, often lead to confusion, and should be avoided.)

The way our brains have evolved to build up a functional language model is by observing lots and lots (and lots) of examples of the language being used for communication. Which implies that, even from the very beginning, graded readers, level-appropriate dialogues, etc. should be the foundation of a language study program and not, as most language instruction courses and apps make it, just a little bit of icing on top.

The primacy of input is also kind of a big deal, and, at least for me, it took a long time before I was willing to let go of forced production exercises such as "translate this sentence into your target language". Perhaps in part because they're so endemic to language learning resources. You can't abandon them without also abandoning Duolingo and most formal classroom programs. But the problem with these kind of practice exercises is, we now know that it's normal for there to be a long delay between when someone can comprehend a grammatical structure, and when they can use it in a natural setting. (Anyone with kids over a certain age should be familiar with the phenomenon.) Forced production relies on - and reinforces - that aforementioned misplaced encoding, and there's a mountain of research demonstrating that skill in performing those sorts of exercises simply doesn't correlate with the development of communicative fluency.

Tangentially, the transformer architecture that's taken natural language processing by storm has some interesting similarities to the leading model among SLA researchers for how language is represented in the human brain. Which isn't the monitor model itself, but might hint at a mechanism for a few parts of the model. Acquisition order, for example.

therefore it’s safer to build then on twitter, facebook, apple, etc.

the entire ecosystem may be a fraud, but if it is not then it’s incredibly enduring. i have more faith that i can get what the balance of an account is in 10 years from ethereum than i do from my banks api staying stable or open.

I got Joseph M. William's "Style: Toward Clarity and Grace" recommended [1] so you might be interested in it. I read the introduction (I'm planning to read it this year) and with the few examples the author presents it sells the idea that prose doesn't need to be utterly complex to communicate ideas and concepts succinctly and clearly.

[1]: https://news.ycombinator.com/item?id=33601492

My top 3: 1/ Edit ruthlessly. Every single word is reduced to its simplest form and pulls its weight--it has a damn good reason for being there. 2/ Aspire to write at a third-grade reading level. Readers prefer simple writing even when reading deeply technical content. 3/ Start your most important conclusions up front, not at the end. You're not writing The Sixth Sense. Do your reader a favor and tell them the big reveal first. You can then follow through and persuade the reader why your conclusions are right.

Out of curiosity, in the skit, do you know which book the actor is reading? In the skit, at the top of the page, the book is titled: "Making outlines and summaries"[0].

[0] Fast forwarded to specific time: https://youtu.be/yfcyVtD8-Dk?t=129

What manual process does ChatGPT speed up?

Because terminology matters, and some terms are quite misleading. What some people tend to miss about the "Socialism with Scandinavian Characteristics" that folks claim to like these days is that Scandinavian countries are actually near the very top rankings by economic freedom and lack of excess regulatory burden. I.e. they're actually some of the most free market and capitalist, while applying effective redistribution after the fact (leading to moderately high tax rates). So I don't get why people decry capitalism and free enterprise while praising Scandinavia as "successful" socialism? It makes no sense.

Well, full-blown free-market capitalism would be one alternative to the current US system, albeit probably not the best.

What it does is incentivise more content. More is not always better for everyone, and is even less likely to be better for those who were early adopters to the platform - but what it is usually is more popular. It's just democracy in action: the largest numbers decide, and sometimes privileged minorities lose out.