Hacker Newsnew | past | comments | ask | show | jobs | submit | throwaway173738's commentslogin

This is essentially the same thing that happened with Fukushima Daiichi. The organization running it failed to respond to new information.

This comment kind of epitomizes the way the Perl community works, to be honest.

Erasing the Federal Government is the motte and saving money is the bailey.

It doesn't look like the Federal Government is being erased. In fact, it and its debt are rapidly growing. I'd say the motte is autocratic authoritarianism (ie fascism).

It’s not about the latency between when words are spoken and when they’re heard, it’s snot when a packet is sent and when it’s received. There’s a lot of jitter and you really don’t want intermittent drops to cause people to miss parts of your programming.

> bypassing a long queue of cars only to merge into the lane at the last possible second,

If everyone did this the jams would flow faster, according to WSDOT.


This is true, but with a few caveats:

* The time spent adjacent to the traffic lane should be used calibrating your speed with the speed of traffic, once you're at the front you should then be able to merge into an open spot without causing any change to the speed of the cars behind you. So many times I see people zip quickly to the front then merge in and slam on their brakes, causing an extra delay to ripple back through traffic. Some people do this at the beginning of the merge lane which is even worse.

* Once you get there you should endeavor to zipper merge so multiple cars aren't trying to squeeze into one spot. As a corollary, if you're already in the lane that's being merged into you should leave an open space big enough for one vehicle to enter at this point, or better yet consider leaving the lane entirely.

* And by that I mean leave the lane to move deeper into the highway, don't exit into the merging lane just to zip ahead and cut back in, this decidedly does not improve traffic flows.


From what I can see, it's not about higher throughput (which stays the same)

It's about reducing queue length (you use 2 lanes instead of one, so the queue length is halved) and smaller speed differences between cars on adjacent lanes.

I can't find a good WSDOT source, but here's Minesotta: https://www.dot.state.mn.us/trafficeng/workzone/doc/When-lat...

Anyway, I'm not talking about cases where one lane is closed (which is what WSDOT and the Minesotta doc talk about). I'm talking about cases where there is a one lane offroad from the highway, with a queue of cars waiting to take it. Plenty of people will skip the entire queue and try to merge right at the end, blocking half of their own lane while waiting for a gap in the queue.


If there is a right turn only lane, and a straight lane, and the right turn only lane is backed up with people queuing, you are not making traffic go faster by merging in at the last second. You are slowing down a bunch of people trying to turn, and blocking the people trying to go straight.

You can change straight/right/left here and it all holds. Zipper merges are for merges, when 2 lanes of traffic become one, and everyone merging early is a little bit worse. Above is just selfish.


You should not do jams with opposite direction lanes. I assume op talked about that.

It’s also a good argument for not allowing children to be victims of their parents’ circumstances. Which is the heart of compulsory schooling and school lunch and a whole host of other things.

I’d be curious to get to the heart of why we believe heritability in behavior is due to genetic changes. It’s way more likely to be due to mimetic changes.

in terse, behaviour is dependent on neural activity; neural activity is dependent on expressivity, and penetrance of genetic constituency.

https://en.wikipedia.org/wiki/Behavioural_genetics

https://assets.cambridge.org/97811084/87979/frontmatter/9781... [PDF]


A spec consists of three different kinds of requirements: functional requirements, non-functional requirements, and constraints. It’s supposed to fully describe how the product responds to the context and the desires of stakeholders.

The problem I see a lot with Agile is that people over-focus on functional requirements in the form of user stories. Which in your case would be statements like “X should do…”


I don't necessarily disagree, but can you give an example of a non functional requirement that influences the design?

I always find the distinction between the two fuzzy (because many non-functional requirements can be argued to be functional requirements) but the list here is useful for the discussion: https://en.wikipedia.org/wiki/Non-functional_requirement

Take things like "capacity". When building a system, you may have a functional requirement like "User can retrieve imagery data if authorized" (that is the function of the system). A non-functional requirement might be how many concurrent users the system can handle at a time. This will influence your design because different system architectures/designs will support different levels of usage, even though the usage (the task of getting imagery to analyze or whatever) is the same whether it handles one user at a time or one million.


Yeah, that aligns with my thinking that such a view has rather a narrow view of a "function".

There’s a third possible reason which is that they’re taking it as a given that the machine is “intelligent” as a sales tactic, and they’re not academic enough to want to test anything they believe.

Calling it “exploring” is anthropomorphising. The machine has weights that yield meaningful programs given specification-like language. It’s a useful phenomenon but it may be nothing like what we do.

Or it may be remarkably similar to what we do

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: