10 ms·

Have there been any downsides or annoyances with that approach?

WalterBright 8y ago
1. The filename characters have to be valid D identifier characters. This annoys some people. 2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people. 3. There are command line switches to map from module names to filenames for special purposes. They're very rarely needed, but invaluable when they are. Overall, it's been very successful.
- xyproto 8y ago
  Those people are easily annoyed.
- deleted 8y ago
  [deleted]
- coldtea 8y ago
  >The filename characters have to be valid D identifier characters. This annoys some people. I'd say "valid X language identifier characters" should always be ASCII. I never understood the BS fad for unicode identifiers. Wanna allow some math symbols? Maybe. The full unicode gamut, so that you can have a variable named shit emoji? Yeah, no.
  - enedil 8y ago
    But that's not only about Unicode. You can't start your filename with digit or a dash.
    - deleted 8y ago
      [deleted]
  - ketzu 8y ago
    Valid characters are usually not the full ASCII set at all, so why not pick and chose from unicode as well? Or why not full unicode text support? Is there any real reason besides "some people might want emoji and I don't like that"?
    - SiempreViernes 8y ago
      They might use their native language too! But no, the totality of the argument always reduces to: "I'm not used to this and would find it inconvenient"
  - ZiiS 8y ago
    This stops most of the world naming things in their native language.
    - kungtotte 8y ago
      Speaking as someone who doesn't have English as their first language I think programming should be in English and ASCII. This includes identifiers and filenames. Strings on the other hand should be 100% valid Unicode, never ASCII. This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world.
      - lifthrasiir 8y ago
        > This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world. Uh, no? You are not supposed to be able to read this valid Unicode string literal in Korean: `"그뤼고 이 문좌열은 일부려 기ㅖ버역을 어럽게하러고 오타비문이 산개해 있구먼요."` Also a significant portion (and possibly the majority) of codes would be ever read and written by a small group of people, often sharing a common language other than English, so non-English code is just fine for them. If you are saying that a public library should be written in English, I almost agree---there would be some exceptions though.
        yarosv 8y ago
        Do you mean you want like C#? public class 그뤼고 { private 이 이 {get;set;} public 그뤼고() { var 문좌열은 = 이.문좌열은; var 기ㅖ버역을 = Enumerable.Range(0, 10); var 오타비문이 = 기ㅖ버역을.Select(요 => 요); } } public class 이 { public int 문좌열은 {get;set;} }
        lifthrasiir 8y ago
        Sometimes, though my example was intentionally obscured to prevent machine translation and you were not aware of Korean conjugations (usually omitted in identifiers) ;-) I have seen numerous instances of pseudo-English when it comes to naming. It is hard to name things in non-native tongues. When reasonable, reducing that overhead can be indeed beneficial.
  - Sharlin 8y ago
    That's a false dichotomy. If you were talking about restricting identifiers to codepoints in the Unicode "letter" categories, you might have a point. (Nb. there are approximately 160,000 "letter" codepoints in Unicode, the vast majority of which being CJK ideograms.)
    - WalterBright 8y ago
      D allows the same Unicode codepoints as identifier characters as does C and C++.
    - coldtea 8y ago
      No, I'm saying restricting identifiers to AZaz09_. I don't see a dichotomy (much less a false one). What are the two options I separate artificially? I'm saying just don't impose regional alphabets (other than AZaz that's already par for the course with the syntax of all major programming languages anyway) and regional words into source code.
      - Sharlin 8y ago
        You disregarded 99.99% of Unicode as "math symbols and poop emoji". That's just a ridiculously biased Anglocentric viewpoint. It's 2019; there's zero reason to force people to stick to either a subset of their native script, or a completely foreign one, when naming identifiers in a programming language.
- mort96 8y ago
  > 2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people. That's also a problem in most other languages; just a couple of days ago, someone else's C++ code didn't compile on my machine because they had accidentally included <something/whatever.h> when the file was actually named <something/Whatever.h>, because macOS is case insensitive. I had the same experience with JavaScript some months ago, that time because they were running Windows. On the "filenames must be valid identifiers" thing; I really wish more languages would start allowing kebab-case in identifiers. That's also absolutely not a D thing, more of a common complaint about most languages.
  - giornogiovanna 8y ago
    Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or adding whitespace sensitivity?
    - wtetzner 8y ago
      > adding whitespace sensitivity? Would adding whitespace sensitivity really be a problem? You already need whitespace to separate identifiers, so it's not a totally foreign concept in mainstream languages. It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.
      - phkahler 8y ago
        >> It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands. Some people don't want to bother putting a space between operators and operands, and proponents of kebab-case just don't want to push the shift key to get an underscore.
        ModernMech 8y ago
- afiori 8y ago
  > 1. The filename characters have to be valid D identifier characters. This annoys some people. this could be solved by allowing strings in qualified imports import "illegal identifier"."some more weird unicode" as someLib;
  - AnIdiotOnTheNet 8y ago
    Which, incidentally, is how Zig does it: const thing = @import("relative/path/to/thing.zig"); const package = @import("packagename");
    - gpm 8y ago
      And rust `extern crate foo` `extern crate "foo-bar" as foo_bar` This is all legal identifiers but `use std::path::Path;` `use std::path::Path as int; // For maximum confusion` And not that anyone uses this part but: `mod bazz;` `#[path = "bazz-bar.rs"] mod bazz_bar;`
kccqzy 8y ago
I haven't used D, but in Haskell we have the same module name == file name thing. The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory: import A -- compiler reads A.hs import A.B -- compiler reads A/B.hs Thus, two semantically related modules are now in different directories. Python, IMO, handles this correctly by having __init__.py support inside directories. It's theoretically less elegant because of the special name, but in practice leads to better file organization. Same for Rust, but even better, because one can define nested modules in the same file. So you can either define a new module in the same file, put it in a different file named by the module, or put it in the file `mod.rs` inside the directory named by the module.
- JoshTriplett 8y ago
  > The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory: > import A -- compiler reads A.hs > import A.B -- compiler reads A/B.hs That has to happen at some level, assuming subdirectories; otherwise, what would "import A.B.C" refer to?
- ben-schaaf 8y ago
  D also has package.d for the same effect as python. It works quite well as package is a keyword and thus can't be used as a regular module anyway.
  - p0nce 8y ago
    But package.d could lead you to overdepend on too many modules too :) it's mostly great for end applications rather than internal to libraries.
    - ben-schaaf 8y ago
      Sure, but that's not specific to package.d. See the earlier convention of all.d or d.d. That's the trade-off with having public imports. I don't see how this is related to my comment though?

