The whole lens thing was what really turned me off to Haskell in the first place. It seems like I would never get it and it's hard to want to be in a language where you don't get something.
Based on the people who have amount of "C++ experts" I've interviewed over the years who don't know much about template metaprogramming or weird rules about initialization and class layout, yet have shipped meaningful code while avoiding most of the weird parts of the language.
Even languages like Python can get weird, such as default arg initialization:
def add_item_to_list(item, list_to_add=[]):
list_to_add.append(item)
return item
a = add_item_to_list(1)
a.append(3)
b = add_item_to_list(2)
This is my go-to Python 1st-round question, and many prolific Python coders don't get through this.
From what little I've learned of Haskell so far, it seems like one can eschew the weird PL-heavy parts of the language and just be productive (with the tradeoffs the language contains, e.g. GC).
It seems to me that it's one of those things you've either encountered (and go "well, that's weird") or... haven't encountered (and go "well, that's weird" upon having it explained). Have pop quizzes about the sharp edges of various languages proved useful as a filtering mechanism?
It is scary that software engineers want to be considered professionals, and yet don't want to be held responsible for understanding the tools they use.
Would you trust a bridge designer who didn't really understand the intricacies of concrete? Not me, no thank you.
Is it fair to expect a candidate claiming fluency in language X to back that claim up? Sure. But I don't think the general thrust of your comment is very productive.
If you're coming into a role saying "I'm very familiar with Python" and you don't know one of the most famous 'gotchas', that says something.
If you're coming into a role and saying "Hey, I'm not so familiar with Python but I have experience in other languages and I'd love to learn it as part of this role" I think that question is not appropriate.
It's pretty easy to just never bump into certain corners of languages -- even if you use said language extensively. I've used Python for, like, 8(ish) years professionally. I maintain a few moderately popular open source libraries. I honestly don't recall exactly what happens when you do the `list_to_add=[]` thing, because these days I pretty much never pass in a list with the purpose of having it be mutated by something else. I know is that I did try it once, a long time ago, and that it does something unexpected. But I couldn't tell ya more than that just by looking at in.
Color me dismayed to discover that I'm actually a hack fraud.
What I said elsewhere still stands. Yes... this kind of thing is the difference between 'works well' and 'exposes private user data to other users'. I'm glad you don't use such constructs, but realistically, given python's closure rules and when data with interior mutability are captured, this situation arises more than just in this particular situation. And like I said... it can easily lead to exposing private information to other users.
it would be extremely hard for a Python developer not to encounter this core property of the language (call by assignment), unless the candidate has just graduated from a random 1-month bootcamp, which may be the purpose of discovering of with the first-round question.
a = add_item_to_list(1)
a.append(3)
b = add_item_to_list(2)I should not try to HN comment while running out the door to catch my bus...
Trick question it's a type error?
`struct ^. field1 . field2` to get stuff
and
`struct # field1 .~ blah` to set stuff.
It's syntactical memorization on par with any other language. A bit strange, but just syntax.