skysight-inc/HackerNews huggingface dataset:
What? I'm not sure I understand what you're saying exactly, so please correct me if I'm making misinterpreting you here.

There are going to be people who are worse off with universal health care due to higher taxes, there is no doubt about that. The question is how much worse off will they be versus how much benefit will the average person gain as a result? How many losers will we have and how many winners, and by how much will the losers be hurt / the winners gain?

Like I've already mentioned, the costs that I've seen in the media are 32 trillion for universal healthcare, versus the 34 trillion we're paying now. So already the universal health care system is saving money and thus increasing "freedoms."

There will of course be people who have a higher burden than they used to, though. The idea is that this burden would be put on the wealthiest among us, who have, by the way, seen their share of wealth grow over the past 30 years while the wealth of the bottom 90 percent has fallen. Today, the top 1 percent of households own more wealth than the bottom 90 percent combined.[0]

Given such facts, I for one am comfortable with the idea that we sacrifice some of the "freedom" of these individuals in order to increase the "freedoms" of everyone else. By the way, even under such a tax system, the freest among us will still remain the most free.

This is all ignoring the fact that the current status quo is needlessly killing tens of thousands of people per year, which you neglected to address in favor of talking about some abstract decrease in freedom for people due to a decrease in income for people who are already extremely well off / the most free.

Am I massively misunderstanding you here?

[0] https://www.washingtonpost.com/news/wonk/wp/2017/12/06/the-r...
Verbosity certainly is an issue with XML, but far from the only one. IMO the main problem of XML is that it was designed as a markup language, but then misused as a data structure serialization language. When used as a markup language, the distinction between attributes and children is meaningful. When serializing data structures, the dichotomy breaks down. For most subfields of a larger data structure, it's not obvious whether to serialize that subfield as an attribute or as a child. Contrast with JSON, which only consists of obvious data structures.
Damn, looks like I should stop using 21 as my PK then.
This is what PackageCompiler.jl aims to do, for whatever plotting etc. packages you use all the time. It seems to work well for some people but is, right now, a bit fiddly to get set up.
Your project looks interesting, but I looked through the Github project and site, but I couldn't find a language specification, reference manual, BNF-like grammar, or anything to indicate what the syntax is, beyond a very trivial example in the Github. To be blunt, I think you need to start with a spec to get any traction. That allows people to understand your data model and particular text encoding of it. If they like it, they might use your tool and perhaps port the system to other languages.
I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't.

My one request would be to bring back to SGML-like closing tag abbreviation:

That is, instead of

<foo><bar>qux</bar></foo>

we should be able to write

<foo><bar>qux</></>

I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.
I fear we've gone down a wrong turn. You may be 100% correct that fears about instability are irrational and not well-grounded, which is the point you've argued for several posts.

But nobody is arguing with you. Nobody is making the contrasting argument. That simply isn't the conversation anybody is having. It's an interesting conversation, it just doesn't happen to be this conversation.
Ask HN: How to validate an idea using a landing page
The problem I want to solve: hassle free photo printing app.

I know that there's tons of apps like that but there's only websites in my country that allow you to do this and they're not the most user friendly sites especially on mobile.

To avoid building something people don't want I built a landing page with minimal content and just links to app stores which open up an email signup form when clicked.

I've google ads for a couple of days so far and this is how the funnel is looking currently: 13.19% (google ad to landing page visit), 32.56% (landing page visit to cta click), 28.57% (cta click to leaving your email) and overall 1.23% (ad impression to leaving email). This is from a low budget google ads campaign: ~300 ad impressions, ~40 ad clicks, 14 cta clicks, 4 emails.

Issue is that that I have no clue how to interpret these numbers, I understand that 3 days is not a lot, but I'm not sure what should be my goals with this landing page.

My goals for the business: employ a single person to handle operations (printing, shipping) full time.

Having this basic landing page should I be:

* Looking into different marketing channels to measure how many customers I could get? (google ads estimate ~2k clicks per month)

* Validating if there's enough interest in general? (conversion should be above x%?)

* Something else?
I think it's a decent bet that future generations will see our usage of plastic in the past few decades pretty similarly to the way we see the historical usage of asbestos during the middle part of the 20th century.
It's not.

But people who like the language will invariably use beyond its core competency.

Hence it is important to ensure that julia is "kinda mediocre" for CLI scripting (big step up from "absolutely terrible"). Personally, my familiarity with julia and its features outweighs the fact that python/perl/bash would be the better tool for many CLI scripts.
Absolutely. But this is just another use case.

The real risk of working UC by UC, is that you might get locked into bad architecture.

