skysight-inc/HackerNews huggingface dataset:
> But how could the reviewers have found the errors in this article?

The same way this guy wrote the thorough debunking of the paper: https://osf.io/preprints/socarxiv/rp5ae/

...by actually reviewing the citations and noticing they do not, at all, support the claims she made.

> ...such extensive checks...

The checks didn't need to be extensive, they needed to be cursory. The problem is they were absent because the reviewers enjoyed the same political bent as the author of the paper.
I would disagree with this.

Some points:

- UI frameworks and Game Engine tends to be huge when completed to a point where they are an easy choice for anything beyond some fun projects. The _huge_ majority of them have organizations/money backing in some form, through sometimes implicit. So the huge majority of open source versions of them no matter which language they are in will never be competitive.

- the state of established UI frameworks is kinda a mess, the divergence between the research world and what is practically used is in most places quite often humongous (e.g. what the blog post describes is conceptually a version of using continuations for GUI libraries and state handling in them, something well established as "a grate idea, if you can make it work nicely with the limitation of widely used programming languages" in computer since since I think 10+ years or so), and it's pretty common that patterns people are used to (e.g. inheritance for code reuse) are actually anti-patterns which kinda somewhat happens to be usable in that case but have serious issues you IMHO often don't notice until using them in larger projects (as in many people working on the software in parallel) where it's then often blamed on other things

- due the the mess the state handling in GUIs often ends up in it tends to profit from using a GC and the using borrows only in rust will likely fail. But then given the perf-characteristics and what tends to be a hot paths of GUIs _you really don't need to write borrows only code_, using an Rc/Arc and similar tends to be perfectly fine, i.e. the issue is in my experience more people obsessing over micro optimizations for that context

- on the other hand for game engine you often want to avoid GC for the engine/core parts themself (i.e. not dialog script and similar) and in general have a much stricter state handling using stuff like a ECS, there is no reason for rust to not handle that well. Through writing the ECS library might involve usafe code, due to it involving writing fundamental data structures. Most importantly in recent years "memory safety" of C++ has become an increasingly bigger issues for AAA-games, especially for multiplayer games where there is a risk of a hacking the users computer through the game client, and the money spend on combating that issue is non trivial to a point that you probably should avoid most code which conceptually works in C++ but couldn't work in rust due to the borrow checker (assuming you already have a well done ECS library with the right soundly implemented data structures).

- similar to writing fundamental data structures, writing a game engine proper is really really hard but seems simple as long as it's only a "toy", rust isn't good at that, sure. But also there is limited value at being good at writing throw away toys which can't be used in any production context IMHO. What does matter is if you can have a nicely usable production ready _maintainable_ game engine in rust, and AFIK yes you can somewhat already have.
There’s no reason why alternatives won’t achieve the same ubiquity in the future. The EU has already built the common infrastructure that makes inter-county bank transfers instant and seamless. Honestly only Americans seem to struggle with the idea that companies like Visa/Mastercard/Paypal/Venmo are just symptoms of a dysfunctional banking system, not some incredibly new and innovative way to move money.
Essentially "doing less with less". We still want to do as much as we can, so we have to do everything smarter.

We need to use less energy (because energy is CO2 emissions, and because we will have less abundant energy in the future), and therefore we need to rethink society to work without abundant cheap energy.

