> 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."
1,019 karma · joined February 7, 2019
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."
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.
> 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'm all ears.
Ageing whisky.
As is "mainstream medicine" or "mainstream climate science". If you don't trust mainstream science, you must be either extremely smart or just delusional.
You could say the same about musicians and authors. Are they immoral as well?
> 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.
Also, word-of-mouth advertising is, as the name suggests, a form of advertising.
Some newspapers were 50% advertising. You still had to pay for them.
Ultimately, it's a trade-off: larger pages mean faster I/O, while smaller pages mean better CPU utilisation.
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.
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.
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.
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.
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.
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...
> 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.
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.
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.
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.