5 ms·

Obviously some will find this a silly opinion but the one thing that turned me off the most about the Nim programming language was its use of significant whites

Obviously some will find this a silly opinion but the one thing that turned me off the most about the Nim programming language was its use of significant whitespace. The same is true with F# (and of course Python). Having had apps with YAML for config, and having had nightmares trying to copy/paste config directives from various sources, I just find whitespace to be unwieldy. Now that's a strong opinion, (weakly held - as a language can't be judged based on this design decision). But it does sour my interest a bit.

scotty79 1y ago
I'm automatically going to be interested in any language with significant white space because there are very few mainstream ones and I hate the visual clutter that block delimiters create. Pretty much there's just Python. Scala 3 can happily do both. I think we'd be better off if text editors just had option of representing braces and such as consistent indentation. Block delimiting tokens should optionally have semantics of non directly printable characters like new line or tab.
- pklausler 1y ago
  You'd love Haskell, which uses curly braces for many constructs, but also has rules by which they are implied by indentation -- so in practice you only ever see them on records.
  - scotty79 1y ago
    I'm not sure. The semantics is too wild to care about indentation or delimiters. I love Scala 3 though. Very rich and flexible language.
  - recursivecaveat 1y ago
    I love python syntax overall, absolutely despise Haskell. Wastes my time constantly and gives me incomprehensible compiler errors when you screw it up. Expression oriented languages are really poorly suited for whitespace imo, unless they're hyper-regular like s-expressions: I could imagine a decent whitespace-based version of those.
- baranul 1y ago
  A language that can do both Python and C "styles" is Ring. It is possible. But the issue is people have such a strong preference for one or the other, that they force the language and developers to permanently choose. Even Allman versus K&R or tabs versus spaces are huge battles, without even going into significant white space.
