With realtors taking a 10% cut on each transaction? Or do you envision a more liquid market with less paperwork? What about escrow, inspections, and handling disputes on large transactions?
BTW in the US, a big advantage of renting is not having to buy, sell, or maintain appliances like a fridge because the landlord has to deal with it.
right, freedom of speech is free as long as it agrees with the viewpoint of who's in power. similar to how history is written by victors but this part is conveniently ignored. it's just facts in the open marketplace of ideas yay!
the difference here is if you search or seek something, i.e. explicitly consent to viewing advertisements for guitar in your active browsing session vs them being pushed to you without your consent the next day on your phone.
I'm not against monetizing advertisement for the 1st use case either.
don't you think it is empowering and aspiring for artists? they can try several drafts of their work instantaneously, checking out various compositions etc before even starting the manual art process.
they could even input/train it on their own work. I don't think someone can use AI to copy your art better than the original artist.
Plus art is about provenance. If we could find a scrap piece of paper with some scribbles from Picasso, it would be art.
oh they hate it so much when this hypocrisy is pointed out. better put the high school kids downloading books on pirate bay in jail but I guess if your name starts with Alt and ends in man then there's an alt set of rules for you.
also remember when GPU usage was so bad for the environment when it was used to mine crypto, but I guess now it's okay to build nuclear power plants specifically for gen-ai.
this what happens when you centralize all decision making to people who have no local knowledge of the community they are administrating, and predicate their jobs on following a checklist, usually as implemented by buggy software, instead of making a judgement call based on experience and circumstances.
Yes and the open source models + local inference are progressing rapidly.
This whole API idea is kind of limited by the fact that you need to RT to a datacenter + trust someone with all your data.
Imagine when OpenAI has their 23&me moment in 2050 and a judge rules all your queries since 2023 are for sale to the highest bidder.
deferring to best practice instead of best judgement is a major plague of the software industry these days.
best practices usually come from giant companies with tens of thousands of engineers like google (who doesn't seem to be keeping up with competition btw) and amazon (which is notorious for burning out people).
what science or evidence drives the best practices?
this doesn't always work. many things can go wrong in distributed systems and you cannot test for all of them. also you have no control of your dependencies like when AWS networking degrades or a 3rd party API provider changes their APIs without letting you know.
Sure, in many languages we have the notation of thing.do_thing(arg1, arg2).
I suggest this is a good notation for data structures like, stack.push(10) or heap.pop()
I'm suggesting we don't use this notation for things like rules to validate a file, so I suggest we write validate(file, rules) instead of rules.validate(file).
Then we can express the rules as a data structure, and keep the IMO unrelated behavior separate.
Note then we don't need to worry about whether it should be file.validate(rules) perhaps. Who does the validation belong to? the rules or the file? the abstractions that are created by non-obvious answers to "who does this behavior belong to" are generally problems for future changes.
this isn't what I would call an abstraction, that's creating a named type. named types are simple because their algebra is also simple and their maintenance cost is low.
problem is more when you have types that "do things" and "have responsibilities" (usually to "do things with other types they hold pointers to, but do not totally own"), such a type is very difficult to maintain because there's now:
- a boundary of its responsibilities that is subjective,
- responsibility of building collaborators and initializing the type
- dealing with test doubles for the collaborators.
Kind of disagree with this article, when you add a "noun" (aka type), you're often introducing a new abstraction.
Abstractions have a maintenance cost associated with it ie, another developer or possibly yourself must be able to recreate the "algebra" associated with that type (your thought process) at the time of making modifications. This creates some problems:
1. Since there's no requirement to create a cohesive algebra (API), there was probably never a cohesive abstraction to begin with.
2. Requirements may have changed since the inception of the abstraction, further breaking its cohesion.
3. Since we largely practice "PR (aka change) driven development", after a few substantial repetitions of step 2, now the abstraction has morphed into something that's actually very tied into the callsites (verbs), and is essentially now tech debt (more like a bespoke rube goldberg machine than a well-designed re-usable software component).
You can introduce types if you follow the open/closed principle which means you don't change abstractions after their creation (instead create new ones and then delete old ones when they have no callsites).
this is a great video to rewatch whenever interacting with non-technical stakeholders.
IMO the "microservices" architecture is kind of a failure from an economic perspective. On top of many of the talks like this one [0], which discuss things technically, microservices gave us "tech companies" employing 5-10 eng + PM + EM, which inevitably leads to "org building" and office politics, bloated engineering teams (anecdote: Musk reducing much of X staff).
I think we'll see a trend toward monorepos + high velocity programming utilizing LLMs like copilot, enabling higher productivity with smaller teams.