caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Tom <tom.primozic@gmail.com>
To: "Robert Fischer" <RFischer@roomandboard.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading
Date: Thu, 8 Mar 2007 22:05:50 +0100	[thread overview]
Message-ID: <c1490a380703081305m534dbb94oc1f97c443fd46844@mail.gmail.com> (raw)
In-Reply-To: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB74@selma.roomandboard.com>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On 08/03/07, Robert Fischer <RFischer@roomandboard.com> wrote:
>
>
> When I see "+", I want to know what that means.
>

I disagree and I couldn't disagree more. In mathematics, we're perfectly ?!?
using + for integer, float, complex, vector and matrix addition (and the
combinations of them) and * for integer, float, complex, vector, vector and
scalar, and matrix multiplication. One who doesn't understand what the
"code" - mathematical notation - means should blame oneself for not
understanding the algorithm, not the "designer" for making the "language" -
mathematical conventions - unappropriate.

Albeit Brian Hurt's comment about operator overloading making more harm than
good in C++, I believe that overloading simply has to be used appropriately
- it's like saying pointers are bad because they can introduce memory leaks
and null references, and division is bad because it can raise
Division_by_zero exceptions.

Like a saying for magic goes, "There is no black magic or white magic, there
is only magic. It's classification depends on the intentions of the caster!"
Any tool given to a programmer can be used either to his advantage or
disadvantage. Even in the "best" language, a stupid programmer will programm
poor algorithms, so there is no point protecting the programmer from himself
(or herself).

Hence, one can hardly say overloading (in general, not only operator
overloading) is bad in C++. If designed carefuly and mantained with a bit of
common sense, it can result in enormous productivity gain. And, how often
does it happen that you don't know what a particular operation means in a
three-lines-long numerical calculation involving vectors, floats and
matrices? Anyhow, if you DID get lost, then you would equally lose yourself
in a mess of *|, +\, %, -| and /. operators. You don't want OCaml be named
LISO - Lost In Superfluous Operators.

I believe that operator overloading an d overloading in general can result
in great productivity and readability gain. Also, they can improve
polymorphism. For example, does it matter if you can't figure out the type
of a in length a? Actually, it doesn't - it could be a list, an array, a
dynarray, a train or a snake - as long as it "fits" algorithmically, it can
be anything.

- Tom

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

  parent reply	other threads:[~2007-03-08 21:05 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 20:02 Robert Fischer
2007-03-08 20:15 ` Michael Hicks
2007-03-08 20:50   ` Brian Hurt
2007-03-08 21:05 ` Tom [this message]
2007-03-08 21:31   ` Brian Hurt
2007-03-08 22:09     ` Michael Vanier
2007-03-08 22:34     ` Till Varoquaux
2007-03-09 16:02       ` Brian Hurt
2007-03-10  3:23         ` skaller
2007-03-08 22:14   ` Ian Zimmerman
2007-03-09 10:29     ` Jon Harrop
2007-03-09 16:28       ` Ian Zimmerman
2007-03-08 23:51 ` skaller
2007-03-09  7:23   ` Tom
2007-03-09  9:24     ` skaller
2007-03-09  9:32       ` Tom
2007-03-09 10:00         ` skaller
2007-03-09 10:14         ` Jon Harrop
2007-03-09 10:38   ` Jon Harrop
2007-03-09 10:20 ` Jon Harrop
2007-03-09 12:08 ` Andrej Bauer
2007-03-09 12:48   ` Jacques Carette
2007-03-09 13:24   ` Andreas Rossberg
2007-03-10  5:08   ` Daniel Andor
2007-03-10  5:33     ` David Thomas
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 16:40 Robert Fischer
2007-03-09 17:25 ` Jon Harrop
2007-03-09  7:36 oleg
2007-03-09 11:09 ` [Caml-list] " skaller
2007-03-09 13:52   ` Andreas Rossberg
2007-03-09 15:07     ` skaller
2007-03-09 16:28       ` Andreas Rossberg
2007-03-10  3:13         ` skaller
2007-03-08 23:20 Robert Fischer
2007-03-09 10:31 ` Jon Harrop
2007-03-08 14:41 [Caml-list] F# Robert Fischer
2007-03-08 17:30 ` Roland Zumkeller
2007-03-08 17:54   ` Brian Hurt
2007-03-08 19:40     ` [Caml-list] Operator overloading Jon Harrop
2007-03-08 20:44       ` Brian Hurt
2007-03-08 22:24       ` Fernando Alegre
2002-04-15 17:05 [Caml-list] operator overloading Issac Trotts
2002-04-14  4:15 Issac Trotts
2002-04-13  8:43 forsyth
2002-04-13  5:26 Issac Trotts
2002-04-13  1:32 Gurr, David (MED, self)
2002-04-12 19:08 Issac Trotts
2002-04-13  8:48 ` William Chesters
2002-04-13 13:58   ` Brian Rogoff
2002-04-13 15:31     ` William Chesters
2002-04-14  3:10       ` Brian Rogoff
2002-04-13  9:00 ` Daniel de Rauglaudre
2002-04-13 21:35 ` Johan Georg Granström
2002-04-14  1:50   ` Jacques Garrigue
2002-04-15 16:22 ` Jun P.FURUSE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1490a380703081305m534dbb94oc1f97c443fd46844@mail.gmail.com \
    --to=tom.primozic@gmail.com \
    --cc=RFischer@roomandboard.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).