motorest

> The original 2003 DDD book is very 2003 in that it is mired in object orientation to the point of frequently referencing object databases¹ as a state-of-the-art storage layer.

Irrelevant, as a) that's just your own personal and very subjective opinion, b) DDD is extensively documented as the one true way to write "good code", which means that by posting your comment you are unwittingly proving the point.

> However, the underlying ideas are not strongly married to object orientation and they fit quite nicely in a functional paradigm.

"Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

The criticism on anemic domain models, which are elevated to the status of anti-pattern, is more than enough to reject any claim on how functional programming is compatible with DDD.

And that's perfectly fine. Not being DDD is not a flaw or a problem. It just means it's something other than DDD.

But the point that this proves is that there is no one true way of producing "good code". There is no single recipe. Anyone who makes this sort of claim is either both very naive and clueless, or is invested in enforcing personal tastes and opinions as laws of nature.

> The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant documents, which mind you means absolutely none whatsoever.

But just because a browser supports broken documents, that doesn't make them less broken. It just means that the severity of the issue is downgraded, and users of said browser have one less reason to migrate.

> They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed.

I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate.

The principle still states that if you cannot validate input, you should not accept it.

> Being liberal in what you accept comes at _huge_ costs to the entire ecosyste

Why do you believe that?

Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters.

It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the irrelevant fields.

The law is "be conservative in what you send, be liberal in what you accept". The first one is pretty obvious.

How do you add cost to the entire ecosystem by only using the fields you need to use?

> Which cloud company can casually find 100B cash in a year?

AWS. Because AWS reports close to $11B/quarter, which is over half Amazon's entire revenue, and AWS owns the cloud computing market, on which the whole world runs.

> These aren't "job losses", these are "firings". They aren't unfortunate accidents of external origin that happened to them, they are conscious internal decisions to let people go.

This. They also make it their point to send the message this particlar firing round is completely arbitrary and based on a vague hope that they somehow can automate their way out of the expected productivity hit, and that they enforce this cut in spite of stronger sales.

> How is AWS getting billions of cash and low interest rate loans for capex?

AWS is the cash cow. It owns between a third and half of the world's cloud computing market. Do you think it's hard for AWS to get financing?

> Probably many reasons for this, but what I've seen often is that once the code base has been degraded, it's a slippery slope downhill after that.

Another factor, and perhaps the key factor, is that contrary to OP's extraordinary claim there is no such thing as objectively good code, or one single and true way of writing good code.

The crispest definition of "good code" is that it's not obviously bad code from a specific point of view. But points of view are also subjective.

Take for example domain-driven design. There are a myriad of books claiming it's an effective way to generate "good code". However, DDD has a strong object-oriented core, to the extent it's nearly a purist OO approach. But here we are, seeing claims that the core must be functional.

If OP's strong opinion on "good code" is so clear and obvious, why are there such critical disagreements at such a fundamental levels? Is everyone in the world wrong, and OP is the poor martyr that is cursed with being the only soul in the whole world who even knows what "good code" is?

Let's face it: the reason there is no such thing as "good code" is that opinionated people making claims such as OP's are actually passing off "good code" claims as proxy's for their own subjective and unverified personal taste. In a room full of developers, if you throw a rock at a random direction you're bound to hit one or two of these messiahs, and neither of them agrees on what good code is.

Hearing people like OP comment on "good code" is like hearing people comment on how their regional cuisine is the true definition of "good food".

> They might be bitter but evangelize Amazon products are their most marketable skills.

I think you are talking out of ignorance and spite. Most of the services used by Amazon employees are internal services that may or may not be on par with the state of the art. Apparently a big chunk of Amazon doesn't even use AWS at all, and instead use proto-cloud computer services that are a throwback from the 90s take on cloud computing.

> By your definition then every little part of “Amazon” is technically a separate “company” including every geo.

No. My definition is Amazon's actual organization chart as a holding. AWS is an independent first-level branch of direct reports of Andy Jassy, who was AWS's CEO before replacing Bezos. A similar branch is Worldwide Consumer, which groups what you think Amazon actually is, which means the online store, prime, books, devices, etc.

> Kindle is a loss leader?

What do you think "Kindle" is? Is it a specific device? Is it Kindle for Web? Is it the Android or iPhone apps? Is it Kindle for Windows or Kindle for Mac? Among these, can you count how many are paid?

> Like a lot of big tech companies Amazon is a small number of teams with profitable products and a whole bunch of other things that don’t make money.

I think that's a simplistic view of the issue. At Amazon, each team owns at best specific features embedded in products. Some projects such as e-readers are there as loss leaders to support cash cows such as it's ebook market. From your simplistic opinion, Amazon would have cut zero employees from it's books organization as it's business is booming and it's a profit center. But that doesn't match reality.

Also note that you are making that unfounded claim while commenting on news that Amazon is going to focus it's firing round on HR. Is HR a profit center now?

> Events like this are when the teams not contributing to the bottom line are cleaned up.

Except that's bullshit. Amazon decimated teams by firing new arrivals and by transferring projects out of the US into Europe and Asia. This hasn't anything to do with efficiency or performance in mind.

> Amazon includes AWS. They’re not “separate companies.”

Actually, they are. Perhaps what is causing your confusion is that other parts of Amazon, such as Ring or Rivian, are also separate companies, whereas parts such as Alexa and Amazon Music aren't.

> Not surprising given folks have been saying Amazon/AWS has been a bloated mess for a while now.

Who exactly do you think is saying this? Because from what I'm understanding, so far Amazon has been decimating teams at the expense of overworking them even more, and by cutting projects at the expense of cancelling maintenance and feature work.