That's the point. They are by far the largest player in the game, and can ( and do) use their size to squash competition. You don't have to use their marketplace but as a small business you don't have many options that can compete.
Hell, they're even extremely anti-competitive with their employees. Their NDAs are very restrictive and have threatened non-senior employees with them, even ones that they let go.
Got anything to back that up? Businesses managed to thrive before when taxes were considerably higher. How do you account for the Gilded Age? How were those monopolies different than today and how did taxes and bureaucracy exacerbate issues then? Because there are many parallels between them and now.
Cept the part about Amazon not letting you sell your goods cheaper elsewhere. That keeps the price inflated and is anti-competitive since it squashes competition from other marketplaces, not because their platform is better, mind you, but because they have all the power.
When I was trying to learn monads no one ever gave me an example of mapping a list-returning function to a list. Everyone went on about 'effects', monad laws, etc. For some of us it's best to work backwards from something concrete and then show why the laws are important.
I love how simple most things are in FP compared to OO. I also hate how poorly FP concepts are explained.
I'm not saying you're wrong about people learning terminology. However, you definitely get more strange looks from FP terms than OO terms. Class, interface and object are common terms. When I mention a word like 'monad', 'monoid', 'magma', or 'functor' people look at me like I'm nuts. It's not logical. A new word is a new word. It's just FP words sound almost alien and trigger extra confusion in people.
This is probably the biggest problem with FP, and I love FP, and use fp-ts which is marred in category theory. It took me a while to understand concepts that are really quite simple but explained very academically.
I prefer functional. Procedural is not restrained enough and allows for mutable global state. This can go off the rails when multiple people are in the code.
Functional stresses composition so functions should stay small, and ADTs allow for all effects (errors!) to be represented. Strong typing helps reduce the number of tests I need to write, as well.
Sorry, I should have said JSONB. Do you still consider a table with a single JSONB column SQL or NoSQL? Sure, it may be contained within a RDBMS but you are treating it more like a document store than a relationship database.
Common in the States too. I'm from Eastern MA and work in Boston. If I order a "vodka, soda" it sounds normal, but if I say "vodka AND soda" then "vodka" becomes "vodkar". My accent is a pretty standard Eastern New England accent.
Gotcha. I may have to give HTMX a try again. Though, I worked on a HAL-based, full RESTful service back in 2016 and I'm not sure how eager I am to go back.
REST was ok for the read-side of things, but for writing I find RPC/commands to be better than PUT/PATCH. Combine that with the lack of framework for HATEOAS made full REST APIs cumbersome at the time, though things may be different now.
It should be: start with a well architected monolith, and then slice things into microservices when you need to. Fowler and many Microservice evangelists even say to start with a monolith first, because you don't know the correct slices at the beginning.
EDIT: I suck at writing coherent messages on my phone.
I feel the same way. I started my career in the mid-00s in Enterprise software writing .NET. We used to have many conversations around modeling, patterns, testing, etc. I work at a Node shop now and none of that happens.
I am trying to introduce strong typing with typescript and aspects of functional programming but it is very slow-going...
My world changed when I started thinking in a strongly typed way (not just using string and number) and representing state changes as different types rather than interpreting than through property values. Once you do that then your code becomes mapping from one type to the next.
For example, if `type ShoppingCart = EmptyCart | LoadedCart` then `addToCart` is just a map from `ShoppingCart` to `LoadedCart`. It makes invalid states impossible to represent and flows become clearer. Add in good FP and composition becomes easier.
Exceptions should absolutely be a part of an interface and it stops you from leaking implementation details. If I have an IRepository interface then none of the methods should ever throw SqlException, HttpException, or anything like that. You'd map them to something else. Exceptions in most languages are implicitly part of the contract, and not having consistent ones on an interface breaks Liskov's Substitution Principle.
Hell, they're even extremely anti-competitive with their employees. Their NDAs are very restrictive and have threatened non-senior employees with them, even ones that they let go.