Adding Unicode operators to D

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> Spacen Jasset wrote:
>> Bill Baxter wrote:
>>> On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> Please vote up before the haters take it down, and discuss:
>>>>
>>>> http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/ 
>>>>
>>>>
>>>
>>> (My comment cross posted here from reddit)
>>>
>>> I think the right way to do it is not to make everything Unicode. All
>>> the pressure on the existing symbols would be dramatically relieved by
>>> the addition of just a handful of new symbols.
>>>
>>> The truth is keyboards aren't very good for inputting Unicode. That
>>> isn't likely to change. Yes they've dealt with the problem in Asian
>>> languages by using IMEs but in my opinion IMEs are horrible to use.
>>>
>>> Some people seem to argue it's a waste to go to Unicode only for a few
>>> symbols. If you're going to go Unicode, you should go whole hog. I'd
>>> argue the exact opposite. If you're going to go Unicode, it should be
>>> done in moderation. Use as little Unicode as necessary and no more.
>>>
>>> As for how to input unicode -- Microsoft Word solved that problem ages
>>> ago, assuming we're talking about small numbers of special characters.
>>> It's called AutoCorrect. You just register your unicode symbol as a
>>> misspelling for "(X)" or something unique like that and then every
>>> time you type "(X)" a funky unicode character instantly replaces those
>>> chars.
>>>
>>> Yeh, not many editors support such a feature. But it's very easy to
>>> implement. And with that one generic mechanism, your editor is ready
>>> to support input of Unicode chars in any language just by adding the
>>> right definitions.
>>>
>>> --bb
>> 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.
>

But what operators would be added? Some mathematician programmers might 
want vector and matrix operators, others set operators, others still 
derivation/integration operators, and so on. Where would we stop?
I don't deny it might be useful for them, but it does seem like too 
specific a need to integrate in the language.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D