Live data from Hacker News

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

queue.acm.org

261–270 of 291 posts

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

#261

Earlier quoted context omitted.

Some other people in this thread suggested having a keyboard with little e-ink displays on the keycaps. Then the character map could be completely user-defined. Then you could just have a big bank of keys off to the side to select your desired set of characters, i.e. greek, math, emoji etc. You can already sort of do this in software, but you have to manually remember the location of every character in each extra map…

Well damn. I don't have a dog in this fight but boy oh boy do i want that keyboard now. The possibilities of every key being changed to match context sounds awesome. Especially since i love modal editors with visible prompts. Vim/Kakoune users could have their help menu _be_ the keyboard. Every action changes all of your keys to whatever is possible. Sort of mind blowing. Come to think of it, i bet someone has done t…

>Vim/Kakoune users could have their help menu _be_ the keyboard. Every action changes all of your keys to whatever is possible.

Wow, this is an amazing idea. Think of all the other unimagined possibilities if we had real innovation in human-computer interface tech

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

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

No new symbols in english? How about emoji?

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

#263
post #247
post #140

I wrote this, and I'm here if you have questions.

This isn't the kind of article people have questions about - everyone is ready to jump in feet-first with strongly-held opinions! I thought the article was fascinating and thought-provoking, I hope all the strongly-worded opinions aren't causing you to regret it. I was also wondering whether tokenizer rules deserve some flak for making it harder to build identifiers and operators? Why is it more important (in C-like…

Far from, if anything the opposite.

I mainly write this kind of stuff to make people think about what they would not otherwise have thought about, with the secondary goal getting at chuckle or two along the way.

This particular one have been discussed on HN previously and every time the "beause ASCII == keyboard" argument have come up.

...and been slapped down by people from the rest of the world, who have two or even three keystroke sequences to reach [\]{|} etc, because more important national characters, like æøåÆØÅ lives on the "usual" keys.

If I managed to get people to think about that, I've done my job.

As for C:

I think the C lanuage has been mismanaged, why did we need yet a threading API, while we still dont have explicit struct packing, including per struct or per field endianess specification ?

The ISO-C Group is incredibly conservative, which is plain wrong: A finite amount of C code have already been written, but there is a potentially infinite amount yet to be written. They should focus on the larger oeuvre.

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

#264
post #195
post #165

Earlier quoted context omitted.

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

For anyone on Vim, you can insert lots of special characters by hitting Ctrl+K: =3 is ≡, -> is →, l* is λ, M- is —, etc. You can also run :dig! to see a list of all digraphs, and :help digraph for information on how to define your own.

You can also use ^VuXXXX to insert characters by the hex Unicode value. I find that handy sometimes.

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

#265
post #140

I wrote this, and I'm here if you have questions.

I'd love to use unicode on a current project - but just the unicode library is bigger than the memory of the small computer being used :( Seriously, unicode is appallingly messy and heavy-weight. With all that code-point space to burn, a rational design would be very different to what we've got.

All you need to know about unicode, is that they thought they could "unify" all the asian glyphs into one alphabet.

That said, given the origins of writing, I dont think there are any much cleaner solutions.

Their biggest mistake is probably not insisting on a mandatory vector representation which could be used to generate a "font-of-last-resort"

My personal pet-peeve is that unicode have not yet assigned 128 code points and two modifiers to cove all possible combinations of 7-segment LEDs :-)

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

#266

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…

Formulae simply aren't understood like prose, or more precisely, formulae aren't understood as isolated bits of logic. For plumbing code where the logic is important, descriptive variable names are useful in aiding comprehension of the code. For formulaic code, where verifying the equality of two written expressions (one in code and one in the derivation, possibly on a piece of paper) compactness--so called simplification of equations--is far more important. A formula cannot be understood or verified in isolation by itself: as you say, it can only be truly understood by someone familiar with the content. It is by definition, arcane. But the use of arcane variables aids the practitioner since it leads to more compact expressions which makes it easier to check against another source. You cannot eliminate this arcane aspect from formulae simply by spelling out the names of things.

  G_{ab} = 8 \pi T_{ab}
does not benefit from being converted in code to,

  einstein_tensor[index1][index2] = 8 * PI * stress_energy_tensor[index1][index2]
For a practitioner of physics, this is just unhelpful and takes more effort to comprehend. In the spirit of The Humble Programmer, we have unwisely spent the mental energy of the reader. If you actually expand out the Einstein tensor in terms of the Levi-Civita connection and spell it out instead of using the canonical symbol \Gamma and respectively g for the metric tensor then you will just make an incomprehensible wall of text--especially if you inline the summation. What is added by expanding the variable names? A practitioner has gained nothing and lost familiarity and compactness while a layperson has learned nothing about general relativity except the names of the objects. Don't apply best practices uncritically: they are always premised on context.

That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.

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

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

Check out https://docs.raku.org/language/unicode_ascii for an overview how Raku supports Unicode. And an article about its implementation from 2015: https://6guts.wordpress.com/2015/04/12/this-week-unicode-nor...

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

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

No new symbols in english? How about emoji?

I think emojis are mostly a passing trend, just like at some point people loved to decorate the first letter of a book, article or paragraph. They're solving a problem (show the emotion on your face when the only thing you have is written text) but they are one of the many solutions, and will probably be replaced some day.

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

#270

Earlier quoted context omitted.

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…

Formulae simply aren't understood like prose, or more precisely, formulae aren't understood as isolated bits of logic. For plumbing code where the logic is important, descriptive variable names are useful in aiding comprehension of the code. For formulaic code, where verifying the equality of two written expressions (one in code and one in the derivation, possibly on a piece of paper) compactness--so called simplific…

In the example, you are not really naming your variable usefully. You are merely transcribing from a one letter variable to its abstract name.

You can do that in a general function, where the general concept is expressed, where it would still help me to understand your code and search for concepts and terms online, in case I do not understand what is going on.

However, in many contexts it wont be merely an "einstein_tensor", but something that has a meaning in the specific context. Ask yourself what you are doing with that einstein_tensor. What is it used for? Is there a real-world equivalent to the thing you are looking at in the code? Those are the names you should choose in a non-general context and that is why naming things is hard.

Post reply on HN