Overloading

Posted Apr 26, 2014 10:54 UTC (Sat) by rsidd (subscriber, #2582)
In reply to: Overloading by tialaramex
Parent article: Porting the Go compiler to Go

Not C++ but python, and libraries (numpy, sympy) that others wrote and I use (and, rarely, read and try to understand). It makes complete sense to allow arithmetic operations (+, *) to matrices and symbolic types, and python lets you define methods in the class definitions that let you do that. Of course it make no sense to define "+" to mean something totally different, like exponentiation. The language provides tools, but can't force common sense on the programmer. Properly done, operator overloading makes such code (ie code using user-defined or library-defined mathematical objects) more readable, not less.

The other extreme is OCaml which has different operators for integer and floating-point arithmetic. Now that makes code harder to read, or write.

Overloading

Posted Apr 26, 2014 13:57 UTC (Sat) by aggelos (subscriber, #41752) [Link] (1 responses)

The other extreme is OCaml which has different operators for integer and floating-point arithmetic. Now that makes code harder to read, or write.

Actually, I've found that to be quite helpful when writing code and I don't think +. (floating point addition operator in OCaml) is any harder to read than + (integer addition). Same for lack of automatic integer type promotions (wish I could opt out of that in some C code). I don't doubt there's programs where the extra type conversion calls would get in the way, but for most of the programs I write these days, it's nice when the type system discourages sloppy thinking about arithmetic. YMMV :-)

Overloading

Posted Apr 26, 2014 14:34 UTC (Sat) by rsidd (subscriber, #2582) [Link]

Indeed, my mileage varies -- it's one reason I quit ocaml after writing one very serious program in it (with a published paper associated). Note that it's not just floats: you need to define new operators for bignums, complex numbers, matrices, and anything else that you may need to deal with. I still like other aspects of ocaml though. Maybe I should look at F# more seriously.

Overloading

Posted May 19, 2014 7:38 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

> The other extreme is OCaml which has different operators for integer and floating-point arithmetic. Now that makes code harder to read, or write.

"1.0 +. 2.0" is very hard to read, really?

The problem with operator overloading (and many other C++ features, or Perl,...) is giving kids matches. You CANNOT rely on programmers not to abuse them, it just does NOT work in real life. Sure, you can always find some teams of geniuses so good they don't live in real life (lucky you if you are part of one) but you also need programming languages for the masses.

Ocaml's "+." is the perfect balance. It's just as readable as a plain "+" without falling into the operator overloading trap.

Overloading

Posted May 19, 2014 14:11 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

I'd say Haskell got this right more than OCaml. Forcing a new operator for every type is crazy when you have things as abstract as Monad or Applicative sitting right at your fingertips with obvious operators that should exist on the class of types. Would OCaml have different operators for Maybe and Either's monad operator bind (>>=)? If so, why couldn't OCaml have made their operators polymorphic with restrictions?

Overloading

Posted May 19, 2014 17:06 UTC (Mon) by marcH (subscriber, #57642) [Link]

Just for the record: I was merely using '+.' as a very specific example in a general operator overloading discussion and not actually making any comment about OCaml.

Also, this discussion should probably make a clearer difference between built-in versus user defined operators.