7 ms·

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

topspin 5y ago
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
- deleted 5y ago
  [deleted]
- glouwbug 5y ago
  Canadians now roll with the term Indigenous instead of Aboriginal
  - spenczar5 5y ago
    That may be, but in this case it is a precise technical term, referring to a particular block of Unicode: https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_Syllabics_(Unicode_block) https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_... Maybe the Unicode Consortium should change it, but for now, Canadian Aboriginal is the correct term.
  - uuddlrlr 5y ago
    Colloquially in the north "native" is ubiquitous.
  - andai 5y ago
    For now...
  - LudwigNagasena 5y ago
    In 10 years a new word may become fashionable. Better to keep technical terms the same.
    - Cthulhu_ 5y ago
      It's not about fashion, it's about cultural identity. I take it you don't see a problem with master/slave either? Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.
      - earleybird 5y ago
        If identity is about appearance, that would seem to admit fashion for consideration.
      - asguy 5y ago
        I take it you didn’t grow up in the 80s. Trends in words change: you’ll see it with your own eyes. > trying to argue on the internet about it is tiring. … exactly.
- jandrese 5y ago
  That's the kind of thing you see in a comment and then back slowly out of the room, never breaking eye contact with the code until you are far enough away to turn tail and run. At the very least they could have used the cute Japanese 「quotation marks」 to avoid confusion.
  - weego 5y ago
    This is the person you need. Be assured that they were the person willing to log into the live prod server to fix that script that was killing your startups app at 2am on a Friday night in 2007 when everyone else was too gun-shy.
- killingtime74 5y ago
  Java Certified Professional
- kodah 5y ago
  > oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.
  - ithkuil 5y ago
    Bow to the One whose Name cannot be expressed in the Basic Multilingual Plane
  - jcelerier 5y ago
    > > c++ allows 0-width spaces in variable names. Is that true though ? > A valid identifier must begin with a non-digit character (Latin letter, underscore, or Unicode character of class XID_Start) and may contain non-digit characters, digits, and Unicode characters of class XID_Continue in non-initial positions. Identifiers are case-sensitive (lowercase and uppercase letters are distinct), and every character is significant. Every identifier must conform Normalization Form C.
    - therein 5y ago
      > every character is significant. Every identifier must conform Normalization Form C. This seems to be the only limitation for that to be true. So the question is does 0-width space (U+200B) survive canonical decomposition, followed by canonical composition? It feels like it does to me.
    - jeroenhd 5y ago
      I don't know about the standard, but both GCC and Clang accept ZWSP characters in the middle of variable names. Clang logs a warning about potentially invisible characters every time you use them. g++ just compiles the code without warning, even with -Wall and -Wpedantic. What clang _doesn't_ warn for, is the use of the left-to-right override character. This can be used to confuse the victims of your code even more.
  - LastMuel 5y ago
    I'm dying. This is hilarious.
- iamcreasy 5y ago
  I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
  - maattdd 5y ago
    On VSCode, I use the Gremlins extension which highlight all those suspicious characters. https://github.com/nhoizey/vscode-gremlins https://github.com/nhoizey/vscode-gremlins
  - ipmonkey 5y ago
    vim user here. Most of us are running the same linters and language servers as every other major editor, which does a pretty good job catching stuff like this. Modern vim is really only a C core with a web of JS, Python, Lua, and vimscript using the exact same third party solutions for every other part of an "IDE". emacs is probably similar, but no personal experience with that.
  - CodesInChaos 5y ago
    The rust compiler warns when it encounters confusable symbols like that. Not sure about other languages.
  - Cthulhu_ 5y ago
    It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.
    - Joker_vD 5y ago
      That's why Powershell actually recognizes those fancy quotes and treats those as normal quotes.
      - 5y ago
dagmx 5y ago
I'm actually curious if Go would normalize the characters AND if it had used angle bracketd, and make those equivalent to angle brackets? Would he then not have to even change his code? I guess that's a lot of ifs/ands but it's interesting that one could have future proofed their code if their bet on syntax paid off
- jchw 5y ago
  They're semantically different characters and Go supports multilingual identifiers, so I would not expect normalization to impact this. At most I would expect normalization to simply deal with ordering combining marks and standardizing on composed or decomposed forms of characters (where applicable.)
  - nitrogen 5y ago
    This got me curious what I'd read about domain names and visual normalization of Unicode, and found this: http://www.unicode.org/Public/security/revision-05/confusables.txt http://www.unicode.org/Public/security/revision-05/confusabl... It might be useful for editors and compilers to check for tricky Unicode (lookalikes for common characters, atypical changes in direction, invisible spaces or other formatting control codes, etc.) in this era of copy/paste coding.
    - tialaramex 5y ago
      I believe Rust will warn you if your non-ASCII identifiers are potentially confusing based on this list.
