The Rune Programming Language

Post by PointyFluff » Sun, Nov 27, 2022, 5:29 PM UTC

lvass wrote: post #116

kibwen wrote: post #111

Earlier quoted context omitted.

Here's my hot take: if you're designing a new programming language in the modern era, even a systems language, ignore the precedent of C and don't use &|^~ as bitwise operators. You can still have infix bitwise operators, but spell them out as bitand/bitor/bitxor/bitnot. Then you can just use &| for logical and/or, which are 1000x more common than bitwise and/or, and you can reclaim ^ for exponentiation as well. And…

Hard disagree on single characters for logic and exponentiation. ASCII has too few special characters and you'd want to use those elsewhere, without creating ambiguity. Elixir got it right.

Post by nerdponx » Sun, Nov 27, 2022, 5:34 PM UTC

mumblemumble wrote: post #142

kibwen wrote: post #111

Earlier quoted context omitted.

Here's my hot take: if you're designing a new programming language in the modern era, even a systems language, ignore the precedent of C and don't use &|^~ as bitwise operators. You can still have infix bitwise operators, but spell them out as bitand/bitor/bitxor/bitnot. Then you can just use &| for logical and/or, which are 1000x more common than bitwise and/or, and you can reclaim ^ for exponentiation as well. And…

Interesting. I'd go the other way. Continue using single-character bitwise operators, but spell out "and" and "or" for the logical operators. Rationale: in normal usage, short-circuiting logical operators are, in effect, a special kind of control flow statement, and control flow statements are typically spelled out. Bitwise operators are more unequivocally meant for calculation, and therefore perhaps more deserving o…

Post by mumblemumble » Sun, Nov 27, 2022, 5:54 PM UTC

prirun wrote: post #146

mumblemumble wrote: post #133

Earlier quoted context omitted.

As someone who has some difficulty with reading sometimes, I find Python's way of doing things to be a genuine readability challenge. Python's the language I get paid to write, but, if I thought I could get away with it at work, I might try advocating we try out Hy simply so I could return to a world of having visible, non-whitespace delimiters to aid me in reading code. I don't want to make too much hay about my cha…

The braces could be automatically added or removed by any editor, so I don't see the problem, unless someone wants to write code like: if a == b { do this } else { do that }

Post by rurban » Sun, Nov 27, 2022, 5:56 PM UTC

xiphias2 wrote: post #85

jstx1 wrote: post #41

What's up with having two different new experimental languages from Google on the front page https://news.ycombinator.com/item?id=33756800 - did Google just happen to release them at the same time? I think when Carbon came out people's reaction was stronger than deserved (like saying that Google don't believe in Rust, or that Go has been a failure because it hasn't replaced C++ etc.) while in reality all of this is v…

It seems like somebody got too easy access to the Google Github repo. Usually only higher quality projects get approved to the central repo.

Post by aflag » Sun, Nov 27, 2022, 6:23 PM UTC

mumblemumble wrote: post #138

aflag wrote: post #117

Earlier quoted context omitted.

What makes that different from creating a Secret class that's just a container class and defines its own methods? I just don't see what it is that requires a new language to accomplish and couldn't just be implemented as a library in many of the pre-existing languages (including popular ones like C++).

It seems like we're focusing way too much on just the very first example, instead of the feature list as a whole? There are plenty of other interesting features, such as disallowing conditional branching on the contents of secrets, all the way down to enforcing Spectre and Meltdown mitigations around secrets without necessarily globally taking that performance hit on sensitive and non-sensitive data alike.