3 ms·

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,

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.

mpweiher 3y ago
> 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.
- javcasas 3y ago
  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.
  - mpweiher 3y ago
    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-assembly-language-of-software-interconnection-connectors-deserve-first-class-status/ https://insights.sei.cmu.edu/library/procedure-calls-are-the... See also: https://blog.metaobject.com/2019/02/why-architecture-oriented-programming.html https://blog.metaobject.com/2019/02/why-architecture-oriente... and: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p...

mpweiher 3y ago

> 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.

javcasas 3y ago
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.
- mpweiher 3y ago
  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-assembly-language-of-software-interconnection-connectors-deserve-first-class-status/ https://insights.sei.cmu.edu/library/procedure-calls-are-the... See also: https://blog.metaobject.com/2019/02/why-architecture-oriented-programming.html https://blog.metaobject.com/2019/02/why-architecture-oriente... and: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p...