Live data from Hacker News

Show HN: Alumina Programming Language

github.com

71–80 of 90 posts

Re: Show HN: Alumina Programming Language

#71
post #57

Earlier quoted context omitted.

What is it that people hate about Rust syntax beyond the terrible lifetime syntax? Seems pretty reasonable to me.

Semicolons, braces, double colons Using " " as both operators and delimiters Turbofish Symbols instead of words (ref -> &, and -> &&, not -> !, …) Inconsistency (Why [i64; 5] and not something like array ?)

I have this thought of solving this sort of thing via emoji's. It's gross but at least you would have a syntax that doesn't grossly overload symbols.

Re: Show HN: Alumina Programming Language

#72
post #71
post #57

Earlier quoted context omitted.

Semicolons, braces, double colons Using " " as both operators and delimiters Turbofish Symbols instead of words (ref -> &, and -> &&, not -> !, …) Inconsistency (Why [i64; 5] and not something like array ?)

I have this thought of solving this sort of thing via emoji's. It's gross but at least you would have a syntax that doesn't grossly overload symbols.

https://www.emojicode.org/

Re: Show HN: Alumina Programming Language

#74

Earlier quoted context omitted.

Rust's syntax is just baroque. It's full of unnecessary noise and additionally very irregular. (With complete craziness thrown in between like the semicolon rule to "visually distinguish" procedures and functions, which must be a kind of joke I don't get). I really don't understand how such a conceptionally well thought out language got this pretty ugly syntax. (And no, you don't need such ugly syntax "because langua…

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled

Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness.

Usually nobody reads semicolons! They are usually just line noise coming form a time as parsing code was actually still some kind of science and people made syntax with the explicit intent to be easy readable by archaic computers (and not humans in the first place).

I think `return`s are superfluous but given the choice between some more line noise in the form of a `return` statement and this semicolon brain-fart I would clearly prefer the `return`…

> (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

Since when? Did I miss something? (This could be, I'm looking only occasionally into Rust).

AFAIK leaving out the semicolon is only an option on the last expression of a procedure, turning that "procedure" into a function.

Leaving out (the completely unnecessary!) semicolons elsewhere is a syntax error to my best knowledge.

  fn main() {
      let baz = if false {"bar"} else {"foo"}
      println!("Hello, {baz}!", baz = baz);
  }
The above code would not compile, afaik, because the semicolon is missing on the first line of the procedure.

The completely unnecessary semicolons are just one of the examples that make the Rust syntax heavyweight and needless noisy for no good reason. I don't get how a modern language can fall back to such antique syntax.

The very rare use-case where you really want to write some comprehensive one-liner could have been easy supported by optional semicolons. But in the general case one just doesn't need that line noise.

Rust is a great language, really! But they obviously didn't put any effort into the syntax. The result is that the language reads partly like C++, and I guess almost everybody could agree that C++ has one of the most terrible syntax out there.

Rust is "modern" language with a stone age look & feel. That's a big missed opportunity, imho.

Re: Show HN: Alumina Programming Language

#75
post #39

Earlier quoted context omitted.

Please try to offer some kindness. Or at least accept that people have various motivations and goals. Languages are regularly remixed. Also, "language designer" is not an elite term -- it can be a hobby, a way to learn, and even a way to inspire others. Perhaps I could invent a spoken language where disparaging remarks are possible but extremely lengthy, thereby discouraging negativity from people in bad moods.

> thereby discouraging negativity from people in bad moods A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”.

> A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”.

A counter punch from someone who feels attacked, right?

Alternatively, you could accept the well-intentioned and fair criticism.

Re: Show HN: Alumina Programming Language

#76
post #39

Quoted post unavailable.

Please try to offer some kindness. Or at least accept that people have various motivations and goals. Languages are regularly remixed. Also, "language designer" is not an elite term -- it can be a hobby, a way to learn, and even a way to inspire others. Perhaps I could invent a spoken language where disparaging remarks are possible but extremely lengthy, thereby discouraging negativity from people in bad moods.

> Perhaps I could invent a spoken language where disparaging remarks are possible but extremely lengthy, thereby discouraging negativity from people in bad moods.

I can see how you might think think my comment is passive aggressive, but it is not. Passive aggression is "the expression of anger, hostility, or resentment through indirect means, especially obstructive or uncooperative behavior: those who expected him to lambast his foes were always going to be disappointed; passive aggression is more his style." (Apple dictionary)

First, if you take my comment as a whole, you can see I was not indirect in my criticism of your comment. Second, I do not feel anger, hostility, or resentment about you or your comment.

Rather, I feel disappointment that this kind of thing happens so often. It is not just you (or any one person) that disparages creativity -- many people have done it, including myself.

The language design comment is sincere. It was a sort of thought experiment. I can also recognize that it is a pointed comment that led to some reflection (I hope), which is why it might have felt like an attack. Still, remember I criticized your behavior, not you.

The comment had the additional purpose of highlighting that language design has broad applicability, and perhaps might reduce some kinds of unwelcome behavior, whether it be bad-mood inspired negativity or error-prone programming abstractions. Rust and Alumina aim to have more expressive types than C, for example. Human language shapes culture and thought -- at least according to many linguists.

Re: Show HN: Alumina Programming Language

#77

Earlier quoted context omitted.

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usual…

> But they obviously didn't put any effort into the syntax.

Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did.

The result is... not very human-friendly IMO.

Re: Show HN: Alumina Programming Language

#78
post #52

Earlier quoted context omitted.

Honestly, the with example seems simpler if you ignore what it takes to build a context manager (which isn’t all that hard). Maybe it’s just I’ve never used defer before but I do use python with whenever I get a chance. Not like that, I don’t really understand what the code is trying to achieve by removing the name at the end, but to close resources at the end of the block. And even then only if it makes sense for wh…

It's not that it's hard, it's just that it is not inline, so it requires a context switch because the CM is defined outside, even when it's doing something specific. The most common problem that defer is trying to solve is cleanup when the function returns early (ususally because of an error). Writing the cleanup code inline before the early return results in code duplication. C#/Java/Javascript have try/finally for…

There's `contextlib.closing` for objects that do not support the context manager protocol and they should be closed.

And then one can simulate defer in the spirit of the `atexit` module with a single context manager (say `finalizer`), defined only once, which could be used as:

    with finalizer() as defer:
        ...
        req = requests.get('https://w3.org/')
        defer(req.close)  # just like contextlib.closing
        ...
        a_dict['key'] = value
        defer(a_dict.__delitem__, 'key')
        ...
        defer(print, "all defers ran", file=sys.stderr)
        ...
The `__call__` of finalizer adds callables with their *args and **kwargs to a fifo or a stack, and its `__exit__` will call them in sequence.

Re: Show HN: Alumina Programming Language

#79

Earlier quoted context omitted.

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usual…

> they obviously didn't put any effort into the syntax

This is an incredibly arrogant and ignorant statement to make, especially for someone who self-describes as "looking only occasionally into Rust". A whole lot of thought has been put into Rust's syntax.

> The result is that the language reads partly like C++

My impression is that a certain amount of this was intentional; if their goal is to attract C++ developers, they can't scare them off with syntax that's wildly alien. Rust took the parts of C++ syntax that made sense to keep and that fit into Rust's semantics, refined/modernized/distilled them, sanded off the rough edges and ambiguities, and presented something cohesive that's still familiar.

The syntax isn't without warts - turbofish comes to mind - but overall I find it pleasant and comfy (and I'm not even a C++ developer). I appreciate that it makes a lot of things explicit that should be explicit. Fewer characters doesn't automatically mean better readability; in many cases it can mean the opposite.

Re: Show HN: Alumina Programming Language

#80

Earlier quoted context omitted.

Rust is a fly-pollinated flower. Without garbage collection, it needs flies. Rust is in part designed to look familiar to C programmers. Rob Pike once famously described C syntax as able to survive a channel that mangled whitespace. That's less of an issue now, but habits die hard. Indentation in place of syntax is nevertheless controversial. That's a toy version of the bigger question: Why should text be required to…

> Rust is in part designed to look familiar to C programmers. Rust may be accompanied by a design statement like that somewhere, but it actually does no such thing.

I'm sure you're right. Rust is a popular language in Haskell user surveys, as it's not such a stretch coming from Haskell.

The majority of the lines I've ever written were in C. When I look at Rust, all I see is `{};`

Post reply on HN