Adding Unicode operators to D

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Oct 25 13:31:26 PDT 2008


Spacen Jasset wrote:
> 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.
>>
> 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? 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.

Surprisingly there's not a lot of choice, witnessed by the prevalence of
Fortran for scientific code. One interesting thing is that quite a few
scientific coders mess with D and hang out around here, such as Don
Clugston, Bill Baxter, bearophile, Benji Smith (he's doing machine 
learning if I remember correctly) and, if I may aspire to the status,
yours truly.

(I remain with an unformed opinion regarding Unicode operators.)

Andrei


More information about the Digitalmars-d-announce mailing list