|
eschaton posted:the downside of string interpolation is that it's harder to localize it's no harder than string concatenation the only reasonable localization apis end up being of the form getLocalizedString("there are %d butts", nButts)
|
#
?
Mar 6, 2016 01:25
|
|
|
|
| # ? May 12, 2024 06:17 |
|
|
the "problem" is mostly just that string formatting is usually more readable than string concatenation, so when those are your only options, even people that don't give the slightest gently caress about localization are usually happy with converting everything to use string formatting, but when you ask them to give up string interpolation there'll be a bunch of grumbling and unhappiness
|
|
#
?
Mar 6, 2016 01:45
|
|
|
just require your users to learn english imho, they'll thank you for it later
|
|
#
?
Mar 6, 2016 02:12
|
|
|
eschaton posted:Lisp gets this even more right than Haskell by just always using prefix notation the loop macro is a perfect example of why macros are dangerous
|
|
#
?
Mar 6, 2016 02:43
|
|
|
Soricidus posted:just require your users to learn english imho, they'll thank you for it later shaggar alt spotted
|
|
#
?
Mar 6, 2016 02:56
|
|
|
i've literally shipped non-localized software to a customer where half the people didn't speak english, on the basis that the guy who knew english could tell the others what to click when they were happy with this as an alternative to paying for localization
|
|
#
?
Mar 6, 2016 03:16
|
|
|
operators should only describe basic mathematic operations everything else should be String.concat(a, b) or a.concat(b) or w/e because gently caress, if + means concat, what else does it mean? where's that defined? and the answer is invariably line 13433 of a utils lib that's in every project and takes hours to hunt down programmers like to think they're clever but 90% of them are dumbshit fuckwads who don't understand that the cleverest thing is to say what you mean and mean what you say. verbosity should be encouraged because the opposite is expensive when onboarding or maintaining code
|
|
#
?
Mar 6, 2016 04:24
|
|
|
Other examples of appropriate operator overloading include smart pointers overloading operator-> and operator*, and container classes overloading operator[] (although the latter does have the occasional slightly-dumb design decision, like of C++'s std::map's operator []).
|
|
#
?
Mar 6, 2016 04:36
|
|
|
Soricidus posted:just require your users to learn english imho, they'll thank you for it later hackbunny posted:shaggar alt spotted
|
|
#
?
Mar 6, 2016 05:17
|
|
|
Soricidus posted:just require your users to learn english imho, they'll thank you for it later
|
|
#
?
Mar 6, 2016 06:32
|
|
|
some people don't get that '+' means something the way 'Add' means something, so you get dumb poo poo like 'shift standard output left by "hello world" bits', and 'divide pathA by pathB' so for each library you get to learn dumb mnemonics like "* looks kind of like a hub", or "@<@ points to the indexing we want to preserve" because the author sees the operators as a smorgasbord you just randomly assign based on loose visual associations without caring about semantics without custom operators you get "we overloaded +,-,*,/,%,&,| as shorthand for the methods on this car class" and in haskell you get "we named the operator *-~ to not conflict with *-, **, *~ or *-* from other libraries"
|
|
#
?
Mar 6, 2016 15:14
|
|
|
what language is this and what does it do? 3==D ~o
|
|
#
?
Mar 6, 2016 15:59
|
|
|
hmm, looks like APL. Probably conway's game of life
|
|
#
?
Mar 6, 2016 16:02
|
|
|
i only use languages that permit the use of U+42069 ERECT PENIS as an infix operator
|
|
#
?
Mar 6, 2016 16:10
|
|
|
Soricidus posted:i only use languages that permit the use of U+42069 ERECT PENIS as an infix operator ꑕ YI SYLLABLE NYOT Yi, also known as Lolo, is the Sino-Tibetan language used by aboriginal people of south-west China.
|
|
#
?
Mar 6, 2016 18:05
|
|
|
suffix posted:some people don't get that '+' means something the way 'Add' means something, so you get dumb poo poo like 'shift standard output left by "hello world" bits', and 'divide pathA by pathB'
|
|
#
?
Mar 6, 2016 18:09
|
|
|
I kind of always liked how lisps could never have operator overloading debates because they are the same poo poo as functions and there's no precedence rules to get all angry about.
|
|
#
?
Mar 6, 2016 18:28
|
|
|
MononcQc posted:I kind of always liked how lisps could never have operator overloading debates because they are the same poo poo as functions and there's no precedence rules to get all angry about. nobody is tempted to do anything stupid with lisp naming. you would never see anyone seriously suggest @**@ as a lisp function name. there's something special about infix notation that makes people go bonkers
|
|
#
?
Mar 6, 2016 18:42
|
|
|
suffix posted:some people don't get that '+' means something the way 'Add' means something, so you get dumb poo poo like 'shift standard output left by "hello world" bits', and 'divide pathA by pathB' I actually think that both of those are pretty decent uses of operator overloading. Both significantly reduce line noise when used multiple times in a single line (which is a common thing to do for both), and there is little chance for confusion with the original operator because (as you pointed out), bit shifts and division are semantically meaningless when applied to streams and paths. The cost you pay for this is that you have to learn what the operator does. In the case of using '/' as a path separator, this is immediately obvious, and literally every C++ tutorial covers using ">>" and "<<" for cout and cin so people aren't likely to be too confused by their use for other streams. It seems like maybe your objection is that the same symbol is being used to mean drastically different things within the same language (and sorry for arguing with a straw man if that was not your objection), but I don't really buy that argument because that is incredibly common in programming (unary vs. binary -, *, and &), in math (the center dot means can mean scalar multiplication, the dot product, the group operation, the convolution of functions, and probably way more), and in everyday life (# can mean "number". "pound", or "hashtag"). This is no undue burden in those other cases, so why should it stop us from cleaning up line noise in our programs?
|
|
#
?
Mar 6, 2016 21:38
|
|
|
the main problem with operator overloading is that people who use it tend to be the type who like to write clever-looking programs, and these are the worst kind of people
|
|
#
?
Mar 6, 2016 23:22
|
|
|
VikingofRock posted:It seems like maybe your objection is that the same symbol is being used to mean drastically different things within the same language that is exactly my objection you wouldn't call a method to write to a stream "shiftRight", and you wouldn't call a method that shifts bits in an integer "write", so why do people think it's okay that they share a name just because the name looks like line noise? im not against operator overloading in principle, but you should have only a few operators, with a consistent definition, so every time a programmer encounters it it has the same semantic meaning e.g. if you want a short syntax to join paths, don't use the division operator, use your concatenation operator that also concatenates strings, lists and arrays
|
|
#
?
Mar 6, 2016 23:42
|
|
|
if anything c++ should drop the bit-shifting versions of << and >> because it's really not an operation that benefits significantly from having an operator and the precedence is stupid for bit shifting but good for streaming (1 + x << 2 being (1 + x) << 2 is stupid; cout << x + 1 being cout << (x + 1) makes perfect sense) using * for both multiplication and dereferencing is a far more egregious example of symbol reuse. not only does it confuse humans, it means that you can't even lex c without a symbol table.
|
|
#
?
Mar 6, 2016 23:50
|
|
|
suffix posted:that is exactly my objection Well, those aren't the names of the operators--their names are just symbols. Think of them like homophones. It's not really any weirder than having dog.walk() and directory.walk()
|
|
#
?
Mar 7, 2016 00:03
|
|
|
Plorkyeran posted:if anything c++ should drop the bit-shifting versions of << and >> because it's really not an operation that benefits significantly from having an operator nor is stream io though? iostream operators are really really bad and the only way anyone could think otherwise is stockholm syndrome
|
|
#
?
Mar 7, 2016 00:03
|
|
|
ive never understood why c++ uses << for sending something to a stream
|
|
#
?
Mar 7, 2016 00:04
|
|
|
i bet someone felt /very/ clever about it though
|
|
#
?
Mar 7, 2016 00:04
|
|
|
Awia posted:ive never understood why c++ uses << for sending something to a stream because it was there
|
|
#
?
Mar 7, 2016 00:05
|
|
|
VikingofRock posted:I actually think that both of those are pretty decent uses of operator overloading. you're part of the problem.
|
|
#
?
Mar 7, 2016 00:34
|
|
|
all of the bitwise operators should be reclaimed for non bitwise purposes
|
|
#
?
Mar 7, 2016 00:35
|
|
|
MALE SHOEGAZE posted:all of the bitwise operators should be reclaimed for non bitwise purposes great idea, but you're like 30+ years too late for that
|
|
#
?
Mar 7, 2016 00:40
|
|
|
Blinkz0rz posted:operators should only describe basic mathematic operations category theory duh
|
|
#
?
Mar 7, 2016 00:57
|
|
|
I mean don't get me wrong, I think their are plenty of poor design decisions around C++ iostreams. I just don't think that their choice of using operator<< and operator>> is necessarily one of them.
|
|
#
?
Mar 7, 2016 00:58
|
|
|
Notorious b.s.d. posted:nobody is tempted to do anything stupid with lisp naming. you would never see anyone seriously suggest @**@ as a lisp function name. but *@@* as a defvar name… quote:there's something special about infix notation that makes people go bonkers it's really non-prefix notation, not just infix, Forth implementations typically wind up with an insanity of weird operators too
|
|
#
?
Mar 7, 2016 01:01
|
|
|
VikingofRock posted:I mean don't get me wrong, I think their are plenty of poor design decisions around C++ iostreams. I just don't think that their choice of using operator<< and operator>> is necessarily one of them. the use of operators at all is one of the poor design decisions, since it leads directly to horrors like the use of mutable state to control output formatting
|
|
#
?
Mar 7, 2016 01:16
|
|
|
Soricidus posted:the use of operators at all is one of the poor design decisions, since it leads directly to horrors like the use of mutable state to control output formatting So I agree that controlling output formatting through global mutable state is a really bad design decision on iostreams. What I was trying to argue was that, mutable state aside, code:code:VikingofRock fucked around with this message at 01:59 on Mar 7, 2016 |
|
#
?
Mar 7, 2016 01:57
|
|
|
VikingofRock posted:So I agree that controlling output formatting through global mutable state is a really bad design decision on iostreams. What I was trying to argue was that both are bad but the latter example, using a builder pattern, is the better of the two
|
|
#
?
Mar 7, 2016 01:59
|
|
|
VikingofRock posted:So I agree that controlling output formatting through global mutable state is a really bad design decision on iostreams. What I was trying to argue was that, mutable state aside, 
|
|
#
?
Mar 7, 2016 02:02
|
|
|
Notorious b.s.d. posted:both are bad but the latter example, using a builder pattern, is the better of the two I mean they are the exact same code, just with the name of a function changed. So you can't really argue that one is using a builder pattern and the other isn't. But I think in this case, the focus should be on pretty much everything except the '<<'s or the '.put()'s, because those functions are the least important part of the code. I think that using '.put()' instead of '<<' defeats that slightly, which makes the code with '.put()' a little harder to read. Again, I probably would have been fine with C++ using '.put()' instead of '<<', although I do prefer the latter. It would have been even better had C++ done something besides having global mutable state for outputting stuff (because yeah, that code is disgusting either way). But I think that if you are going to design iostreams the way C++ did, then this is a very defensible use of operator overloading.
|
|
#
?
Mar 7, 2016 02:13
|
|
|
VikingofRock posted:So I agree that controlling output formatting through global mutable state is a really bad design decision on iostreams. What I was trying to argue was that, mutable state aside, yeah but in reality no one would use the latter
|
|
#
?
Mar 7, 2016 02:13
|
|
|
|
| # ? May 12, 2024 06:17 |
|
|
MALE SHOEGAZE posted:yeah but in reality no one would use the latter So the argument against operator overloading here is that "it made this bad thing more ergonomic and readable, so this bad thing got implemented"? I guess I understand that argument but it seems pretty weak to me.
|
|
#
?
Mar 7, 2016 02:26
|
|