Live data from Hacker News

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

queue.acm.org

151–160 of 291 posts

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

#151

The Unison language stores code as a syntax tree and they're planning to support multiple alternative syntaxes for the language. https://www.unisonweb.org Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial. Som…

This is fascinating. Thank you for linking to this.

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

#152
> How desperate the hunt for glyphs is in syntax design is exemplified by how Guido van Rossum did away with the canonical scope delimiters in Python, relying instead on indentation for this purpose. What could possibly be of such high value that a syntax designer would brave the controversy this caused? A high-value pair of matching glyphs, { and }, for other use in his syntax could. (This decision also made it impossible to write Fortran programs in Python, a laudable achievement in its own right.)

The irony here is that Python does have an open-scope delimiter. It is the colon. What it lacks is a close-scope delimiter. But you can hack one using the PASS statement and emacs auto-indent, and in my code I do this so that my Python code always auto-indents correctly. Without this you cannot reliably cut-and-paste Python code because you can't count on leading white space being correctly preserved.

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

#153
post #129

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…

Mathematicians have been thinking about nomenclature for a long time - certain fields have very specific usage of symbols. I see no evil in using these well-known one-letter variables in these rare/small parts of functions.

Sorta. Examples abound of notation that had changed or that is adapted for some fields. Complex numbers using j instead of i, for example.

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

#154
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 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.

The touchbar on my M1 Macbook Pro does this. It makes using Emojis a lot easier. I incorporate emojis into my languages more and more nowadays.

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

#155

A programming language designed by a Mac user might make use of the symbols §, ±, ≤ and ≥, among others. I think the tyranny of ASCII is really the tyranny of the tragically poor support for entering characters beyond a small national-language set on the commonly-used OSes, especially Windows. (macOS is significantly better here but no utopia.) Windows-1252, MacRoman and so on may not be the standard character sets a…

Character inputs will always differ between platforms and the most common denominator will always end up being popular for text input. Most of the world is on Windows, so most of the world will use Windows text input. From that input, a limited subset of characters will be used for common expressions, because many people simply don't know they can write the ¬ symbol. Does it make sense to use that instead of the excl…

> Apple shipping keyboards that have the £ character where the # character would otherwise be

That's not really an Apple thing so much as a non-US thing. The standard PC UK layout also has a £ in that position.

> I personally prefer US International over Apple's layout.

Which Apple layout? Apple has its own US English, International English and British English layouts, as well as myriad other languages.

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

#156
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.

I am not really familiar with Unison, but I presume it works like this: Only the code itself is hashed. The then-current name is then added as an annotation. When you refer to a name, the language compiler looks up the hash currently associated with that name and stores the hash instead of the name. When code is rendered, the name associated with the hash at render-time is looked up and displayed. That way if the name is changed, all of the renderings generated after that automagically use the new name.

It's actually quite a clever idea.

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

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

Colorforth not only does this but solved the colorblind problem by switching fonts.

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

#158
post #93

Earlier quoted context omitted.

Hmm, Julia begs to differ, with most editors replacing lambda with the lambda Unicode symbol for example.

Using ligatures (of sort) in presenting code doesn't mean the code itself is not ASCII. Plus, let's see mainstream languages adopt this, I doubt they will. Languages do stupid things all the time.

It means in julia, the Editor and the repl actually replace \lambda with the unicode greek letter

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

#159

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…

I like the rule of thumb that an identifier in code should usually be longer and more specific as scope increases. The main exception is that if your problem domain has well-established terminology or notation for some concept, reflecting that as closely as possible in the code is often best. So, I personally have no problem with someone using short identifiers and concise notation if it’s either used very locally or idiomatic.

For example, suppose we have a function whose job is to calculate two vectors of weights and do something unless they are equal but opposite. Personally, I would rather read something like

    v = someCalculation()
    w = someOtherCalculation()
    if (v ≠ -w) {
        doSomething()
    }
where we use short names for the local variables and vector-aware unequality and negation operators, than read something like

    weights1 = someCalculation()
    weights2 = someOtherCalculation()
    if (not(vector.equals(weights1, vector.negate(weights2)))) {
        doSomething()
    }
The longer but still arbitrary names for the vectors add no value here and the longhand function names for manipulating them are horrible compared to the short and immediately recognisable vector notation.

In general, I think there could be advantages to using a broader but still selective symbol set for coding, as long as we also had good tool and font support to type and display all of the required symbols. I would be hesitant about including Greek letters in that symbol set, but that’s because several letters in the Greek alphabet look similar to other common letters or symbols, not because I think calling a value ω_0 is a bad idea if that’s how practitioners in the field would all write it mathematically.

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

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

This thread is making the point that the issue isn’t the character set, but rather the keyboards. We’re probably locked in, there is so much inertia around the standard QWERTY with a few arrows and Esc. Maybe an integrated system builder with large scale like Apple could shift things slightly.
Post reply on HN