4 ms·

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said tha

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to read with all them GOTOs. You should do structured programming, use constructs such as loops to make it easier to follow. Man, your code is so long written like that, you should break it into functions to make it easier to reason about. Dude, you have so many functions it's impossible to make heads or tails of the logic, you should break it into classes to be able to abstract away all of this detail. Bro, you have so many classes I don't even know where to start. You should introduce modules so that it becomes possible to isolate different parts of the design. Dawg, you have so many modules, you ought to break them into small different runtimes communicating via a rest protocol to isolate different parts of the code. Choom, you have so many microservices, you ought to break them into different microclusters to separate the different parts of the API. X'man, you have so many microclusters, you really ought to break them into different miniclouds to spearate the functionality and make it easier to follow. 𐀘𐀐, you have so many miniclouds it's impossible to deal with this code, you really ought to separate it into functional minicloud clusters.

nopeYouAreWrong 4y ago
this is a good summary of why I pay zero attention to power point decks and blog posts. there is never a right answer and it's just people masturbating in circles. it's not rocket science, half of the time it's not even computer science. design patterns, at a certain point, become full of themselves.
- deleted 4y ago
  [deleted]
Scarblac 4y ago
It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.
- still_grokking 4y ago
  This sounds brilliant! What's the marketing name for that?
  - goto11 4y ago
    "Lose coupling"
  - withinboredom 4y ago
    I’ve called it Model-T development[1]. The Model-T brought standardization to building cars where companies only built to a very specific spec. It didn’t matter that some companies would be better than others, or cheaper/expensive. The point was choice, competition, and interchangeable parts. Granted, I don’t actually know about that, but that’s the end result. [1]: I apparently deleted the post so I’ll have to undelete it and come update this comment.
  - layer8 4y ago
    It’s called separating interface from implementation. When using an interface, only make assumptions on what the interface specifies, and not on how it may happen to be implemented. When implementing an interface, only make assumptions on what the interface specifies, and not on how it may happen to be used.
    - gadflyinyoureye 4y ago
      Even this confuses people. Often the name of the interface is something like S3Client. No, the name should be something like PolicyWriter.
  - cutemonster 4y ago
    It's called Microcompanies. >> Otherwise [without microcompanies] you just can't do software engineering right. So true
- mannykannot 4y ago
  For that to work, there has to be, somewhere, a clear understanding of how the units all work together to achieve the higher-level goals without violating the higher-level constraints which, in practice, increase in number and scope the higher up the pyramid of abstraction you go. Pace Robert Martin, divide-and-conquer cannot be used to reduce systems-level thinking to doing just one thing, even in an abstract sense.
BulgarianIdiot 4y ago
Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as well as it works across files, or across statements in the same file, up from data centers to CPU instructions. Our languages and platforms are full of the SAME THING but SLIGHTLY DIFFERENT, under DIFFERENT NAMES. You listed many of them. Machine opcode, expression, function, class, module, service etc.
- marcosdumay 4y ago
  Modules are recursive. Libraries are recursive. Hell, functions and classes are recursive too. I don't think we have any non-recursive code abstraction tool. Some of the problem is that people need different capabilities from different abstraction layers. The rest of the problem is that there are a lot of incompetent people creating software.
  - BulgarianIdiot 4y ago
    If you start listing what different capabilities you need on each layer, you'll notice it can all be done, as a very lean abstraction, in one layer. I'm working on creating a platform that's doing just that, BTW. I'll cite Erlang as an example that comes somewhat close to what I mean. An Erlang process is a function, a class, a module, and a remote service, all at once. It can be done. We just never stopped to truly think about it and try.
    - marcosdumay 4y ago
      > We just never stopped to truly think about it and try. Oh, you are right about this. But a lot of people stopped to think about it. It always seemed to fail due to market failures, like most other innovations in development.
