skysight-inc/HackerNews huggingface dataset:
If you half-ass using an ORM then you get the worst of both worlds. To get value out of it you have to embrace it completely: write all the queries in the ORM (so that the ORM's caching functionality etc. can actually work for you), define the schema in the ORM and generate the tables and migrations from that. Working with an ORM and avoiding SQL is not just doable, it's easy, but you have to actually try.
> And all browsers continue to have that same hazard that querying layout-dependent properties forces a synchronous style recalc and layout.

Could you explain why?

Is the following true even when the parent is already in the DOM?

parent.appendChild(document.createElement('div')); // Fast; ~50 us
let w = parent.innerWidth; // Slow, forces reflow; ~20 ms
The mathematics of SDFs are arguably easier to define then that of ray intersections, even for boxes and spheres. For arbitrary surfaces the intersection may not even have analytic solutions (true for >5 order polynomial surfaces), perhaps you'd need iterative solvers, so SDFs generalize and facilitate this intersection problem. You can even raymarch really exciting objects like fractals!

You can of course triangulate your surfaces into tiny triangles and use raytracing or rasterization. But then you're plagued by inevitable little edges unless you have at least as many pixels as triangles, at which point your performance gets really poor. So SDFs are really exciting for extremely accurate (photographic quality) reproduction of mathematically-defined objects.
I don't understand what that means; this isn't reddit, please don't just post blatantly false statements.
> And that means they suck for society at large compared to what? Random guessing? A corrupt government price system? An omniscient one that can solve NP hard problems?

There's an intriguing recent book (that, admittedly, I haven't read) called "The People's Republic of Walmart" https://www.penguinrandomhouse.com/books/564287/the-peoples-...

