Live data from Hacker News

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

queue.acm.org

181–190 of 291 posts

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

#181
> we still find it more uncompromisingly important for our source code to be compatible with a Teletype ASR-33 terminal and its 1963-vintage ASCII table than it is for us to be able to express our intentions clearly.

D is a fully Unicode language - comments can be Unicode, the builtin documentation generator can be Unicode, even Unicode characters in the identifier. I've been tempted to add Unicode characters for operators many times.

The trouble is the keyboard.

I've seen many ways to enter Unicode. I even invented a new way to do it for my text editor. All awkward and unsatisfactory. No way to touch type them, either.

What is needed is a dynamically remappable keyboard, with a configurable display on each keytop so you know which letter it is. Nobody is going to remember what the remapped letters are without it.

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

#182

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

Why not go all the way, and write ω₀ :-) I don't often write complicated formulae, but I do find it easier to use the original symbols if possible. Its one less thing to think about when comparing the source code with a mathematical description of the algorithm.

believe it or not but the ₀ (u2080) is not allowed in Python, it's not for a lack of trying :)

for some reason the entire Unicode "No" (Number, other) category is not included in the admissible character list for identifiers

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

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

Lots of e-ink screens are monochrome. There was recently a thread here about a big one that seemed intended for desktops. I often use my phone in monochrome for various silly reasons.

I like having my code coloured, but if the colour was part of the code I'd lose the control I currently have. I'm not against that in principle, but if it was done in a way I didn't like it would really put me off.

The best uses, imho, like rainbow brackets, are applied after the fact. It would be a nightmare to have to match red brackets to red etc.

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

#185
post #97

Earlier quoted context omitted.

That... sounds like a special keyboard setup to me.

OK, I guess that’s a reasonable use of the word “special”. Here is what I was trying to get at: I can not effectively use my computer for anything without customizing the keyboard a little. I need to make the capslock key into an extra control key. I need to set up a compose key so I can type accents when writing in Spanish (even if I didn’t do that, what about writing people's names?). Even sticking with English, I…

Right, but the whole point of language design is to be used by many people. I’ve programmed for 30 years and have never customized my keyboard setup. If you want to create a language for both of us, sticking with standard keyboard characters seems like the best choice.

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

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

I can and have resurrected busted systems with a serial interface, sed, and ed. This is not fun as it is. It would be much suckier if each line of code were subject to out-of-band context such that it wasn’t obvious when having access to only the text.

I see negative value in representing code as anything other than text. Every time I've seen an entity try to do this, I've seen programmers come up with a text-based alternative that compiles to whatever janky format the other party thinks is clever this month.

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

#187

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.

That's the inverse. What we're talking about with keyboards is the opposite, some are advocating for more division. That's like starting a movement for scientists worldwide (who unflinchingly use metric even in the US, as far as I'm aware) to ditch metric and start using the standard units that were historically common in their culture.

And for what it's worth, I've never talked to a person who doesn't agree that the US using metric would be great, the problem is that getting over the inertia of the existing casual measurements is extremely difficult because even when metric is on the label, imperial is the emphasized one (the entire traffic sign infrastructure, the vast majority of cooking implements, decades of cookbooks, most food packaging, medical records systems, drivers licenses, advertising campaigns, the personal fitness ecosystem, entire product names and trademarks). 60 years ago maybe it could be doable, but at this point it's a bit of a lost cause without very much gain.

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

#188

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 disagree. Instead of writing one letter variable names, one could do the hard work of naming things properly, which software developers often do. Instead of going with one letter or the name of that letter as variable name, which tells your fellow non-mathematicians exactly nothing about what it contains, one could put in the effort and make the code readable. Using these one letter variables forces the reader of t…

> Using these one letter variables forces the reader of the code to either be already familiar with the concept, which that letter refers to, or keep the whole calculation in their head, until the final result, to hope, that they then can make sense of it. It is implicitly requiring outside knowledge. It is shutting out many potential readers of the code.

When you're writing code for physics, then yes - absolutely: It is intended for other physicists, and the prerequisite is precisely that you have outside knowledge. When they use a symbol like ℏ in a journal article, it is expected that the reader knows it is Planck's constant[1]. Why should they have a different expectation when writing code? To a physicist, -ℏ^2/(2 * m) is a lot more recognizable than -planck^2/(2 * mass).

To be clear: The chances that a person who doesn't recognize these symbols will need to read and understand your code are virtually nil.

Within a context, single character symbols are very useful. To take a different example, what if I insisted that people should write:

2 add 3 add 7

instead of:

2 + 3 + 7

Would anyone reasonably argue that the former is more readable? We all accept that it's OK that a reader is familiar with the '+' sign. While ℏ is not readable to most, it is likely readable to anyone who is expected to read the code.

The thing that really is annoying when writing physics code is the need to explicitly write * for multiplication, and not being able to write fractions the way you would on paper.

[1] divided by 2π

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

#189

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?

Okay, so we need better keyboards then. If a character is annoying to type, that is a keyboard problem, not a language or charset problem. So let's improve the keyboard. Currently we are stuck with the garbage qwerty keyboard (and various slightly better permutations of it) which doesn't even let you type all of ascii. Computers should just do what humans want. If you see a character, you should just be able to type it. It's absurd that cpus can do billions of ops per second but you can't just type an omega. Absolutely shameful, really.

You should dream bigger. A better world is possible but only if people really want to throw out all the shitty designs from the ancient past

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

#190
post #163
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…

> Well, one of the underlying reasons for the lack of imagination might be... keyboards. That and the fact that it would probably take me longer to search for whatever obscure mathematical symbol is supposed to represent than it would take to just type out its name. And ASCII is just easier to deal with.

Another problem with Unicode is far too many symbols for different Unicode characters are too similar looking, or even identical.

Then there are the Unicode symbols that convey semantic information rather than just the appearance. These are an abomination and should never have been put in Unicode, but here we are anyway.

Post reply on HN