Hacker News Reader

Comment by oconnore | Hacker News Reader

This reminds me of the microservices trend where the main justification is modularity —- which is of course perfectly possible to implement in a programming language using standard language constructs.

Similarly: any separation of concerns you can implement with APIs and multiple databases you can also implement with a schema. The difference being you have to reimplement a bunch of capabilities that are baked into an rdbms (and will probably never correctly implement something like a hash join).

View on HN

It should be possible to implement modularity in a programming language using standard language constructs.

In practice, the programming language and software engineering communities have largely failed to provide usable modularity. IMNSHO due to our clinging to call/return (so procedural/functional/method-oriented) as our modularity mechanism.

It ain't working.

So we the OS/systems guys and gals need to bail us out. Process boundaries are pretty hard, though of course we then manage to build distributed monoliths.

One thing that's interesting is that µservices, if actually REST-based, use data as the modularity mechanism, rather than procedures.

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

So because we have bad programmers that don't use the stuff provided by the programming language, we are going to throw away the baby with the bath water.

And, somehow, this is going to fix the fact that this happened because we have bad programmers. Bad programmers that now have to also deal with network complexity on top of the basic complexity they already can't deal with.

> bad programmers that don't use the stuff provided by the programming language

Er, no. We actually don't have the right stuff provided by the programming language.

And no, µservices are not a good solution. They are a bad solution to a real problem that programming languages do not solve.

Ok, in your opinion, what would it look like the right stuff as provided in a programming language?

Microservices are a good solution for scaling a company into multiple sub-sections, I/E a solution for an org chart problem. If your org chart has less than 4 levels, most likely you are doing microservices too soon. At that point, you can have people in charge of dealing with network interactions exclusively, and that allows your bad programmers to still be productive.

It is not necessary to be able to solve a problem in order to identify it.

That said, what I think what is needed is general support for architectural connectors in programming languages. Our so-called "general purpose programming languages" (actually: domain specific languages for the domain of algorithms, see ALGOL) effectively support one: the procedure call.

https://insights.sei.cmu.edu/library/procedure-calls-are-the...