3 ms·

Simplicity is about the cognitive overhead to understand code, the simpler it is the less effort it requires to reason about. That doesn't mean you don't have

Simplicity is about the cognitive overhead to understand code, the simpler it is the less effort it requires to reason about. That doesn't mean you don't have to learn anything to understand it. Going the easy route usually means dumbing down things and while it can help reading in the moment it definitely doesn't help in the long run as the code evolve over time.

dbcurtis 9y ago
I agree. Idiom plays a huge role. Example: Python list and dictionary comprehensions can often make the result clear much more easily and succictly than the equivalent loop. But you have to learn Python comprehensions, and the common idioms. And it is possible to take it too far, and write an overly-complicated and obtuse comprehension that is difficult to reason about. The goal should be code that is easy to reason about, given a reader that is familiar with the popular idioms. I think that for most languages, thoughtfully chosing good names and writing idiomatic code goes a long way to reducing the cognitive load in reasoning about code. I also find that Python's syntax helps readabilty, and that also decreases cognitive load. Over the holidays I spent some quality time reading up on Rust and starting to climb the learning curve. I'm still at the stage that I find Rust's syntax jarring. It looks like so much ASCII salad. I can't help but think that a little more attention paid to natural syntactic flow would make Rust code easier to reason about for the long haul. Of course, I'm only at the beginning stages of learning Rust idioms -- a fair analaysis can only be done after I have learned them well. But still, it looks like Rust values screen real estate over readabilty, which is a misguided optimization IMHO.
- steveklabnik 9y ago
  We chose a lot of Rust's syntax to be familiar to those who use "curly brace and semicolon" languages, and some stuff from functional languages. It's not really about brevity.
  - dbcurtis 9y ago
    Fair enough. I get twitchy-semicolon-pinky when I switch back and forth between Python and C. I have much sympathy for Python core devs... I don't really do C++ because most of my C is embedded real-time, so dynamic data structures are not a thing, out of an abundance of conservatism. If I did C++, I'm sure I'd find Rust less jarring. My excitement about Rust is mainly the potential for using Rust for embedded real time -- but I see microcontrollers are still 3rd tier support. It seems like Rust the language is directed at exactly that problem, but Rust's build system and overall ecosystem are not embedded-aware, unless there is plan for xargo to get tier 1 support? So... this isn't the thread for it but I have to ask... the only Rust reference I've seen to list/hash comprehensions is somebody who did a macro. So... is that the idiomatic way to do a list comprehension in Rust? Or is Rust going to make comprehensions first-class syntax? It seems to me that if it can be done in a macro, it isn't a big leap to make it part of the language.
    - steveklabnik 9y ago
      The plan is still to "unfork" xargo, that is, to put its functionality in Cargo. We'll see how long that takes. Many people are advocating for 2018 to be focused on embedded in some way, so we'll see! I'd imagine most people reach for iterators when it comes to list comprehensions. If the crate gets popular enough, there might be a thing, but I don't even know the name of the crate you're talking about, so I don't think it is.
      - dbcurtis 9y ago
        Pulling xargo functionality back into tier 1 mainline would be an excellent piece of enabling infrastructure for all embedded work. I think a challenge with embedded is that the platform landscape is highly fragmented. I would advocate for picking one target CPU and making it tier 2, let the rest stay at tier 3. Pick one that has a cheap development board to use as a reference platform. Don't even try to test everything in the cpu/platform matrix -- just pick one to be the pilot, and the rest will benefit from at least having that one big snowplow clear the road in front. My specific suggestion would be an Arm Cortex-M4 with hard float of some flavor. That clears the road ahead for a lot of hardware of general interest. ST has quite a few easily available dev boards at reasonable prices, but that is just what I am most familiar with -- there are certainly others. I am also a big fan of Micropython, and the reference board for that is the Pyboard, which might be a good inexpensive choice also, not to mention a good way to spread the open source and open hardware love. It would be easy and reliable to flash a Pyboard back and forth between Micropython or some Rust-on-bare-metal image, I would personally be a fan (that's only one data point, but it's mine :)
