5 ms·

The other parts: Part 2: https://prog21.dadgum.com/24.html https://prog21.dadgum.com/24.html Part 3: https://prog21.dadgum.com/25.html https://prog21.dadgum.c

• sph 3y ago
  Most of the criticism outlined in his follow-up is because of the state of functional programming in 2008 when this was written: - "Not being able to re-use names for values in functions". It's not a feature of functional languages, and thankfully many these days don't suffer from this limitation (see Erlang vs Elixir for example) - "The lack of a simple dictionary type". Again, blame the terrible functional ecosystems of 2008.
  • deleted 3y ago
    [deleted]
  • taeric 3y ago
    I'm curious what you mean? How can you re=use a name in a function? I've seen this problem even in Java code.
    • asimpletune 3y ago
      It’s called variable shadowing and it’s super common in these days. The rust book introduces it in like the 2nd chapter.
      • taeric 3y ago
        Ok. Shadowing has been a thing for a very long time. If you are in languages that use block scoping, yes, you could just build a new block and call it a day. No, that isn't ergonomic, though.
        • asimpletune 3y ago
          Not all variable shadowing requires block scoping. Like I said about rust, you can literally just redeclare the variable, even one that’s not mutable. About ergonomics, I think it’s a matter of opinion. To me though it is very ergonomic. As an example, let’s say you get the users input, trim the length, and parse it as a number. Without variable shadowing you have 3 variables (like, inputResult, inputStr, inputNum) and all those variables are still accessible , potentially by accident, throughout your code. If you just have one input variable that you redefine, then you don’t have to pollute the scope with variables or think of more names and you won’t accidentally use one of the intermediate ones elsewhere. To me that’s more ergonomic.
          • taeric 3y ago
            Reading on how rust does it some. First search I'm finding is https://maxuuell.com/blog/how-not-to-shadow-variables https://maxuuell.com/blog/how-not-to-shadow-variables, which amuses me to see that you can just redeclare variables in the same scope. That feels like a footgun in itself. The rest of the footguns listed there seem about right. Is that how other languages are starting to do this? And agreed that not polluting the scope is good. That is why mutating the variable was the preferred way for a lot of folks.
          • horsawlarway 3y ago
            This is not shadowing. Or at least not any definition of variable shadowing that I've ever seen. This is just redeclaring or redefining the variable. Variable shadowing is allowing a variable of the same name as an existing variable, but within a different scope. The difference in scope is absolutely critical - because the shadowing happens within some scopes, but not within others - there are still two instances of the variable, and both values are still kept, but which one is visible depends on the scope. Basically, to quote the def - "At the level of identifiers (names, rather than variables), this is known as name masking. This outer variable is said to be shadowed by the inner variable, while the inner identifier is said to mask the outer identifier."
            • 3y ago
• taeric 3y ago
  The follow up is definitely worth reading. In particular, the section where the author notes, "Everything started to flow much more nicely when I went down the road of comical inefficiency." Computers are fast enough today that much of this inefficiency is borderline invisible to the vast majority of us. Always fun to read from perspectives that this is not a true statement.