skysight-inc/HackerNews huggingface dataset:
Aside from the fact children are already given loads of vaccinations, there's much worse things they don't get to decide, like having part of their dick cut off shortly after birth. Also, in some traditions, having an old dude suck on their dick after having said portion cut off.

Your arguments are... quite weak. Some children also don't get to decide if they're going to get forcefully sent to a camp/hospital where they literally shock you, repeatedly, which is incredibly painful, in an attempt to change something about you.

Or, once upon a time, not too long ago, give you a lobotomy with an ice pick.

If only people fought for all of these things, which are quite detrimental, instead of vaccines, which are quite beneficial.

Also... if the world goes to shit because of the climate, it's highly likely we (in the US) may begin to see some mandatory military service. Guess how many vaccines you get to get there, some of them pneumatically shot in to you...

Humanity will never know peace.
You both made me smile, if not actually laugh.
> a Rust port of Qt might be more workable than bindings to the C++ toolkit.

That's an interesting idea! it might be worth considering it, at least.

I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term.

I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?
Yeah, like those Canadians in Lytton, B.C. who endured temperatures hitting 49.6 in last week's heat wave, only to then have their entire town disappear in a fire.
The way I understand it is that if you don’t trust your ISP then a VPN is a suitable choice, if you don’t trust your government then much more serious technological measures are required and even then it’s fairly unlikely you’re winning against a state organisation that’s decided it specifically doesn’t like you.

I don’t trust either my government or my phone company to be honest, but I’m not doing anything that would offend my government so I’m not enormously worried about them while my ISP and phone company have a strong incentive to abuse my privacy and monetise my traffic further. Even if they didn’t, VPNs offer protection when using public WiFi which can often be badly set up. Having said that using a free VPN is asking to get mugged off in my opinion, paid VPN providers at least have an incentive not to compromise your privacy as it’d be bad for their business.
Lyft is $40 to go 2 miles in SF quite often. With tip it's rarely less than $20
I never really get why you need to preserve naturally dying language no matter what.

Can anyone explain in simple words — if something abstract is dying naturally (not by force or someones bad intentions etc.), why we need to waste resorces and energy to saving it?

Don't we people have higher priority issues right now?
GraphQL is stiff competition, in the sense of "stiff as a corpse". Yes, it has the words "query language" in the name, but that's where the similarities end.

In GraphQL, you can select fields of JSON objects, optionally a field may have parameters which affect the values it returns in unspecified ways. That's it. Because of this design, unlike in SQL where you are concerned with modeling the structure of your data, GraphQL also requires you to think about the API all users will use to access the data. In SQL, I can write a table defining the structure of my dataset, and then users of that table can perform arbitrary queries when they know what data they need (aggregate with a month average grouped by account ID, filter to only rows where x = 7, JOIN this to grab some data from some other table etc.).

GraphQL has no aggregates (sum, average...), no grouping, no joins, no sorting, no filtering, other than what you manually design each using parameters at schema design time. Good luck anticipating the use cases of every future consumer of your data. Miss one? Better dig back into your implementation code & implement that use case each & every time a new one comes up.

The only part of GraphQL that is standardized is the query syntax. In SQL, the actual underlying relational data model exists and the syntax of queries exists within that context, not so in GraphQL land. In SQL, I define my data structures, and users can write queries and access the data. But GraphQL throws up it's hands and says "not my problem, try one of these libraries that ask you to implement your own custom data access functionality for all your data types".

OK, so it's a rubbish query language, but even the graph part of the name is misleading. Assuming that you even have a domain that it makes sense to model with a graph of types, GraphQL provides you no tools for dealing with the backend complexity of such a design. Because the syntax is so simplified, there is no mechanism within the syntax to define rules about relationships between types. For example, imagine a simple parent/child relationship. There is no mechanism within the syntax to tell GraphQL that for parent X, parent.child = parent.child.parent . So you can't even think about writing a GraphQL query optimizer, because there isn't enough information about the structure of the data encoded into the schema or query to do so.

So in practice no GraphQL implementations that I know of have anything resembling a query optimizer - someone asks for cart.item, and then item.cart for a cart with 1000 items? Have fun re-requesting the cart from your DB 1000 times (yes you can cache the item by ID to save a DB lookup, but we shouldn't even need to hit cache here! Every programmer involved knows the data is the same, it's just dumb GraphQL has no clue about the details of the relationship).
SQL is exactly like the QWERTY layout: A first quickshot with little design thoughts and unfixable architectural issues that‘s so widespread that everyone is used to it by now.

