Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

queue.acm.org

Post reply on HN
Print view View original

231–240 of 291 posts

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

#231

Post by Zababa »

inglor_cz wrote: post #227
Zababa wrote: 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…

"And no new letters have been added to English or French lately." Counterpoint: €

That's a symbol that refers to "euro" or "euros", the currency. "euro" or "euros" are still written with our lovely 26 letters.

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

#232

Post by asoltysik »

lisper wrote: post #156
tyingq wrote: 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.

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

You presumed right, that's how it works ;)

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

#233

Post by inglor_cz »

Zababa wrote: post #231
inglor_cz wrote: post #227

Earlier quoted context omitted.

"And no new letters have been added to English or French lately." Counterpoint: €

That's a symbol that refers to "euro" or "euros", the currency. "euro" or "euros" are still written with our lovely 26 letters.

Ok, symbol, not a letter. But it is still commonly used in everyday work, much like $ or £. People who do accounting etc. would be very unhappy if they could not produce it on a computer keyboard.

So, in practice, you need to support it and it is a relatively new addition. Most other symbols are 200+ years old.

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

#234

Post by bborud »

As much as I admire Mr Kamp's work, I think this is nonsense. Just because something looks familiar doesn't really mean it is the same. There are good reasons to pick syntax that is familiar. Novelty comes at a cost.

And I also think he is wrong if he thinks languages will be improved by making them harder to type and read.

I've spent a considerable amount of time trying to understand code written by someone in China. All the comments in that project are Chinese - which I don't understand. Now imagine using symbol names in Chinese. Or Hangul. Or Russian. Or in Baybayin script. Or Sanskrit.

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

#235

Post by ampdepolymerase »

Zababa wrote: 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…

Be glad you don't code in one of the new age async languages. They love coloring their functions.

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

#236

Post by robocat »

taeric wrote: post #209
robocat wrote: post #194

Earlier quoted context omitted.

And ASCII has the reverse problem: one symbol gets extremely overloaded semantically (syntax wars?!). Tell me what does ":" mean? Now if I tell you the language is Typescript, what does "?" mean? I personally believe semantic overloading causes a lot of problems, but we are so steeped in the existing limitations that we don't recognise it is a problem.

Odd choice. Punctuation, by itself, is virtually meaningless. Language overloads things. Pretty much period. I doubt programming will get away from that.

The implied topic of my comment was programming languages, where your punctuation characters really do matter. So much so in some languages that a single misplaced " " can really ruin your day.

We are so short of semantic operators that languages start to use single letters like "s", "q", " u" as operators or modifiers - which I find ugly (although the best compromise).

I have experienced how the wrong Unicode character can ruin my day - but that is what tooling and editors and best practice are there to help with.

Keyboards are the main problem now I think (in the past it was your OS, your editor, and your tooling). I regularly type Unicode characters from my handheld devices, but hardly ever from my qwerty entry devices (I can't easily find ¡, ∆, ↑ or ç as examples).

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

#237

Post by walshemj »

benjaminjosephw wrote: post #34
eterevsky wrote: post #16

The best thing about using only ASCII for the main syntax is that everyone can type it with their keyboard. I think the recent fad of supporting Unicode identifiers is misguided. Of course, Unicode should be permitted in string literals, but not in the code itself. *Also I don't think Go is better than modern C++, though it might be better than C++99 which was the main standard when the article was written.

But "everyone" doesn't have the same keyboard nor does everyone speak the same language. 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". Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with n…

Remind me how well typewriters worked in Japan and China

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

#238

Post by walshemj »

doctor_eval wrote: post #36
benjaminjosephw wrote: post #34

Earlier quoted context omitted.

But "everyone" doesn't have the same keyboard nor does everyone speak the same language. 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". Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with n…

Not sure why you're downvoted; it's simply true that ASCII is not universal. The "A" in ASCII stands for American. I am a monolingual English speaker but I think I should be able to write ÷, ≤ and ≥ in my Go code, and I think I should be able to do maths using π.

Fine do math's using π this is about programming

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

#239

Post by wtallis »

brandmeyer wrote: post #141
kaba0 wrote: post #131

Earlier quoted context omitted.

I believe it is most definitely easier to read/maintain -- restricted to that small domain-specific function. Some greek letters have very specific meanings, replacing them with long-ass names straight up worsens readability. Writing out density, velocityX, etc will quickly fade the core logic of that function.

I don't think that there is a single example of a greek letter which has been universally adopted by all of the different engineering and mathematics communities to have a single non-overloaded meaning. The use of greek letters in academic writing has a single purpose: Compact notation. It has nothing to do with abstract readability.

> The use of greek letters in academic writing has a single purpose: Compact notation. It has nothing to do with abstract readability.

The compactness of the notation is a major factor in overall readability. Long variable names make it harder to see the overall structure of an expression. When operators, numerical constants and parentheses mostly are represented with one or two characters each but variable names are all much longer, then the only thing you can tell about a long line of code at first glance is what variables it uses as inputs. Mathematical pretty printing can help with some operators (eg. fractions) and make it more visually apparent what's being grouped together by parentheses, but even then long variable names will still detract from the ability recognize the structure of an expression.

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

#240

Post by taeric »

robocat wrote: post #236
taeric wrote: post #209

Earlier quoted context omitted.

Odd choice. Punctuation, by itself, is virtually meaningless. Language overloads things. Pretty much period. I doubt programming will get away from that.

The implied topic of my comment was programming languages, where your punctuation characters really do matter. So much so in some languages that a single misplaced " " can really ruin your day. We are so short of semantic operators that languages start to use single letters like "s", "q", " u" as operators or modifiers - which I find ugly (although the best compromise). I have experienced how the wrong Unicode charac…

Taken at minimal value, punctuation is merely another symbol. A variable named by the symbol "index" will have context dependent meaning.

So...I don't see how this changes my point. The list of symbols that is a program will have many of those symbols in need of context to understand. Do you really think programming can escape that?

Edit: I am sympathetic. I like lisp for having fewer signifiers than other languages.

Post reply on HN