bernawil

  - If your code base utilizes dependency injection to make the code more "testable" with mocks, you are making the code 10x worse. There are other ways to make your code more modular without injecting new scope, logic and apis into an object.

what other ways?

Urine is recorded to being used for whitening teeth since at least ancient Egypt. I always thought they used something like a swab for it though, but you can be sure someone out there had the idea to use it as mouthwash lol.

> The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events.

Well the article introduces weird new lingo which I don't think is all that great, but whatever.

"operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer.

The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.

It was super heavy though. So dense and heavy I remember I couldn't carry it in my pocket when wearing shorts shorts.

hey, we all love how fast HN loads, not gonna argue!

On the other hand, I don't think it's usable for other crowds. I spend most of my day inside vim, so I'm used to switching windows and going back all the time but I don't think that having to load a submit form in a new page, losing all context of the conversation tree is particularly usable.

First time I hear XMLHttpRequest was a mistake.

No one is going to sit through a full-page reload on every form validation.

Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.

People need way more validations than html5 elements can provide. They need CC number validation. Validations that depend on the content of sibling elements. And they need it to display in custom ways like internationalized or whatever.

  In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

Though it is possible to overengineer this, you're probably underestimating ho seemingly simple apps can justifiably have complex state.

Say you make API calls. Your application state just grew to reflect

1. Pending request 2. Request succesful or failed 3. Request result or error 4. Finished request.

Redux apps track all of this explicitly. The alternative to this is not reducing statefulness. It's just ignoring it with all the brings.

  They're forms that submit stuff to a server and get a response

What kind of response? Asuming no React,

a. json

b. SSR-html?

If,

a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that.

b. You'll be merging your server-rendered html to your current view. Re-binding event handlers if you've got any interactive stuff (e.g your SSR came with a modal link) and god knows what else.

React is a million times better than this.

> do one thing when field a is null and field b is not

And that would have been a good example! contrary to the one in the docs.

Pattern matching for checking fields of things of the same type is a good use. Pattern matching when checking your parameters type? bad.

> The nice thing about it is the compiler can assert that your match is exhaustive

If you pass a new Shape object for which you forgot to implement a new case in the pattern matcher, you just get the default case, which is wrong, but the compiler can't know that. Now have the function argument ask for something that implements IArea interface and if you don't implement getArea() in your new Shape class, the compiler will know.

I personally hate when official documentation uses badly applied approaches because it will be invariably be quoted as source for some "best practices" argument at some point.

That's clearly a use case for interfaces and type-level programming.

They could have made a better and shorter case with error handling logic.

How is that particularly functional? In Haskell the same example would be approached at type-level using type classes, something extremely similar to using Interfaces.

I guess in a dynamic functional language you'd probably avoid doing this type of contact-oriented stuff, but you'd rather pass a callback at the last point rather than check type of what you got passed.

>superheroes are creatures/concepts as old as stories though, from the oldest myths of Ulysse

Ancient/Mythical "heroes" are not like our modern superheroes which are kind of a mix of gods/demigods and christian saints. Superheroes are people with superpowers plus a drive of serving justice, helping the weak, protecting mankind, etc. Plus always ready to sacrifice themselves for others. Classical heroes range from purely self-motivated (Ulysses), selfish and self-serving (Achiles) to literal assholes (Gilgamesh). Achiles values are very similar of former-gangster rap stars (or at least the characters they built of themselves). Fighting is most important. Only fights for himself and his glory. Top dog of his culture. Has a particular sense of fairness in regard to his own selfishness.

I was browsing the thread, trying to recollect my oldest memory of me having an internal monologue and remembered one time in my grandmothers back garden when I was 5/6, then read this :)

My story was that I was playing around in the garden. I was messing with a pile of stuff placed against the garden wall and as I'm touching something, suddenly I feel a huge electric shock. There was an old electric socket there, probably for pluggin a grass cutter. I remember the strong tinge around my whole body and how it pull me into it. I quickly twitched and jumped back. I remember telling myself "Wow, I could have died there". And, "electricity really gets you stuck" (I remember when I was that age adults would warn you about touching electric sockets, saying you could "get stuck to it", I guess not grounding installations was common).

It's common in all Spanish Spain places

That's how rules/law work. If they'd let people enter 2 years on a tourist visa, for every person like you they'd get 100 with the intention to settle. So better ban it outright.