1. The filename characters have to be valid D identifier characters. This annoys some people. 2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people. 3. There are command line switches to map from module names to filenames for special purposes. They're very rarely needed, but invaluable when they are. Overall, it's been very successful.

xyproto 8y ago
Those people are easily annoyed.
deleted 8y ago
[deleted]
coldtea 8y ago
>The filename characters have to be valid D identifier characters. This annoys some people. I'd say "valid X language identifier characters" should always be ASCII. I never understood the BS fad for unicode identifiers. Wanna allow some math symbols? Maybe. The full unicode gamut, so that you can have a variable named shit emoji? Yeah, no.
- enedil 8y ago
  But that's not only about Unicode. You can't start your filename with digit or a dash.
  - deleted 8y ago
    [deleted]
- ketzu 8y ago
  Valid characters are usually not the full ASCII set at all, so why not pick and chose from unicode as well? Or why not full unicode text support? Is there any real reason besides "some people might want emoji and I don't like that"?
  - SiempreViernes 8y ago
    They might use their native language too! But no, the totality of the argument always reduces to: "I'm not used to this and would find it inconvenient"
- ZiiS 8y ago
  This stops most of the world naming things in their native language.
  - kungtotte 8y ago
    Speaking as someone who doesn't have English as their first language I think programming should be in English and ASCII. This includes identifiers and filenames. Strings on the other hand should be 100% valid Unicode, never ASCII. This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world.
    - lifthrasiir 8y ago
      > This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world. Uh, no? You are not supposed to be able to read this valid Unicode string literal in Korean: `"그뤼고 이 문좌열은 일부려 기ㅖ버역을 어럽게하러고 오타비문이 산개해 있구먼요."` Also a significant portion (and possibly the majority) of codes would be ever read and written by a small group of people, often sharing a common language other than English, so non-English code is just fine for them. If you are saying that a public library should be written in English, I almost agree---there would be some exceptions though.
      - yarosv 8y ago
        Do you mean you want like C#? public class 그뤼고 { private 이 이 {get;set;} public 그뤼고() { var 문좌열은 = 이.문좌열은; var 기ㅖ버역을 = Enumerable.Range(0, 10); var 오타비문이 = 기ㅖ버역을.Select(요 => 요); } } public class 이 { public int 문좌열은 {get;set;} }
        lifthrasiir 8y ago
        Sometimes, though my example was intentionally obscured to prevent machine translation and you were not aware of Korean conjugations (usually omitted in identifiers) ;-) I have seen numerous instances of pseudo-English when it comes to naming. It is hard to name things in non-native tongues. When reasonable, reducing that overhead can be indeed beneficial.
