HN user

mwotton

68 karma

haskell, perl, shimweasel.com

Posts0
Comments37
View on HN
No posts found.

I had some code for the Servant type-level HTTP API library in Haskell that does type-correct property testing on arbitrary web apis without user input, then Servant changed their type structure from a basic list-based format to a record-based one. This was a good change for lots of reasons, but adding the type-level code to make my library (roboservant) compile was absurdly hard, i burned days on it.

GPT 5.something got it in two prompts.

I used sqlite as a backend for scraping 160 million websites a day. It works extraordinarily well if you hold it right - in my case, that meant devoting a database file to each thread. (Arguably in this context, it's competing with flat files, but it does a really good job there.)

I have a crawler downloading 160 million websites a day, almost all in Haskell. It is a much more practical language than the alternatives.

well, let's look.

map f (h:t) = f h:map f t

map f [] = []

member x (h:t) = x == h || member x t

member _ [] = False

I think the only difference is that you can't match for equality directly in the pattern.

It really depends on the type of risk. My assertion is that most startups have most of their risk in the market bucket rather than the technical bucket. If you can move some risk from the market bucket to the technical bucket, and compensate by using Haskell, that may be a good tradeoff.

in the case where your risk is in the market bucket, you may go through many just-barely-working prototypes before you hit product-market fit. at that point, if you've saved some time using Ruby (say) because of external factors like Heroku, Bundler, and ruby-friendly services, you're ahead of the game, even if your tenth prototype sucks and needs to be rewritten.

A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.

It wasn't really intended to make much sense by itself. I find if I make slides that stand alone, the audience reads the slides and ignores me. I put the slides up as a courtesy to the people in the audience.

There was less than zero marketing involved - I gave this talk months ago and only just noticed this thread.

I'm interested in this for ninjablocks, too - I think we're currently bundling a small number of resources (SMSes etc) with each account, but then perhaps more fine-grained tracking.

Privacy is a legitimate concern, but there are useful things you can do that you might feel comfortable sharing with our servers. Zero-information computing is really hard, and we didn't feel it was worth the time it'd take to give that kind of strong guarantee.

yes, we're investigating this. arduinos are a bit tricky because the hardware either needs a general-purpose interpreter which can load new code at runtime, or needs to be able to reprogram itself wholesale over the net. It's doable, I think, but it's a lot harder than uploading some new code to a full linux machine.

yes, exactly. there are a heap of markets that are expensive to target because they're so small - we're in talks with research labs to do experiment automation,for instance, and their equipment is usually priced in the hundreds of thousands. We're aiming at being the glue: geeks have always hacked their own stuff, this just makes it possible for everyone else to do the same.