Live data from Hacker News

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

queue.acm.org

131–140 of 291 posts

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

#131

Earlier quoted context omitted.

I respectfully disagree with this. I do a lot of maths-heavy work, but for me in languages (not Julia!) being able to quickly write the LaTeX names for symbols is more than enough. It's also much quicker, and easier to search for when reading someone elses' code. I personally find it also helpful to make the distinction between the maths and its implementation, though I accept that others would vehemently disagree iw…

It makes it easy to type, but does it make it easy to read/maintain? As they say, it's already way too easier to write code than to read it. A programmer should make every effort to make code more readable. An editor should make it relatively easy to enter special symbols (especially if you can specify a limited set); it is totally solvable problem. An editor can only help you so far with reading code...

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.

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

#133
post #91

Earlier quoted context omitted.

I'm also under the impression that mathematicians generally work much more deeply with a smaller set of variables, so you actually don't need to name that many individual concepts. A typical program contains thousands and thousands of "named things", so you're naturally going to see a proliferation of names. That just doesn't seem to be that necessary in math once you're working in a particular context (e.g. statisti…

Translation: i learned my domain’s variable names, so you should have to as well. Currently learning some dsp. One of the biggest barriers to entry has been the inscrutable variable names inherited from the field’s math connections.

Feel free to reason about a complex statistics formula with full-blown variable names. There are reasons for short variable names. Pass into a specific function a descriptive name of what you do, but do use the mathematically "accepted" writing mode in the implementation of a well-known function.

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

#134

Earlier quoted context omitted.

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…

And again, this helps other people who have to edit your code how?

Well, if my Julia code ever gets to the point where other people want to edit it, the community has embraced Unicode, so there won’t be a problem there. More generally, I’ll turn my comment into a question: how are people using computers without already having them set up to easily type these characters?

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

#135

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

A variable named ω is no better than a list named l. Both are bad. Be explicit. Terse, but explicit.

Depending on the context, ω may be as explicit as it gets.

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

#136

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?

Keep in my that in Unicode there are several symbols that look alike. It is not just the character set that matters, but how many of such things we have.

May be instead of arguing for Unicode, community needs to come up with a unambiguous smaller set of symbols languages should support.

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

#137
> It was certainly a fair tradeoff—just think about how fast you type yourself—but the price for this temporal frugality was a whole new class of hard-to-spot bugs in C code.

> Niklaus Wirth tried to undo some of the damage in Pascal, and the bickering over begin and end would no } take.

"1970 - Niklaus Wirth creates Pascal, a procedural language. Critics immediately denounce Pascal because it uses "x := x + y" syntax instead of the more familiar C-like "x = x + y". This criticism happens in spite of the fact that C has not yet been invented." http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

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

#138
The author wonders,

“But programs are still decisively vertical, to the point of being horizontally challenged. Why can't we pull minor scopes and subroutines out in that right-hand space and thus make them supportive to the understanding of the main body of code?”

Which made me wonder if there might be some way to make an editor do something along these lines, without changing the programming language. Similarly with his speculations about using color.

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

#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 since it's another way to help, but color having some kind of importance so that pink code and violet code run differently would be hell for me.

Edit: something else: color looks different depending on your computer. Consider how many complaints I already see here about people developing UI for extra wide monitors while most people are on 15 inches screen, that would be terrible. Don't even get me started about arguments on "is this blue, blueish green or green?". Colors are way more subjective than what people seem to think.

> For some reason computer people are so conservative that 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.

And no new letters have been added to English or French lately. They seem to be doing just fine. Typing those new symbols would be hell if keyboards are not designed for it.

Post reply on HN