Live data from Hacker News

The Earl Grey programming language

breuleux.github.io

91–100 of 137 posts

Re: The Earl Grey programming language

#91
post #65

Earlier quoted context omitted.

I think the first one is a single function that has pattern matching for the parameter while the second one is defining the function twice and relying on the language to call the right one based on the parameter. I think in Erlang the function identification is the name and the arity and this is as close I know of what you would like to have.

Erlang does it very much like GP's suggestion with the one downside of being 'noisy' with its punctuation (some might say 'clearer'): factorial(0) -> 1; factorial(N) -> N * factorial(N-1). factorial(Foo, 0) -> .. ; factorial(Foo, Bar) -> .. . Semicolons separate partial definitions for a single function of a single arity, and periods end those definitions. Removing the punctuation might make parsing a bit more diffic…

Off-topic: I'm kinda new here, what does GP stand for ?

Re: The Earl Grey programming language

#92

Earlier quoted context omitted.

Just wondering though, how often do people write subtraction as "stuff-thing" instead of "stuff - thing"? I find myself typing the latter almost systemically, so hyphens never get in my way, but of course it's all too easy to be blind to the habits of others.

It's more a question of readability than writeability Something like: result = balance-sheet - ledger-total + discount-total Is harder to read than result = balanceSheet - ledgerTotal + discountTotal

But see, being used to hyphens in variable names, I must tell you I can't figure out which one I find easier to read. On one hand, the presence of hyphens and subtraction is a tad confusing, but on the other, I find "balance-sheet" to be generally nicer to read than "balanceSheet", so it feels like a tie to me. Then, on the other hand, you have things like "xs.for-each(x -> x + 1)" vs "xs.forEach(x -> x + 1)", where I really like the hyphen.

Anyhow, I feel that this is the kind of feature you just stop noticing after a while. I think we often tend to assume that what we are used to is more readable than what we aren't used to, but the brain will adapt to nearly anything. Doesn't mean we ought to go crazy with changes, but hey, I like hyphens.

Re: The Earl Grey programming language

#93

Earlier quoted context omitted.

Just wondering though, how often do people write subtraction as "stuff-thing" instead of "stuff - thing"? I find myself typing the latter almost systemically, so hyphens never get in my way, but of course it's all too easy to be blind to the habits of others.

If you have `stuff - thing` it’s no big deal, but once you start having `(a0-b0)/(a1-b1) + (x0-y0)/(x1-y1)` or whatever, then being able to save all the spaces starts to be kind of nice, especially if your math expressions get to be 60 characters long. There are a few times where I’ve definitely ended up with more readable code by using the presence or absence of a space as a way to group expressions. Also, I general…

In long and complicated mathematical expressions I find myself selectively using whitespace to identify logically matching pieces of code, similar to LaTeX' \left( and \right). If I couldn't write (x-y) that wouldn't be possible in the same way.

Re: The Earl Grey programming language

#94

Earlier quoted context omitted.

Just wondering though, how often do people write subtraction as "stuff-thing" instead of "stuff - thing"? I find myself typing the latter almost systemically, so hyphens never get in my way, but of course it's all too easy to be blind to the habits of others.

If you have `stuff - thing` it’s no big deal, but once you start having `(a0-b0)/(a1-b1) + (x0-y0)/(x1-y1)` or whatever, then being able to save all the spaces starts to be kind of nice, especially if your math expressions get to be 60 characters long. There are a few times where I’ve definitely ended up with more readable code by using the presence or absence of a space as a way to group expressions. Also, I general…

I think using spacing for this can be a little misleading since it can obfuscate priority. To give an extreme example, 1e100 * 1e300/1e300 is infinity, because the multiplication is done before the division, but the formatting suggests it's the other way around. It's not too bad in that case but if you were to accidentally group an addition instead the mistake would be harder to spot. I would rather use parentheses all the time to be safe.

Still, you make a good point with the space savings. I guess I just find hyphens nice enough that I don't mind the tradeoff :)

Re: The Earl Grey programming language

#95
post #65

Earlier quoted context omitted.

Erlang does it very much like GP's suggestion with the one downside of being 'noisy' with its punctuation (some might say 'clearer'): factorial(0) -> 1; factorial(N) -> N * factorial(N-1). factorial(Foo, 0) -> .. ; factorial(Foo, Bar) -> .. . Semicolons separate partial definitions for a single function of a single arity, and periods end those definitions. Removing the punctuation might make parsing a bit more diffic…

Off-topic: I'm kinda new here, what does GP stand for ?

The grandparent comment, as opposed to the parent comment or the original post.

Re: The Earl Grey programming language

#98
post #15

fact(match) = 0 or 1 -> 1 n -> n * fact(n - 1) why not simply fact(0 or 1) -> 1 fact(n) -> n * fact(n - 1)

I think the first one is a single function that has pattern matching for the parameter while the second one is defining the function twice and relying on the language to call the right one based on the parameter. I think in Erlang the function identification is the name and the arity and this is as close I know of what you would like to have.

Erlang has both methods, pattern matching in function definition and case-clause pattern matching.

(some random link http://stackoverflow.com/questions/1050913/erlang-style-case...)

Re: The Earl Grey programming language

#100

Earlier quoted context omitted.

I'd love to hear why people prefer underscores over hyphens. I think I grew out of syntax fanboy-ism, but C and python __private__, _special_variable are everything but readable to me. They break the visual line too much. Even historically it was a weird symbol, originally a line break that made it into non-space separator in PL/1, then almost everywhere. Before that it was pure formatting, a typewriter glyph to be o…

> I'd love to hear why people prefer underscores over hyphens. Because I like subtraction.

[deleted]
Post reply on HN