I'd actually consider that kind of knowledge pretty advanced. Beginners (and early up to even junior coders) usually don't know much about the internals of their environment; they just use stuff.
I'm always interested in the internals; but it's often surprisingly hard to find information on the internals. There are few books, and you'll often need to read lots of source code and specifications and reverse engineer things to find out how stuff works under the hood.
> I'd actually consider that kind of knowledge pretty advanced.
For someone from a C background, that's not advanced: it's simply what strings are. The whole idea that characters aren't bytes may be very strange to someone who's only ever done C and C++. It's probably just as strange to them as the idea that there's any relationship between bytes and "the characters that make up a piece of text" is to someone entirely new to programming.
In a related anecdote, I was once in a room with 4 C programmers and a Haskell programmer who was trying to write his first C program. The Haskell guy asked "hm ok so how can I compare two functions to see if they're the same?" and after a 20 minute discussion the C guys still couldn't understand why you would possibly want that and the Haskell guy still didn't know how to continue (I was one of the C guys). All had many years of programming experience, but the frames of reference were simply so different.
I think it's smart of Zed to confront people with multiple programming languages from the beginning, so that this kind of issue thing never really becomes a problem.
You are almost certainly misstating the Haskell programmer's question, because C makes it very easy to test if two function pointers are equal (intensional equality) whereas Haskell makes it very hard.
I think they might have meant "whether two functions are structurally identical"—i.e. whether their post-link-load-phase object-code hashes the same, presuming they're both position-independent.
I'd have to disagree, but maybe I'm not getting your point.
It's more work in C and C++ (and a lot of other languages) to treat strings correctly, but unless you're talking about a C programmer who's been living under a rock for 20 years, most of them are familiar with the issues around Unicode, UTF-*, etc., and they choose to ignore the issue when they can get away with it. When it's important, there are libraries like iconv and ICU for handling it. C++ even has some character conversion builtin to the locale system, but it's super ugly (which goes without saying, because almost everything in C++ is ugly ;-)
As far as your anecdote goes, I know both C and Haskell, and the question doesn't make any sense to me either. It's provably impossible to compare two functions for equality. Even in Haskell, function types don't derive from the Eq type class, so it wouldn't be possible.
No instance for (Eq (a0 -> a0)) arising from a use of `=='
That is, functions aren't comparable (for equality, anyway), so the type system won't allow you to compare them.
The better answer is either "Look at their type signatures" or "See if they evaluate to the same values when given the same input"; the first is trivial, the second won't, in general, terminate, so you need a more nuanced conception of "equality" to apply in this instance. This is non-trivial to come up with.
Kent Pitman has an interesting essay on this problem from a Common Lisp perspective: "The Best of Intentions: EQUAL Rights—and Wrongs—in Lisp"
I'm always interested in the internals; but it's often surprisingly hard to find information on the internals. There are few books, and you'll often need to read lots of source code and specifications and reverse engineer things to find out how stuff works under the hood.