News for hackers. Stuff that matters.

chrisjharris

Re:The Chemistry of Tea [pdf] on Thursday January 29, 2026 @05:01PM (#46817328)
He's writing from a certain time, place, and culture, in reference to the teas that were available to him at that time. I'm not sure what you're arguing - that black tea didn't subjectively make him feel wiser, braver or more optimistic? And his tips for making black tea are perfectly sound.

If I remember correctly, he actually wrote that essay because there was a world event that his compatriots were getting outraged about, and this was his way of being provocative by not covering it. But I may have that wrong.

Re:Japan's Creepiest Station on Tuesday August 26, 2025 @01:43AM (#45022684)
I've climbed routes in ichinokura a few times. It is impressive, and some of them are quite poorly protected. But 800 climbers seems like an exceedingly high number, and that report seems quite vague and unsubstantiated, even if it does come from the government. So I remain sceptical.
Re:Japan's Creepiest Station on Monday August 25, 2025 @11:29AM (#45014924)
This is a creepy station, green filters notwithstanding. The article repeats this statement that I've seen elsewhere and always found pretty questionable - that 800 people have died on Tanigawa. I've no idea where this data comes from but it seems very unlikely. If you just want to get to the top by the simplest route then it's a non-technical day hike up a not-very-high mountain. It's also a multi-pitch rock climbing area but I'd struggle to imagine that 800 rock climbers have killed themselves there over the past 100 or so years.
Re:Typed languages are better suited for vibecoding on Sunday August 03, 2025 @09:40PM (#44781375)
I've been wondering about this for some time. My initial assumption was that would be that LLMs will ultimately be the death of typed languages, because type systems are there to help programmers not make obvious mistakes, and near-perfect LLMs would almost never make obvious mistakes. So in a world of near-perfect LLMs, a type system is just adding pointless overhead.

In this current world of quite imperfect LLMs, I agree with the OP, though. I also wonder whether, even if LLMs improve, we will be able to use type systems not exactly for their original purpose but more as a way of establishing that the generated code is really doing what we want it to, something similar to formal verification.

Re:Suspicious data pattern in recent Venezuelan election on Wednesday July 31, 2024 @08:42PM (#41125104)
How should they be funded, for you to consider them impartial?
Re:Helix: A post-modern text editor on Monday May 27, 2024 @03:30AM (#40488511)
I agree. If Helix had a client/server model like Kakoune, I'd move to it right away.
Re:Amber – the programming language compiled to Bash on Wednesday May 22, 2024 @12:02AM (#40437200)
I agree. I think that these fancy visuals are not the right way to appeal to the target user base. I just want to read some text.
Re:Amber – the programming language compiled to Bash on Tuesday May 21, 2024 @11:51PM (#40437138)
I think that this does fill a niche. You can still compile to bash outside of this austere environment, and run the scripts within it. And python isn't very ergonomic for running external shell commands (or, say accessing environment variables), the syntax for doing so in amber looks much neater.
The people directly managing the investment are unlikely to also be holding REITs, so your assumption is valid. I think it's basically that: - The people who care about company profit are the asset managers, who will tend to implement their ideas by selling/buying shares, rather than trying to encourage a given company's management towards better practice - Corporate governance itself is therefore usually outsourced to proxy voting companies, who are quite conservatively-minded (and spread quite thin) and so won't tend to micro-manage, they'll assume that profit maximization is the job of management - The only thing the proxy voting companies will tend to have a say on is ESG-related, and WFH doesn't really fit into that
Re:Ask HN: What laptop are you using to daily drive Linux? on Saturday March 02, 2024 @10:29PM (#39578178)
I'm using a System76 Lemur pro. I've had it more than two years and I only have good things to say about it, some of which are: - The battery life started off as spectacular and is still not bad, I get about 5 hours out of it for general use, including compiling code - When it arrived it had a dead pixel in the middle of the screen. They replaced it in a very low-fuss way, sending the replacement immediately (before I'd sent back the original, so that I didn't have any downtime) - The spec is well-suited for coding/general linux work. It doesn't have a fancy graphics card or a hi-res screen, but I don't want those things,they add weight and cost and decrease battery life. - I installed NixOS from the get-go so didn't ever experiment with PopOS so nothing really to say there
I think this is exactly right. Function names actually fulfil the role of documentation really well. I personally tend to make them long and quite verbose, like

`def start_the_car_and_accelerate`

Re:Beware Offers of “Help” with Your Projects on Tuesday May 16, 2023 @09:25PM (#35970185)
I'm sure that somebody has thought this through more fully than myself, but the impression I have is that for software, the benevolent dictator model works best. Python and Javascript occupy adjacent places in the programming language firmament, but the Python language (with van Rossum having fairly tight control over it), although bloating somewhat over time, has still ended up quite a lot more elegant than Javascript.
Re:Why it’s hard to buy deodorant in Manhattan on Thursday November 24, 2022 @09:54PM (#33738691)
These are still pretty rare, and there's always a member of staff present, usually at the counter right next to the self-checkout till.
Re:Rewriting my blog in Rust for fun and profit on Monday August 29, 2022 @11:01PM (#32646188)
I also am quite neurotic about version control, updates etc and if you're prepared to climb up a fairly steep learning curve, I'd recommend Nix/NixOS. It's a much more robust and comprehensive solution than Docker. Docker is not as good a technology as it should be in this use case, and it does stuff like cacheing CMD instructions in the Dockerfile based on their value as a string (rather than the result of the command). This can and does lead to Docker images changing between builds even when the Dockerfile itself has not changed.
Re:The Dhall Configuration Language on Thursday July 14, 2022 @08:59PM (#32103331)
Most of the time with configuration files, you want to be able to do at least basic validation on the config without having to run the whole piece of software. Python has no native typing, so there's nothing to stop the user from creating a configuration file where, for example, they have set a field that is intended to specify a port number, as a string. This error will become obvious when you run the software (and it presumably fails some way in) but for some use cases this is too late. With dhall you can specify that the field for the port number needs to not just be an integer, but be a natural number, so you're able to catch plenty of config errors nice and early, and can go some way to validating the config in isolation from the software it's intended to be used for.
I thought the birth rate was very low? Did I get that wrong?
Re:Dhall: A Gateway Drug to Haskell on Wednesday June 08, 2022 @04:14AM (#31664634)
Dhall is in some ways actually harder (at least, stricter) than Haskell, I think. The fact that there's guaranteed completion means the code has to have complete integrity. If you've defined a union type, then anytime you define a polymorphic function that takes that union type as an argument, you need to both handle all of the union type's actual types, and handle them properly. So even if you as the developer know that that one of the types is never going to actually be passed to this function, you can't just throw an error or set that scenario as undefined.
Not if it works as planned, no.
It is assumed that the wages you earn are a proxy for your productivity. This may sound dubious on the individual level but on the aggregate level it is not, an economy can only distribute in wages and other returns what it has earned from production.
You could see the shift to a four-day week as increasing aggregate demand while decreasing aggregate supply. Prima facie it might seem like fewer hours worked = lower total output = lower GDP, but the macro-economy is a complex system with many endogenous variables (inflation, foreign exchange, debt levels, etc), and the interactions between which can be quite subtle. A lot of schools of economics might put together an argument that this could increase GDP, rather than decrease it. To my mind it seems to increase quality of life which is a more relevant metric than GDP anyhow.
Re:Is π the Same in Every Universe? on Tuesday July 13, 2021 @11:02PM (#27829141)
It's... it's not at all short.
Re:Julia and the Reincarnation of Lisp (2020) on Monday July 12, 2021 @12:22AM (#27807020)
I partly agree but this can too easily become an argument in favour of the lowest common denominator. I can hardly imagine a language that's easier to learn than Python, and for that reason a) lots of people already know it, and b) those that don't can learn fast. But that's at least partly because it just doesn't have features that are widely regarded as beneficial - a type system, metaprogramming, good functional constructs etc.

Before anyone comes back at me for suggesting that Python lacks essential features, I know there are third-party libraries or core features to do this stuff, but they're pretty far off-meta, so your team isn't going to know them, or having good idioms/consensus for using them, and so at that point you might as well just learn something a little more advanced anyway (Julia would be an excellent choice).

Well, those providing credit ratings (the rating agencies) were not the same as those selling the debt (investment banks). But more than that I think it's unwise to be so certain about intent - how do you know they were deliberately getting the ratings wrong, and not making a giant mistake? The rating agencies did very badly from the crisis, so it's hard to argue that they also saw the whole thing coming with premeditation.

I also think your explanation of the GFC overlooks what was an extremely multi-factorial situation. Most explanations would allocate some causality to changes in regulation, changes in global debt dynamics. Securitization aside, it was the peak of a huge borrowing/lending boom not unlike numerous previous financial market crashes.

I don't disagree with the general sentiment that the GFC was a total disaster, and I'd certainly not argue against the idea that a system had developed that had poor incentives, with sometimes greedy and unethical people working in it. What kind of concerns me, though, is the way that poor decision-making is conflated with breaking the law, or the belief that a terrible outcome ex-post necessarily implies illegality. I don't really see this logic being applied in other walks of life - in most jobs, if you are incompetent, or even incompetent and amoral, you wouldn't expect to be prosecuted.

For the most part I'd not see the GFC as a morality tale but rather a kind of weird emergent phenomena whereby one area of the economy became so big and complex that it was beyond's anyone's ability to manage, and the interactions of the millions of bit players in it - all of whom in their own way wanted to succeed and do well for themselves - led to this collectively disastrous outcome.

Which isn't to say that nothing illegal occurred - I'm not sure how you'd draw a boundary around the GFC but there were a number of securities fraud prosecutions in the years afterwards - but I think if you take the GFC and subtract all illegal behaviour, you'd still have the GFC.

I can see that you mean well but I really cannot agree with this statement.
Re:Strand Programming Language on Monday April 26, 2021 @11:44PM (#26951752)
I find this fascinating, if a bit incomprehensible, but what might an intended use case be?
Re:Amp: Vi-like terminal editor written in Rust on Monday April 12, 2021 @06:39PM (#26786076)
I was thinking the same. There is some cool new stuff in this space (ie Kakoune), which probably is actually somewhat more ergonomic to use than vim/neovim. And maybe this is slightly faster than vim, although vim isn't exactly the kind of program where people complain about it being too slow. But to try to upturn the anthill for a 10% improvement in any direction, on an already excellent product, feels like a mistake.
Bit different for medical studies, though, isn't it?
How would you know?

Do you not feel guilt yourself?

The more time I live outside my homeland, the more I agree with the idea of pointing to George Washington to understand modern American society. I don't mean America in particular, but if you want to know why different cultures think differently, the only thing you have is their intellectual history, which changes (I think) surprisingly slowly.

Older »