Earlier quoted context omitted.
This is just the English/Esperanto problem again. Do you do the thing that's the most fair or do you do the thing that's unfair but has the most benefits for everyone involved? Yes, it's unfair to limit people to ASCII but it's also the only way their code is going to see widespread engagement.
> it's also the only way their code is going to see widespread engagement Wow, what a claim! I can see how this may have some anecdotal evidence behind it since programming has had such a strong English bias but it's conjecture to say that this is the only path. Not only does that claim lack evidence, it also lacks imagination. The future doesn't have to follow the same patterns of the past. The technical constraints…
Sir, Please Step Away from the ASR-33 (2010)
171–180 of 291 posts
Re: Sir, Please Step Away from the ASR-33 (2010)
#172>> For some reason computer people are so conservative [...] Well, one of the underlying reasons for the lack of imagination might be... keyboards . If keyboard keys were small e-ink displays, easily configurable and accessible by programs, programmers would have come up with a lot of interesting stuff already. We do it with function icons in regular interfaces. If we could intergrate with keyboards, we'd definitely…
> If we could intergrate with keyboards, we'd definitely take advantage of it. From my own personal experience this is extremely true. A while back I made myself a custom keyboard [0] which can enter lots of characters, mostly for linguistic tasks. I didn’t intend to start using it for things outside linguistics, but before long I was using it everywhere — and my inventory of available characters expanded correspondi…
Re: Sir, Please Step Away from the ASR-33 (2010)
#173> And need I remind anybody that you cannot buy a monochrome screen anymore? Syntax-coloring editors are the default. Why not make color part of the syntax? Why not tell the compiler about protected code regions by putting them on a framed light gray background? Or provide hints about likely and unlikely code paths with a green or red background tint? I'm colorblind, please never do that. Syntax highlighting is fine…
Re: Sir, Please Step Away from the ASR-33 (2010)
#174Earlier quoted context omitted.
Having to do math and physics heavy work, I very much support the "fad" of having Unicode literals. "omega_0" is much worse than "ω_0" especially if you have tons of these variables. If you don't do math it's difficult to understand, but try writing without the alphabet and expressing the same concepts. Possible but clunky
I have a degree in math and I disagree with this. ω_0 definitely looks better than omega_0, but it is much harder to enter unless you have a special keyboard setup. Suppose you write a function that uses a variable ω_0, and somebody else wants to change it. Unless they have the same keyboard setup as you, they will have to just copy-past it everywhere. And what if you have several variable with special names?
Re: Sir, Please Step Away from the ASR-33 (2010)
#175Majority of developers are not from Greece; they don’t have the keys on their keyboard. Technically, modern C# supports Unicode just fine, here’s an example.
using System;
using System.Collections.Generic;
using System.Linq;
static class Program
{
static double Σ( this IEnumerable elements ) =>
elements.Sum();
static void Main( string[] args )
{
double[] α = new double[ 3 ] { 1, 2, 3 };
Console.WriteLine( α.Σ() );
}
}
> Why not make color part of the syntax?Similar reason, because input becomes more complicated. You gonna need to either memorize hotkeys, or reach for the mouse. Also copy-pasting UX becomes way too complicated.
Re: Sir, Please Step Away from the ASR-33 (2010)
#176Earlier quoted context omitted.
No, because the mangled names still depend on the names ...
Not sure I get the distinction. Hashes "depend" on the name as well. You perhaps can't (easily) unmangle, but it's still a derivation.
This does appear to pose a small issue for types, since isomorphic types are identical regardless of their names, but I believe they have a way to attach a unique id to enforce a distinction.
Re: Sir, Please Step Away from the ASR-33 (2010)
#177Earlier quoted context omitted.
Not sure I get the distinction. Hashes "depend" on the name as well. You perhaps can't (easily) unmangle, but it's still a derivation.
From what I recall from looking at Unison not long ago, the hashes do not depend on names. `f x = x * x` and `g y = y * y` both have the exact same hash and are considered to be the exact same function. Any call to `f` or `g` will be stored as a call to their hash, so `f2 x = f (x + 1)` and `g2 x = g (x + 1)` would also have identical hashes. This does appear to pose a small issue for types, since isomorphic types ar…
Re: Sir, Please Step Away from the ASR-33 (2010)
#178Re: Sir, Please Step Away from the ASR-33 (2010)
#179Computer language needs to abstract time and space representation. Solving will improve human - computer interfacing problem. Connect two worlds with commonality, humans writing instructions is not that.
MOV command is the single source of truth. It does something with space and involves time. Start there and build upwards.
Re: Sir, Please Step Away from the ASR-33 (2010)
#180Earlier quoted context omitted.
> ASCII is not a universal character set and treating it as such is nothing short of cultural imperialism: "If it's good enough for us, it's good enough for everyone". SI units like meters and kilograms are also cultural imperialism and we should return to diversity of units, ideally different one for each town. /s
Yeah, go start using metric in the US.