Spacen Jasset wrote:
Andrei Alexandrescu wrote:
Spacen Jasset wrote:
Bill Baxter wrote:
On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu
<[EMAIL PROTECTED]> 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