Some parts of economy will benefit from that (e.g. building bikes should work well), and many will not (typically the airspace industry will be reduced dramatically, probably the whole modern software has to go back quite a bit and stop wasting resources all over the board, etc).
Fun idea of consent. I hope you never walk on someone else's private property, even accidentally.
I actually love “they” because it waves off every ambiguity at once: not only you don't have to care about the gender of the person, you don't even have to bother whether it is an individual or a collective (this super convenient when discussing about open-source projects).
How the Most Useless Branch of Math Could Save Your Life
Somebody removed all the insane UB-"optimizations" and the result wasn't even any slower. Can't find the blog now.
Exactly. Come for the content, despite the looks.
My favorite Le Carre book is probably The Perfect Spy (especially that it is autobiographical to a great extent).
The history of the Unix pipe operator linked from this page was interesting: http://cm.bell-labs.co/who/dmr/hist.html#pipes
In a typical "early internet" straightforward way, you can just leave out the "dmr" from the URL and get a listing of some other ex-Bell Labs employees. Although at least two other ones I know about (Ken Thompson and Rob Pike) are missing. Some who you might know that are there include Brian Kernighan (the "K" in "K&R C", co-author of "The C Programming Language" and later "The Go Programming Language") and Russ Cox (I think he's the only ex-Bell Labs person left working on Go at Google after Thompson and Pike retired?).
This is a difficult question and the the history to all of this predates my involvement.

Indeed, a fair amount of people believe that the IFC is intentionally unnecessarily complex to limit interoperability and retain a monopoly.

Over time, I've come to believe hanlon's razor is also in play here and it's more of a poor understanding of use cases, academic ideas blowing up scope and inheriting obscure schema and serialization tech.

Meshes + metadata can facilitate most of the use cases in industry today, which is coordination, interference checks and visualization.

But at the same time, there's some pretty compelling use of the standard that requires slightly more semantic geometry descriptions:

- calculating geometric quantities according to local norms, which requires some additional geometric knowledge on things like openings and the axis of a wall for example

- The opening direction of doors is often good to know, but this is just a convention on the local transformation matrix, so could be just meshes.

- steel manufacturing can derive quite a bit of information from the IFC geometry, like parametric cross section profiles and where to drill for bolt holes and using which diameter

And then there is the ultimate end goal according to some to be able to exchange all parametric and constraint information from the native model. But this is still quite far out.

The challenge for future editions of the spec is to better align required complexity of certain use cases with a more modular spec so that you depend on a more appropriate amount of complexity.

Btw. since you mention Blender. The BlenderBIM addon https://blenderbim.org/ is actually one of the most avid users of complex and parametric constructs in IFC :)
This seems like the sort of a comment that can only be written by completely refusing to understand why compiler writers take advantage of UB. Compiler writers are not engaging in "adversarial" behavior with their users -- they are their own users!

The simple truth is a lot of UB exists to allow for optimizations that programmers entirely take for granted. In order to optimize something, you have to make assumptions, particularly when dealing with languages as permissive as C and C++. By programming to an abstract machine and explicitly specifying which behavior is defined and which is not, we allow a compiler to make these assumptions. Despite what you may wish, a compiler is not able to read your mind to know when a given piece of UB is actually code that you intended to execute with particular semantics, or whether it's the result of some other optimizations on a code path that will never execute.
Bloomberg Originals has a ~7min video-doc on it - https://www.youtube.com/watch?v=y8ojlJoM0FE
My personal opinion is that solar panels on vehicles don't make any sense, and probably won't _ever_ make sense.

There are two concept cars I know of that can actually get enough power from the solar panels on them to be useful. One of them is the Aptera, which is a no-compromise low energy vehicle. It's tear drop shaped and can only hold two people, so it's going to be a bit niche.

The second is the Lightyear solar electric vehicle, which is shaped a bit more like a standard car but is going to cost luxury car money for an ultra lightweight (read: no soundproofing) car.

And to what advantage? Charge per year doesn't matter, since you're recharging multiple times per year anyway there's no difference between the panels being on the car vs the ground, other than panels on the ground can be directed more optimally and don't add to the weight of the car.

Charge per day matters, and taking a 500 mile trip up to maybe 600 miles (on a perfect sunny day) isn't that big an improvement in practical terms.
PicoKeys: A Personal Secure Key with open hardware and software
Personally I found it slightly funny but only because there is some truth to it. Sometimes I really miss the smoothness of 90s era of app design - you could create relatively complex interfaces and test them very quickly. And the things you learned in Delphi 1 were still mostly valid in Delphi 6. When I compare it to what is needed to create a modern app in React, there is an abyss of difference - in terms of initial setup, tooling complexity, diagnostics, and maintenance.
In old days there would be little vibrating hammers mounted to the side of them to 'unstick' them automatically. And that 'low power arc' is actually a few thousand volts across an airgap of a couple of millimeters, the EM from that is massive.

For an encore: you can pick up lightning strikes with a long piece of rebar overwound with insulated copper wire stuck into the ground (so it's vertical). Every 'click' you pick up is a lightning strike somewhere within a few thousand km from where you are, louder clicks are closer or more energetic discharges.
Yeah. Maybe weak is too strong a claim. I have done a lot of typed Python code fwiw. I'm certainly never going back to untyped Python for anything outside of a scripting context.

"Python wasn't weak, I was" is an accurate call out, I have abandoned complex annotations in Python before because there was a bunch of cruft involved and the documentation wasn't always as straightforward as I'd have liked.

The lack of ADTs (and thus a Result type) combined with the lack of exceptions as part of the function signature (like Java) make it really difficult to develop a reliable application. Maybe that's not quite a type safety issue, but it's a safety issue for sure.

Digging in, it looks like people are working around this by returning exceptions, which is very clever and I hadn't thought of it before.
The crime statistics are real, though. Failing to recognize the problem created the likes of Alternative für Deutschland, Marine Le Pen, Brexit.

Let me reiterate it, because it is crucial: liberal policy of pretending that the problem doesn't exist is what created all those garbage political organization. Which, interestingly, are often co-financed by Russia.
Stories convey insight, not truth.
> In the United States, the average selling price for a new light vehicle came to around 46,290 U.S. dollars in 2022

and

> The cheapest Tesla model is the base Model 3, which starts at $40,240

The US is the far bigger market. But your point is correct that this is not true for every single market.
> but it will become one with tens- or hundreds-of-thousands of refcounted objects which are frequently created and destroyed (and with a naive approach those numbers are easily in reach as soon as table views come into play)

Look, I'm sorry but it's just bananas to throw around "hundreds of thousands of refcounted objects" when I've already bluntly pointed out that I'm discussing general application building. Joe Schmoe wanting to put together an email client should be able to slap a column view somewhere that can render a virtualized list and move on with their life.

This has been fine in multiple different native widget kits for some time now. It is not as intensive as what some games want to do UI-wise. The current situation does lead to overly complex UI approaches and contributes to the general approach of "smack it with a web browser" that we all collectively bemoan.
Granted, it probably has improved a lot since 2016, but I didn't have an occasion to update my knowledge about Swift since then. Back then you definitely ended up with tons of pointless ARCs, but in fairness the compiler was brand new at that point so no wonder it wasn't good at optimizing stuff away.
Hyundai Kona is named Kauai (after another Hawaiian island) in Portugal, since "cona" is slang for female genitalia.
Maybe OP isn't familiar with the Show HN rules, which state that you can only submit something you've personally worked on.

Or maybe OP really has worked on all these things. Without more context, it's hard to say.

https://news.ycombinator.com/showhn.html
English is definitely leading in terms of genderlessness, but that advantage is more than offset by its complete detachment between spelling and pronunciation.

It would be nice to have a language with sensible spelling/pronunciation but no gender.
If it improves safety then it isn't wrong
That's why the data should be collected by a government department rather than Tesla
Cornwall was a full-on liberal, very woke and cynical about the state despite being one of its minions. He was always on TV berating Tony Blair or the tories. He had this in common with very many of the junior ranks of MI5/6 with whom there was a great divide with the upper echelons who were loyal cynical establishment servants. It's difficult to imagine him knowingly serving as the propaganda arm of MI6.
That's a weird one for sure.
I've seen config files which were valid TCL, I've seen JSON, I've seen bad old INI files... TOML is relatively new after all, but that too...

What I never understood are those who looked at all these options and said "No, I'll write my own parser!" instead...
Sometimes switching positions dynamically is less straining than staying in the same (ergonomic) position forever, which is why most ergonomic chairs are about dynamic sitting.

But no amount of dynamic sitting and no ergonomic chair will make the bad influence of sitting go away — this can only be dealt with excercise, breaks and stretching. And every ergonomic chair can be misused. A person with good habits can sit healthy on a rock, a person with bad habits can sit unhealthy on a custom made ergonomic chair.

The same is true for the hands. As a life-long multi-instrumentalist with trained hands and fingers I could totally see someone with a laptop and the right habits ultimatly acting healthier as someone with the wrong habits and the best ergonomic keyboard that exists for them.

And this is the truth: Everything that involves the human motor system is never just about the objects we interact with, but always also to a major degree how we interact with them. My grand-grandmother that worked in her garden with 109 didn't have any ergonomic tools (as they didn't exist), but all the right habits. Habits are always more important than tools.
That's impossible in the general case, but there are compiler warnings that try to help you catch as much as they can, use `-Wall` when building code, and there is runtime instrumentation `-fsanitize=undefined` to catch as much UB as possible without breaking the ABI. Also consider using `-fsanitize=address,undefined` while developing and `-fsanitize=thread` for threaded code. `-fsanitize=memory` is a bit difficult to deploy because you need all your libraries (except libc) to be built with it too, including your C++ standard library if you're building C++.
No, there is a clear distinction between typographic and idiomatic markup. The i and b elements are considered typographic elements, not idiomatic ones (as em). So newer standards actually made them idiomatic.
Mass produced is probably not what you want because it's usually pasteurized.
My grandfather once said: "I'd complain if it would do any good."

Better off voting with one's feet, wallet, eyes, etc. than bothering to give the gift of feedback to a business whose attitude is shrug. But of course a writers predictably must bitch and snark as dramatically and rhetorically possible while minimizing their own credibility and squander an opportunity (opportunity cost lost) to discuss something meaningful such as the more-or-less uniform lack of leadership for net carbon reduction.

This writer cannot begin to fathom the meaning of the word "suffering", so it's worth ignoring their scrawled tantrum.
Use justwatch.com
Thanks! I just ordered one!
I can't find this book. Can you link me to it?
No, failing to adress the root causes behind the statistics, and failure to properly report and read them, is what enabled the AfD Le Pen to actually use those issues for their populist agendas. Brexit was a different thing.
The fact that coke was sufficiently worried about a 2um thick layer on the inside of their cans that they decided to do what appears to be an emergency formula change tells me that management probably has data showing BPA to be really bad (and therefore a risk to their business if everyone with infertility, obesity, heart disease, type 2 diabetes, and cancer sues them)
I'd be quite interested to read that post, given that one of the big UB hammers is strict aliasing which gets used a _lot_
Thanks!! I just ordered one, turned out there was even a seller in my country. And it's not too expensive.
Not often an article has a full page photo of the author in his youth in it.
If that tickles your interest you might enjoy some of Doug' other works

https://www.cs.dartmouth.edu/~doug/

particulary the actively adversial anti-quicksort

https://www.cs.dartmouth.edu/~doug/source.html
I am reading this article and munching on sauerkraut. Not because I like the taste but because of the potential gut benefits.
I feel very sorry for Santiago.

His pain seems to be real, even if it is not even connected with scrum.

What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern.

1) "1. They tried to convince me that Poker is a planning tool, not a game."
Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.

