Adding Unicode operators to D

[Bill Baxter]

On Sun, Oct 26, 2008 at 3:46 AM, Spacen Jasset <spacenjasset at yahoo.co.uk> wrote:
>>> I am not entirely sure that 30 or (x amount) of new operators would be a
>>> good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs m3 =
>>> m1 X m2 ? and how often will that happen? It's also going to make the
>>> language more difficult to learn and understand.
>>
>> I have noticed that in pretty much all scientific code, the f(a, b) and
>> a.f(b) notations fall off a readability cliff when the number of operators
>> grows only to a handful. Lured by simple examples like yours, people don't
>> see that as a problem until they actually have to read or write such code.
>> Adding temporaries and such is not that great because it further takes the
>> algorithm away from its mathematical form just for serving a notation that
>> was the problem in the first place.

Yes, heavy math code is hard to read in the current situation.
I almost always prefix any significant math with a comment giving the
equations being implemented in a more compact notation.
Having to write the same thing in two different ways like that is a
waste of effort.
It would be very cool if I could just write it once and have it look
like it does in my notebook.


> Yes, that is indeed a fair point and I agree. D is a "systems programming
> language." [sic] though; and so what will people use it for in the main?

D is a compile-to-the-metal language that is of interest to anyone who
ranks performance high on their list of priorities.  Mathemeticians
and scientists are among the few remaining groups where maximum speed
is still needed.  Games are another area, and games are becoming more
and more sophisticated mathematically under the hood.

> I suggest that communities that require scientific code have options now, and
> that they can and do choose languages for the purpose which have better
> support for thier needs than D might achieve.

The traditional math languages suck at doing anything besides math.
Want to do a bit of math then display the results interactively in an
OpenGL window?  With Fortran?!  Ha!

On the other end there are the Matlab and NumPy-type solutions.  They
are convenient for tinkering around and displaying some results, but
these are not good for performance.

D has both.  So I think D has potential to gain traction in the world
of math-heavy computing.

But anyway, I'm got convinced several posts back that the time is not
yet ripe for Unicode in D.  So I'm not gonna argue that D go Unicode
now.   I'm just saying that math code is hard to read, and that heavy
math users are a good target audience for D because they need
performance, but don't necessarily want to give up
general-purposeness.

--bb