FredPret 1y ago
YAML has given me eye-twitching ever since I went on an ill-considered quest of setting up wifi on a Debian server years ago. I never figured it out by the way - just bought a really long LAN cable.
- nobleach 1y ago
  YAML with Go templating (like you'd find in Helm Charts) was enough to push me over the edge.
  - tzot 1y ago
    Was there any reason not to use flow collection style, which would free the templates from significant whitespace?
bobbylarrybobby 1y ago
Never understood how putting up roadblocks for developers trying to copy-paste code was deemed acceptable, or GVR (and others) thought the solution to poorly formatted code was making formatting carry semantics instead of just writing an auto formatter.
- Night_Thastus 1y ago
  I agree. Autoformatters are everywhere and easy to use. I'd far rather do that (plus maybe a pre-commit hook) than have to deal with whitespace in the language.
- adiabatty 1y ago
  To be fair to GvR, autoformatters weren’t commonplace in the late 80s and early 90s. Were there even any? Ever since Go got big, though, everyone else is discovering how fantastically nice they are, and that’s a good thing.
  - mdasen 1y ago
    Yea, in the 90s significant whitespace seemed great because it meant that you got readable code. The amount of code that you might see copy/pasted with terrible formatting/indentation in other languages could make you want to scream. Now, when you paste code and things are wrong, an auto formatter cleans it up for you. Before, you'd just end up with an unreadable codebase. It's definitely an odd choice to make now.
  - cb321 1y ago
    GNU indent was already at version 1.9.1 by 1994: https://ftp.gnu.org/gnu/indent/ https://ftp.gnu.org/gnu/indent/ If you grab that version and unpack it and look at /OChangelog then it seems to date back until at least 1989, same as Python itself. That was for C source, of course. I expect there were pre-GNU indent variants, perhaps posted on comp.sources.unix and maybe some commercial things as part of very expensive compiler packages. I would say that running autoformatters in any kind of routine way was pretty rare. EDIT: but I think ascribing the language design to commonality or not is probably ahistorical. Even today it's a rather passionate debate. And even at the time, Lisp - the poster child of copy-paste friendly PLangs - was routinely autoformatted within Emacs', but that was not enough for people to not find Lisp code "ugly".
nialv7 1y ago
Was coming here to comment the exactly same thing. Significant indentation makes me shudder.
yoyohello13 1y ago
I get everyone has their thing, but I've been writing Python professionally for years and I can't even remember the last time significant white space was an issue. You just get used to it, like everything else.
tzot 1y ago
> Having had apps with YAML for config, and having had nightmares trying to copy/paste config directives from various sources, I just find whitespace to be unwieldy. Convert your YaML into JSON and save it in your YaML file. There is probably an online converter, but writing one in your language of choice should be less than ten lines of code. Do the same YaML→JSON for the “source” configuration you want to copy from, and copy-paste the parts you want. Leave them as JSON. Complaining about Python's significant whitespace, I get it. I don't mind it personally, but it's obligatory and you can't overcome it (unless you do `coding: with_braces` tricks, of course). But why one would complain about YaML's whitespace? It is not obligatory. some_key: attr1: val1 attr2: 12312 is equivalent to {some_key: {attr1: val1, attr2: 12312}} is equivalent to {"some_key": {"attr1": "val1", "attr2": 12312}} is equivalent to {"some_key": { "attr1": "val1", "attr2": 12312 } } and they're all valid YaML (and on the plus side you can leave dangling commas at the end of sequences, but it won't be valid JSON anymore).
- esrauch 1y ago
  > But why one would complain about YaML's whitespace? It is not obligatory. The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation. It's not a problem that the format "at rest" has whatever certain indentation to be correct, its that while being actively editing your formatter cannot automatically set the correct indentation. The flow that you're talking about of converting yaml to json and then putting it into yaml could work in some cases but thats very much a kludge. It will have numerous bad side effects unavoidable, including that it would discard comments in the middle since JSON doesn't allow for comments at all, theres no timestamps in JSON, there's no octal numbers, etc.
  - tzot 1y ago
    > The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation. That problem I undestand, and that is why I suggested to convert both into JSON —or YaML with default_flow_style=True which would preserve datetimes and other non-JSON stuff— and copy-paste without the hassle of having to indent/unindent correctly. Of course that doesn't help with copying comments. That would need extra copy-paste operations, but still one hasn't the hassle of significant whitespace. The following is also valid YaML: {"some_key": { "attr1": # an intermittent comment "val1", "attr2": 12312 # more comments! } }
deleted 1y ago
[deleted]
harikb 1y ago
+1 white space significance brings back whole tab vs space preferences and make it much harder for automatic re-formatting as well

scotty79 1y ago

I'm automatically going to be interested in any language with significant white space because there are very few mainstream ones and I hate the visual clutter that block delimiters create. Pretty much there's just Python. Scala 3 can happily do both. I think we'd be better off if text editors just had option of representing braces and such as consistent indentation. Block delimiting tokens should optionally have semantics of non directly printable characters like new line or tab.

pklausler 1y ago
You'd love Haskell, which uses curly braces for many constructs, but also has rules by which they are implied by indentation -- so in practice you only ever see them on records.
- scotty79 1y ago
  I'm not sure. The semantics is too wild to care about indentation or delimiters. I love Scala 3 though. Very rich and flexible language.
- recursivecaveat 1y ago
  I love python syntax overall, absolutely despise Haskell. Wastes my time constantly and gives me incomprehensible compiler errors when you screw it up. Expression oriented languages are really poorly suited for whitespace imo, unless they're hyper-regular like s-expressions: I could imagine a decent whitespace-based version of those.
baranul 1y ago
A language that can do both Python and C "styles" is Ring. It is possible. But the issue is people have such a strong preference for one or the other, that they force the language and developers to permanently choose. Even Allman versus K&R or tabs versus spaces are huge battles, without even going into significant white space.

FredPret 1y ago

YAML has given me eye-twitching ever since I went on an ill-considered quest of setting up wifi on a Debian server years ago. I never figured it out by the way - just bought a really long LAN cable.

nobleach 1y ago
YAML with Go templating (like you'd find in Helm Charts) was enough to push me over the edge.
- tzot 1y ago
  Was there any reason not to use flow collection style, which would free the templates from significant whitespace?

bobbylarrybobby 1y ago

Never understood how putting up roadblocks for developers trying to copy-paste code was deemed acceptable, or GVR (and others) thought the solution to poorly formatted code was making formatting carry semantics instead of just writing an auto formatter.

Night_Thastus 1y ago
I agree. Autoformatters are everywhere and easy to use. I'd far rather do that (plus maybe a pre-commit hook) than have to deal with whitespace in the language.
adiabatty 1y ago
To be fair to GvR, autoformatters weren’t commonplace in the late 80s and early 90s. Were there even any? Ever since Go got big, though, everyone else is discovering how fantastically nice they are, and that’s a good thing.
- mdasen 1y ago
  Yea, in the 90s significant whitespace seemed great because it meant that you got readable code. The amount of code that you might see copy/pasted with terrible formatting/indentation in other languages could make you want to scream. Now, when you paste code and things are wrong, an auto formatter cleans it up for you. Before, you'd just end up with an unreadable codebase. It's definitely an odd choice to make now.
- cb321 1y ago
  GNU indent was already at version 1.9.1 by 1994: https://ftp.gnu.org/gnu/indent/ https://ftp.gnu.org/gnu/indent/ If you grab that version and unpack it and look at /OChangelog then it seems to date back until at least 1989, same as Python itself. That was for C source, of course. I expect there were pre-GNU indent variants, perhaps posted on comp.sources.unix and maybe some commercial things as part of very expensive compiler packages. I would say that running autoformatters in any kind of routine way was pretty rare. EDIT: but I think ascribing the language design to commonality or not is probably ahistorical. Even today it's a rather passionate debate. And even at the time, Lisp - the poster child of copy-paste friendly PLangs - was routinely autoformatted within Emacs', but that was not enough for people to not find Lisp code "ugly".

nialv7 1y ago

Was coming here to comment the exactly same thing. Significant indentation makes me shudder.

yoyohello13 1y ago

I get everyone has their thing, but I've been writing Python professionally for years and I can't even remember the last time significant white space was an issue. You just get used to it, like everything else.

tzot 1y ago

> Having had apps with YAML for config, and having had nightmares trying to copy/paste config directives from various sources, I just find whitespace to be unwieldy. Convert your YaML into JSON and save it in your YaML file. There is probably an online converter, but writing one in your language of choice should be less than ten lines of code. Do the same YaML→JSON for the “source” configuration you want to copy from, and copy-paste the parts you want. Leave them as JSON. Complaining about Python's significant whitespace, I get it. I don't mind it personally, but it's obligatory and you can't overcome it (unless you do `coding: with_braces` tricks, of course). But why one would complain about YaML's whitespace? It is not obligatory. some_key: attr1: val1 attr2: 12312 is equivalent to {some_key: {attr1: val1, attr2: 12312}} is equivalent to {"some_key": {"attr1": "val1", "attr2": 12312}} is equivalent to {"some_key": { "attr1": "val1", "attr2": 12312 } } and they're all valid YaML (and on the plus side you can leave dangling commas at the end of sequences, but it won't be valid JSON anymore).

esrauch 1y ago
> But why one would complain about YaML's whitespace? It is not obligatory. The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation. It's not a problem that the format "at rest" has whatever certain indentation to be correct, its that while being actively editing your formatter cannot automatically set the correct indentation. The flow that you're talking about of converting yaml to json and then putting it into yaml could work in some cases but thats very much a kludge. It will have numerous bad side effects unavoidable, including that it would discard comments in the middle since JSON doesn't allow for comments at all, theres no timestamps in JSON, there's no octal numbers, etc.
- tzot 1y ago
  > The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation. That problem I undestand, and that is why I suggested to convert both into JSON —or YaML with default_flow_style=True which would preserve datetimes and other non-JSON stuff— and copy-paste without the hassle of having to indent/unindent correctly. Of course that doesn't help with copying comments. That would need extra copy-paste operations, but still one hasn't the hassle of significant whitespace. The following is also valid YaML: {"some_key": { "attr1": # an intermittent comment "val1", "attr2": 12312 # more comments! } }

deleted 1y ago

[deleted]

harikb 1y ago

+1 white space significance brings back whole tab vs space preferences and make it much harder for automatic re-formatting as well