2) Scrum does not have "ceremonies". They are called "events" and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?

2) "Scrum of Scrums" is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.

3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.

4) "We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint." -> this is not scrum. This is whatever the team came up with.

5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques.

6+7 "story points" are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)

8. "Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.
You're stuck in the UNIX-ism of everything is a file. So things are files in Unix that in other operating systems are not. COM1 is a file in Windows. It doesn't make sense to transfer COM1 over the network. You can't store it. You can't send /dev/null over the network. You can send a representation of it via NFS, but anything you write to it via NFS isn't writing to the file, you're writing it back to the original server that you mapped NFS from. The representation of it isn't the file, just like a map isn't the terrain. If I map a filesystem over the network, I'm still not sending the file over the network. I'm just sending a hook for the server that's getting mapped to know what's going on.

When I say most people, I mean most users. Most users aren't concerned with socket files, or write only files, or device files, because they aren't things they're concerned with. They think of a file as a blob of data, with maybe metadata for who can access it (et al). So, for the purposes of storing files, a file is a blob of data, not something being exposed across the network through special drivers.
> If it doesn't react with the beverage... what's the issue supposed to be?

BPA doesn't react with the beverage, but it does dissolve in it in small quantities, and although it's not acutely toxic it has biological effects even in small quantities as it (imperfectly) mimics estrogen.
How the Japanese companies operate can be pretty strange from a non-Japanese perspective. I've read that Toru Iwatani, also from Namco, who designed Pac-Man, was not compensated in any way financially for the success of the game. He seems to have integrated better in the company's structure than Takahashi, but that may have been thanks to other skills besides game design.
Waaaaaat! <3
Ask HN: What kind of fun did you use to have before the HR-organized joy?
After three days at a metal festival (in Pilsen), I realized something sad. In the software world, we don’t have fun at work anymore. I am not talking about the HR-inspired fun; I am talking about the joy that comes from the inside.

Do you remember the chair rowing?

Do you remember how amazed we were to crash a keyboard or two on each other backs? Do you remember us singing songs about Java while writing fake protocols?

What kind of fun did you use to have in your teams before the HR-organized joy of playing volleyball and drinking beer from PHP-shaped mugs? Help me inspire more people with a talk I am building.

Thanks!
1000 oscillators version: https://m.youtube.com/watch?t=300&v=c3wk9WWTfNs
Should we also be lenient on attempted bank robberies and attempted murders?
Try JustWatch, it's the closest I've found.
> In a text to Fan, Liu defended himself

How is the American court getting access to messages sent from one Chinese person in China to another Chinese person in China?
I've had very bad experiences with those. Most vendors don't want to send to those either and then cancel orders that were already paid, and it was a hassle to get my money back.

But I'll use this greaseweazle, it sounds good!
The major ingredients, like sugar, water, CO2 are the main ones that affect the design of a processing factory.

Yet the flavourings are the ones that will be organic molecules in tiny concentrations, not affecting the design of processing plants, yet very important for anyone wanting to copy the flavor.