Live data from Hacker News

Swift Thinking [video]

realm.io

11–14 of 14 posts

Re: Swift Thinking [video]

#11
Interesting that the Apple-provided sample app mentioned around 7 minutes in uses "~=" as a custom operator, given that it's already defined for use with pattern matching (match an input with some sort of pattern), and intended to be overloaded for that purpose. I wonder if this is just an oversight?

Re: Swift Thinking [video]

#12
post #2

Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…

I for one can't wait to create circular references between objects that then stay alive together for ever and ever using the ❤❤❤ operator. More seriously, I wonder why user-defined operators are considered any worse than user-defined functions. I mean, I think that they often are, but I wonder why. Maybe we assume less potential for ambiguity when we read a symbol than when we read a word. The possibility that isEqua…

> I wonder why user-defined operators are considered any worse than user-defined functions.

User-defined functions can take more than two parameters. User-defined operators have one or two parameters (allowing rare exceptions).

User-defined functions can have any signature and specify any contract. To prevent surprises, user-defined operators should return a boolean or a number. Not a Maybe. Not a return code. Not a LazilyConvertsToFloatWhenYouCopyIt.

That being said, I like user-defined operators and the ability to overload operators. But there are tradeoffs, just like in any engineering decision.

Re: Swift Thinking [video]

#13
post #2

Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…

I for one can't wait to create circular references between objects that then stay alive together for ever and ever using the ❤❤❤ operator. More seriously, I wonder why user-defined operators are considered any worse than user-defined functions. I mean, I think that they often are, but I wonder why. Maybe we assume less potential for ambiguity when we read a symbol than when we read a word. The possibility that isEqua…

User-defined operators are bad when they betray our expectations of what they should be doing - and by that, I mean if they don't exist in textbooks which are decades/hundreds of years old (and thus, almost universally accepted as part of our languages/cultures), they're gimmicks. That includes =~ for matching regular patterns - nobody would ever expect this to be the case - only someone who has encountered it in an existing language will use it as such.

User defined functions have names that we can understand, because we already share a common language - English. If we started "making up our own words" for functions, then we're doing just as bad as user-defined operators - nobody will recognize what the hell we're doing without looking up their implementations. It's like reading obfusticated code, or code in some language you don't know. If every programmer invents his own operators, good luck ever getting shit done - people don't have the time to learn some arbitrary language you conjure up just for the sake of shaving a few characters off code. Nor should anyone need a PhD in mathematics to understand the strange notations in your examples/proofs.

Operators cannot be searched for in the same way ASCII text can - we need specialized search engines which don't ignore characters - and they generally need to be written on a per-language basis to be useful. I think the time wasted doing this far exceeds the benefits user-defined operators provide.

Also, many unicode characters look alike, and it may be possible to utilize this in malicious ways where arbitrary characters may be used - by assuming someone reading/reviewing code will not look up the code points of every character. Having a limited set of characters makes it pretty simple to distinguish each one, unless you have poor fonts and can't make out differences between 1,I,l etc.

Operators are useful for sure, but they're never necessary. More to the point, they are just functions - treating them specially is silly, because it's much more useful to abstract over functions of any arity than to abstract over only binary functions.

Re: Swift Thinking [video]

#14
post #11

Interesting that the Apple-provided sample app mentioned around 7 minutes in uses "~=" as a custom operator, given that it's already defined for use with pattern matching (match an input with some sort of pattern), and intended to be overloaded for that purpose. I wonder if this is just an oversight?

The pattern matching example he showed from a few other languages uses =~ instead of ~=. This, however, illustrates the potential confusion with operators that appear to be similar at first glance.
Post reply on HN