HN user

akegalj

31 karma
Posts1
Comments9
View on HN

I would second this.

My experience is that people get scarred of so much new terms which get introduced in Haskell and that could feel overwhelming.

When beginning with Haskell, I would advice to just write code and try to intuitively understand bits, but not get down into unwrapping things or theory much. Stay high level and figure out how things interact as you would do in black box model. Don't open the box, but poke it and see what result you will get (in other words; just write code and do trial and error).

When you get comfortable with black-box learning then open the box and look for the details.

When interviewed for engineering position at Google 6-7 years ago I asked:

"How is the weather at OfficeWhereIAppliedTo?"

It was a really honest question because sunny weather is something that I really care for as I am from mediterian.

The reaction was really positive - everyone was laughing and interview ended in a very positive and relaxed tone.

At the end I didn't get the offer - but that's because I was too slow at solving algorithmic problems.

You can't rest fingers on this touch keyboard the same way you can on phisical keyboard (laying hand on a keys without enogh force to push the keys). I would not be confortable of hovering hand all the time - usually I rest my fingers on keycaps when in idle mode (not actively hovering above the keyboard)

This can be solved by dependent typing

dependant typing isn't needed for some use cases you have mentioned:

list must not be empty you can use NonEmpty

https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-L... . We are still encoding this special case and our intent in types. Cons is that we need a special support for it (special library) where with dependant types we could reason about this use case without a special library

EDIT: added newlines