5 ms·

They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain poin

They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain points for me with the language. I don't think the execution model you mention, which results in the absurdity of C style transitive includes polluting the global namespace, will ever be changed though.

tomstuart 4y ago
> I don't think the execution model you mention, which results in the absurdity of C style transitive includes polluting the global namespace, will ever be changed though. There is a proposal at https://bugs.ruby-lang.org/issues/19024 https://bugs.ruby-lang.org/issues/19024 to change this but, as you can see from the comments, it’s a bit tricky to get right while preserving backwards compatibility. (Whether that conversation makes you more or less optimistic about the chances of it ever being changed is up to you.)
michaelteter 4y ago
> They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain points for me with the language. Searching for a mismatched/missing _end_ is preferable to having a line or block get accidentally unindented and end up still "working" (running) while producing very confusing results. Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into. Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries. To be fair though, my vim-memory of using % to bounce between start/end brackets doesn't work in Ruby because of the begin/end words instead of matched symbols :(. However, RubyMine does show the beginning of the block as an unobtrusive popup at the top of the window when your cursor is on the _end_ keyword. That's super handy when there are several blocks closing in succession.
- p_l 4y ago
  I had over million euro of machinery stop because a rarely reached branch had one line with one less space due to missing linter run. Apparently Python 3 still doesn't fully parse and validate code on load, or somehow it made a valid if nonsense AST out of that.
  - andai 4y ago
    I know it's offtopic, but this is really a case of using spaces where tabs are the correct choice ;)
    - michaelteter 4y ago
      Perhaps, but should _that_ choice (or more likely, misconfiguration of a system) be so dangerous?
    - p_l 4y ago
      Unfortunately, Python (and YAML, though it wasn't YAML this time) specifies spaces as the syntactically critical element.
  - mypalmike 4y ago
    Sure, Python has a variation of the same problem.
- dragonwriter 4y ago
  > Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into. Even when I was new to python, the only problem I ever really had with this is when I mess up and copy the first line starting at the the first nonwhitespace character so the relative indentation is wrong. When do you ever move a block and not know what scope you want it in? At most, with really long blocks, you fold the more deeply nested blocks before pasting. > Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries. No, it doesn’t. In practice, editors usually don’t, but they recognize the beginning and ending of blocks, and use it for folding, which means they could insert phantom labels (as editors often use for blame information, inferred type signatures, etc.) to provide informatiom about the block ending (and even align them to indicate the indentation level corresponding to each ending block.) An existing line of text is not necessary for editors to provide feedback.
- bhaak 4y ago
  > To be fair though, my vim-memory of using % to bounce between start/end brackets doesn't work in Ruby because of the begin/end words instead of matched symbols :( Put "runtime macros/matchit.vim" into your .vimrc. Or for even better support add the matchup plugin. https://github.com/andymass/vim-matchup https://github.com/andymass/vim-matchup
  - mypalmike 4y ago
    I'm not a vim user, but I think the problem with Ruby here is that it's not begin/end. It's anything that evaluates to an iterable/end.
    - bhaak 4y ago
      Yes, that's the problem for plain vi(m) which only supports single character braces. matchit/matchup extends this to language specific delimiter words. This animation https://github.com/andymass/vim-matchup#screenshot https://github.com/andymass/vim-matchup#screenshot shows how you can iterate over multiple sequences like if/elsif/else/endif.
- mypalmike 4y ago
  Yeah indentation in Python can be problematic - I've run into problems from time to time. The issue with Ruby specifically (which doesn't exist in other common languages that have bracket- or keyword-delimited blocks) is that non-keywords can start blocks. So it's difficult for an editor to determine the likely matches, and it's even harder for a human. That's my vague recollection of the problem that I ran into numerous times, though it was about a decade ago.
michaelcampbell 4y ago
> serious pain points This suprises me. I've missed `end`s before as much as anyone, but I guess as an OCD reformatter (prettier, IntelliJ, rubocop, etc.), they show up VERY OBVIOUSLY and right quick. They've never even been an itch, much less "pain".

