HN user

yazzku

848 karma
Posts7
Comments713
View on HN
Updates to H-1B 2 years ago

It would be good to have a "no military" filter.

Results would probably come out empty anyway.

Updates to H-1B 2 years ago

You are very confused about how the US works. Go find out where the Internet comes from, for example.

Updates to H-1B 2 years ago

Why is this down-voted? I was going to add most people have already seen some sort of linear algebra even in high school. Determinants, Gaussian elimination, etc.

It's unclear what "linear algebra" means to GP, though. I agree writing linear algebra libraries is next level, since that involves numerical code and knowing FP math well.

Ah, right, the 50-year cut-off makes a lot of sense, circa Exxon Mobil deciding to engage in the largest terraforming experiment done on Earth for profit despite its own knowledge of the consequences. That makes total sense; God created Exxon Mobil, and anything we do to challenge it is interfering with God's fine handiwork.

Let me prepare the school curricula for next calendar year.

Superluminal is a sampling profiler for the most part. It works great for what it does, sure. But in the author's own words:

So far, we’ve only used perf to record stack traces at a regular time interval. This is useful, but only scratching the surface.

For cache hits and other counters, you're gonna have to go deeper than just sampling.

Compiler messages:

The big difference here is that the OCaml compiler has a lot less work to do. It's not that the Haskell error messages are inadequate (they are actually pretty good), but that the amount of compiler features and type gymnastics make the errors deeper and more complex. For example, if you get the parens wrong in a >> or >>=, you'll get some rather cryptic error that only hits home once you've seen it a few times, as opposed to "did you mean to put parens over there?"

Engineer vs mathematician. Haskell is the schizophrenic product.

If I come to an existing OCaml project, the worst thing previous developers could do to it is have poor variable names, minimal documentation, and 200+ LOC functions. That’s fine, nothing extraordinary, I can handle that. > If I come to an existing Haskell project, the worst thing previous developer>s could do… Well, my previous 8 years of Haskell experience can’t prepare me for that

This is kind of like Go vs C++, or <anything> vs Common Lisp. The former is a rather unsophisticated and limited language, not particularly educational or enlightening but good when you need N developers churning code and onboard M new ones while you're at it. The latter is like tripping on LSD; it's one hell of a trip and education, but unless you adopt specific guidelines, it's going to be harder to get your friends on board. See, for example: https://www.parsonsmatt.org/2019/12/26/write_junior_code.htm...

FP is not a silver bullet. GUI is the classic OOP showcase.

Ideally, you should be able compose them several of them into a single app and not have a custom implementation of a giant state

If you are suggesting that components store their state, I'm not sure about "ideal" there. That works well for small GUI applications. In GUI applications of modest size, you do want a separate, well-organized and non-redundant data layer you can make sense of, at least from my experience. Qt, specifically, allows you to do both things.

If you only have 3 states, then yes, that should be an enum, not a pair of booleans, because you have 3 states, not 2x2 independent ones. Making the 4th state unrepresentable removes code and error checking. It's also just simple domain modeling.

Your latter example needs context. In what situation have you had an enum with 2^16 states? In any case, if you generally have a reasonable number of booleans, with some states being logically invalid, then you'll need error checking on those anyway.

Leaving them as booleans gives you the ability to monkey-patch things later in an ad-hoc manner, which is useful when you're still in a prototyping phase and the requirements aren't clear (and you could argue that this is almost always the case in many problem domains; I think that would be valid criticism.) But if you've already modeled the domain and you want any assurance of correctness, then I don't see why you wouldn't enforce the constraints at the type level. Your criticism seems to me the usual trade-off between strong static typing and dynamic and/or weak monkey-typing.