Comment by seagreen | Hacker News Reader

Comment by seagreen | Hacker News Reader

Parent Full thread

I've had trouble getting into it because the ergonomics are so incredibly, wonderfully, art-project level rough.

For example:

    $ erl
    Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:8:8] 
    [ds:8:8:10] [async-threads:10] [kernel-poll:false]
    
    Eshell V9.2  (abort with ^G)
    1> 2 + 2
    1> 2 + 2.
    * 2: syntax error before: 2
    1> 2 + 2.
    4

Note the trailing whitespace(!) after the last `2 + 2. `, necessary for the result to be printed.

I was coming from Haskell which has its own very serious tooling and ergonomics problems. Trying Erlang made me realize things could be even worse. My internal model in my head of language designers/promoters is COMPLETELY wrong, I have absolutely no idea how people could spend time promoting languages with such strange tooling to a general audience with any expectation that it will work.[1]

[1] Not to say that these languages/tools aren't awesome. Trailing whitespace matters semantically absolutely not at all. But if you're trying to promote a language with meaningful trailing REPL whitespace to a general 2020 audience there is some terrible mismatch between your expectations and your actual chance of success.

There's no meaningful whitespace in your example. You have a syntax error in the first example.

To get the effect you wanted in the you needed a `.`:

  1> 2 + 2
  1> .
  4

That is, if you really wanted it split over multiple lines.

The syntax error is indicated as being on line 2 (though not obviously on line 2) with the prefix to the error:

  * <line number>: <syntax error information>

What you've essentially typed in your first example is (replacing the newline with a single space):

  1> 2 + 2 2 + 2.

You'd expect an error from that since there is no operator between the second and third 2. Even placing a comma would've been enough:

  1> 2 + 2
  1> ,2 + 2. ;; this is weird to do, but valid
  4

The shell expects a period terminating an expression before it parses it. This permits entering multi-line expressions without doing anything special (you don't need a special "I'm going to continue on to the next line please don't parse this one" backslash, for instance).

Oh, that makes sense! Thanks to both you and moreoutput.

My argument is wrong then-- this isn't shockingly bad anything, just a little quirkiness.

I think part of it is that the shell is not the most forgiving of syntax errors, and Erlang doesn't always give the clearest syntax error description.

It's always been correct by line number for me, but I usually have to read that and the line above/below to understand what my actual errors are.

What am I missing here? I see no meaningful white space when running the same logic. I would expect this from any language when expressions aren't properly terminated.

Eshell V10.4 (abort with ^G)

1> 2+2

1> 2+2.

* 2: syntax error before: 2

1> 2 + 2.

4

2>

Yep, GP mentions in another comment that they misinterpreted the error.[0]

Anyway, Python replaces the prompt ">>> " with "... " if the input is mid-statement, and I suppose it would be nice if Eshell did the same thing.

[0]: https://news.ycombinator.com/item?id=22799222

This whole thread is going in my "Humility" file, not only did I misinterpret the error this one time, I've been messing around at the Erlang REPL putting a space after each command for absolutely no reason <headdesk>.

If you think that's bad, wait until you realize that even though people will fill threads talking about zig being a successor to C, it -purposefully- errors out on carriage returns and tabs! It is specifically built in that if you save a text file out of any windows editor without changing special settings, zig will error out. If you put in tabs, it will error out. Now trailing white space doesn't seem so bad.

what is this, 2009? If your language cares about it, Your code editor should automatically convert CRs and tabs as you type.

Every language in existence is able to deal with default windows files. Zig -intentionally- breaks on carriage returns and tabs. It went out of its way to not work.

I think that's a wise choice. The zig ecosystem doesn't need people that get hung up on that.

Hung up on what? Working? Please explain why this problem that would take 30 minutes to correct makes sense to keep around?

Reply on news.ycombinator.com