The way to mitigate that is by using microservices.
Everybody will need new private keys.

What do you do with old coins? Satoshi's one for example? Or lost coins that nobody has the key for?

Do you set a threshold day, after which all unclaimed coins are just marked destroyed forever? If not, how do you know someone claiming some coins didn't use a quantum computer to get the key?
My overall impression is that this was a quick and dirty summer intern project. Nothing against quick and dirty projects but I'm not sure it really belongs on HN.
> we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.

If no one can answer the question, maybe they don't understand it? Maybe there's something unclear in the way it is worded?
wow that is awful
It's not a time to invest in ANY waterfront property anywhere.
Its not cheaper once you factor in the need for backup energy and thats the only fair way of calculating the cost of wind and solar for that matter.
So what’s wrong with plastics?

If not recycled they go to landfill and stay there, buried. No greenhouse gas emissions, no ocean pollution.

If one wanted put efforts into ecology one would be more productive reconsidering their commute options - each commute trip in a car is a gallon of gas that goes straight to CO2.
> what is a bigger problem is that the us is seen as a place where companies (the wealthy) can avoid the cost of public services like universal healthcare, public transportation, and government backed pension that all other modern countries have.

“Other modern countries” don’t pay for these services through taxes on “companies.” Of the big 5 EU countries (which together comprise 70% of the EU population), 4 countries rely less on corporate taxes than the US. The UK is the only exception, with corporate taxes making up 8.3% of revenue, versus 7.6% in the US: https://www.oecd.org/tax/tax-policy/revenue-statistics-highl... (page 3). By contrast France is 4.5%.

Nor do corporate taxes fund the Nordic welfare states. Corporate taxes make up between 4.9-6.2% of tax revenue (less than the US) in Denmark, Sweden, Finland, and Iceland. Norway is the only one that’s higher than the US, and that’s only because of the special 55% tax on oil company profits (the normal 23% Norwegian corporate tax is in line with the other Nordic countries, and lower than the US).

In Germany, 65% of tax revenue comes from social insurance and consumption taxes, which are paid for by the middle class. (Those who make more than about $70,000 per year are exempted from having to purchase the mandatory health insurance, and from the corresponding payroll taxes.) In the US it’s under 40%.

Put another way, Germany’s higher consumption taxes amount to 3.7% of GDP, and its higher social insurance taxes amount to 5% of GDP. That’s almost all of the difference in total tax burden between the US and Germany.
It's not an unreasonable problem, but one way to smooth it out could be to provide a list of "potentially helpful" string functions relevant to the variety of ways one might solve this problem. Not all string libraries are equal among programming languages, and recognition is easier than recall. I guess it really depends what you want to measure with the problem though. I use a problem that at the end of the day requires them to output an edge (start point, end point) that is used to feed a line drawing routine. I provide the standard junior high formulas for euclidean distance, mid-point, slope, inverse-slope, and two ways to represent a line, since I'm not testing for remembering those, but whether a subset of them can be used to solve the problem. I've still run into candidates who seemingly had never modeled a line mathematically before, and found myself hastily trying to explain how one would do so, like I were giving a lecture to a junior high student for the first time in pre-algebra. Needless to say they weren't able to then program a solution, or anything at all really... They would have been filtered out by your problem in less time. I think your problem could also be made easier to filter out the same people faster, but from my standpoint, I'm usually mandated by policy that I'm going to spend an hour with the person, so I try to make my problem answer a bit more than just the basic "can you code at all?"

