It's mind boggling that you
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."
HN user
It's mind boggling that you
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."
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.
Neither is medicine, climate science, nor the marxist interpretation of the labor theory of value I was replying to.
You're missing the point
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%.
I fail to see the moral problem with being able to write a book that millions or even billions of people can enjoy. To me that's a feature, not a bug.
> I could give you examples of how value is created without any work at all.
I'm all ears.
Ageing whisky.
"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.
The work is the same, yet if the take home is different, you've proven that your income is not in fact earned through work in a moral sense.
You could say the same about musicians and authors. Are they immoral as well?
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.
You have it the wrong way round: In the US the slave owners lived on the farms. The bustling cities were in the free states.
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.
Advertising is as old as humanity itself. Asking what people did before advertising doesn't make sense.
Also, word-of-mouth advertising is, as the name suggests, a form of advertising.
Not really a counter example: gh.de is a pure advertising platform.
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.
When we used to pay for newspapers
Some newspapers were 50% advertising. You still had to pay for them.
How? If you don't advertise, no one can see you.
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.
You will get most of the benefits of HTTP 3 even if your app libraries run HTTP 1.1, as long as the app is behind a reverse proxy that speaks HTTP 3.
How? Stored procedures?
Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.
My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.
SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.
How do you version that code
You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.
how do you reason with the business logic split all over the DB and code
You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.
Before the invention of SQL, people wrote software using VSAM files and navigational databases with extremely limited computing and memory resources and it worked.
That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.
htmx is HTML-driven, Datastar is server-driven
As far as I understand, the main difference between HTMX and datastar is that HTMX uses innerHTML-swap by default and datastar uses the morph-swap by default, which is available as an extension for HTMX [1].
Another difference is that datastar comes with SSE, which indeed makes it server driven, but you don't have to use SSE. Also datastar comes with client-side scripting by default. So you could say the datastar = integrated HTMX + idiomorph + SSE + Alpine.
tons of logic _in_ your html
That is not at all what HTMX does. HTMX is "If the user clicks[1] here, fetch some html from the server and display it". HTMX doesn't put logic in your HTML.
[1] or hovers or scrolls.
HTML is a document markup language
No it is a hypertext [1] markup language and it doesn't suck if you actually use it as such.
The problem is that we decided that <a> and <form> tags should be the only hypercontrols, only triggered by clicking on them. However, libraries like HTMX and Unpoly enhance HTML so that every element can act as a hypercontrol, responding to all kinds of events. This allows you to implement interactive features such as autocompletion, form validation and infinite scrolling without writing a single line of JavaScript.
ORM keeps sucking because RDBMSes simply don't operate on objects
Have you read [2]? Modern SQL can return nested JSON. No ORM needed.
[1] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
[2] https://www.scattered-thoughts.net/writing/sql-needed-struct...
You are using one right now!
REST [...] is a software architectural style that was created to describe the design [...] of the architecture for the World Wide Web. [1]
People forget that the Web is the original REST. You have
- resources (https://news.ycombinator.com/item?id=45468477)
- HTTP verbs (GET, POST)
- and hypermedia controls (<a href="item?id=45468365">parent</a>)
This is all you need to meet Fielding's definition, and it has become so ubiquitous that we don't even notice it anymore.
to the point where tried and true RDBMS are shoehorning support for storing and querying JSON documents
That was in 2012. Nowadays, NoSQL companies are shoehorning SQL into their products.
All flagship database services from major cloud providers are nosql databases.
AWS Aurora, Google's Spanner and Big Query and Snowflake are all SQL DBs.
I respectfully disagree. The BOM is a Windows-specific idiosyncrasy resulting from its early adoption of UTF-16. In the Unix world, a BOM is unexpected and causes problems with many programs, such as GCC, PHP and XML parsers. Don't use it!
The correct approach is to use and assume UTF-8 everywhere. 99% of websites use UTF-8. There is no reason to break software by adding a BOM.
It turned out to have a huge multiplying effect on productivity
In retrospect, I am highly sceptical that OOP has had any positive impact on productivity. Its popularity coincided with the advent of automatic memory management, the World Wide Web and relational databases, and later with dependency management tools such as Maven. It is much more likely that it is these factors that have improved productivity, rather than OOP.