skysight-inc/HackerNews huggingface dataset:
I can never really decide the answer to this question and I have been programming a long time. I end up just not thinking about it too much and doing what I feel like because getting things done is more important than standing around thinking about the millions of different options.

There are various arguments that seem to have flaws of their own. For example, "use ORMs for all the simple things, and raw SQL for the complex things". The problem with this is that even simple things like "insert this into the database" often require checking that the foreign keys you insert are within the domain of the user trying to insert them, and various other constraints like that. So with SQL, you can do this all in one query, but with an ORM, you often create a query for each check.

Related to that is the idea of "premature optimisation". The problem with this concept is that all queries add up together to determine how much hardware you need, which determines your costs. You can argue the opposite of premature optimisation, depending on your case. Why not spend 5 minutes extra writing a manual query that will be run hundreds of thousands of times for years?

Are your goals about reducing infrastructure costs as much as possible? Is "developer time" really a thing, or are you doing this in your own time for a startup or something?

Then there is the fact that doing simple things faster isn't much of a selling point because they are already simple. It is very obvious though that ORMs are much, much more readable than raw SQL.

Then another question starts to come up, if you are using this abstraction like an ORM or GraphQL as an ORM, why are you even using a SQL database when none of the features are really available to you?

SQL has has interesting new features in that you can do the object mapping inside the queries now. For example:

select
post.id,
post.content,
json_agg(comments),
json_build_object('id', a.id, 'name', a.name) as "author"
from
posts,
comments,
authors
group by
etc...

Still, it is nowhere near as easy as using an ORM. The other thing is that when you start using an ORM, you really do end up having a different approach to querying your data in every situation. You don't use all of the various features of SQL. It ends up being a lot slower, but maybe in some cases that is worth it.
How well does cache warming support users editing the content directly on the database and control-versioning it?

Witch static webpage generators, your non-technical editors get all the benefits from editing flat-text files with markdown and git, instead of relying on a sys-admin to watch the state of the database for them.
I would expect that a let at a function scope should be equivalent to a var inside a block
Historically the dependency management tool for C++ is the system's package manager, and/or a shell configure/provision script.

I don't see any value add to a "built in" dependency management tool to C++. Not as in it isn't a useful thing to have, just that it can't solve the big problem which is that most C++ projects would never support it.

There's also the fact that long dependency chains are frowned upon in many C++ code bases.
What I found to work really well (esp. with GraphQL / Dataloaders) is using something like postloader by gajus [1]. It generates a slim interface from the database schema. For the simple run off the mill things you get an easy interface to get certain rows of a table or load related data, which is a huge part of what you will need when writing GraphQL resolvers. We extended the idea to generate simple wrappers for creating and updating tables as well, if anyone is interested in that I may dump the code for that in some gist.

