zygo_histo_morpheus @ zygo_histo_morpheus @programming.dev

Posts

1

Comments

176

Joined

2 yr. ago

If you find yourself writing regexes often enough that speeding up that process would increase your productivity by "a lot", then you should get good at writing them yourself which means practicing without an LLM. If its something that you don't do often enough to warrant getting good at then the productivity increase is negligible.

I think the main benefit here isn't really productivity but developer comfort by saving them from having to step out of their comfort zone.

I try to write comments whenever what the code isn't obvious on its own. A "never write comments" proponent might argue that you should never write code that isn't obvious on its own, but that doesn't always work in practice

• Sometimes you have to write cryptic code for performance reasons
• Sometimes you have to deal with unintuitive edge cases
• Sometimes you have to work around bugs in 3rd party code
• Sometimes you are dealing with a problem that is inherently complex or unintuitive, no matter how you put it in to code

One of my most controversial gaming takes is that I like the first witcher game the most of the trilogy. There is a lot of jank and some cringeworthy parts but overall it feels like a much tighter experience than the later games, notwithstanding some clearly undercooked parts. It takes a lot more cues from older rpgs in how it's structured and I suppose I might just have a weak spot for that.

To be fair, I've never gotten that far in the third witcher so maybe I'd like more it if I played it enough to properly get in to it. I just got kinda bored after a dozen or so hours which is not a problem I had with the first witcher.

Yeah I in general think that Graber is very good at giving good answers in interviews!

Honestly even if bluesky does become enshittyfied, which is a very real possibility, the work they've done on AT proto so far will probably be extremely useful for whoever takes a crack at a more decentralized internet next. There are a lot of clearly smart and passionate people who are given space to research and experiment with different ways of doing things and I think that's both very valuable and interesting

I agree that the interviewer shouldn't have implied that they are decentralized today! I don't know if bluesky even say that they are decentralized themselves, on their website it says that they're "building an open foundation for the social internet" which is more accurate but maybe they mischaracterize themselves somewhere else.

So first of, the part of my comment that you quoted doesn't make sense because what I'm saying is that bluesky theoretically allows for decentralized relays but it's impractical in practice. Your analogy doesn't really apply to that.

I do think that it's misleading to call bluesky decentralized today (at least without any caveats). The goal of the project however is to eventually create a more meaningfully decentralized social network and they have tangible plans for moving in that direction so I think it's unfair to dismiss this aspect of bluesky completely.

I think that it's fair to want the interviewer to ask more critical questions and in general be more precise with their phrasing but

repeat that PR talking point

is a very cynical and uncharitable take on bluesky and decentralization. Cynical takes aren't necessarily wrong but they're not necessarily correct either.

The AT protocol is by its own account an ongoing project with problems that still need be solved before it is able to provide a social network with all the properties that they're interested in.

I don't think that it's accurate to say that bluesky is "completely" centralized (it is less centralized than most social media) as much as it's de-facto centralized. One reason for this is that it's prohibitively expensive to self-host relays. This is something that the AT protocol devs have plans for addressing, so it's possible that this de-facto centralization is a temporary stage in the evolution of bluesky and AT proto.

It is of course possible that they are lying or that they will be unsuccessful despite best intentions but taking for granted that it's just a "PR talking point" is, once again, very cynical in a way that I don't think is completely motivated.

They are open to drop some features apparently, but maybe not "90%"

The developers are taking a “less is more” approach. This means that some features of the original sudo may not be reimplemented if they serve only niche, or more recently considered “outdated” practices.

Well it's not like everyone who uses Chat GPT is going to become delusional but if you start going down the path Chat GPT is going to make it a lot worse

Can I mod games as freely and as easily as I do on Windows?

It depends a lot on the game, but in my experience not always. Running games straight from steam works really well with a small number of exceptions, but a lot of the sometimes weird tools for patching exe:s and so on that some games use can sometimes be a pain to get running. Not necessarily impossible but yeah this is a reason for why I still keep around my windows installation for dual booting.

It's another c/c++ competitor along with rust and zig. https://odin-lang.org/

I don't know that it's the "algorithms": a lot of people just use their following feed on twitter and although it changed a while back that was the default feed on bluesky for a long time. I think that there is a fairly large portion of bluesky users who mostly just look at following and still don't really like mastodon.

Imo, a big reason why bluesky has been a more successful twitter competitor than mastodon is cultural: mastodon has been around for years before musk bought twitter, and a big selling point was that it wasn't like twitter, for example that its "less toxic". A large part of mastodons userbase never liked pre-musk twitter that much and will tell you of for acting like you would there. Bluesky on the other hand has a large portion of users who liked pre-musk twitter and are happy to follow pretty similar social norms as they did in pre-musk twitter.

This is to some extent reflected in the functions of the different sites as well, for example you can't quote retweet on mastodon which iirc is deliberate because qrt dunking is "toxic". Bluesky has quote retweets (although they allow you to untag yourself from a qrt).

Yeah I agree, I think looking towards the future is a better idea in general. I'm on lemmy but not tumblr myself

Fresh memes!

My theory is that the primary reason why the fediverse isn't more popular with young people is cultural. For instance, I don't think anyone in generation z would use the term "fresh memes" :)

But yeah I also think that tumblr has a nostalgia advantage. It represents the internet before it "turned bad", while the fediverse represents a possible future for the internet. Both have different appeals, but I think that nostalgia wins out for a lot of people.

Don't think it has anything to do with electron. VSCode is just the largest editor that people install extensions for, so it's what makes the most sense to write malware for. If vim was more popular, I'm sure there would be more crypto mining extensions for that (I wonder how many there are? Surely more than zero?)

This article uses the term "parsing" in a non-standard way - it's not just about transforming text into structured data, it's about transforming more general data in to more specific data. For example, you could have a function that "parses" valid dates into valid shipping dates, which returns an error if the input date is in the past for instance and returns a valid_shipping_date type. This type would likely be identical to a normal date, but it would carry extra semantic meaning and would help you to leverage the type checker to make sure that this check actually gets performed.

Doing this would arguably be a bit overzealous, maybe it makes more sense to just parse strings into valid dates and merely validate that they also make sense as shipping dates. Still, any validation can be transformed into a "parse" by simply adding extra type-level information to the validation.

Why do you think it's a bad idea? Both you and OP are in agreement that you should validate early, which seemed to be what your first comment was about. Is it encoding that the data has been validated in the typesystem that you disagree with?

If you want to test windows programs on linux, you're probably going to want to do that in a virtual machine, or even a spare computer just for testing on windows. Depending on how much you need to use excel, a virtual machine could be a good option for that as well, but if using Microsoft Excel™ is a big part of your job, maybe it makes more sense to just stay on Windows for work at least

Always squashing is a bit much for my taste, sometimes the individual commits have interesting information! Text from the MR in the merge commit is great though, maybe I should see if we can set that up with gitlab and propose that we start doing that at work.

Putting the message in git puts the information closer to the code, since the pr isn't in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it's also available to anyone who might come across it when doing git archeology