Live data from Hacker News

Sir, Please Step Away from the ASR-33 (2010)

queue.acm.org

171–180 of 291 posts

Re: Sir, Please Step Away from the ASR-33 (2010)

#171

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…

That's the brilliant thing about programming: you can do it however you want. If you want to write your code in such a way that an Anglophone spends half their time looking up ALT key combinations to type the characters, go ahead. I'm just saying that I'm not touching that code with a ten foot pole, nor is anyone I know, nor would any of my customers. There's too much talent in the world for me to put up with one iota more hassle than necessary.

Re: Sir, Please Step Away from the ASR-33 (2010)

#172
post #165
post #143

>> 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…

If I see a character I can't enter in someone's code, I think I'll run away. It's cool and all for your code, but sooner or later someone else is going to have to deal with it.

Re: Sir, Please Step Away from the ASR-33 (2010)

#173
post #139

> 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…

Further in this point; even without the subjective warts, the composability of colors would leave a lot of confusion. Blue-green, or green-blue?

Re: Sir, Please Step Away from the ASR-33 (2010)

#174

Earlier 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?

It really doesn't have to be. For instance, in Julia IDEs \omega would complete to ω, which takes 2 extra characters to enter (\ and tab). Its not hard to imagine this concept, but applied at the OS level...

Re: Sir, Please Step Away from the ASR-33 (2010)

#175
> Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?

Majority 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)

#176
post #149

Earlier 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.

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 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)

#177
post #149

Earlier 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…

Ah, that makes it more clear.

Re: Sir, Please Step Away from the ASR-33 (2010)

#179
Wow. The same thing I was thinking about. We built a fundamentally flawed system when it comes to ASCII, strings and human languages.

Computer 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)

#180

Earlier 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.

[deleted]
Post reply on HN