Trying to change to the Dvorak layout taught me a lot about enacting change on such a grand scale.

After a lot of hassle switching machines and OSes, typing on other user‘s computers, them typing on mine and general headaches among internationalization and inaccessible key combinations, I switched back to QWERTY in the end.

As said in other threads, there is no shortage of attempts to replace SQL. A lot of them are pretty good. But having learned SQL the hard way, I feel zero urge to learn another language from scratch right now.

It‘s why nearly all big databases eventually switched to it despite the FORTRAN vibe and its general ugliness.

Anyway, probably time to SET TRANSACTION LEVEL READ UNCOMMITTED and call it a day ^^
This article is why desktop Linux is so broken.
Nobody firmly in control to root out misbehavior like this.

This article broke my heart, because it’s indicative of a greater problem in our beloved Linux community.
Files are closest to the metal.

That's where we can improve things most for everyone.

But drivers need to be compatible with everything and hardware needs to also be compatible with everything, there is no progress.

To really change things we should design hardware (disks and monitors) that have drivers that only work with them.

But in the meantime having simple database like functionallity in the filesystem, like being able to list files 100-200 in alpabetical order f.ex without wasting CPU/memory would be interesting (today you need to use multiple commands that list the whole directory)!

Also looking at directory compression that does not require you to uncompress the whole directory to get a small subset of files.
For SQLite I use 'natural join':

select foo_id, quux.value
from foo natural join bar natural join quux

Unfortunately this doesn't actually use the foreign key relation; it matches on the same element name. So you have to have `foo.bar_id` and `bar.bar_id`, as well as `bar.quux_id` and `quux.quux_id`. But I find that actually makes queries more readable.
Also worth noting that recent versions of Firefox block GA by default
The half she kept is the identifying details other than names of the actual, real-life people she based it on - so much so that their friends immediately recognised them in the story - and the half she changed is stuff internal to their relationship that those friends would have no way of identifying as false and that seemingly fits their existing sterotype-based assumptions better than the actual reality would've.
You can already do that by having circle and rectangle relations. Union types dos not give you any additional power compared to relations.

Your proposal might be more convenient though than creating multiple relations, so we should look into making it just as convenient to create the necessary relations to express this. So lets say your syntax proposal creates multiple relations under the hood - then I'm all aboard!

The "everything is a relation" is a really powerful concept in the relational model. Adding composite column types like arrays, unions etc. are still less powerful than just using relations. But people like it because the syntax is more convenient to use.
> I think the point was having the binary be of the same name, so it could work as a drop-in replacement that is compatible with existing software.

This is a long solved problem, you don’t use the same name. That’s very bad joojoo.
Uber sold their entire SE Asia operation to Grab a couple of years back.
add Singapore to your list of places that didn't need Uber

OTOH Kuala Lumpur is so much more accessible with Grab than before
they got rid of that
I'd have said "candidate expects employers to beg them" was a straw man if I wasn't replying to someone literally insisting that's the role of the interviewer. Would have said much the same about comparing interview questions to Jedi mind tricks! And tbh if someone asked me interview style questions during a date I'd run a mile...

It's not a "stupid Jedi mind trick" to ask people why they want a job, it's a pretty straightforward way of finding out whether they have a particular skill, interest or aspiration that might lead to further relevant questions and a filter to remove people who either don't want the job, haven't read the job spec, think they're too important to answer questions or somehow both realise that framing matters and think framing themselves as uninterested is a good move. "I am here to find out how I can help you succeed" or regurgitating the list of the company's "principles" off their website probably comes off as fake, "no, you tell me why I should take the job" certainly comes across as egotistical: perfectly acceptable answers include talking about being good with their tech stack, knowing their market, looking for a more senior role or wanting to find a new employer that values x more (do you value x?) and can include followup questions.

I go back to my earlier point: if you get to the inevitable point in the interview where you're asking them questions and their answer to what's good about the job or what they like about the company is "no, what's good about you" or "um....", the alarm bells start ringing. The whole point of interviews being a two way information exchange is not setting off the same alarm bells in employers' minds
> People: write simple, portable code!

That isn't always how it works in practice, though. It's useful for your build system (or meta-build system) to be able to check for, say, C++17 support, and cause the build to fail early if this is missing.

Similarly, you can use a tool like CMake to detect libraries. If a library is missing, you might want the build (or, rather the 'configure' stage) to instantly fail, or you might want to build with certain features removed to cope with the library being missing. CMake supports both, as does autotools.

