Hacker News new | comments | show | ask | jobs | submit login

The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare."

Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis.

The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead.

Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework.

Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.

> DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability

Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability.

In test.js:

  //paymentService may be an instance or a class
  services.paymentService = mockPaymentService;  
  //use paymentService in your tests here.
The above over-simplified example satisfies most test cases. You can convince me with some use-cases.

(Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)

With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about.

Beyond testing, DI makes it much easier to swap in different implementations of a dependency than simply throwing things into the global scope lets you do. Suppose I want to switch my model from one that communicates with Parse to one that communicates with Firebase. Supposing I adhere to the same interface, I should be able to simply drop it in place without affecting other functions or objects that still rely on the Parse version of the model.

Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem.

Parse and Firebase example:

  //works as long as both retain the same interface.
  provider = new FirebaseProvider; //new ParseProvider()

  //add: just using an if condition, the old fashioned way.
  getProvider: function() {
    if (config.provider === 'parse')
      return ParseProvider()
      return FirebaseProvider()
Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.

Whether or not Angular's implementation of its provider is cleaner is irrelevant to your original point that DI is a "problem looking for a solution" in dynamic languages.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact