Oh - that's interesting too! But I meant more as a frontend across various integrations a business might have. E.g. having a bot that tells you if your CI failed is currently likely surfaced inside Teams or Slack. Having an internal chat service feels like a big win so companies don't need to integrate private companies' tooling so deeply.
I like this article, but I would take some issue with the concept of the percentage of time taken up being a major issue.
If you go from taking 2 days to write some code and 20 minutes to type check (which does seem long, don't get me wrong, but still) to 10 minutes to prompt some code and 20 minutes to type check, that percentage increase to me isn't enough to justify switching.
You're still almost 2 days ahead, and converting those 20 minutes to 20 seconds are not going to make you ship a feature appreciably faster. But those types stand strong and I don't believe they can yet be replaced by an LLM believing they're correct.
Having said that, I also think that Haskell should massively speed things up. Having strong types if nothing else should surely produce some amazing type-checking speed wins.
Very good. I was wondering about this a while ago - lots of companies want something to aggregate notifications and perform simple bot actions, but don't necessarily want to lock into a chat provider. Having this as the frontend to a load of integrations (or even just internal chat) would be really interesting.
I see what you mean, but I think gamers on a budget will cancel. Other gamers would've paid full price for 12 games and instead paid $15 each for 12 games.
> So if you put your new game that you would have sold for $60-80 dollars to me directly and it translates to three weeks of engagement on your $15-ish/month (depending on level) subscription, it's hard to see how that is an economic win. Put that game on Gamepass in a year or two, sure, that can make sense, but on release?
I think that's what I thought it would be, too. XboX has a really good track record of backwards compatibility. I can (and do, occasionally) play 360 games on my series X.
A model where people can buy the latest games, can not only keep them but play them forever on future consoles, and can have access to an increasingly vast back catalogue of older games, seems like a huge win. And maybe each full price new game gets them a bit of a discount on their next month's game pass, to make it slightly better value than the playstation equivalent full priced game.
But they didn't seem to want to do anything like that.
Some people will exaggerate one way, and some the other way. The internet is big and you can say, and substantiate, "people said" for any opinion you choose, and show that it was wrong later.
That's fair enough - I see what you mean. I think I read the case I was thinking into the article. Now I re-read it, it is saying what you're saying, which does make a lot of sense.
Using types like this also means you can more easily avoid assignment errors, as everything will have a very specific type (e.g. Age instead of int).
This feels right, and I also have never done it (or had the guts to get others to do it).
The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right.
The classic answer is to move the logic inside the domain object, or have a helper function outside the object, so you aren't constantly checking for field presence/absence, but are instead writing the logic once and calling some code.
I'm not sure in practice types can help with this. But I'd love to be proven wrong.
> Forcing hand written should really not be necessary. It would be very cheap in terms of old computing hardware to set up a test room with old desktop PCs that have wired only NICs (with a network connection that goes to a switch in the same room with no uplink, connected to a decent size laser printer only), running something like lubuntu and libreoffice writer as a basic word processor.
Exams that only require paper, tables, and chairs can be done anywhere, and require minimal setup/set down, transport, or power, and no tech support.
> I'm not saying that we shouldn't do security review of open source libraries, just saying that this situation puts a lot of pressure on the maintainers.
This is true, and worth saying, but it is also a problem of the OSS philosophy. All software is used at your own risk, so if maintainers want their software used they need to keep up, and the (true) promise of "more eyeballs means more secure software" has this downside built in.
In fact, I applied for an Engineering Director role there not too long ago and they rejected me, so they must have extremely high standards!