3 ms·

yeah! That's exactly how I think of it.

• coldtea 9y ago
  Significant whitespace has some real benefits (enforcing proper indentation, no lines wasted for "}" or "end", etc) too. Case insensitive and _ ignoring identifiers not so much -- they just add mental burden, encourage different styles in the same codebase, make things ungreppable without special tools, etc. And for what? If the best one can say about a feature is "people still like the language despite it", it might be better to axe it.
  • apotheon 9y ago
    Significant indentation comes with trade-offs -- real benefits, and real detriments. I agree it's entirely understandable that a language designer would include significant indentation, such as Python's use of the off-side rule (even though I don't like it in Python). Labels (e.g. variable names) coming with style insensitivity is indeed weird, and likely to be far more off-putting for many than significant indentation, though both put together will likely have even more of a negative effect on adoption, in my estimation. I can imagine benefits to the style insensitivity, but I think those benefits could be had without a style insensitivity, and they come with trade-offs as well when you use style insensitivity to get those benefits (for instance, some typos could be ignored altogether by the parser, but cause the human eye to miss them or cause codebase searches to fail to find all instances of a label when using tools external to the language's implementation itself). I think some of the benefits of style insensitivity are worthwhile, though, and should be pursued (by other means, preferably). For example, a language feature that allows one to define (with a single line of code, perhaps a pragma declaration) a standard for label formatting could be used to make library functions conform to your project's code style standards would be a much more palatable solution to the problem of alien code looking alien than style insensitivity, in my opinion. I think a (Proposed? In development?) feature of Nim -- syntax "skins" -- might offer exactly that, and it could result in effectively being able to turn off style insensitivity in your projects. If so, I would expect that to become the standard way to handle code style in Nim projects.
    • nimmer 9y ago
      A code formatter/linter (similar to gofmt) would do the trick and prevent ambiguity.
  • dom96 9y ago
    > encourage different styles in the same codebase Actually, case sensitive identifiers encourage this. If a library uses camelCase but your code base uses snake_case then you will be using a mix of camelCase and snake_case in order to use that library. That is a real benefit and is entirely the point of this feature.
    • PMunch 9y ago
      This. I can't count the number of times I've used two libraries with different casing just to have my own code end up as a mess of both.. I can see the point though that grepping, and things like editors which highlight the selected variable would have to take these rules into consideration. It's a valid concern but I feel the benefit of clean unified code is more important.
      • coldtea 9y ago
        >This. I can't count the number of times I've used two libraries with different casing just to have my own code end up as a mess of both.. Whereas referencing the exported identifiers from the library with a different style than they are written with in the library's code sounds more satisfactory to you?
        • PMunch 9y ago
          Yes, that way my code looks more like one entity than a mess of different things. I can see why you are skeptical of it but once you've used it for a while it becomes second nature. And you can always mix if you want to. The thing is that you can choose how you want to do it. And there are extremely few cases where the casing actually makes the identifiers different (keeping it mind that the first character is type sensitive).
    • deleted 9y ago
      [deleted]
    • coldtea 9y ago
      >Actually, case sensitive identifiers encourage this. If a library uses camelCase but your code base uses snake_case then you will be using a mix of camelCase and snake_case in order to use that library. Which will be totally fine, as it involves different variables / things pointed at. Whereas the "case/underscore insensitive" qualifiers lets you have 10 different versions of the same variable name, in the same codebase -- even without using any third party "library". Besides, the problem of "third party library uses a different style" is easily solved by having a tool like go fmt that enforces a unique single style. End of story.