- wtetzner 9y ago
  > But still, it looks like Rust values screen real estate over readabilty, which is a misguided optimization IMHO. If that were true, I suspect it would look a lot more like ML and a lot less like C.

dbcurtis 9y ago

I agree. Idiom plays a huge role. Example: Python list and dictionary comprehensions can often make the result clear much more easily and succictly than the equivalent loop. But you have to learn Python comprehensions, and the common idioms. And it is possible to take it too far, and write an overly-complicated and obtuse comprehension that is difficult to reason about. The goal should be code that is easy to reason about, given a reader that is familiar with the popular idioms. I think that for most languages, thoughtfully chosing good names and writing idiomatic code goes a long way to reducing the cognitive load in reasoning about code. I also find that Python's syntax helps readabilty, and that also decreases cognitive load. Over the holidays I spent some quality time reading up on Rust and starting to climb the learning curve. I'm still at the stage that I find Rust's syntax jarring. It looks like so much ASCII salad. I can't help but think that a little more attention paid to natural syntactic flow would make Rust code easier to reason about for the long haul. Of course, I'm only at the beginning stages of learning Rust idioms -- a fair analaysis can only be done after I have learned them well. But still, it looks like Rust values screen real estate over readabilty, which is a misguided optimization IMHO.

steveklabnik 9y ago
We chose a lot of Rust's syntax to be familiar to those who use "curly brace and semicolon" languages, and some stuff from functional languages. It's not really about brevity.
- dbcurtis 9y ago
  Fair enough. I get twitchy-semicolon-pinky when I switch back and forth between Python and C. I have much sympathy for Python core devs... I don't really do C++ because most of my C is embedded real-time, so dynamic data structures are not a thing, out of an abundance of conservatism. If I did C++, I'm sure I'd find Rust less jarring. My excitement about Rust is mainly the potential for using Rust for embedded real time -- but I see microcontrollers are still 3rd tier support. It seems like Rust the language is directed at exactly that problem, but Rust's build system and overall ecosystem are not embedded-aware, unless there is plan for xargo to get tier 1 support? So... this isn't the thread for it but I have to ask... the only Rust reference I've seen to list/hash comprehensions is somebody who did a macro. So... is that the idiomatic way to do a list comprehension in Rust? Or is Rust going to make comprehensions first-class syntax? It seems to me that if it can be done in a macro, it isn't a big leap to make it part of the language.
  - steveklabnik 9y ago
    The plan is still to "unfork" xargo, that is, to put its functionality in Cargo. We'll see how long that takes. Many people are advocating for 2018 to be focused on embedded in some way, so we'll see! I'd imagine most people reach for iterators when it comes to list comprehensions. If the crate gets popular enough, there might be a thing, but I don't even know the name of the crate you're talking about, so I don't think it is.
    - dbcurtis 9y ago
      Pulling xargo functionality back into tier 1 mainline would be an excellent piece of enabling infrastructure for all embedded work. I think a challenge with embedded is that the platform landscape is highly fragmented. I would advocate for picking one target CPU and making it tier 2, let the rest stay at tier 3. Pick one that has a cheap development board to use as a reference platform. Don't even try to test everything in the cpu/platform matrix -- just pick one to be the pilot, and the rest will benefit from at least having that one big snowplow clear the road in front. My specific suggestion would be an Arm Cortex-M4 with hard float of some flavor. That clears the road ahead for a lot of hardware of general interest. ST has quite a few easily available dev boards at reasonable prices, but that is just what I am most familiar with -- there are certainly others. I am also a big fan of Micropython, and the reference board for that is the Pyboard, which might be a good inexpensive choice also, not to mention a good way to spread the open source and open hardware love. It would be easy and reliable to flash a Pyboard back and forth between Micropython or some Rust-on-bare-metal image, I would personally be a fan (that's only one data point, but it's mine :)
wtetzner 9y ago
> But still, it looks like Rust values screen real estate over readabilty, which is a misguided optimization IMHO. If that were true, I suspect it would look a lot more like ML and a lot less like C.