HN user

ocharles

1,009 karma

[ my public key: https://keybase.io/ocharles; my proof: https://keybase.io/ocharles/sigs/Y-VS6LzrOymRE0X5OtcbxGcmUDLT5J-FmfpyqWSNs_w ]

Posts13
Comments184
View on HN

A small diff /= a small change! They are completely separate things. Quite often a small diff is hours of actual work. Even in this case _finding_ those lines could have taken work - we don't really know.

We're a Haskell shop, so I usually just say "review the current commit. You're an experienced Haskell programmer and you value readable and obvious code" (because that it is indeed what we value on the team). I'll often ask it to explicitly consider testing, too

I recently started using LLMs to review my code before asking for a more formal review from colleagues. It's actually been surprisingly useful - why waste my colleagues time with small obvious things? But it's also gone much further than that sometimes with deeper reviews points. Even when I don't agree with them it's great having that little bit more food for thought - if anything it helps seed the review

I write Haskell with Claude Code and it's got remarkably good recently. We have some code at work that uses STM to have what is essentially a mutable state machine. I needed to split a state transition apart, and it did an admirable job. I had to intervene once or twice when it was going down a valid, but undesirable approach. This almost one shot performance was already a productivity boost, but didn't quite build. What I find most impressive now is the "fix" here is to literally have Claude run the build and see the errors. While GHC errors are verbose and not always the best it got everything building in a few more iterations. When it later got a test failure, I suggested we add a bit more logging - so it logged all state transitions, and spotted the unexpected transition and got the test passing. We really are a LONG way away from 3.5 performance.

This keeps getting parroted but it's flawed/overly idealistic/frankly naive. An awful of children are, unfortunately, poorly parented. This is not a new phenomenon, nor something we seem to be improving. OTOH, exposure to extreme material for young children is increasing, and has consequences beyond that child. Exposure to extreme pornography leads to a warped view of sex which affects everyone this child might have sexual encounters with. Exposure to extreme violent material leads to the murder of other innocent children.

I don't know where I stand on this legislation - my gut is that it's too heavy handed and will miss the mark. But I think we need to stop saying this falls solely on parents. The internet is far too big, and parenting is far too varied for this to work. I wish it would, but it won't. There simply aren't enough parents that care enough.

Because we know the implications of poor quality food, and we also know those who would buy it have no choice but to buy the cheapest. So, no thanks. I'd much rather the state intervene here and keep this crap out. This "let consumers choose" argument is tiring when consumers don't have the ability to choose. They are just trying to survive

Honestly there's way more there, and you get consistent solid speeds. Find a provider with a lot of retention and you can find almost all mainstream media regardless of it's age. (Public) torrents tend to track what's popular and quickly fade. The masses seem to favour low size encodes too, so if you're looking for more quality (and again, public trackers) you're usually much more out of luck.

On what timeline? Per hour? Per day?

Surely a pinch of critical thinking answers this? 4 deliveries a day isn't going to pay a daily minimum wage. If it did, then we wouldn't have this situation - surely most riders manage more than one delivery every 2 hours and make more than the minimum wage!

Sleep isn't the metric to track here, there are much better things to analyze such as HRV. For reducing drinking you shouldn't be doing that because of your sleep, you should be doing it because of your overall health. If you care about future health, take blood tests, weigh yourself, evaluate your physical fitness.

Very hard to answer without knowing what your goal is. Do you want to be a practitioner of DL, or do you want to be a researcher?

For those who won't bother to RTFA: the trains run cooler than other trains, so they are taking advantage of the difference such that the net result is the same temperature in tunnels, but the interior of trains can be cooler.

As I understand it, the point is that these models while they are _trained_ on identifying cats or cars, because they have soon so much variation during training have internalised very different concepts to help come up with "its a cat". The idea then is to take all of these pre-trained weights that let you build this classifier, but then add your own custom head on the front of this network. This saves you doing a huge amount of training for what is essentially feature extraction - that part is already done. All you need to do is just add a bit more training that works out how to use these learnt features. I could be way off the mark, but that's how I understand it.

Pixel 8 Pro 3 years ago

I have the 9 and it's a fairly good phone, but seems to have a hard time working with UK phone networks. I get patchy 4G, not sure I've ever seen 5G, and there seems to be a very magic combination of settings that allows me to actually make and receive calls (turning of VoLTE, and a bunch of other things need to be on or off). A shame, because otherwise I love the form factor and other features.

Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two, moving commits, etc. But having _everything_ operate on commits is really nice! Other niceities that I like:

- `jj log` is awesome for getting an overview of all your branches. If, like me, you have a lot of work in progress at once, this provides a great map

- Conflict resolution is really cool, as you can partially resolve conflicts, and then switch branches. Conflicts are also tracked specially, but I haven't done too much with this yet.

- The abbreviated changeset ids are really handy. I often will just `jj log` (or in my case just `jj` as that's the default), notice a changeset I want to rebase, then run `jj rebase -s qr -d master`. `qr` here is an abbreviated changeset id for a branch/commit, and usually much quicker than typing the branch name out! This will probably change when clap gets updated to support dynamic tab-completion though.

Very nice, but what's the upgrade story on these kind of things? Like if there's a bug in any of these, you've got to basically manually watch the repository and manually copy bug fixes back over

OP is delusional if they think that their approach can be made practical. I mean, what if the expectation from the data that an value is a prime number? -- How are they going to encode this in their type systems? And this is just a trivial example.

People get too caught up in thinking that the type _has_ to express intricate properties, it doesn't. How am I going to express the expectation that something is prime? With the following closed API:

  module Prime where

  data PrimeNumber

  parsePrime :: Int -> Maybe PrimeNumber
  toInt :: PrimeNumber -> Int
Now the problem is that _leaving_ this API forgets information. Whether or not that is a problem is a different question, and very dependent on the context.

The same applies to your comment about passwords. One can quite easily create a closed module that encapsulates a ValidPassword type that simply performs runtime character tests on a string.

I want to stress that this approach is making a trade off (as I earlier mentioned about leaving the API forgetting information, forcing you to re-parse). However, this puts this design somewhere in the middle of the spectrum. At one extreme end we have primitive obsession and shotgun parsing everywhere, with this we push the parsing into a sane place and try and hold on to these parsed values as long as possible, and at the extreme end we need dependent types or sophisticated encodings where the value carries a lot more information (and here we get towards propositions as types)

This isn't strictly true, an alternative is to have a language with enough encapsulation that you can parse into something that can only be observed as correct. The underlying parsing doesn't have to parse into sum types, provided your observation functions always preserve the parsed invariants.

I think voice is a fine interface for a lot of smart home things. If I'm watching TV and want the lights on/off, I don't want:

* To have to reach for my phone * To have a tablet mounted within reach (that's more clutter) * To have to get up to the light switch/nearest controller.

This sounds lazy but that is literally the point of all this stuff - to make things convenient.

Likewise, if I'm in the kitchen and want to set a timer, I don't want to have to use my hands (I'm probably already using them), I just want to yell that I need a imer set.