[1] https://github.com/gajus/postloader
I always wondered that myself, but 'rep movsb' sounds like a great solution. Back when I was still programming assembly, there were blitters (https://en.wikipedia.org/wiki/Blitter) to copy large chunks of memory.
I like the point the author is making. It appears that the examples themselves are talking of changes over long periods of time, that the programming community benefits from.

Are there examples where this applies to shorter time periods?

e.g. the discussion on the evolution of C++ language is fantastic, but it took place over.... years? A decade?

If I'm this person in my org trying to write better software for my project, does it really help to not be more disciplined? Before the invention of reference counting, wouldn't the developers who did know how the thing really worked be more productive?

I think this is important to call out, and not go to the other extreme. Discipline is definitely not scalable, but neither is ... the lack of it? Inertia is very strong in production software systems.
This paper just gets me every time I see it.

It really doesn’t claim or do much that isn’t already quite obvious (it also has the other problem of going on completely unrelated tangents.)

First, it does this funny thing where it “proves” that EMH (or market efficiency) is NP-hard, by building gadgets based on options and then using them to “embed” 3-SAT. This is fine except (a) we often don’t care about an exact solution (so we need approximation-hardness that isn’t shown) and (b) I can come up with millions of other obvious things like this! Here’s a silly one one: I give a derivative whose price is $1 if a solution (that is known to exist) to an NP-hard problem is found by a given time. This will “show the NP hardness of EMH” because obviously the derivative price should be 1 (the problem has a solution, by construction) and so anyone should “obviously” price it at $1.

This is like saying “life is NP-hard.” Like, yeah, of course it is. That doesn’t mean we aren’t pretty good at doing the right thing and rationality (like EMH) is a good, if imperfect tool to analyze behavior. Taking it to its extreme then everything breaks, because the model is wrong. We don’t throw up our hands and quit because making real-life decisions is a sampling-hard, query-hard, and NP-hard problem (if all data is known), but a basic model of rationality would say that humans can “perfectly” solve it. (Which is obviously crazy, but we obviously don’t throw the assumption of rationality of agents out the window because of this.)

Otoh, I am definitely of the opinion that some economists hold EMH as a “magical” axiom, but that’s a different story.
A discovery that could provide a potential therapy to Covid-19
Microsoft Announces Azure Space and Partnership with SpaceX Starlink
> Doesn't the graph database community have something better to offer?

Probably not in the same kind of resource-constrained way, no. Whilst it might be a suboptimal graph database, it's also not going to require 2GB of RAM to run...
In most cases, it is sufficient if your database runs on the DB in production and sqlite for local development. If it's too big to be able to run on the dev computer, then it should use one db across the board.

Portability across databases rarely buys you anything but hard to reproduce bugs.
Have you explored svelte or solidjs yet?
Perhaps, but the Google anti-trust suit would seem a timely contradiction too. Monopolies are incentivised to keep the market inefficient (or roughly as efficient as it is) because change jeopardises their dominant position.
Cars don't solve a majority of life's problems so by this logic they must be the solution for almost nothing. Forget the fact they are incredible at the thing they do well.

Blockchain also solves very few of life's problems, but it's great for a distributed trustless currency potentially with smart contracts.

If cars had gotten overhyped and someone wrongly said you should use them as money, that doesn't make them stop being good transportation.
Follow up: If you ever encounter a case where webkit/jsc is significantly slower than other engines they will happily take bug reports at bugs.webkit.org as the JSC team is always looking for tests that show suboptimal compilation that occurs in the real world.
The biggest “aha” moment for me was when I started working with graphql.

The tooling would statically analyze your queries, and produce types for exactly what you were requesting.

Then you would just have a bunch of raw queries laying around, but you’d be confident the data retuned is the right data at compile time.

That made just writing raw queries a lot more simple and feasible than building abstractions on top of them.

Now TS and sql doesn’t really have a robust lib for that I think, last time I checked it was only https://github.com/adelsz/pgtyped
But haven’t looked at how far it has progressed.
Based on a research I did months ago, the best open source commenting systems are: https://schnack.cool/ (nodejs)
https://posativ.org/isso/ (python)
Having money to buy something that is for sale is not anti-competitive in itself, neither is selling stuff to a monopolist at market rates.

You need to look at why Google's adtech is so obscenely profitable, why they are able to generate so much profit per user. A lot of it is powered by things that either already are or should be illegal, from various abuses of monopolistic power to forced tracking without informed consent.

Fixing those issues would be a good start. Otherwise, nothing will change. Google has enough of its own moat with Pixel devices and Android and Chrome that banning or somehow restricting the sale of default search engine position will hurt sellers of those defaults like Mozilla much more than it will hurt Google's monopoly.

Just because the lawsuit is on paper targeted at Google, doesn't mean that their competitors (or the public) will be the beneficiaries of its results.
Diminish, you're right.
> Of course you can't redefine it.

Well, you can redefine it by editing its source code file on disk. (Unless the file is read-only.) But it's a lot faster to be able to redefine it interactively inside the DevTools console and I wish there was a "dev" setting that allowed this. Also, you said "you declared it" but usually it wasn't me who declared it constant. Rather, some other programmer thought `width=800` or `numColumns=80` should be declared constant. "Variables aren't; constants won't be." No coder is an island: one programmer's bad `const` can't make life harder for other coders. Related: One reason I use Chromium browsers instead of Firefox is because in Firefox DevTools console once you declare `class A {}` you can't interactively change it to, say, add a constructor like `class A { constructor (foo) { this.foo = foo } }` During learning and experimentation this is lousy; you can't interactively iterate at the console prompt like a proper dynamic language. You must instead put your code in an external file and set up a "save file and re-run everything" system just like static languages like C++ require.
> I'm a Go developer and I notice a lot of other Go developers instantly suggest things like GORM to noobs writing applications.

And there is nothing wrong with that. It's like recommending against the use of HTTP before people learn TCI/IP, or recommending against PHP/Apache just because people aren't really writing servers.

Learning how to write a web app and learning database management are 2 separate topics. Furthermore, GORM is rather barebone, compared to Entity Framework or Hibernate, due to Go type limitations...
JAMstack is not about "everything is static", it's about "everything is encapsulated behind an API and implemented with the best technology available".

The JAMstack pattern allows storing static content as editable flat-text files, and dynamic comments in a database without mudding everything within the same CMS code; it's just a better separation of concerns.
What about supporting multiple versions of libraries at a computer? They all support it: npm, rvm, virtualenv, cargo, golang, python, maven and etc.

A very common use case is to use some newer version of something than what shipped with the OS but at the same time you don't want to potentially cause instability in the OS...

Or you know, developing multiple projects w/ different versions from a single OS.

Also in case I really want to do it, I have to go to some obscure website download some payload and read some build instructions to see how to best integrate to my messy CMake/Make system...

All of it could literally be replaced by something akin to

cppvenv create myproject
cppvenv --depend-on grpc-1.40 zeromq json
cppvenv build
Oboe is quite a neat instrument though:

https://www.youtube.com/watch?v=2WJhax7Jmxs

https://www.youtube.com/watch?v=vE2O_yfgtBU
Disappointing lack of technical depth in the report.

> Typical problems that arose include how Apple's use of glue required precision the machinery couldn't reliably match

Aren't robots commonly used to place adhesives (even replacing welds in metal fab) exactly because they can apply it far more precisely than humans? Picturing an iPad, I'd guess the issue would have been flexibility in placing glue in 3D space, around odd angles and tight corners, and not precision.
> Prospective performers of the piece (if any) are advised to > heed its basic precept and plagiarize the author's version.

Appropriate... https://tomlehrersongs.com/wp-content/uploads/2018/12/lobach...
Yeah you can just use a migration system and store your functions in text files checked into the version control. Nothing but the migrations are allowed in staging and production so everyone is forced to use it.
Do you think the market is not pricing it correctly?

In the dawn of computing, machines were far less common, much more expensive, and society was willing to pay programmers boatloads of money to write optimized code because that was cheaper.

The hardware engineers did an excellent job, they reduced costs of computing by a lot. Society is not willing to pay programmers boatloads of money to write optimized code; because hardware is cheap, they can do fine without that optimization.

Whether we thing the pricing is correct or not is a different question I guess. We could theoretically raise computing prices artificially (say through taxation).
A rant about const vs. let
When you know a user is likely not coming back you've got virtually nothing to lose by sending them a push or email notification. Active users don't need to get any.
I'd say startups are a much better example. But I didn't come here to argue politics, just asked for someone to describe their superior optimization process (math being my actual interest, so still waiting to hear it). I wouldn't describe "do what walmart did" as a particularly useful optimization strategy.
A question please, "and it is still my favorite instrument sound wise". Can the sax in general be said to have one sound? I knew 2 sax players at school, their instruments were much the same in size and appearance, excepting a little ornamentation on one. One was very smooth, it was a great sound. The other was much harsher, almost braying[0]. They seemed to be played with much the same high level of skill, so why the difference? They both sounded like saxes but...

[0] edit; certainly in tune but quite harsh, rough as a terrier's coat
Vochain: A Blockchain Optimized for Voting
The Google Keyword Planner gives you an estimate of traffic for a given keyword, which is a proxy for interest.
Sure, but the criteria should be the same for everyone. The killedbygoogle site that people love spamming to HN comments has equally questionable entries.
Like a few of you I get the sentiment in this, but disagree pretty hard. Wordpress commenting is a minefield, and from my experience has many issues - particularly around moderation. A lot of the suggestions in the comments here show there are a tonne of methods to integrate comments into a statically published website. Yes most of those rely on server'ful' implementations but you'know what that's ok! I've been following 'serverless' and 'JAMStack' and whatever for years now and I think it is at a point of existential crisis. On the one hand you have the purists that want everything to exist in cached buckets otherwise it doesn't count. These people are taking the 'serverless' vibe a little too seriously for my taste. Yet on the other hand you have things like Nuxt, Next and Sapper - yes more frameworks - but these 'meta-frameworks' embrace the great things about static content alongside the benefits of dynamic APIs. Some of the stuff that Vercel is doing is insanely good and makes it possible for small teams to implement rapidly and let ideas win out. At the core it feels this argument is a team of 8 devops, vs the two or three product people that are doing it all. I get that metal will always win, but I feel that there are compromises in technology that need to happen to get stuff made.
I salute your level of abstraction but I personally draw my line in the sand a bit higher. A library project for the data access layer with a stable app facing code API gives me the best bang for my buck in terms of flexibility and abstraction.

That said, its easy for me to push out new code versions. I realize it doesn't work for everyone.
I'm just impressed that a private citizen (? -- I am not familiar with the guy publishing these reports) has taken on the interest and duty to monitor and characterize errors in a global satellite system. Just to think that that would be something you could do (and not be lulled into thinking that some big corporation has it all under control) and go about making that your pursuit.
The Amiga 3000 Plus System Specification [1991, pdf]
Which variables are being omitted? Certainly there are other variables relevant to a quality life than money. But the rules apply to any utility function you might come up with. You want to maximize risk-adjusted return.
> I would assume by default that anything involving graphs should not involve SQL.

That would be a questionable assumption. SQL databases are a widely tested tool, and SQL itself can allow you to augment your "graph" with constraints and semantics that many graph-focused systems have trouble with. CTE's, while not entirely trivial, are not overly complex; they're not something you'd spend "hours" debugging.
This is a big vehicle - can't it store larger batteries and get greater range? I feel like 350 miles in ideal condition is not what I want in a truck that may be taken offroad to remote areas.
This is a slightly weird example because it's adding an empty <div>, so you can imagine it could be optimized if it provably has no effect on layout.

But let's imagine instead that the node added to parent was a div with a text child. Or, slightly less obviously, the div is getting added in a document with a style rule of `div { width: 1000px;} In that case, the width could change. So the browser engine's options are:

1. Return a stale value from parent.innerWidth for now, and just lazily update style at the next event loop iteration.
2. Synchronously update style and layout (note, this update is not as expensive as a from-scratch layout), and return the up-to-date value of parent.innerWidth

It turns out that, historically, the earliest browsers with scripting did option (2), and websites came to depend on it. So browsers had to keep on doing it, and so forth. Many folks in the web standards world would like to find away out of this dilemma, where DOM mutation doesn't risk this kind of performance hazard.

You could also imagine an extra bad option:
3. Every time the DOM (or the CSSOM) is mutated, synchronously update layout.

This is super expensive in the face of repeated DOM mutations. Repeated DOM mutations (e.g. adding multiple elements, setting multiple attributes) are way more common than repeatedly getting style/layout-dependent attributes. (3) has the same observable functional behavior as (2), but it's a lot slower, because it will do a lot of unnecessary layouts.

I'm not totally sure if this explains everything you were wondering about, but I hope it helps some.
GPT-3: Informational Hyper-Inflation
Definitely not the latter ;) I think it's too new of an article to already qualify as a gem, but it's certainly made me think about a few things with a new perspective, so there is that :)
So much this. ORMs? That way lies madness. For example if you use Hibernate in Java you can end up writing stuff like this:

