The Silently Shifting Semicolon [pdf] • Hacker News Board

Re: The Silently Shifting Semicolon [pdf]

#11

Post by xxxyy » Sat, Apr 11, 2015, 8:14 PM UTC

tfoil2 wrote: post #2

So Alice quits programming and goes back to cooking because Math is Hard. And we wonder why there are gender issues in tech.

To be precise, Alice quits programming because modern languages lack proper concurrency specification, and thus lack actual "Math" in this area. I can sympathize with that.

Re: The Silently Shifting Semicolon [pdf]

#12

Post by acqq » Sat, Apr 11, 2015, 8:31 PM UTC

avandeursen wrote: post #9

tfoil2 wrote: post #7

Earlier quoted context omitted.

I see the reference to the "1998 ACM Subject Classification", but this paper is part of a May 2015 conference: http://www.cs.ucla.edu/~todd/research/pub.php?id=snapl15

Yes, it is from the "Summit oN Advances in Programming Languages (SNAPL)", May 3-6, 2015. http://snapl.org/2015/

Then ignoring the existence of the weaker memory model of ARM (versus the stronger x86/x64) is even stranger. And even if x86/x64 models are stronger, they still need some fences and using them all the time would be too slow. So I still don't really understand the arguments of the article.

Re: The Silently Shifting Semicolon [pdf]

#13

Post by eternalban » Sat, Apr 11, 2015, 8:37 PM UTC

tfoil2 wrote: post #2

So Alice quits programming and goes back to cooking because Math is Hard. And we wonder why there are gender issues in tech.

She's not much of a cook either, apparently : "A: heat oil in a skillet, and B: add in chopped vegetables"

Re: The Silently Shifting Semicolon [pdf]

#14

Post by dietrichepp » Sat, Apr 11, 2015, 8:41 PM UTC

xxxyy wrote: post #11

tfoil2 wrote: post #2

So Alice quits programming and goes back to cooking because Math is Hard. And we wonder why there are gender issues in tech.

To be precise, Alice quits programming because modern languages lack proper concurrency specification, and thus lack actual "Math" in this area. I can sympathize with that.

The concurrency behavior of Java/C++/etc is specified, it's just that the specification doesn't match the model given in the article. It follows a different mathematical model—that doesn't mean that it "lacks actual math".

Re: The Silently Shifting Semicolon [pdf]

#15

Post by xxxyy » Sat, Apr 11, 2015, 8:50 PM UTC

dietrichepp wrote: post #14

xxxyy wrote: post #11

Earlier quoted context omitted.

To be precise, Alice quits programming because modern languages lack proper concurrency specification, and thus lack actual "Math" in this area. I can sympathize with that.

The concurrency behavior of Java/C++/etc is specified, it's just that the specification doesn't match the model given in the article. It follows a different mathematical model—that doesn't mean that it "lacks actual math".

Well, seems that you are right. I stand corrected.

Re: The Silently Shifting Semicolon [pdf]

#16

Post by escherplex » Sat, Apr 11, 2015, 9:50 PM UTC

leereeves wrote: post #6

tfoil2 wrote: post #2

So Alice quits programming and goes back to cooking because Math is Hard. And we wonder why there are gender issues in tech.

Would the fable be any different if the character was named Adam?

Or if the main character in the allegory lacked plumbing fixtures altogether and were named C3PO?

Re: The Silently Shifting Semicolon [pdf]

#17

Post by sctb » Sat, Apr 11, 2015, 10:11 PM UTC

_delirium wrote: post #5

> The Silently Shifting Semicolon (1998) [pdf] This article is from 2015, not from 1998.

Thanks! We updated the title.

Re: The Silently Shifting Semicolon [pdf]

#18

Post by conistonwater » Sat, Apr 11, 2015, 10:53 PM UTC

Can somebody weigh in on their claims of performance differences? IIUC that's the strongest argument so far against sequential consistency by default, yet I'm not sure I understand their evidence. I haven't followed their references yet, but after reading their arguments I'm not sure just what the overhead is now, and what they expect it to be in the future (tbh, I would have expected them to be much clearer about this point, since it is so crucial). They say they expect the overhead to be reduced substantially to the point of not being worth caring about, but is that actually true/likely? I'm not familiar with this enough to judge on my own. My suspicion here is that they (cheekily) say that the overhead can be reduced, without having to prove that it will be reduced.

The alternative, if it is genuinely more expensive to implement SC guarantees in hardware, is that we simply stop teaching people that "A;B" means A is executed and then B. Maybe there really should be an exception saying "but nobody is allowed to look at any intermediate states, unless explicitly allowed". We could also just teach the full meaning of it from the start, it can't be that difficult. Their argument seems to be that non-SC is much less convenient, which I agree with.

On a scale from plenty-real to not-real-at-all, how real are the hardware performance limitations exactly?

Re: The Silently Shifting Semicolon [pdf]

#19

Post by imh » Sat, Apr 11, 2015, 11:01 PM UTC

Good article, but I was kinda disappointed not to have what I expected to be a good read about the evolution of how people use semicolons in natural language. Now I want to read that too.

Re: The Silently Shifting Semicolon [pdf]

#20

Post by wtbob » Sun, Apr 12, 2015, 12:22 AM UTC

eternalban wrote: post #13

tfoil2 wrote: post #2

So Alice quits programming and goes back to cooking because Math is Hard. And we wonder why there are gender issues in tech.

She's not much of a cook either, apparently : "A: heat oil in a skillet, and B: add in chopped vegetables"

What don't you like about that? If you heat the vegetables and oil together, they can slowly lose their water and essentially boil, and taste boring; if you let the oil get to the right temperature and then add the vegetables, then they'll cook up nicely, with plenty of Maillard reactions (browning), and taste delicious.