Do you get candidates that ever ask "can I assume the strings are ascii?" The usual solutions to this will break in amusing ways if you allow arbitrary unicode. I know some interviewers who actually would have as a hidden scoring criteria "candidate asked about input encoding", and a lack of asking about that is a fail even if they correctly solve the problem for ascii. I myself disagree with using such hidden criteria -- if I'm going to score something, and not tell the candidate what exactly I'm scoring, it's at least going to be something in the code like "correctly avoided the divide-by-zero case without me pointing it out" and not an expectation of the candidate to read my mind on my expectations of things I haven't told them. (I do tell them to try and write code without errors (I help fix up basic syntax quirks or if I spot a typo I'll point it out), or ask how confident in their code they are and whether they might have in mind any edge cases to try -- I'd like to get a candidate who actually writes a unit test on their own, I always point out junit is set up...)
Everyone tends to make everything personal and about themselves.
The revulsion a lot folks express at one based indexing is always bizarre to me. I write code in c, python and matlab. Switching between these is really not that hard. The two indexing models just seem to be convenient/painful for different things.

And yes, perhaps one based indexing introduces a class of bugs when you need to call into c. But zero based indexing has the same problem if you need to call into fortran, and calling fortran is really common for numerical code.
If possible, prefer what tools in your vicinity use. My team uses Kubernetes and Concourse extensively, which both use YAML, so I tend to stick with YAML since people are already familiar with it.

(More recently, I've come around to prefer plain environment variables for configuration, but that only works nicely when the amount of configuration is fairly limited, say 20 values instead of 1000 values.)

For my own use, I do prefer TOML.
Assuming these candidates already made it past an initial filter it would be interesting to ask the filtered out applicants the same question and see how well they do
you should try Nim.
Nobody has commented on this, so I will. This seems one of those "boring" businesses that is useful. The biggest problem in offshore development is trust.

I guess they only problem is getting people to trust you that you can vet properly and independent.
You're right, I was confused.
So one guy? An Intelligent Design proponent whose work is partly funded by the coal industry?
Yeah, that puts a little damper on anything he's writing, doesn't it?

And this isn't even getting close to the IPCC report. It's not even in the same league.
I'm not sure you even know what the IPCC is, who is involved and what its results are, am I right?
Algorithmics by David Harel. Not a textbook, but a more popular Scientific American level treatment. Very readable and accessible but quite rigorous also - Harel's a noted computer scientist. I recall there was a slightly different edition of this book called something like Algorithms - the Soul of Computing.
I dont think, rust is competing with python in a similar space. The biggest win for Rust would be to have someone in the community rewrite Cython in Rust and get rid of GIL. Its a win-win for everyone.
Tesla: Rent Solar for $50/Month
Also A2 performance requires operating system level support, and all of these tips go out the window if you're using the card for a Raspberry Pi.

https://www.jeffgeerling.com/blog/2019/a2-class-microsd-card...

https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-...
> Most of the complicated mathematical proofs that have been produced by humans, cannot currently be automatically produced using an algorithm in reasonable time.

That's true, but humans have not done that in a time frame that's even remotely reasonable for verifying programs. Automatic verifcation methods outperform humans by orders of magnitude, on average, as far as program verification is concerned. My point is that if it is true that real-world programs are far from the worst case -- and note that we do not currently have much evidence to support that belief, because we have not been able to regualrly and affordably verify programs with deductive proofs -- then automated tools will be able to exploit that as well (once we know what "that" is, assuming "that" exists at all).

> My point is that using theoretical computer science results to talk about the difficulty of finding mathematical proofs in real-world cases is a bit of a non-sequitur.

Why? That's the entire point of the entire field of computation complexity. But don't think I'm pessimistic. I just think software verification is an extremely complex subject, and anyone who says they can certainly tell now which approach will "win" simply does not know what they're talking about.

As Fred Brooks wrote, realizing the limitations and understanding the magnitude of the challenge is not pessimistic. Physicists don't feel that the speed of light is a non-sequitur. Quite the opposite: understanding the limitations and challenges allows us to focus our efforts where they'll do the most good, rather than bang our heads against the wall just because that's what we happen to know how to do.

> Dependent types in Haskell gives you the freedom to do more. You can choose not to use that freedom where it doesn't make sense.

Given that only 0.01% of programmers use Haskell in production I don't really care what approach Haskell uses. But as someone who takes verification seriously, I think contract systems give you the freedom to use deductive proofs -- just as dependent types do -- as well as other methods, which currently have proven much more practical and useful in the real world.
The F-18 is navalized YF-17 (specifically, it's based on YF-17 model 267). It's competitor was literally F-16 "navalised" by team up of General Dynamics and Vought Aerospace, with resulting model being Vought Model 1600.

You don't usually already produced units to "navalize", but making a derivative is the norm, and was the case for both.

F-22N was proposed but never went far.

As for JSF sensor fusion - the helmet itself comes form pretty bad visibility from the cockpit. Incorporating modern passive sensors was an obvious choice, though.

(I'm still waiting on reports of "sensor fusion finally works", given our local idiots in charge decided to jump on the Lockheed Welfare project)

And outside of F-35, everything talks Link-16 with possible tunnelling/subnetting, and MADL was considered "too immature" to start fitting on F-22 despite Congress "ordering" it.
From a quick glance, my issue with Tree Notation would be that it's not enough syntax, i.e. it does not provide enough structure for me to grasp the overall structure with a cursory glance. Maybe it would work better if GitHub had a syntax highlighting for it. (But requiring syntax highlighting to be readable is a large red flag on its own.) Or that's just a feeling that would be mitigated if I saw larger files.
Chat (such as Slack) is far superior to other modes of communication. Only in person or video communication is more efficient, but even for that Slack is a good way to initiate since it is less interruptive.

Some of the points in the article actually highlight reasons why chat is better:

They promote a false sense of urgency

This is very much a culture thing. You can always vary the communicated urgency by e.g. saying "when you get the chance" vs. @-mentioning people. Importantly though, when you do need a reply soon, Slack is much better at getting that.

They destroy focus

The article mentions paranoid checking. My experience is the exact opposite - with async tools (e.g. email, task manager, google docs) I find myself paranoidly checking / browsing to make sure I'm not missing anything. With a tool like Slack, it's easy to know when I've read everything (or read everything in channels that matter), and don't need to keep paranoidly checking because I'll get a notification for important stuff.

They allow for bypassing project prioritization ... ALL WORK, including troubleshooting issues, fixing bugs, and answered questions should go through the Product Owner.

That's ridiculous. You shouldn't have to go through a high overhead prioritization process just to do some quick work. Sure, put it in prioritization / whatever when you realize it's a big piece of work and / or needs to be kept track of, but don't take away the ability to get things done quickly without having to go through a burdensome product process.

They strip away essential business context

Feature, not a bug. You can always link to extra context, but often the concise nature of chat forces people to use tl;dr which results in far more efficient communication for the reader.

They encourage poorly thought-out communication

Again, feature not a bug. Lots of brief communication is far better than a few carefully drafted essays. Well written communication requires a lot of time and effort to write, and people don't need that overhead to get on the same page, which is the point of internal communication.
If you spent some time applying clearly it’s only fair I spend some time talking to you?

I have yet to encounter a case where people applied and they weren’t even remotely a fit. When that happens I may consider changing this strategy.
Its just desperation when the solutions are nonexistent or inefficient

Not dissimilar to calling everyone that disagrees with you a Russian bot, which was very prevalent in the states for a few years
Does invention come from deprivation or plenty?
Given that most private info such as SSNs have been leaked to the public domain, that covers quite a lot haha.
Nitpick: What people like to call "Satoshi's coins" were actually mined in transactions to pubkeys rather than to pubkey hashes.

Early Bitcoin transactions did not use addresses.

Example from block 1:

https://www.blockchain.com/btc/tx/0e3e2357e806b6cdb1f70b54c3....

You'll see at the bottom that the opcode is a PUSH / CHECKSIG rather than the later DUP / HASH160 / PUSH / EQUALVERIFY / CHECKSIG format.

So this isn't true. (blockchain.info derives an address but actually the pubkeys are right there in plain sight. Have at it!)

Most transactions are indeed made to pubkey hashes though, yes.
Good feedback, thank you. You may have seen the spec, it’s just quite minimal (here’s a more elaborate one: https://github.com/treenotation/jtree/blob/master/spec.txt)

Here’s a BNf:

https://github.com/treenotation/jtree/issues/1

There’s a FAQ as well.

Docs needs work, in particular I’m hoping people will create their own explanations of the ideas in external places, as that might be a better way to understand it. Happy to provide help to anyone that is interested in that.
Just go with Dhall and be done with that
Countries most exposed to climate change face higher costs of capital
The anxiety is not about the wait but rather the potential consequences of the delay, such as the potential death or prolonged suffering of a loved one.
I can be outdated, but extensively could mean maybe 90% wild, 10% cultured.
Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.
The power of marketing campaigns. It's a bit disturbing to see Google push so hard for this - and still majority of ordinary of customers just want a cheap Windows laptop. The Best Buy guy gave pretty reasonable advice. Also confirming my suspicion that actually hardly anyone wants that expensive Pixelbook. But as long as one can install Linux it should be fine - but I'd rather pick a slick Surface Laptop.
R is a hybrid of a very slow language and statistical algorithms written in C that can't be debugged. Also the libraries don't have name spaces, not strongly typed, and there are many other features and libraries that show their age.

My favourite examples of Julia's great type system are its automatic differentation libraries that take a native function and wouldn't be possible with R.
> And as for the code, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.

Could it be that you're having issues communicating the problem?
The hidden messages about piracy damaging the industry almost brought a tear. If only they knew where the end would come from...

Too bad that evident mismanagement bringing companies to self destruction isn't as illegal as piracy, and isn't sanctioned likewise. If it was, we probably would still have Commodore and many others around along with who knows what newer incarnation of the Amiga.
That bounty is currently at 185 billion USD.
Of course, it would be pretty difficult to sell all the bitcoins without slippage, but I guess one could cash in at least several tens of millions.