If large corporations are the shining beacons of capitalism, how come they are run internally as top-down planned economies? And to the extent they prove than planning can work at scale, could planning work society-wide? Not saying I agree or disagree (again, I haven't actually read it), but dusting off the ye olde calculation debate and updating it for today seems like an interesting idea.
I am aware of a written work on which the author inscribed "Copyright (C) <year> <organization>" and as best I can tell <organization> was fictional, and thus incapable of enforcing any terms of the copyright. What is your opinion as to what would happen if someone attempted to claim that copyright?

It looks like a pretty brilliant hack to me.
Not so sure that's a good example? From https://isotope.metafizzy.co/#commercial-license , it looks like they are offering paid commercial licenses.
They might just be statistical outliers. Given infinite time, would any investor beat the market? That's the real question (sticking to the mathematical theory here).

Be careful before holding up a single example as an exception to the rule. Some basic statistical analysis show there was a 30% chance the Red Baron, the most famous WW1 fighter pilot, was just lucky. And obviously his luck eventually ran out.

https://www.scientificamerican.com/article/news-bytes-red-ba...
I’m having trouble understanding your comment, but it sure sounds a lot like complaining about downvotes–that’s usually not well received.
This is SSE. Here's a good answer on SO comparing the two: https://stackoverflow.com/a/5326159/1714997
To be more clear, the statement should have been that on average, they don't. As far as I am aware, this _is_ true, although quite surprising, and not a popular idea among investors. The second part of the argument is interesting. On the one hand, a la Warren Buffet's analogy of thousands of professional coin flippers, it is obvious that a small number will do great, while the average will do average (or slightly worse, because of fees). This does not imply that there are _zero_ people who can consistently and on average outsmart the markets, only that it seems to take more than the median full time, relatively highly trained professional to do so.
Microsoft Edge on Linux
Fuse.js: JSON vs. JavaScript object literal speed tests
There are many reasons why ORMs work better than it did earlier. For one, people prefer simpler database schema these days - and what used to be larger monolithic apps are often broken into micro services. Earlier, you'd have one big database - today you'll have many. And ORMs are great with simple queries and joins.

The language plays a big role in whether an ORM is actually useful or not. In the .Net world, ORMs work quite well because querying capabilities are integrated into the language. Queries and schema are verified at compile-time, and I wouldn't trade it for slightly better performance or control. On the other hand, with Python (or say Node), or with Java and Hibernate the wins are smaller.

Of course, there will be some queries which are just better written in plain SQL. If you're willing to accept that, ORMs are a good tool in your toolbox.
I'm a Go developer and I notice a lot of other Go developers instantly suggest things like GORM to noobs writing applications. Whereas I always suggest against it.

I'm a big advocate of understand your data model at the database level. Need to join on too many tables is too easy to do with an ORM.

My go-to strategy for SQL is simple. Abstract your SQL as far away from your application as possible. Not just by using interfaces in your application, but by using stored procedures in your database.

In my mind SQL is just another service your application depends on. And you want that interface to be as simple as possible for your application. If you need to tweak SQL performance it should not need any input from your application. I could completely migrate to a new table relationship structure without the application realising if that was what was needed. You could even go as far as to unit test just your SQL code if you wanted, something you can't do too easily when it's in your application.

Yes, if you need to return new data then you need to update your stored proc and code. But that's so worth it in my opinion for that extra layer of abstraction.

My opinion is slightly skewed from a decently sized business perspective, but I do still follow this pattern in personal projects. When migrating applications to different tech stacks (like Java to Go, or C# to Go) this abstraction has meant the world to us.
I agree, the performance is a very nice bonus, but it is primarily about expressiveness, composability and natural simplicity.

It just seems profoundly un-natural and arbitrary to limit dispatch to only the first argument.
How do you deal with complex reporting queries when embracing ORM completely?
My project has no ORM, and now that other developers are coming on it is hard to work with - the readability of an ORM far surpasses writing your own queries and I can see that the benefits far outweigh the cons.

And what's not to say you can't write your own lightweight ORM to abstract the database if you can't find a tool that suits your goals - and as always it all depends on your use case.
Sure. You could also multiply by 4, wasting at worst twice as much memory as optimal on pathological input.

But wait, why are you converting from utf-8 to utf-32? To iterate through? You don't need to count your codepoints for that, you can just advance through your utf-8 linearly. To index into it? You might as well index into byte offsets—sure, that makes some possible indices invalid, but so does the finite length of your buffer.

And what are you doing with the codepoints anyway? utf-32 turns out to be profoundly useless for pretty much every concrete use case, because its whole appeal, that its code units map 1:1 to code points, presupposes that there's something you'd want to do with the codepoints.

There isn't. Code points are practically orthogonal to all of: user-perceived characters, user-perceived graphical symbols, grapheme clusters, text width. They combine arbitrarily in ways that you cannot infer without knowing the semantics of every possible code point. There is no linguistically sensible text operation you can do at the codepoint level. They are completely useless to you.

The worst part is, there are a lot of operations you can do with codepoints that seem, to cursory inspection, to do something you want. But they're wrong, all of them, necessarily so, because you're working at a level of abstraction that does not have the information needed to do just about anything correctly, but the cases that are broken are ones where none of your developers even know what the correct result should be.
I think I understood correct

"When you have foreign keys, you refer to related identities with an identifier."

"What this results in is having to manipulate the ORM to get a database identifier by manually flushing the cache or doing a partial commit to get the actual database identifier."

This(and the sentences before it) basically saying if you have if you have a foreign key you have to first save the main object to get it's id. Id doesn't have to be responsibility of the database. In fact, I'd argue an identifier is an application layer concern. Orm could still solve this problem by simply cascading, or you can use one of the identity strategies that don't rely on database assigning it. You can generate them in either application layer or orm layer through identity generators.
On all Apple devices the display is glued on, and on smaller devices a few of the internal parts are glued. Check out an iFixit tear down for a look at where the glue is.
That's called cache warming and high-volume sites have been utilizing that upon deploy for decades.
This is interesting to me. It makes me wonder "are there cases where someone made the market more efficient and was not made very wealthy?" I think you're right that there is a massive incentive for the market to be more efficient, but I suspect there are cases where people were able to develop alpha without being able to capitalize on it, because the market denied or neglected the insight.

Were there free markets in the 17th century, would they have been able to incorporate Galileo's insight? Or would they have joined the church in denunciation? Part of me thinks that if they did eventually come around to the solar system, it wouldn't be all that quick.
One application not mention in this thread is to traverse trees, like in the old forums where you had many levels of categories/subcategories. AKA hierarchical query. SQLite already has support for this[0]. It seems they are supporting multiple selects now.

[0] https://sqlite.org/lang_with.html
There is trust and there is visibility. Here’s an alternative example I actually do quite often: I attach debuggers and such to system processes. Not because I don’t trust them to not do something malicious, but knowing what they are doing is always useful to me. If Mail is randomly reading files from my Documents folder, perhaps something is wrong with it. Maybe I should just tell it that I can’t look there and see why it might be doing so. These are things that give me more control over my system, not things I engage in because of a lack of trust.
Is this real? I feel like this is April’s fools. When reality becomes the simulacrum.
The most pragmatic reason to stay on Mojave a little longer might be that it’s been tested on many millions of Macs for two years. So I’d say Mojave is less likely to break than Big Sur, whose hidden issues are probably yet to be discovered. That goes double if you have a less common setup, e.g. an eGPU.

(Note that this is not necessarily true for security vulnerabilities. As in most complex pieces of software, security bugs are guaranteed to abound in both Mojave and Big Sur.)

Other reasons to stick to Mojave for now: support for 32-bit apps, fewer confirmation pop-ups, easier kext handling (I guess?) and better AirDrop support for older devices. Also, iTunes – in case that’s your thing.
And in that same vein, why haven't we focused on the infinitely easier realm of rail automation and safety?

We jumped right to the hardest problem set. Probably because it's the most sensational and easiest to get broad financial support by selling people the promise of less rush hour drain.
I agree and for any serious database used in production SPROC's have so many advantages improved security as well.
Regardless of whether that want is feasible today, having something that gets closer to it is clearly the goal.
It depends on the host firewall... many quality operating systems allow host firewalls to apply process-based policy which your upstream certainly can’t achieve.
Linux Mint Cinnamon has this feature, with package `nemo-preview`. It even plays back actual video when spacebar'ing on an MKV file, something I can't do in macOS!
When we are talking about malware that's irrelevant. And if we are talking about inspecting Apple's traffic, I don't think you should trust things you see on their hardware running their operating system.
Less sexy, less money, more government.
Is warren buffet himself not an example of someone who has been able to consistently generate alpha?

I think this question is hard to comprehend when you blow it up to this massive scale. Heres a simpler (and I claim) equivalent problem.

Imagine you're in a room with a friend. You're both tasked with estimating the price of a company. You both read through the companies 10Ks and whatever other information you can dig up. You read a bit more carefully than your friend, and detect an issue in the company's finances. Now you have alpha, and can develop a better estimate.

The market is this same scenario, but there are millions of folks playing the same game. That means its harder to find that undiscovered blip of insight, but that doesn't mean it doesn't lie in wait for the diligent. Just as there are still original thoughts, there are still original insights, and possessing them means, for a moment, you can beat the market.
Debian Maintainer from Zero to Hero
If you're talking about linq I wouldn't call that an orm.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.

Pretty much the case for every non-Software Engineering discipline.

But then again, people in the tech field will vehemently defend the system - because it's one of the very, very few fields where you don't need a college degree, can go on and "grind leetcode" for months, and land a six-figure job.

And it is because of that, that tech companies are making their recruitment process bordering the absurd. They're simply deadly afraid to vet frauds, that have "gamed" the system.

So in short - tech companies would rather let 10 decent candidates slip by, if it means they can block 1 fraud.

I've been to many engineering interviews, outside tech, and it is not even remotely the same process.
Thanks for the example. Could you also tell how much the speedup of this led to?
Amnesia: The Dark Descent or How to Forget to Fix Copy Paste
I think the most important part is to create your database schema through your ORM. I used to do that ages ago with Ruby on Rails, and that worked very well. We still had our complex reporting queries in SQL, and that was no problem. The point is that if you use an ORM, your database needs to be optimised for that ORM. Bolting an ORM onto an existing database is a recipe for disaster.
This is perhaps one of the most serious problems with software as an industry. More precise is that human investment doesn't scale, which includes: discipline, education, training, mentoring, and so forth. That is true for all industries.

Other industries know human investment doesn't scale, but even still it is absolutely professional and so it must still be accounted for. Software intentionally ignores this and then looks for things to blame when the tech debt becomes overwhelming.
> There are 20 more that you could have named.

Of course; these were just examples as the "e.g." tells.

> How do you test that someone is an expert, especially if you don’t have an expert on staff?

I gave some idea on https://news.ycombinator.com/item?id=24841552
The effect of the recent lockdowns on seismic noise is discussed here if you want to read more about seismic noise:

https://ethz.ch/en/news-and-events/eth-news/news/2020/07/loc...
There's many problems with meson and cmake, but as for meson. Meson is the kind of build system that makes using tools hard as it forces certain workflow to you. It detects the compiler and tries to be too clever what you can do with it and what you can't. For example recent mishap was that it detected emscripten compiler and didn't allow me to use it as non cross-compiler and so on. There's no way to build static libs, if the project hardcodes shared library building. The codebase is also pretty nuts, I welcome you to go read it.

(GNU) Makefiles with some standard variables and pkg-config are still the king. Cmake and meson can work okay for very simple projects, but other than that I'd recommend always using native build system for each platform, or going Makefile + mingw route (if you need windows builds).

Using native build system eventually saves you time and headache, especially when these "portable build file generators" don't support some feature you absolutely need, or doesn't allow you to put that command line flag in one of the tools that gets executed under the hood.

CMake also absolutely sucks at finding system dependencies when everyone uses those "FindFooBar.cmake" files with hardcoded search paths and what not, instead of using pkg-config. This forces many packagers to hack the projects build system, because the project would otherwise link to wrong library, or not find the library at all. With pkg-config the distributions can provide the correct paths and flags when linking against something.

Autotools, while slow and generates tons of shell script that's compatible with all sort of ancient shells and platforms, still manages to offer a standard interface to packagers and fine tune exactly how things get linked, how things get configured and where stuff gets installed. Autotools in general is less headache to packagers than meson or cmake.
While the end result looks like a graph, I think that still qualifies as a standard relational DB use case though?

A graph database usually means you’re storing the graph nodes and edges as entities, so you can traverse the graph easily from any direction, and express different kinds of relationships.
Amen. A properly configured and hardened VPS on a service like Digital Ocean or Linode can run and vertically scale your app well into profitability. It’s really not that hard to manage a server with Nginx, Php (or whatever) and Mysql (or whatever).

After mastering those basics, any obfuscation layer built for “ease of use” was actually limiting to me. With a few exceptions like Laravel Forge. But that essentially auto-manages a VPS with a Laravel app for you. You still have root access to Ubuntu.
More like replacing declarations with magic number literals. And that does hurt interactive prototyping if it happens a lot!
It is a feedback cycle that has a negative effect on all consumers, not just the consumers that would use a different search engibne.

The feedback works like this:
1. Google is dominant and can outbid competitors.
2. Many (most?) users will not change default search provider so long as it is basically functional.
3. Google's competitors will only attract a minority of customers that realize they can change and decide to.
4. Google stays dominant and competition is stifled and with it any improvements.

As a user of alternate search engines, I am hurt because if 2 did not occur and people that did not care were distributed evenly then my search provider would have more revenue and would presumably hire more engineers to improve the service. Another competitor cannot capture that revenue from 2 simply because Google can always outbid them because of their dominance.

Of course, there are some number of people who would switch to Google if the default was Bing, but is it significantly different than the people switching now?
Either figure out how to express the queries you need within your ORM, or create a place where you can run ad-hoc SQL reporting queries that's completely segregated from your live data - e.g. a read-only replica, or regular database dumps.
You can get some benefits you mention by using query builders (like jOOQ). They can get unwieldy at times (not part of the language), but you can drop directly to SQL if you need to, and they tend to be simpler than ORMs in various use cases.
Well, that's my main opposition to "AI will replace [insert any profession]". Many jobs are so specific it will never be economical to hire a team of software+AI specialist to create and maintain the software to automate that work. Plus the fact that the said specialists usually know nothing about the domain.
It depends. ORMs are for dealing with the objects and schema, not with aggregate reports. I still use raw SQL for that. But more often you can just project your data into some BI system and let the users click together their reports themselves.
Linq + ef or linq + nhibernate. You can use linq to query against both.
Among US utilities, local public utilities seem to work best. Federal run facilities are deeply mired in bureaucracy and acquisition guidelines, while fully private power companies are prone to get bought out by large investor conglomerates and end up too driven by quarterly profit to invest in maintenance.
What I've learned about career development (*) (**)
AWS and their Billions in IPv4 addresses
Speaking only of CMake, it makes my life much much easier. If a project has < 5 files, a pure makefile is just fine. However once it gets any larger CMake makes linking, recompile times, and other stuff much much eaiser
> If enough people said to Apple "hey, this stuff is not acceptable and we won't pay for it" and then they actually did follow through, Apple would stop.

“The market will price this out” doesn’t actually work because it assumes that 1. Apple’s product strategy is done to match market desires perfectly and 2. The decision to buy is solely predicated on this particular thing. The first is false because nobody can do that and the second is because people buy Apple products for other reasons than just that. I personally know many people (although this sample is of course unbiased) that buy Apple devices for a number of reasons (they work well, they look nice, they have good support) but hate that they can’t do thing on them. But their purchase decision doesn’t reflect their opinions on this particular issue.
Application code have one way of describing data and their relationships. RDBMSes have a very different way of describing data and their relationships. At some point, you are going to have to reconcile the differences between the two worlds - this is the so-called "object-relational impedence mismatch".

Unfortunately, even if you choose to reject ORMs and go SQL, you're still going to have solve this problem at some point, and it will not be pleasant.
The purpose of in-place operations is to avoid allocations, so this seems like an oversight.

Is this a matter of simply wrapping the 'right' LAPACK routines, or is there something missing in the interfaces that could be trivially added in principle?
ORMs are good for quickly building something. But if you're building something that is expected to last and that will be passed on to other developers... ORMs will likely derail or put severe limitations on your application.