tomstuart 4y ago

> I don't think the execution model you mention, which results in the absurdity of C style transitive includes polluting the global namespace, will ever be changed though. There is a proposal at https://bugs.ruby-lang.org/issues/19024 https://bugs.ruby-lang.org/issues/19024 to change this but, as you can see from the comments, it’s a bit tricky to get right while preserving backwards compatibility. (Whether that conversation makes you more or less optimistic about the chances of it ever being changed is up to you.)

michaelteter 4y ago

> They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain points for me with the language. Searching for a mismatched/missing _end_ is preferable to having a line or block get accidentally unindented and end up still "working" (running) while producing very confusing results. Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into. Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries. To be fair though, my vim-memory of using % to bounce between start/end brackets doesn't work in Ruby because of the begin/end words instead of matched symbols :(. However, RubyMine does show the beginning of the block as an unobtrusive popup at the top of the window when your cursor is on the _end_ keyword. That's super handy when there are several blocks closing in succession.

p_l 4y ago
I had over million euro of machinery stop because a rarely reached branch had one line with one less space due to missing linter run. Apparently Python 3 still doesn't fully parse and validate code on load, or somehow it made a valid if nonsense AST out of that.
- andai 4y ago
  I know it's offtopic, but this is really a case of using spaces where tabs are the correct choice ;)
  - michaelteter 4y ago
    Perhaps, but should _that_ choice (or more likely, misconfiguration of a system) be so dangerous?
  - p_l 4y ago
    Unfortunately, Python (and YAML, though it wasn't YAML this time) specifies spaces as the syntactically critical element.
- mypalmike 4y ago
  Sure, Python has a variation of the same problem.
dragonwriter 4y ago
> Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into. Even when I was new to python, the only problem I ever really had with this is when I mess up and copy the first line starting at the the first nonwhitespace character so the relative indentation is wrong. When do you ever move a block and not know what scope you want it in? At most, with really long blocks, you fold the more deeply nested blocks before pasting. > Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries. No, it doesn’t. In practice, editors usually don’t, but they recognize the beginning and ending of blocks, and use it for folding, which means they could insert phantom labels (as editors often use for blame information, inferred type signatures, etc.) to provide informatiom about the block ending (and even align them to indicate the indentation level corresponding to each ending block.) An existing line of text is not necessary for editors to provide feedback.
bhaak 4y ago
> To be fair though, my vim-memory of using % to bounce between start/end brackets doesn't work in Ruby because of the begin/end words instead of matched symbols :( Put "runtime macros/matchit.vim" into your .vimrc. Or for even better support add the matchup plugin. https://github.com/andymass/vim-matchup https://github.com/andymass/vim-matchup
- mypalmike 4y ago
  I'm not a vim user, but I think the problem with Ruby here is that it's not begin/end. It's anything that evaluates to an iterable/end.
  - bhaak 4y ago
    Yes, that's the problem for plain vi(m) which only supports single character braces. matchit/matchup extends this to language specific delimiter words. This animation https://github.com/andymass/vim-matchup#screenshot https://github.com/andymass/vim-matchup#screenshot shows how you can iterate over multiple sequences like if/elsif/else/endif.
mypalmike 4y ago
Yeah indentation in Python can be problematic - I've run into problems from time to time. The issue with Ruby specifically (which doesn't exist in other common languages that have bracket- or keyword-delimited blocks) is that non-keywords can start blocks. So it's difficult for an editor to determine the likely matches, and it's even harder for a human. That's my vague recollection of the problem that I ran into numerous times, though it was about a decade ago.

michaelcampbell 4y ago

> serious pain points This suprises me. I've missed `end`s before as much as anyone, but I guess as an OCD reformatter (prettier, IntelliJ, rubocop, etc.), they show up VERY OBVIOUSLY and right quick. They've never even been an itch, much less "pain".