It's like a museum of problems. Waves of solutions that became problems after.

The culture of code generation before the culture of XML configuration.

doesn't depend on any "context" in that example. Both written and spoken follow strict rules.

> when do you move from using in-application data structures?

as soon as you need any of these:

* a relational model -because you need to model your data that way or you are required to because someone wants to consume it with tableau-.

* concurrently read/read data between 1+ instances.

* a standard way of doing backups.

moving from that to a database would probably equal a rewrite.

I don't get it. Is it related to rankings, star systems, etc?

> pervasive assumption

I think whenever "rating" anything people are aware that it's a subjective and probably useless number meant for convenience than accuracy.

Isn't the real problem that Ruby's "magic" a lot of the time relies on monkey-patching stuff?

I mean, Javascript's modules also are dynamically executed and then returned as a singleton module object (also cached, so only the first require actually runs the code before the module export). This means you can make a module which requires other modules and monkey patches methods inside them (this is how mocking actually works), wrecking havoc amongst all other dependencies, but library authors just don't.

> or you’re just loading the same sites over and over again.

That's right, I am loading the same sites again every day consuming different data. Both for work and fun. That was the whole point.

On a bad connection, I'd pick a react SPA with a slow upstart over a classic server-side rendered one any day all things being equal.

With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.

> With this type of contingency plan, I don't see any reason to use server-side rendering at all

A case of vital context missing. Ever tried something like Next.js? It's a react framework for client + server-side rendering. What's really cool about it is that it does SSR for the initial view and the client-side react picks it up from there. It doesn't sound very impressive like that but where it blew my mind was when I realized that I could save URLs for some deeply nested view in a react site, enter that URL later and I'd get an instantaneous SSR'd view seamlessly.

I guess what I'm trying to say is that some tech is cool like that, not really a contingency plan but a plan.

I think these languages are thriving in the cloud because they not only have a favored concurrency model, they have it mandatorily and so they spun a cohesive ecosystem.

Take Java for example. You can make an event loop and use it on a web server (Play framework is just that). It doesn't mean you can retrofit all dependencies to do the same. It also doesn't mean business logic inside this server will necessarily use one instead of spinning up os threads nor that it can even plug into the same event loop. And it also means you just introduced opposing views into your ecosystem.

It's the concurrency model. The industry has decided threads just don't scale and it's doing away with the two most popular languages that rely on multithreading (Java and C#) and favoring NodeJs (event loop), Go (goroutines) and I guess Elixir (I'm not sure what really is the concurrency model, I guess the actor model somehow).

> borrowers will have to either not get the money

If credit shrinks, asset prices decrease so borrowers would need less money anyway. In the end it's all about who owns the capital.

Mesopotamian civilizations had to forgive debts periodically because the economy was heavily leveraged: farmers had to rent the land. A bad harvest could mean they'd have to sell their children to slavery. They were also surrounded by nomadic tribes. Social unrest would spiral out of control pretty quickly as broke people would join the nomads and turn to pillage.

That's a lesson every Abrahamic religion learned.

It was quite literally a rallying point for Lincon and a reason for the civil war. Southerners wanted free trade to export tobacco and cotton. Northerners wanted tariffs and protection for their industries (both to make their factories more competitive against European manufactures as to get cheaper raw materials from American farmers).

> completely wrong and ruined our perception of OOP.

or maybe Erlang is its own thing and OOP -as what most people are thinking when talking about it- is the set of practices followed in languages descended from the cross between C and Smalltalk.

This explains how every introductory course in OOP using either Java, C#, Python, etc. will list some sort of OOP principles always including something along "objects talk to each other though message passing" which is hand-waved simply as something to do with taking other objects by ref

  // taking a reference
  bar.someMethod(foo)
 

Or some form of import method

  import Foo;
  
  class Bar {
    someMethod() {
       // init the import
       foo = new Foo() 
       // ... do something with it
       foo.someMethod()
    } 
  }

which is worse since you need a huge disclaimer to explain that in practice you need to account for Dependency Injection and something for Mocking.

"Objects" in OOP, as in "let's couple data with behavior" necessarily means mutable state, otherwise they are just types. Use only immutable data; write abstract classes only; do polymorphism with interfaces and you'll end up with something very similar to what people mean by 'type-level programming' in Haskell.