I agree with everyone who says CMake's scripting language is atrocious and that it's often miserable to work with, [0][1] but that's because CMake specifically is terrible. The problem it's solving is a legitimate one.

An example: you can write a desktop application with two different platform-specific front-ends, and have CMake compile the appropriate one given the target platform. This is nicer than relying on the two platform-specific build systems directly.

[0] https://news.ycombinator.com/item?id=24203172

[1] https://news.ycombinator.com/item?id=24565266
Don’t running out of fossil fuels and combating climate change have overlapping solutions anyway?

Also not just temperature increases but more weather unpredictability. Impact on food supply and for many people impact on shelter. Basic life necessities. Coronavirus and wars might be a walk in the park by comparison as much as I hate to say that as it sounds callous
Show HN: HubMeter – snackable recent GitHub activity stats visualized
I was just looking at one URL that hit the front page a day or two after publication so I don't think there were many bots.
My Mental Model for the World of Crypto
Oh I actually made a compact font too, but it's 7x13 (most characters are 5px wide). Don't have a name for it yet. The first version was bitmap, but at some point I figured out how to make macOS render vector fonts pixel-perfectly and so made a vector version too.

My way of making it is questionable too — I drew characters as SVGs (because font editors suck way too much) and wrote a php script to convert them to an .sfd file that I could then open in FontForge and export in whatever format I want.
One and only problem is that you cannot travel too much because of Covid. I would go to Norway Nordkapp and enjoy the all-year-round 10°C, but I have to sneak in and maybe end up in Norwegian Jail. But they probably have AC and Internet, so is not a bad option either.
> marketing F# as a C# replacement

I agree with this; it should of never be marketed this way. For me C#, once you get past a lot of the initial ceremony of the language and all the libraries/OO patterns you need to learn (DI, mocking frameworks, etc) the gap between C# and F# gets a lot smaller. C# isn't a bad language and has a lot of features, it just also has a lot of history that adds complexity. IMO the benefit of F# and other newer languages is about simplifying things while keeping the same level or more expressive power. If you've already learnt all the patterns and frameworks in C#, have reasoned around the historical complexity and the ways around things seem second nature to you there isn't much to gain and some things to lose (e.g. familiarity, politics, fear of change, support).

Grab a Go, Python, JS dev however and show them idiomatic F# code vs idiomatic C# code (with tests, and scaffolding) and from first hand experience I've seen what they choose. Even more so because typically these people typically use tools like VS Code and not a full blown IDE, where F# has the advantage at present.
I agree that a more selective approach might be better.

The typical response when talking about bindings to Qt is that there are so many impediments to make a decent bridge between language X and the C++ land. But I think that while correct (I've suffered trying to do it myself), it never compares that effort with what would really take to do it from scratch and get to a comparable level of features or robustness. Not only because of the code itself, but because of the knowledge, the know-hows and know-whys of the field, all the tiny decisions that the original library made and you'll take ages to come up with and make too.
My apologies! I misread and thought you'd written intellisence. I thought you were talking about the realm of autocompleting tools in general. My bad!
Glad the project helped a bit a few people :) I don't have much time unfortunately to enhance the engine nowadays, and the code is dirty and broken beyond any repair. Yet I'm still puzzled to see how many people are still using the project today.

You'll probably find better approaches, and while I never tried scrapy, it seems to be using a javascript engine for hard cases, which was something I thought about (but this was way above my skills at that time).

The hard parts remains however, if you want a functional site: you need to rewrite links, or use an external proxy-like mechanism. Having a fully functional offline, file-based site, is the real tricky part. Cases will remain unsolvable, as the inside code logic can produce whatever external link resource based on randomness, time, etc.

