Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stroustrup's Rule (2024)

buttondown.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Stroustrup's Rule (2024)

#31

Post by hackrmn »

epolanski wrote: post #21

I dislike terse notations even as an experienced engineer. Writing few characters more has never been an issue, at best it's annoying. I can understand the counter argument and it's benefits but in my experience one never discussed aspect is that terse notations are cool in isolation, yet quickly compound to hard to reason soups. Take JavaScript: ternaries are cool, yet quickly become hard to understand when nested.…

> Writing few characters more has never been an issue, at best it's annoying.

I don't think the implication is that writing is the issue. In my experience it's the _reading_ that is an issue. I don't mind writing verbose code -- I don't enjoy it but I'd understand the rationalisation in a team of developers that prefer that -- not as much as I mind _reading_ verbose code myself. It feels like you hit the brakes and the accelerator interchangeably. Which proves the point the law is trying to make, for my part.

Re: Stroustrup's Rule (2024)

#32

Post by seanhunter »

I'm pretty ambivalent about this and don't really think the rule is true as stated. It also just comes across as pretty smug. In my experience the preference for terse/verbose or noisy/"quiet" syntax is really down to individual taste and how much things are used, rather than a function of how new or expert a person is.

Since TFA mentions the walrus ":=" operator in python, as an example from another field, when you first learn maths, you might define a function as "f(x)=x^2 - 2" or whatever. Later on, you'll start to see people write ":=" for definitions such as the above and the plain "=" sign just where you have an equation so you are specifying a particular value rather than a definition (eg you might see "let f: R->R be f(x):= x^2-2. Find x such that f(x)=0").

However, some sources (especially in physics or some books on analysis[1]) use an equals sign with an equilateral triangle over it (like this "≜") to mean definitional equality (ie ":="). Now to me, coming from a computer science background, := for a definition seems very natural and ≜ seems super weird, but that really is just down to what you're used to.

And through it all, some people just use "=" everywhere.

This being mathematics, the author gets to choose whatever syntax they want and readers just have to cope as best they can. In computer languages, people go into huge amounts of bike shedding trying to force everyone else to use (or not use) a particular thing.

[1] Kevin Murphy's machine learning books use ≜

Re: Stroustrup's Rule (2024)

#33

Post by MarkusQ »

maleldil wrote: post #29
MarkusQ wrote: post #2

There's a missing dimension: orthogonality. Having terse notation that implements a feature that you can reason about in isolation is fine for both beginners and experts. But features that have complex interactions with their environment are hard to reason about regardless of the syntax (though bad syntactic choices can certainly make it worse). You can introduce a notation that's terse without problem, so long as it…

This operator exists as a macro in rust as dbg[1]. I know this wasn't the point of your comment; I just thought it was a funny coincidence. [1] https://doc.rust-lang.org/std/macro.dbg.html

Yup.

But 1) `dbg!(·)` uses normal syntax and 2) my expository version is two characters shorter. :)

Re: Stroustrup's Rule (2024)

#34

Post by Balinares »

krick wrote: post #28

Even though the premise sounds true (kind of, sort of), everything about the post makes me question it. And it's not just that Stroustrup is among the last men I'd trust about syntax design, every example in the post just feels wrong. Python walrus operator wasn't opposed by "teachers and beginners", because it's "harder to learn". Quite the opposite, it was opposed by purist old-timers, because for 20 years the abse…

Mainly I disliked the walrus operator because Python already has a keyword that means "capture the output of this clause into this variable": as.

E.g.,

    try:
        with open("file.txt") as f:
            do_something(f)
    except OSError as e:
        print(e)
And now:

    L = [abs(x) as x_abs for x in some_list if x_abs

Re: Stroustrup's Rule (2024)

#35

Post by challengerapp »

tialaramex wrote: post #14

Having observed that this is true, a good designer would see Rust's Editions and seize upon this as a useful, even necessary idea for a language intended to last for more than a few years. In 2019 P1881 "Epochs" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... was instead given the usual treatment by WG21, Vittorio was told it would be very difficult, numerous obstacles were identified and he was told…

A challenge:

In the below code snippet, that it is assumed was gotten on GitHub or a documentation site or somewhere else, you are not allowed to figure out which edition the code is meant for. You must tell, without knowing the edition, whether the code has a deadlock or not. You may not assume a specific edition.

fn f(value: &RwLock>) {

    if let Some(x) = *value.read().unwrap() {

        println!("value is {x}");

    } else {

        let mut v = value.write().unwrap();

        if v.is_none() {

            *v = Some(true);

        }

    }
}

If you are not able to, you must delete all your social media accounts and never comment on any topic related to programming languages or Rust ever again.

Re: Stroustrup's Rule (2024)

#36

Post by pjmlp »

challengerapp wrote: post #35
tialaramex wrote: post #14

Having observed that this is true, a good designer would see Rust's Editions and seize upon this as a useful, even necessary idea for a language intended to last for more than a few years. In 2019 P1881 "Epochs" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... was instead given the usual treatment by WG21, Vittorio was told it would be very difficult, numerous obstacles were identified and he was told…

A challenge: In the below code snippet, that it is assumed was gotten on GitHub or a documentation site or somewhere else, you are not allowed to figure out which edition the code is meant for. You must tell, without knowing the edition, whether the code has a deadlock or not. You may not assume a specific edition. fn f(value: &RwLock >) { if let Some(x) = *value.read().unwrap() { println!("value is {x}"); } else { l…

In my point of view, editions do not achieve much more than a plain -std=langXY, alongside clang-tidy, or equivalent depending on the compiler, or AI based tool.

Because they don't support as many language and standard library evolution scenarios, as many think they do.

Post reply on HN