HN user

hesselink

420 karma

meet.hn/city/nl-Driebergen-Rijsenburg

Posts5
Comments137
View on HN

Same in the Netherlands. Postcode and house number is unique and enough to deliver mail. I usually write the return address that way.

I was confused as well. I think (from some other comments) that the issue is that you can scroll to text that is specific to you and others might not have on their page (e.g. 'cancer' on some medical page) and then somehow gather from the requests that you scrolled there. It seems pretty hypothetical, but I can see the issue with forcing a scroll depending on what text is on the page, I guess.

Haskell type classes by default pick the implementation based on a single type variable in its signature, but it can occur in multiple positions (including the return type). A commonly used language extension (multi parameter type classes) extends this to an arbitrary number of type variables.

The thing is, you're focusing on when you've detected that there is an issue (a crash). A lot of the issues with NULL are the fact that you can't easily detect if beforehand. It's not indicated in the types, or the syntax. That means that it's incredibly easy for a NULL issue to sneak into an uncommon branch or scenario, only to be hit in production.

I aliased 'g' to 'git'. Combined with git aliases ('st' for 'status' etc) this is almost as short but doesn't steal all the short names from your shell. So instead of 'gs' you have 'g st'. Upside is you save two letters even on uncommon git commands :)

I feel like this is a false dichotomy: you can have a fast iteration cycle, and have statically checked guarantees. I've worked in Haskell for 7 years and had exactly this. I could load my entire app in GHCi, make changes, reload and test. Now I'm working in Java and in IntelliJ I can have something similar with hot-swap. And in the browser with typescript I have a strong type-system and can reload my app in seconds.

I agree that it's easy to build a slow, batch based build system and just tell people that's how it is. Fast iteration is important and requires effort to keep working. It might even be more important than a static type system, at least for some apps. But you can have both.

If I understand correctly, the point is not raising IPC necessarily, it's finding what to optimize. If you have low IPC, optimize for memory access. If you have high IPC, optimize for code execution. This is in the article under "Interpretation and actionable items". In the end, what you want to improve is the wall-clock time of your program (or benchmarks, realistically). Slipping in useless operations is not going to do this.

It's interesting how different people's preludes are. We have a custom prelude at work, and things that it has that this one doesn't:

* Time types and functions.

* Overloaded (.) and `id`, and some arrow functionality. * More from 'safe'.

* Semigroup.

* String conversions from 'string-conversions', type synonyms for both lazy and strict Text and ByteString types.

* Vector and UUID.

What we don't have:

* The monad transformers by default, although maybe we should.

* Generics. Again maybe we should.

* Bits, Complex.

* All the custom implemented improvements.

* Semiring, DeepSeq, the containers types, concurrency.

Basically our prelude is more conservative, I guess, although it identifies and solves a lot of the same problems. Perhaps that is some common ground to start doing small improvements to the "real" prelude.

This is literally in the first paragraph of the story:

The staccato pop of a cracked knuckle might sound like a balloon bursting — but it’s actually triggered by the formation of gas bubbles, rather than their disappearance.

It says they go to Spam, so I assume it will be treated like other spam (autodelete after 30 days, IIRC).