> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. [1]
I was talking specifically about the moral implications of books that can be read without any additional work from the author. This statement is about books, not authors.
> but it's certainly not "work" the same way that digging a ditch
I don't think so. Value comes from utility, not from toil.
You're missing the point. The difference between three-year-old and fifteen-year-old whisky is mainly due to capital costs, not labour costs. According to the LVT, capital costs are not real.
> product is constantly evaporating and you're getting a lower yield on the same initial input
This so-called 'angel's share' accounts for ~2% per year, not 10%.
> "Mainstream economics" is doing a lot of heavy lifting.
As is "mainstream medicine" or "mainstream climate science". If you don't trust mainstream science, you must be either extremely smart or just delusional.
As the Wikipedia article states, the labour theory of value (LTV) was replaced by the theory of marginal utility in mainstream economics due to its major inconsistencies.
> Take Google as another example. The profit per employee has famously been (at times) over $1 million per year.
So, are you saying that the employees were exploited in some way?
I could give you examples of how value is created without any work at all.
It isn't that simple. The most important thing about a city is the streets and blocks. Manhattan and Barcelona are good examples of cities that have been designed in a way that make them walkable and high density.
Companies spending money on advertising is just another way of acquiring customers. If they were unable to do that, they would need to resort to other, more costly ways of acquiring customers. I doubt that higher costs would result in lower prices for customers.
On the other hand, smaller pages mean that more pages can fit in your CPU cache. Since CPU speed has improved much more than memory bus speed, and since cache is a scarce resource, it is important to use your cache lines as efficiently as possible.
Ultimately, it's a trade-off: larger pages mean faster I/O, while smaller pages mean better CPU utilisation.
I use Postgres JSON functions to return nested results. The database itself contains no JSON; just a well-normalised data model. However, the queries return nested JSON in the format required by the application, e.g. for rendering an HTML template or returning JSON to the client in a single round trip. Check out the old dogs can sort of learn new tricks in this great article: https://www.scattered-thoughts.net/writing/sql-needed-struct...
Again, performance is not my point. If you want maximum performance, use a low-level key-value store, hence my VSAM analogy. On the contrary, for me it is about simplicity.
SQL is the most high level language in common use. It abstracts away everything: Storage, memory, concurrency, and, most importantly, control flow. Complexity comes from complecting things, simplicity comes from decomplecting [1] things. SQL decomplects the what (data flow) from the how (control flow) which means less cognitive load, higher developer productivity and better maintainability.
In my experience, writing business logic in SQL results in fewer bugs and less code. I have replaced 50-line Java methods with 15-line SQL projections multiple times. With Python, the ratio is closer to 2:1, but it's still impressive.
And all of this without having to consider type impedance, eager versus lazy loading, result set mappings, second-level caching, dirty tracking, lifecycle management, OCC, or obscure savepoint bugs. Performance is just a nice, but welcome side effect.
Please don't do this.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
https://news.ycombinator.com/newsguidelines.html