dmead 5y ago
Oh my god.
throwaway894345 5y ago
I love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”
- tambre 5y ago
  Fixed in C++23 by adoption of P1949R7 [0], which didn't originally set out to fix that, but seems to have after a Netherlands national body ballot comment. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1949r7.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p194...
- aitchnyu 5y ago
  I once read a comment like "Gives a new meaning to the term native code".
ashton314 5y ago
S̷͕͂̒c̴͉͈̆ŕ̶̘͚̄e̸̘̽̌ͅa̵̼̳͌m̷̬̓̈́͜s̴͙͆ ̸̨͓̾̈́i̴͈̼͐ņ̶̟̊̍ ̵͍̐̊Ű̸̪̤n̴̪̝̅̍i̶̜͌c̷͎̩̑̀ỏ̶̜͊d̴̟̎͠e̴̘̿ Oh gosh oh gosh zaglo variables please no
- Cthulhu_ 5y ago
  HE COMES
EdwardDiego 5y ago
It's funny how codegen has become widespread in Golang to work around its deficiency.
- Cthulhu_ 5y ago
  I've come to prefer code quantity over code complexity. I mean, what the fuck is def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) = fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)
  - Athas 5y ago
    This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'. That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this: fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None)) So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently. (If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)
    - Someone 5y ago
      scala has infix everything ‘operators’. f(x) can be written as f x and f.g(x) can be written as f g x if the parser manages to figure out what it means (I’m sure they phrase that differently) Idea, I think, is to make the repl look more like a CLI, but it also may be a fight against punctuation.
jhoechtl 5y ago
The syntax the OP gave reference to has nothing to do with how generics in Go 1.18 will look like. If you are interested in generics in Go 1.18 please read https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...

topspin 5y ago

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

deleted 5y ago
[deleted]
glouwbug 5y ago
Canadians now roll with the term Indigenous instead of Aboriginal
- spenczar5 5y ago
  That may be, but in this case it is a precise technical term, referring to a particular block of Unicode: https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_Syllabics_(Unicode_block) https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_... Maybe the Unicode Consortium should change it, but for now, Canadian Aboriginal is the correct term.
- uuddlrlr 5y ago
  Colloquially in the north "native" is ubiquitous.
- andai 5y ago
  For now...
- LudwigNagasena 5y ago
  In 10 years a new word may become fashionable. Better to keep technical terms the same.
  - Cthulhu_ 5y ago
    It's not about fashion, it's about cultural identity. I take it you don't see a problem with master/slave either? Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.
    - earleybird 5y ago
      If identity is about appearance, that would seem to admit fashion for consideration.
    - asguy 5y ago
      I take it you didn’t grow up in the 80s. Trends in words change: you’ll see it with your own eyes. > trying to argue on the internet about it is tiring. … exactly.
jandrese 5y ago
That's the kind of thing you see in a comment and then back slowly out of the room, never breaking eye contact with the code until you are far enough away to turn tail and run. At the very least they could have used the cute Japanese 「quotation marks」 to avoid confusion.
- weego 5y ago
  This is the person you need. Be assured that they were the person willing to log into the live prod server to fix that script that was killing your startups app at 2am on a Friday night in 2007 when everyone else was too gun-shy.
killingtime74 5y ago
Java Certified Professional
kodah 5y ago
> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.
- ithkuil 5y ago
  Bow to the One whose Name cannot be expressed in the Basic Multilingual Plane
