Plus most people that use Dvorak probably don't give a shit at this point because they've been touch typing on qwerty or blank keyboards for their whole life. I'm not sure it'd even be a selling point for me.
You can't use the words "reasonable debate" in your post after you've immediately jumped straight to some mythical worst case scenario of a 5 year old being given a device with no supervision and somehow managing to immediately find their way to some sort of super duper snuff porn that will scar them for life.
> It's pretty clear by now that coding productivity increases by 10-15% with AI.
Completely offtopic for this thread but I can't be the only one that would find this hilarious if it wasn't being said in earnest in every thread.
The only thing that is clear is that measuring programming is just as impossible as it has always been. In all my years of projects they've either been resounding successes or gone down in flames. The difference between good and bad is a difference in kind. Most of the bad ones didn't even know what the hell they were building and built the wrong thing.
Like, the entire idea that some omniscient manager is looking at a thousand timelines and pondering over whether to pick the $11.5M successful one or the $9.5M successful one is literally laughable. Half of them are going to make the Hindenburg look like a bit of a whoopsie and the other half you would lock in sight unseen without a second thought.
Why do you think I'm like the people destroying the Internet? Because I said a bad word? Are you actually retarded? I'd love to return to the Internet we had in the 90s and 2000s, we're not going to get there if defeatist bitches like you cave and let the governments of the world control who is allowed to serve http responses to people that don't put their government ID in the header and route it through a 3rd party.
Destroying freedom isn't a fucking compromise. If algorithmic feeds are as bad as say, heroin, then the correct response is to regulate or ban them. You're arguing for the Internet version of legalising heroin and installing a physical surveillance state to target the addicts, it's absolute fucking insanity.
You can't have freedom if a few people have a microphone that reaches hundreds of millions of people have zero responsibilities for how they use that microphone.
If you actually haven't used social media recently then I get why you'd be confused, because back in the day Facebook had a chronological timeline of people you specifically added in. The way a modern social media recommender algorithms work is completely different. If you, for example, say "I want to hear everything that Bob has to say" by "subscribing" to Bob or whatever, you "might" see when Bob says something, or instead you "might" see Mary's post from the other side of the world that has some strangely aggressive opinions about someone the billionaire platform owner happens to hate.
Social media companies have decided by buddying up to the US administration that they get to decide what everyone around you sees or hears. If a couple of billionaires decide that they don't like phyzix5761 you might just get lynched by an angry mob. That's not gonna do much for your freedom, in-fact it's kind of the opposite.
I can't really tell how you'd even use this. Is it supposed to be some sort of micro-optimisation thing to do with how HTML is parsed (now you can download chunks out of order, presumably with some performance gains since it's browser native?).
When I saw the title I was hoping it was going to be a very simple React-like API for constantly updating parts of the DOM with maximum performance since the browser devs are now involved. It doesn't look like that's what this is at all. And all these years later I'm still wondering why browsers aren't implementing an API like that when it's been obvious for over a decade now that real-time DOM updates are a vital browser feature that needs to be performant, and that developers vastly prefer a declarative model to a procedural one. Why after 15-16 years are we still building 100 versions of the same abstraction in user-land to turn Element.append into "refresh these elements when this data changes"?
Well, if it's any indication, my sister, who is very much not a tech person, randomly asked me to help her install Linux Mint a month ago, and has been using it successfully since without needing to ask for help once (at least not from me, I suspect ChatGPT is getting a workout).
That felt like an indicator to me. I only switched to Linux a year or two ago and haven't mentioned it to her once, so she got the idea from somewhere else, and had enough impetus from whatever she disliked about Windows to actually go through with the change. If I was in marketing at Microsoft I'd be shitting myself over that, assuming Windows even still fits into their long term plans somehow. It's one thing for 100,000 techies to preach Linux across the web, but if random normies start using it without fanfare, that's real change.
It's been legal in Australia since 2018 and frustratingly nobody seems to give a shit except for yanks trying to point out any government's injustices other than their own.
I'm not talking about ditching type safety. I'm saying the whole concept of "safe" and "unsafe" as most people on HN understand it is flawed. The interesting part of a type system isn't whether the compiler checks types or if we just go lmao fuck it let's not even bother, it's whether or not you need to represent the types in your code in order for the compiler to check them. For the majority of what people want from type safety in a language like Javascript, the answer is that no, you don't need to, as long as you're willing to not have every single language feature under the sun.
With compiled languages you can statically infer a ton of type information without having to pepper your codebase with repeated references to what something is. Nominal typing essentially boils down to a double-check of your work, you specify the type separately and then purposely assign it to a variable, so that if you make a mistake with either part the compiler picks it up.
But those kinds of double-checks can be done for almost anything (outside of dynamic boundaries like io/dlls) without nominal type signatures in the code, as long as you jettison the ability to change types at runtime. No language as far as I can tell actually does this because we're all so obsessed with the false dichotomy of nominal and dynamic typing.
In JS everyone likes to use string unions in place of enums so let's use that as an example. If you have something that is only ever set as "foo" or "bar", that's effectively a boolean. If you receive that string in another function, make a typo and write if (str == "boo"), then in every single language I'm aware of that passes a compiler check. But it shouldn't, because the compiler has all the information it needs to statically catch that error and fail the build. The set of assignments to that variable and the set of equality checks on it provide the two parts of the double-check.
In a perfect world we'd have 10 of these "middle of the road" strongly typed static languages to choose from that all optimise for minimal type representation in their own unique way. But every time I see one of these projects pop up on HN it gets like 10 comments then disappears into the sunset because the programming community is so enraptured with the nominal type system of C and all the fucking bullshit Bjarne Stroustrup pasted on top of it 40 years ago. So we end up with this silly situation where the only things considered "safe" by the crowd are strict descendants of C/C++ with the array/pointer/string screw-ups that made those languages unsafe removed.
I really dislike parsing not validating as general advice. IMO this is the true differentiator of type systems that most people should be familiar with instead of "dynamic vs static" or "strong vs weak".
Adding complexity to your type system and to the representation of types within your code has a cost in terms of mental overhead. It's become trendy to have this mental model where the cost of "type safety" is paid in keystrokes but pays for itself in reducing mental overhead for the developers. But in reality you're trading one kind of mental overhead for another, the cost you pay to implement it is extra.
It's like "what are all the ways I could use this wrong" vs "what are all the possibilities that exist". There's no difference in mental overhead between between having one tool you can use in 500 ways or 500 tools you can use in 1 way, either way you need to know 500 things, so the difference lies elsewhere. The effort and keystrokes that you use to add type safety can only ever increase the complexity of your project.
If you're going to pay for it, that complexity has to be worth it. Every single project should be making a conscious decision about this on day one. For the cost to be worth it, the rate of iteration has to be low enough and the cost of runtime bugs has to be high enough. Paying the cost is a no brainer on a banking system, spacecraft or low level library depended on by a million developers.
Where I think we've lost the plot is that NOT paying the cost should be a no brainer for stuff like front end web development and video games where there's basically zero cost in small bugs. Typescript is a huge fuck up on the front end, and C++ is a 30 year fuck up in the games industry. Javascript and C have problems and aren't the right languages for those respective jobs, but we completely missed the point of why they got popular and didn't learn anything from it, and we haven't created the right languages yet for either of those two fields.
Same concept and cost/benefit analysis applies to all forms of testing, and formal verification too.
I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
There's a few comments speculating about fraud, but they're way off on the timeframe. I was approached about this project like 7-8 years ago. It's probably been in development the whole time.
1k * 250 * 8 * a team size of 20 is about 40 mil in salary for engineering, could be low, add on their $12M testing, $4.1M just for the design (vintage Deloitte), some cloud cost blowouts and a bunch of dickhead managers and scrumlords, plus the putrid enterprise-grade 3rd party map/data system they've gone with, I bet that wasn't cheap. All up it's in the right ballpark for a typical well-intentioned trainwreck consulting project.
Wouldn't be the first project to blow out because of a bunch of enterprise Typescript, Java and C# devs that can't deliver anything.
This is what I'm doing for my game, I didn't know it was actually a thing in some big titles too, that's reassuring. I landed on it because it was a huge code simplification compared to every other method of handling transparency, and it doesn't look completely shit in the era of high resolutions and frame rates.
Yeah, there was an entire season about ending the war on drugs and how it was the only thing that actually worked lol.
Also, they caught the drug kingpin at the end of the show by physically following his lieutenants to a warehouse full of drugs and arresting them all on the way out. The only thing the wiretaps were used for was to build a conspiracy charge against the leader, who had been standing outside for months/years doing face to face meetings with everyone that was arrested, clearly being the one in control of every conversation. If somehow that's not enough to charge someone with conspiracy then it seems removing a small amount of freedom to change that would be far preferable to reading everyone's messages and banning encryption.
"The Wire proves the need for mass surveillance" is the dumbest take I've ever heard. It literally shows the complete opposite.
I might be reading parts of it wrong, but I think that's a different sort of thing to the research in the article.
Sugar is a very indirect cause of heart attacks, everyone knows that most heart attacks are a culmination of decades of diet and exercise habits. It's still worth researching everything to do with that, but it's pretty low value research because it's hard to draw any actionable conclusions from it other than "eat healthier and exercise", which is already well known.
The research in the article is talking about a direct cause. Bacteria exists on arterial plaque, viral infection triggers bacteria to multiply, something about that process causes the plaque to detach and cause a heart attack. If that ends up being a rock solid cause and effect, even for a subset of heart attacks, that could lead to things like direct prevention (anti-virals before the heart attack happens) or changes in patient management (everyone with artery disease gets put far away from sick patients) that could directly and immediately save a lot of lives.
The post you replied to was saying that the data from the study isn't as strong as the article and headline make it out to be, which is usually the case. For this one though I'm reading that less as "it's a nothingburger" and more as "it's a small interesting result that needs a lot of follow up".