interface MyRepository {
Page<SomeObject> findEntitiesByIdAndCreatedAtAfterOrderByCreatedAtDesc(int id, Instant after, Pageable page);
}

This abstracts away executing a query along the lines of:
select * from entities where id = $1 and created_at >= $2 order by created_at desc

I'll take the latter any day.
You may create view with complex query. Views are ORM friendly to use, and are human friendly to edit.
Excess liquidity from lets say excessive monetary policy is going to makes its way into other asset classes.
A large grid is harder to manage and runs the risk of a cascading failure. Especially as HVDC is a lot cheaper and more efficient than it used to be, there's an argument we should actually be breaking our grids down further.
The early stage of Theranos wasn't really a scam, they tried to build the actual product. The scam started when they failed to do so and then lied about it.
The key is that hardware has marketpreassure to become faster and faster. Software gets faster if there is market preassure (see gaming & financial). When the feature backlog is more important than performance that is obviously what is prioritized. You obviously can't work on everything.
That's a quite unobvious consequence of the software progress. Making software be "a bunch of bricks for creating applications" do come with costs. And the main cost is performance.
I agree that ORMs lower the barrier of entry for creating a full stack app.

But it's not just the suggestion of GORM. It's that it is often suggested as the solution and anything else is unviable.

I think writing a web app and knowing how the database works are interlinked. It's incredibly valuable knowledge as a web developer IMO.
Counterpoint: a lot of ruby devs are very familiar and capable with ActiveRecord. Al lot of python devs are familiar and capable with using the Django ORM. Why are these ORM more likely to limit your application? You provide no proof or explanation of your statement.
Could it be cloud of asteroids like the oort cloud?
Would something similar be done with Linux's netns ?
Daniel Shiffman’s explanation of the perceptron algorithm
IMO people discussing this topic really need to clarify what type of applications they are working on because the cost/benefit analysis changes quite significantly based on use case. If you're building a web-based reporting tool where you simply query records out of a database to dump to HTML and your objects are short lived, you might not get as much value out of an ORM compared to a client-side app where objects stick around for the entire lifetime of the application and you have to worry about things like object identity and staleness.
I would say that what most people commenting on this thread don't realize are the benefits of storing static content as code in plain text files.

Text content in a database is unversioned and only accessible through SQL queries in sophisticated dedicated clients; while content in markdown files can be changed with plain text editors and treated just like source code, getting all the advantages of branching, diffing and merging versions among multiple users.

Think about whether you'd like to work with all your source code stored inside a CMS like Wordpress instead of VCS like Git, and you'll begin to understand why Static Website Generators are a good thing for the people responsible of updating the content.