The approach in httrack was both ugly and pragmatic: attempting to recognize link/files patterns within javascript and fetch/replace what can be replaced with local links. Javascript producing html will typically be analyzed with really dumb - yet sometimes effective - js parsers. (parental advisory: don't look at the parsers code, your eyes would melt)

And obviously this is not going to solve all cases and will even break pages with tricky js
Please link to a valid source if you're going to make such statements
I believe the point was:
“Their initial work was not fixes or changes they had tried to submit to NSM, but a rebranding effort.”

And no, I don’t know what NSM is, and I might be totally wrong on GPS intention.
This has bugged me for _years_. And it's not like it's asking for, say, full regular expression support or anything. Just the ability to search for braces and hashes and stuff :-(

I don't understand how so much effort can go into things like the "Actions" mechanism, and nobody can get the search mechanism to a minimum level of decency.
Did you have a salaried job in programming where that was in your contract?
Yeah let me try to dig it up.
taxis could never compete with Uber and Lyft because they as actually own the cabs. Uber and Lyft can respond to surges. Taxis can't. they'd lose money owning enough vehicles to support surge times and have them idle during non surge.

The couldn't have tried to be Uber either because the law didn't allow non medallion drivers
"Based on a true story."

It's not fiction. It's taking the personal relationship of two people and editorialising it to turn it into something it wasn't - for personal gain and political status - while causing the people in it genuine pain and grief.

It's a form of appropriation. If it was mostly fictional it could have started from a different premise and used different characters.

The character space that authors can work in is unimaginably vast, and there was no need at all to use personal experiences to "borrow" detail when some imagined experiences would have done the job just as well.

In reality the the impact of the story comes from the people it's based on - not from the creative imagination of the author, who took their private lives and feelings and distorted them into a saleable feminist parable.
I suspect that you might not have worked in one of these positions. I assure you that it'll be in your contract.
>The climate emergency people are going to have to keep struggling to argue that the emergency here is the temperature rise.

Nobody is struggling to argue that because it is absolutely obvious to anyone who's not wilfully stupid and ignorant.

>The evidence remains that running out of fossil fuels is a bigger threat to humanity's comfort than using them

What evidence? You have none.

> At the timescales being talked about moving cities as a one-off thing if any problems become imminent is an entirely reasonable plan. Shenzhen was built in 40 years.

Except you won't have any space to move those cities to that isn't already occupied.

To say nothing about how you'll manage to feed everyone in a completely messed up ecosystem.
Airline pilots have a very high workload when landing and it requires intense focus starting about 30 minute before. They are not allowed to talk about anything unrelated in that period.
Ask HN: What is the best way for the average programmer to grow?
Everyone's way of doing things has some skills, and these skills can avoid taking a detour, Can you teach me what you think are the most valuable ideas, tips, or experiences from your career as a programmer?
Thank you very much
---From a rookie programmer who is not willing to be mediocre
Can you share the data or your findings please?

From what I see, the situation is the same in India - hardly any vaccination and the big 'C' cases have gone down significantly.
You and I discussed exactly this 3 months back. I won't restate my responses here, but for anyone curious: https://news.ycombinator.com/item?id=26722717
After a little bit more than 2 decades of coding, SQL is nearly the only thing that was constant in my career.

It's a skill I used every working day, I'm pretty sure I will still use it in 20 years.

On the other side, tt's very unlikely that the ORM 'du jour' will exist in 3 years from now.
> As for Cargo, [...] I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads.

Afaik Cargo does it out of the box, based on Cargo.lock.

UPDATE: This doc page seems to confirm that: <https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lo...>
Not quite the same, show humans one picture of a giraffe and most humans will recognise the animal in different conditions, poses, angles and so on. Any neural net (up till now) has a difficult time doing the same.
The same concept was advocated by 37signals/Fried, in Rework:

> Let your customers outgrow you [...] When you let customers outgrow you, you'll most likely wind up with a product that's basic--and that's fine. Small, simple, basic needs are constant. There's an endless supply of customers who need exactly that.
LOL, the vaccine was introduced in the USA in 1955, in the Netherlands in 1957 (higher on the chart means more cases):

https://ourworldindata.org/grapher/prevalence-of-polio-rates...

https://www.rivm.nl/polio
While I agree with your point, I wonder why that does not seem to be the case with programming languages.

For example, in iOS development (and, more in general, on Apple platforms), there has been a huge shift from Objective-C to Swift.

The same arguments should apply there. Swift is much better, but Objective-C got the work done, and many codebases were written in it, especially at Apple. And yet, the whole community switched pretty quickly.

One could argue that Swift was easier to pick up for newcomers. While that's true, I would then expect the argument to apply also to SQL alternatives.

So, what is the difference here?
I think it's about developing better log analysis tools. GoAccess does a pretty good job but it's missing a couple of features that would make me entirely stop using GA. Namely: stats over time, and better source grouping.

Even events can be replaced by triggering calls to your own endpoints.
SQL is also an API querying language. The primary difference is that SQL is designed to query relational data (rows and columns), while GraphQL graph data (tree-like structures).

The parent is questioning how useful GraphQL is as a relational query language or if the suggestion centres around moving to the database speaking in graphs. Conceivably, the data storage could still follow what suits the relational model internally with some kind of ORM-style engine that sits in the middle to translate relations to graphs for the GraphQL query processor, but at that point you could argue that the database is a graph database.