- Sharlin 8y ago
  That's a false dichotomy. If you were talking about restricting identifiers to codepoints in the Unicode "letter" categories, you might have a point. (Nb. there are approximately 160,000 "letter" codepoints in Unicode, the vast majority of which being CJK ideograms.)
  - WalterBright 8y ago
    D allows the same Unicode codepoints as identifier characters as does C and C++.
  - coldtea 8y ago
    No, I'm saying restricting identifiers to AZaz09_. I don't see a dichotomy (much less a false one). What are the two options I separate artificially? I'm saying just don't impose regional alphabets (other than AZaz that's already par for the course with the syntax of all major programming languages anyway) and regional words into source code.
    - Sharlin 8y ago
      You disregarded 99.99% of Unicode as "math symbols and poop emoji". That's just a ridiculously biased Anglocentric viewpoint. It's 2019; there's zero reason to force people to stick to either a subset of their native script, or a completely foreign one, when naming identifiers in a programming language.
mort96 8y ago
> 2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people. That's also a problem in most other languages; just a couple of days ago, someone else's C++ code didn't compile on my machine because they had accidentally included <something/whatever.h> when the file was actually named <something/Whatever.h>, because macOS is case insensitive. I had the same experience with JavaScript some months ago, that time because they were running Windows. On the "filenames must be valid identifiers" thing; I really wish more languages would start allowing kebab-case in identifiers. That's also absolutely not a D thing, more of a common complaint about most languages.
- giornogiovanna 8y ago
  Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or adding whitespace sensitivity?
  - wtetzner 8y ago
    > adding whitespace sensitivity? Would adding whitespace sensitivity really be a problem? You already need whitespace to separate identifiers, so it's not a totally foreign concept in mainstream languages. It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.
    - phkahler 8y ago
      >> It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands. Some people don't want to bother putting a space between operators and operands, and proponents of kebab-case just don't want to push the shift key to get an underscore.
      - ModernMech 8y ago
afiori 8y ago
> 1. The filename characters have to be valid D identifier characters. This annoys some people. this could be solved by allowing strings in qualified imports import "illegal identifier"."some more weird unicode" as someLib;
- AnIdiotOnTheNet 8y ago
  Which, incidentally, is how Zig does it: const thing = @import("relative/path/to/thing.zig"); const package = @import("packagename");
  - gpm 8y ago
    And rust `extern crate foo` `extern crate "foo-bar" as foo_bar` This is all legal identifiers but `use std::path::Path;` `use std::path::Path as int; // For maximum confusion` And not that anyone uses this part but: `mod bazz;` `#[path = "bazz-bar.rs"] mod bazz_bar;`

kccqzy 8y ago

I haven't used D, but in Haskell we have the same module name == file name thing. The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory: import A -- compiler reads A.hs import A.B -- compiler reads A/B.hs Thus, two semantically related modules are now in different directories. Python, IMO, handles this correctly by having __init__.py support inside directories. It's theoretically less elegant because of the special name, but in practice leads to better file organization. Same for Rust, but even better, because one can define nested modules in the same file. So you can either define a new module in the same file, put it in a different file named by the module, or put it in the file `mod.rs` inside the directory named by the module.

JoshTriplett 8y ago
> The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory: > import A -- compiler reads A.hs > import A.B -- compiler reads A/B.hs That has to happen at some level, assuming subdirectories; otherwise, what would "import A.B.C" refer to?
ben-schaaf 8y ago
D also has package.d for the same effect as python. It works quite well as package is a keyword and thus can't be used as a regular module anyway.
- p0nce 8y ago
  But package.d could lead you to overdepend on too many modules too :) it's mostly great for end applications rather than internal to libraries.
  - ben-schaaf 8y ago
    Sure, but that's not specific to package.d. See the earlier convention of all.d or d.d. That's the trade-off with having public imports. I don't see how this is related to my comment though?