- jcelerier 5y ago
  > > c++ allows 0-width spaces in variable names. Is that true though ? > A valid identifier must begin with a non-digit character (Latin letter, underscore, or Unicode character of class XID_Start) and may contain non-digit characters, digits, and Unicode characters of class XID_Continue in non-initial positions. Identifiers are case-sensitive (lowercase and uppercase letters are distinct), and every character is significant. Every identifier must conform Normalization Form C.
  - therein 5y ago
    > every character is significant. Every identifier must conform Normalization Form C. This seems to be the only limitation for that to be true. So the question is does 0-width space (U+200B) survive canonical decomposition, followed by canonical composition? It feels like it does to me.
  - jeroenhd 5y ago
    I don't know about the standard, but both GCC and Clang accept ZWSP characters in the middle of variable names. Clang logs a warning about potentially invisible characters every time you use them. g++ just compiles the code without warning, even with -Wall and -Wpedantic. What clang _doesn't_ warn for, is the use of the left-to-right override character. This can be used to confuse the victims of your code even more.
- LastMuel 5y ago
  I'm dying. This is hilarious.
iamcreasy 5y ago
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
- maattdd 5y ago
  On VSCode, I use the Gremlins extension which highlight all those suspicious characters. https://github.com/nhoizey/vscode-gremlins https://github.com/nhoizey/vscode-gremlins
- ipmonkey 5y ago
  vim user here. Most of us are running the same linters and language servers as every other major editor, which does a pretty good job catching stuff like this. Modern vim is really only a C core with a web of JS, Python, Lua, and vimscript using the exact same third party solutions for every other part of an "IDE". emacs is probably similar, but no personal experience with that.
- CodesInChaos 5y ago
  The rust compiler warns when it encounters confusable symbols like that. Not sure about other languages.
- Cthulhu_ 5y ago
  It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.
  - Joker_vD 5y ago
    That's why Powershell actually recognizes those fancy quotes and treats those as normal quotes.
    - 5y ago

dagmx 5y ago

I'm actually curious if Go would normalize the characters AND if it had used angle bracketd, and make those equivalent to angle brackets? Would he then not have to even change his code? I guess that's a lot of ifs/ands but it's interesting that one could have future proofed their code if their bet on syntax paid off

jchw 5y ago
They're semantically different characters and Go supports multilingual identifiers, so I would not expect normalization to impact this. At most I would expect normalization to simply deal with ordering combining marks and standardizing on composed or decomposed forms of characters (where applicable.)
- nitrogen 5y ago
  This got me curious what I'd read about domain names and visual normalization of Unicode, and found this: http://www.unicode.org/Public/security/revision-05/confusables.txt http://www.unicode.org/Public/security/revision-05/confusabl... It might be useful for editors and compilers to check for tricky Unicode (lookalikes for common characters, atypical changes in direction, invisible spaces or other formatting control codes, etc.) in this era of copy/paste coding.
  - tialaramex 5y ago
    I believe Rust will warn you if your non-ASCII identifiers are potentially confusing based on this list.

dmead 5y ago

Oh my god.

throwaway894345 5y ago

I love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”

tambre 5y ago
Fixed in C++23 by adoption of P1949R7 [0], which didn't originally set out to fix that, but seems to have after a Netherlands national body ballot comment. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1949r7.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p194...
aitchnyu 5y ago
I once read a comment like "Gives a new meaning to the term native code".

ashton314 5y ago

S̷͕͂̒c̴͉͈̆ŕ̶̘͚̄e̸̘̽̌ͅa̵̼̳͌m̷̬̓̈́͜s̴͙͆ ̸̨͓̾̈́i̴͈̼͐ņ̶̟̊̍ ̵͍̐̊Ű̸̪̤n̴̪̝̅̍i̶̜͌c̷͎̩̑̀ỏ̶̜͊d̴̟̎͠e̴̘̿ Oh gosh oh gosh zaglo variables please no

Cthulhu_ 5y ago
HE COMES

EdwardDiego 5y ago

It's funny how codegen has become widespread in Golang to work around its deficiency.

Cthulhu_ 5y ago
I've come to prefer code quantity over code complexity. I mean, what the fuck is def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) = fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)
- Athas 5y ago
  This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'. That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this: fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None)) So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently. (If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)
  - Someone 5y ago
    scala has infix everything ‘operators’. f(x) can be written as f x and f.g(x) can be written as f g x if the parser manages to figure out what it means (I’m sure they phrase that differently) Idea, I think, is to make the repl look more like a CLI, but it also may be a fight against punctuation.

jhoechtl 5y ago

The syntax the OP gave reference to has nothing to do with how generics in Go 1.18 will look like. If you are interested in generics in Go 1.18 please read https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...