Not everyone on HN is a software nerd. More than a few here have worked in the shipping and logistics industries.
Which is the sensible thing to do in their position: Hope for the best, prepare for the worst.
Someone says "it COULD be stuck for weeks"
It gets unstuck earlier, fine. Doesn't invalidate the possibility.
The criticism is moot. If anyone had made bets, then I'd take both more seriously.
"Oh, Nate Silver said Trump only had a 30% chance of winning the election, but he did, so Nate Silver is an idiot!"
Multiple times no less.
https://fivethirtyeight.com/features/why-fivethirtyeight-gav...
> Our final forecast, issued early Tuesday evening, had Trump with a 29 percent chance of winning the Electoral College.1 By comparison, other models tracked by The New York Times put Trump’s odds at: 15 percent, 8 percent, 2 percent and less than 1 percent.
As for 2020:
https://fivethirtyeight.com/features/the-polls-werent-great-...
> This year was definitely a little weird, given that the vote share margins were often fairly far off from the polls (including in some high-profile examples such as Wisconsin and Florida). But at the same time, a high percentage of states (likely 48 out of 50) were “called” correctly, as was the overall Electoral College and popular vote winner (Biden). And that’s usually how polls are judged: Did they identify the right winner?
(He also doesn't do the polling. He's an analyst, not a pollster.)
How about linking to others and not him defending his performance. Of course he’s going to have excuses.
Live a little and maybe even pick sources that might not align politically with you too for an alternate POV. Prevents “surprises”. Because as someone with no love lost on either party the election results were not a surprise - you just have to look across all sources, not just the ones that tell you what you want to hear.
The "aggregate the polls" approach appears to have called 48/50 races correctly, so I'm fairly comfortable with it.
I think the pendulum is swinging too far the other direction. "Look how easy it is. They just shook it loose" is the wrong lesson to take here, IMO.
From the YouTube clip, it def seems like it's normal to see them when passing through the canal.
But judgement reservers aren't prone to jump on message boards and shout "guess we'll have to wait and see" to the world.
That was what many investors thought - see crude oil market in last days. There were two tribes - one saying week and second month(s) to solve the problem with ship. One selling, because of optimistic perspective and obviously other buying for opposite reason. In the result the price was standing still on the "same" level.
So, the difference in the expected outcome here doesn't surprise me.
> "We can't exclude it might take weeks, depending on the situation," said Peter Berdowski, CEO of Dutch company Boskalis.
Of course that message got oversimplified as it spread. "Can't exclude" is a pretty important qualifier that suggests that it's an unlikely worst case.
But that nuance already was lost in the title of that same article: "Cargo ship blocking Suez Canal could take weeks to move". If you were to read only that title, you might think it is likely to take weeks.
TLDR: People thought it would take weeks because that's what they were hearing from other people.
That's a factual take on things.
The stuff that gets posted here sometimes is...fascinating.
heh sorry, can't tell how serious you're being. but it tickles my brain that there's someone who would also vibe with that byline: con artists :)
Did you know my experimental observations of quantum gravity & string theory are as good, if not better, than the world's top scientists? If you print this comment on paper, I will have been published & peer reviewed, too!
From that 2017 article:
> You already know we haven’t found anything yet—otherwise you’d have heard of it. But even null results are valuable guides for theory development. They teach us that some ideas—for example, that spacetime might be a regular lattice—are simply incompatible with observations.
I would suggest that publishing and peer review requires an audience, therefore ... err, by publishing this I am actually peer-reviewing your work?! Drat! That makes me 0/2 then!
To conclude my peer-review, I would like to see more details for reproduction, merely stating that you've performed experiments without providing the necessary observational data and steps to reproduce highlights the lack of originality in the paper you're proposing and therefore I would decline to publish. ;-)
You went a bit too far. I'd presume a lot of programmers do know CPU architecture well. While not common some of them to work on boring web platforms, some still do. Also most CPU architects would be decent programmers to begin with.
Programming has not changed all that much and it was not so long time ago that programmers routinely knew assembly and how many cycles (and bytes) each opcode took... Nowadays it might be regarded as an arcane art by most, of course.
That statement partly highlights the problem. It assumes linear execution, when in reality, for most performance-critical products, out-of-order execution is the reality. For example: https://smist08.wordpress.com/2019/11/15/out-of-order-instru...
Most programmers on Apple platforms don't actually think about execution order -- because they don't have to -- but also because Apple is actively using Clang to discourage assembly and writing for specific CPU architectures. It makes Apple's job of releasing new silicon that much easier if they don't have to worry about breaking existing software custom written for a previous architecture.
And this still assumes a one-to-one relationship between the code you're writing and the computer it's running on or designed for. When you get to the cloud, or cloud functions, that breaks down even further. If using Heroku, for example, you don't even have to consider how to deploy your code and you can make it pretty far running a production service.
It's possible for closely related fields to still have very large differences. Consider drivers and cars: The more automation is introduced, the less we might need to know about what the automation is doing for us under the hood. Anti-Lock Breaking (ABS) in cars might be a simple example where folks know about it because there's a light on the dash and instructions in driver's ed. But if we didn't have those indicators, how often would anyone know about it and other such features? Some technologies remain undocumented until discovered later by experimentation, the VW diesels come to mind. Specific chip designers likely know more than your average programmer, just as specific car manufacturers likely know more about their products than drivers would.
This is quite a blatant assumption on its right own (and very far from the truth). The programming, itself, has not changed. But of course, modern hardware is not a von neumann machine. Writing lock-free datastructure is not that different programming, it requires a lot more attention and (possibly) experience but the basic premise is still the same.
Understanding memory topology/hierarchy & latency, concurrency, branch (mis)prediction, cache coherency should be a minimum for anyone who comments on CPU architecture. I did mention Assembly and without some knowledge on the target architecture it's rather pointless to comment on, either.
I encourage most developers to at least understand that memory is not actually 'random access', which makes derefernce not cheap - but accessing data placed together is next to free as it is likely to hit L1.
> discourage assembly and writing for specific CPU architecture
I found out that I could not reliably beat a standard compiler writing everyday Assembly around K6-2 years. Yet, still some inner loops can be carefully hand optimized. The point is that there are plenty of programmers who would be able to understand modern architecture and to me basic understanding is needed unless the job is just gluing code.
Just as an example I see a lot: branch prediction. Some programmers don't know about it at all. Many do know about it, but think that it still works in some form like "assume the branch will go the same way it did last time". Which is how it worked in the 1990s. Then it evolved, and then it evolved two more times. Today there is something like a neural network that learns how the branches will go. (And careful, im a programmer so I may be communicating some subtleties wrong there!)
More like history, where the call comes from. Oddly enough the price of branch misdirection has become lower as not the entire pipeline needs to be thrown away but also due to hyper threading taking the slack.
Flip note: with 'recent' developments of Spectre, one'd think branch prediction got into the lime light. Truth be told, though, not many would be able to write constant time 'fizz buzz' (can try it on your own, bonus points to having constant time int->string conversion)
Of course each meter of depth is a little harder, but not that much harder.
lol - cut and fill on a slope is not trivial. It’s more of an exponential function than a linear one for the amount of material removed the deeper you have to go down. They dodged a HUGE bullet with the highest tides happening this weekend. If they had gone beyond a Tuesday with the drop in tides each day as the moon got further away it would have been sketchy if they could have gotten ahead of the tide or not.
The timing of this couldn’t have been tighter. Thankfully they came out on the good side :)
Someone linked a BBC article stating that they shifted 27,000 cubic meters of sand, so there you go, they could likely remove a meter under the whole thing in a similar amount of time (probably longer to cover area instead of digging down, but that isn't what they would need to do).
Yes, the high tide is a better opportunity to do it, the tides over the next couple of weeks are still within 20-30 cm. The worst day in the next 30 days is 60 cm below the highest.
But maybe the dredge only made a few centimeters of difference running for 5 days, who knows.
Here
There's an offer of:
Limited Series A (5 remaining) just €43.50 (+VAT) per month
Limited Series B (7 remaining) just €431.50 (+VAT) per month
or
Limited Series C (1 remaining) just €862.50 (+VAT) per month
Brilliant!
(I must note that the circuit shown there is... somehow... inducing some negativity in me.... which probably isn't unintentional.)
And the main site has an about page too, in all its glory:
[1] https://news.ycombinator.com/item?id=26585282