Live data from Hacker News

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

queue.acm.org

241–250 of 291 posts

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

#241

Earlier quoted context omitted.

A great example of how very smart capable people can express silly ideas wherein they justify personal preference with bad logic. https://ppig.org/papers/2015-ppig-26th-dimitri/ Code isn't arithmetic nor prose and the majority usage of highlighting is because people intuitively grasp that life is easier with highlighting. It is perfectly ok to have different preferences but one must be careful not to elevate a prefer…

I hypothesised that syntax highlighting just had to provide some tangible benefits just because of how it allows the brain to process lots of information with a quick glance. After having witnessed a few geniuses work and swear by no syntax highlighting, I started to doubt my thesis, so thank you for linking the paper. Maybe some people just perceive the syntax highlighting as cognitive overload although it's meant t…

Maybe They want to try fixing syntax errors to old school way printed out fanfold paper and highlighter pens.

narrator voice : They do not want to do that.

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

#242
post #203

Earlier quoted context omitted.

> There are reasons for short variable names Which are? I suspect the reasons are a combination of the price of paper and ink, the history of teaching using chalkboards. None of those mean we can’t make the canonical version of an equation the expanded representation. Why do we all know e=mc2 and not energy = mass * lightspeed^2. The broader the base of people that have to interact with a formula, the less mathy the…

How about Gauss’s distribution’s density function? Or a numerically stable version of a simpler formula? Also, you forgot the usual case of implementing a whitepaper with mathematical notation. It is much easier to proof read that, when you copy largely the same in your program as well. And if you pass in the readable energy, mass, etc variables, inside the function you can use the domain-specific mathematical notati…

I think we might be arguing different points. I'm not saying use different variable names from the canonical math version - I'm saying the canonical math version should use variable names instead of symbols.

So per your point - I'm not qualified to re-define mathematical notation so I won't go very far with it, but taking the formula you mentioned, Gaussian distribution density function (not focusing on the fact that I had to re-write it in pseudocode to represent it in a text format):

    f(x) = 1/(σ * sqrt(2*pi))*e^(-1/2*((x-μ)/σ)^2)
I would suggest a couple changes:

- change σ to `standard_deviation`, or if you don't like snake_case I could handle `stddev`

- change μ to `mean`.

- change x to `input` - there may be a better name than that, and x is pretty widely used in math so I'm not married to this one.

- e should probably stay the same - e means e no matter the mathematical context, while μ means different things in different fields of math.

    f(input) = 1/(standard_deviation * sqrt(2*pi))*e^(-1/2*((input-mean)/standard_deviation)^2)
This doesn't make it more or less readable, but it does mean I don't have to _just know_ or look up that μ is `mean` to parse it.

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

#243

Earlier quoted context omitted.

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…

To get there, though, you need everything upgraded. Keyboards, sure, but also compilers and editors and IDEs and static analysis tools and grep and...

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

#244
post #30

> Why keep trying to cram an expressive syntax into the straitjacket of the 95 glyphs of ASCII when Unicode has been the new black for most of the past decade?? Because it must be possible to actually type syntax. The problem is a physical one: keyboards are limited in space, we need alphabets, punctuation, a bunch of control keys, and finally we have a very small amount of space left to fit some arbitrary symbols -…

Even if it's possible to type the syntax, there's also the speed of typing. How fast can I type "omega"? Pretty fast. How fast can I enter a unicode omega code point? Probably not as fast.

How fast can I read "omega"? Pretty fast. How fast can I read an actual Greek letter omega? I don't read Greek, and my physics classes were decades ago. Yeah, I can figure out that it's an omega. It might take a bit, though...

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

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

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

It's not a colorblind thing; that's just a terrible idea even if you nominally can distinguish the colors. (Citation: personal experience.)

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

#246
post #163

Earlier quoted context omitted.

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

Don't forget different Unicode code points for the same character, like U+4B/U+212A(/U+39A/U+41A/...).

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

#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 languages) for programmers to write without spaces, than to be able to call a variable ready? or define a +++ operator?

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

#248
post #201
post #150

Earlier quoted context omitted.

I dread the day when I edit some code that has both \Sigma and \sum in the same scope.

You mean ∑ and Σ? Yeah, that'd be terrible. It doesn't seem like it should be Unicode's job to assign meaning to characters, so I don't know why ∑ ("U+2211 N-Ary Summation") exists.

> I don't know why [it] exists.

Ill-considered backward 'compatibility' with block-drawing character sets for mathematical typesetting. (Fucked if I know which character set, but presumably the same one they found U+23B2 '⎲' and U+23B3 '⎳' in.)

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

#249

Earlier quoted context omitted.

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

For me, the biggest problem with the whole maths ---> code mapping is that of nested brackets. For a random quick example, I mean things like (a*(1+exp(1i*theta[0,:]))+foo(x))/((b-cosh(bar(x))+(b+sinh(y[:,-1])). The sort of thing where it just _looks_ far nicer on a page with like _real fractions_ -- where missing a bracket or changing the order of two brackets can _totally_ bugger you. Yes, changing the form of the…

> a nice Euler angle transformation

I'd probably go with something like:

  double cf = cos(phi),sf = sin(phi);
  double cp = cos(psi),sp = sin(psi);
  double ct = cos(theta),st = sin(theta);
  alpha = [ cp*cf-ct*sf*sp   cp*sf+ct*cf*sp   sp*st;
           -sp*cf-ct*sf*cp  -sp*sf+ct*cf*cp   cp*st;
            st*sf           -st*cf            ct];
but I agree it would look better with:

  alpha = [ cψ*cϕ-cθ*sϕ*sψ   cψ*sϕ+cθ*cϕ*sψ   sψ*sθ;
           -sψ*cϕ-cθ*sϕ*cψ  -sψ*sϕ+cθ*cϕ*cψ   cψ*sθ;
            sθ*sϕ           -sθ*cϕ            cθ];
Either way, I don't think Euler angles are ever going to be "nice".

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

#250

Earlier quoted context omitted.

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 π.

Given that the go community does not seem to hold this as a majority opinion, you might consider whether an editor translation layer could allow you to tailor your environment to your preferences while maintaining source-level compatibility with the broader go community. If compatibility is not as important to you, privately forking the language is also an option, but that seems fraught with peril of your code dying…

GoLand actually does this.

But the point is not my preference to use the actual, proper symbols, but rather the technically unnecessary decision forced upon me that says I cannot.

Post reply on HN