|
TooMuchAbstraction posted:i += 1 is only 3 more characters. It's time to move on.
|
#
?
Oct 24, 2017 10:59
|
|
|
|
| # ? May 30, 2024 21:57 |
|
|
I remember in a previous job we had to use the Interlocked.Increment(ref i) function instead of i++ in order to side-step the issue when multiple threads were involved, https://msdn.microsoft.com/en-us/library/dd78zt0c(v=vs.110).aspx Exactly why the use of such a function was required in the implementation I was working on probably is a coding horror in and of itself. AstuteCat fucked around with this message at 14:11 on Oct 24, 2017 |
|
#
?
Oct 24, 2017 14:04
|
|
|
SupSuper posted:Most code increments are by one, why shouldn't it have a shorthand? Because most times you're incrementing by one, what you're really doing is iterating over a container, and that should have a shorthand. In languages that have good iterator syntaxes, I hardly ever find myself incrementing things by 1.
|
|
#
?
Oct 24, 2017 15:15
|
|
|
TooMuchAbstraction posted:Because most times you're incrementing by one, what you're really doing is iterating over a container, and that should have a shorthand.
|
|
#
?
Oct 24, 2017 15:33
|
|
|
next(subject)
|
|
|
#
?
Oct 24, 2017 15:36
|
|
|
Athas posted:Software transactional memory (as seen in functional languages) also hasn't seen as wide usage as was hoped. I think what happened is that a bunch of people invented techniques to make parallel programming safe, but then realised that the real challenge is to also make it fast. You see this happening over and over again (although some research twists the story by indeed focusing on performance, albeit asymptotic cost on implausible machine models). Once again proving that there are only two types of programming languages: unsafe and useless.
|
|
#
?
Oct 24, 2017 16:23
|
|
|
TooMuchAbstraction posted:Because most times you're incrementing by one, what you're really doing is iterating over a container, and that should have a shorthand. You must just not be working on certain types of things though -- some projects require generating sequences of numbers and drawing math functions all the time
|
|
#
?
Oct 24, 2017 16:42
|
|
|
Dumb Lowtax posted:You must just not be working on certain types of things though -- some projects require generating sequences of numbers and drawing math functions all the time Sure, but is that a global enough need to warrant having a special construct specifically to support it?
|
|
#
?
Oct 24, 2017 16:44
|
|
|
Dumb Lowtax posted:You must just not be working on certain types of things though -- some projects require generating sequences of numbers and drawing math functions all the time Sequences are a kind of iterable container. Sequence generators, a lazy kind.
|
|
#
?
Oct 24, 2017 17:06
|
|
|
Cross-posting from Reddit:
|
|
#
?
Oct 24, 2017 18:39
|
|
|
darthbob88 posted:Cross-posting from Reddit: 
|
|
#
?
Oct 24, 2017 18:41
|
|
|
darthbob88 posted:Cross-posting from Reddit: 
|
|
#
?
Oct 24, 2017 19:02
|
|
|
darthbob88 posted:Cross-posting from Reddit: I don't know if I'm scared of this or intrigued.
|
|
#
?
Oct 24, 2017 19:02
|
|
|
Part of me kind of wants to know what IDE has full color on unicode emojis. Before trying it out in WebStorm, I wanted to know what IDEs supported unicode emojis at all, but I guess it kinda makes sense to add native support for them in a web dev IDE.
|
|
#
?
Oct 24, 2017 19:22
|
|
|
VSCode does, as does CodeWriter which probably doesn't count, but seems to come with Windows? Sublime and Visual Studio don't. Seriously tempted to use that ghost 
|
|
#
?
Oct 24, 2017 20:06
|
|
|
Joda posted:Part of me kind of wants to know what IDE has full color on unicode emojis. Before trying it out in WebStorm, I wanted to know what IDEs supported unicode emojis at all, but I guess it kinda makes sense to add native support for them in a web dev IDE. Intellij does (on Mac)
|
|
#
?
Oct 24, 2017 20:11
|
|
|
darthbob88 posted:Cross-posting from Reddit: The real gem is in the comments: '👨👩👦👦'.replace('👦', '👧') // 👨👩👧👦 '👨👩👦👦'.replace('👦', '') // 👨👩👦 '🙅🏻'.replace('🏻', '🏿') // 🙅🏿
|
|
#
?
Oct 24, 2017 20:20
|
|
|
Can you link to the article, please?
|
|
#
?
Oct 24, 2017 21:18
|
|
|
NihilCredo posted:Ah, the whomst'd've of programming. Hello new thread title. Things have been... OK lately, which in deploy suspicious of. The best thing that's happened is watching a dev team try to go from Angular 1 right to angular 4- it's been a hot cluster gently caress for them - half of the dependencies seen to mutate between dev machines. Everybody has different poo poo in their packages and pulling latest seems to churn versions. Npm and the garbage heap of mini dependencies are a big horror for us right now.
|
|
#
?
Oct 24, 2017 22:39
|
|
|
rjmccall posted:It's just lost a lot of interest. TM works alright if you basically don't have contention. If you do have contention, though, guaranteeing progress is hard even in practical cases — you basically need all other threads to gradually stop trying to begin transactions, even unrelated ones, because you can't easily know ahead of time whether a transaction is indeed unrelated — so either the overhead is much higher than advertised or you have really hard-to-predict and hard-to-analyze failure modes. That statement about progress is also true of things like compare-and-swap loops but much less likely in practice, in part because of the nature of things generally being attempted but also because progress is supposed to be the sort of thing you're aware of as a programmer using atomics, and nobody ever said atomics were a feature for novices, whereas people do make grandiose claims about how easy TM makes lock-free concurrency. So it's fraught with the same problems as all concurrency, magnified by the attempt to democratize it and push it out to sub-atomic programmers? Swear I've heard that story before. rjmccall posted:Also, people have been pinning their performance hopes on hardware solutions, but hardware TM is inevitably going to have fixed transaction size limits, which means that a lot of things which would be merely bad ideas suddenly become impossible. For example, you can use TM to splice something out of a linked data structure (like a doubly-linked list) because you only need to touch some bounded number of nodes, but you generally can't use hardware TM to safely walk the entire data structure because the transaction would grow linearly with the size. Athas posted:Software transactional memory (as seen in functional languages) also hasn't seen as wide usage as was hoped. I think what happened is that a bunch of people invented techniques to make parallel programming safe, but then realised that the real challenge is to also make it fast. You see this happening over and over again (although some research twists the story by indeed focusing on performance, albeit asymptotic cost on implausible machine models).
|
|
#
?
Oct 24, 2017 22:44
|
|
|
JawnV6 posted:That's the feeling I get about Rust? Sure it's safe, so would C be if you built at -O0, jammed an instruction barrier every other instruction, and generally made it slow as dirt. Optimized Rust's speed is pretty comparable to optimized C, though*. Most of the safety features have zero runtime overhead when compiled in release mode. *There are some caveats here, like difficulty in getting LLVM to vectorize your code and the need to use unsafe blocks in some data structures. But for the most part I think the benchmarks show that this is true
|
|
#
?
Oct 24, 2017 22:56
|
|
|
VikingofRock posted:But for the most part I think the benchmarks show that this is true
|
|
#
?
Oct 24, 2017 23:08
|
|
|
JawnV6 posted:Oi, I've got a forums-inappropriate story about speeding up spin lock performance leading to Bad Results. I can definitely imagine that sort of thing exposing problems. JawnV6 posted:So it's fraught with the same problems as all concurrency, magnified by the attempt to democratize it and push it out to sub-atomic programmers? Swear I've heard that story before. I would say that there's a difference in kind between the levels of optimism about contention required for normal atomics vs. TM. TM basically demands OS involvement from the start, which inherently limits its scalability and its performance. JawnV6 posted:I guess it'd be hampered by lack of interest, but couldn't the HW just punt out to SW for things like that? Maintaining the bad-idea behavior instead of entirely blowing up. Like a page fault. HW does it's best, if it can't resolve it'll ask SW what to do. I've got X slots for my HW transaction window, when I hit the end of that I'll ask software for a pointer to a blob of memory to store more. That's a lot of extra complexity, though, since loads within the transaction sometimes need to be serviced from the transaction buffer (because they need to see an internally-consistent view of memory). And that complexity is specifically likely to lead to serious processor-soundness problems, since the processor doesn't really have a guarantee that nothing is concurrently modifying the "spilled" transaction buffer.
|
|
#
?
Oct 24, 2017 23:20
|
|
|
Rust's higher level abstractions are designed in the philosophy of C++'s "no overhead abstractions." Rust's aliasing guarantees could theoretically make idiomatic code faster than idiomatic C (ignoring aliasing specifiers in C) with a Sufficiently Smart Compiler.Doc Hawkins posted:Once again proving that there are only two types of programming languages: unsafe and useless. This doesn't eliminate all concurrency problems of course, but in my experience a lot of programmers don't understand the basics of concurrency safety in accessing data across threads. Making these mistakes compile time errors may help a lot. It remains to be seen if this model is ultimately useless, but it seems naively promising at first glance.
|
|
#
?
Oct 24, 2017 23:26
|
|
|
rjmccall posted:I would say that there's a difference in kind between the levels of optimism about contention required for normal atomics vs. TM. TM basically demands OS involvement from the start, which inherently limits its scalability and its performance. rjmccall posted:That's a lot of extra complexity, though, since loads within the transaction sometimes need to be serviced from the transaction buffer (because they need to see an internally-consistent view of memory). And that complexity is specifically likely to lead to serious processor-soundness problems, since the processor doesn't really have a guarantee that nothing is concurrently modifying the "spilled" transaction buffer. I should check on the implementations, my picture has a few gaps. comedyblissoption posted:Sufficiently Smart Compiler.  How'd waiting on a SSC work out for VLIW anyway? There's dozens of naively promising solutions in this space. We're not in need of those. comedyblissoption posted:Rust's higher level abstractions are designed in the philosophy of C++'s "no overhead abstractions." Rust's aliasing guarantees could theoretically make idiomatic code faster than idiomatic C (ignoring aliasing specifiers in C) with a Sufficiently Smart Compiler. It still just feels like handcuffs. Sometimes you can write a nice note to the complier explaining why you need both hands free, other times you just grab the unsafe key and hide all the handwaving in one corner.
|
|
#
?
Oct 25, 2017 03:06
|
|
|
Eela6 posted:next(subject) code:
|
|
#
?
Oct 25, 2017 03:22
|
|
|
People that have been programming for longer than I have: does the confusion around Min/Max/Clamp ever shake off? Just spent close to 2 hours debugging something going weird because I wrote Min( width, 1 ) when trying to clamp to a minimum of 1.
|
|
#
?
Oct 25, 2017 04:41
|
|
|
How long have you been programming? I've been doing it for about... Jesus Christ, probably fifteen years at this point and I still have to walk through that poo poo under my breath every time.
|
|
#
?
Oct 25, 2017 04:48
|
|
|
darthbob88 posted:Cross-posting from Reddit:  Compiles and runs just fine. Perhaps we've made a horrible mistake.
|
|
#
?
Oct 25, 2017 05:01
|
|
|
Sinestro posted:How long have you been programming? I've been doing it for about... Jesus Christ, probably fifteen years at this point and I still have to walk through that poo poo under my breath every time. I always do a double or triple take because getting it wrong suuuucks to track down. See also: given one dimension and an aspect ratio, calculate the other dimension.
|
|
#
?
Oct 25, 2017 05:04
|
|
|
Suspicious Dish posted:People that have been programming for longer than I have: does the confusion around Min/Max/Clamp ever shake off? Just spent close to 2 hours debugging something going weird because I wrote Min( width, 1 ) when trying to clamp to a minimum of 1. Am I misunderstanding clamp? I’ve been programming since around 1978 or so, and as I understand it min() returns the lower of the two values, max() the larger of the two, and clamp() returns min if value < min, max if value > max, else value. This seems fairly straightforward to me, but maybe you are talking about something different?
|
|
#
?
Oct 25, 2017 05:05
|
|
|
LongSack posted:Am I misunderstanding clamp? I’ve been programming since around 1978 or so, and as I understand it min() returns the lower of the two values, max() the larger of the two, and clamp() returns min if value < min, max if value > max, else value. This seems fairly straightforward to me, but maybe you are talking about something different? Suppose I have open-ended range, from 1 up to infinity. What function do I call to clamp a value into that range? It's not the function that you mentally associate with the concept of "smallest value".
|
|
#
?
Oct 25, 2017 05:10
|
|
|
Jabor posted:Suppose I have open-ended range, from 1 up to infinity. What function do I call to clamp a value into that range? max(value,1) ? Edit: not sure where “smallest value” comes into this
|
|
#
?
Oct 25, 2017 05:11
|
|
|
LongSack posted:max(value,1) ? You're specifying the smallest value of the range. You know, the minimum allowable value. Yes, in a context like this where you're being explicitly asked about it, it's not too difficult to avoid. When you're focused on something else instead of the specifics of numeric manipulation, it's a really easy error to make. The right answer is clamp(1, value, value).
|
|
#
?
Oct 25, 2017 05:16
|
|
|
Jabor posted:The right answer is clamp(1, value, value). How is that different from max(1,value)? Assuming the definition of clamp is clamp(min,max,value)?
|
|
#
?
Oct 25, 2017 05:19
|
|
|
LongSack posted:How is that different from max(1,value)? Assuming the definition of clamp is clamp(min,max,value)? The difference is I'm a moron.
|
|
#
?
Oct 25, 2017 05:23
|
|
|
I really want clamp(value, min=1) as a sort of default thing for every language. Too bad very few languages have named parameters.
|
|
#
?
Oct 25, 2017 05:28
|
|
|
edit: redacted 
LongSack fucked around with this message at 05:36 on Oct 25, 2017 |
|
#
?
Oct 25, 2017 05:30
|
|
|
LongSack posted:
In the spirit of the thread: Clearly clamp should just take three parameters in arbitrary order and always return the median. Then there can be no confusion.
|
|
#
?
Oct 25, 2017 05:35
|
|
|
|
| # ? May 30, 2024 21:57 |
|
|
LongSack posted:Disagree. If you use clamp(1,value,value) the results will be different if clamp is defined as clamp(min,max,value) or clamp(max,min,value). This is quite obvious, so I am not sure what you are suggesting here. Ignore the clamp(1, value, value) thing. Unless you want to take it as a challenge to explain why it doesn't work as intended. Actually trying that might lead you towards the reasons for my assertion that order doesn't matter. what happens if max < min? is that even something you want to define? e: ^  you're spoiling the puzzle
|
|
#
?
Oct 25, 2017 05:41
|
|