malaute 4y ago
I'd argue though that the velocity and amount of functionality between those levels increased significantly.
- marginalia_nu 4y ago
  Eh, I'd argue the amount of functionality has if anything stagnated. Computers today don't do significantly more than they did 25 years ago. They just do the same things with 1000 times more resources across a global computer network. Likewise, velocity is startlingly bad if you follow conventional advice.
lakomen 4y ago
So, in short structure is half the code, is what I always say
larsonnn 4y ago
Sometimes it’s just a big-ass software project which should never be touched.

nopeYouAreWrong 4y ago

this is a good summary of why I pay zero attention to power point decks and blog posts. there is never a right answer and it's just people masturbating in circles. it's not rocket science, half of the time it's not even computer science. design patterns, at a certain point, become full of themselves.

deleted 4y ago
[deleted]

Scarblac 4y ago

It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.

still_grokking 4y ago
This sounds brilliant! What's the marketing name for that?
- goto11 4y ago
  "Lose coupling"
- withinboredom 4y ago
  I’ve called it Model-T development[1]. The Model-T brought standardization to building cars where companies only built to a very specific spec. It didn’t matter that some companies would be better than others, or cheaper/expensive. The point was choice, competition, and interchangeable parts. Granted, I don’t actually know about that, but that’s the end result. [1]: I apparently deleted the post so I’ll have to undelete it and come update this comment.
- layer8 4y ago
  It’s called separating interface from implementation. When using an interface, only make assumptions on what the interface specifies, and not on how it may happen to be implemented. When implementing an interface, only make assumptions on what the interface specifies, and not on how it may happen to be used.
  - gadflyinyoureye 4y ago
    Even this confuses people. Often the name of the interface is something like S3Client. No, the name should be something like PolicyWriter.
- cutemonster 4y ago
  It's called Microcompanies. >> Otherwise [without microcompanies] you just can't do software engineering right. So true
mannykannot 4y ago
For that to work, there has to be, somewhere, a clear understanding of how the units all work together to achieve the higher-level goals without violating the higher-level constraints which, in practice, increase in number and scope the higher up the pyramid of abstraction you go. Pace Robert Martin, divide-and-conquer cannot be used to reduce systems-level thinking to doing just one thing, even in an abstract sense.

BulgarianIdiot 4y ago

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as well as it works across files, or across statements in the same file, up from data centers to CPU instructions. Our languages and platforms are full of the SAME THING but SLIGHTLY DIFFERENT, under DIFFERENT NAMES. You listed many of them. Machine opcode, expression, function, class, module, service etc.

marcosdumay 4y ago
Modules are recursive. Libraries are recursive. Hell, functions and classes are recursive too. I don't think we have any non-recursive code abstraction tool. Some of the problem is that people need different capabilities from different abstraction layers. The rest of the problem is that there are a lot of incompetent people creating software.
- BulgarianIdiot 4y ago
  If you start listing what different capabilities you need on each layer, you'll notice it can all be done, as a very lean abstraction, in one layer. I'm working on creating a platform that's doing just that, BTW. I'll cite Erlang as an example that comes somewhat close to what I mean. An Erlang process is a function, a class, a module, and a remote service, all at once. It can be done. We just never stopped to truly think about it and try.
  - marcosdumay 4y ago
    > We just never stopped to truly think about it and try. Oh, you are right about this. But a lot of people stopped to think about it. It always seemed to fail due to market failures, like most other innovations in development.

malaute 4y ago

I'd argue though that the velocity and amount of functionality between those levels increased significantly.

marginalia_nu 4y ago
Eh, I'd argue the amount of functionality has if anything stagnated. Computers today don't do significantly more than they did 25 years ago. They just do the same things with 1000 times more resources across a global computer network. Likewise, velocity is startlingly bad if you follow conventional advice.

lakomen 4y ago

So, in short structure is half the code, is what I always say

larsonnn 4y ago

Sometimes it’s just a big-ass software project which should never be touched.