Adding Unicode operators to D

[Spacen Jasset]

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.


>> If set memebrship test operator and a few others are introduced, then 
>> really to be "complete" all the set operators must be added, and 
>> implemented.
>>
>> Futhermore, the introduction of set operators should really mean that 
>> you can use them on something by default, that means implementing sets 
>> that presumably are usable, quick, and are worth using, otherwise 
>> peope will roll thier own (all the time) in many different ways.
>>
>> Unicode symbol 'x' may look better, but is it really more readable? I 
>> think it is -- a bit, and it may be cool, but I don't think it's one 
>> of the things that is going to make developing software siginficantly 
>> easier.
> 
> I think "cool" has not a lot to do with it. For scientific code, it's 
> closer to a necessity.
On my use of "cool" I only brought it up as this thread has a few 
mentions of the word and it's a bit nebulous. I, personally, am more 
concerened with practicality than "cool".

> 
> 
> Andrei

What I think of unicode symbols therefore depends on whether D should be 
more scientific oriented or not. If it should be, then unicode symbols 
would undoubtedly be a benefit. My responses were guided by the 
assumption that D was more generic in nature, though.