How is it distinct in any way that would undermine their argument? Do people go airport to airport to then not drive, where people going to downtown would want to drive? Their point is that people go to other cities without their vehicle all the time with plane travel, so high speed rail would have plenty of demand up to a certain distance.
You're not wrong, but that just means the <adjective> is where the bulk of information resides. The trade-off matters. Maybe it's a model with good enough quality but really cheap to serve. Maybe it's a model that only plays poker really well but sucks at everything else because it bluffs too much. Etc. etc.
With inflation and the terribly high cost of housing in places like the Bay Area, “seven figures is the new six figures” is an apt observation. I make six figures, yet I can’t afford to buy a home within a reasonable commute from my job, and even finding a decent rental near my job is challenging. Seven figures is indeed the new six figures.
+1. Frameworks learning costs are non-trivial. After you worked so hard to become productive in a particular framework it's frustrating to see its core and/or ecosystem fizzle --- especially when your existing code already tied the framework's unique constraints, making it a hassle to port to other frameworks. In this sense the "bus factor" / resilience of the framework dev does matter to the app dev building on top of it.
> as the overall development workflow is lightyears ahead of C++, mostly due to tooling
My experience has been the other way around. Eclipse-based IDEs from NXP, TI, ST all have out-of-the-box usable tooling integration:
- MCU pinout and configuration codegen
- no need to manually fiddle with linker scripts
- static stack and code size analyzers (very helpful for fitting stuff in low-cost MCUs)
- stable JTAG-based debugging with:
- peripheral registers view (with bitfield definitions)
- RTOS threads view (run status, blocked on which resources, ...)
And yes, these are important enough for me to put up with Eclipse and pre-modern C/C++. I really want to write Rust for embedded but struggling with the tooling all the time didn't help.
The SFBay I-880 and US-101 are always packed, often under construction, but still pothole-filled, with sections of extreme roughness. Compare this to our OR neighbors, where there are signs saying "your tax dollars at work" by ORDOT everywhere. I used to scoff at this as a display of insecurity, but apparently (from TFA at least), Oregonians' tax dollars _are_ at work.
CA takes so many tax dollars from my hands. Why aren't they "at work"?
On the contrary, I believe they are. There are thousands of miles of back roads in California built and maintained by Caltrans that are in absolutely incredible condition. Drive up and down any random mountain/hill/pass off a main freeway and enjoy a road the envy of almost anywhere else: well-built, smooth, with painted lines and signage.
880 and 101 suffer because their high traffic volumes cause much higher wear and tear while also making it difficult to make repairs.
Oregon is 60% the size of California by land area but only 10% of the population.
Roads like 101 & 880 can't be worked on during the day because of massive congestion issues. But drive up & down 101 after 9 or 10pm (even on weekends), and you'll see crews hard at work.
Hats off to those crews working the night shift.
Anecdote: Worked road construction summer 2010 as the guy who put those little sticky tabs on the road to mark where lines are repainted after construction is complete.
Sometimes I'd finish early and get odd jobs. Between Roseburg and the Oregon coast a colleague and I were assigned to stand one of those "your tax dollars at work" signs on a steep slope. Took 2 hours at prevailing wage OT and for total labor cost of $480 between the two of us. By far the steepest labor rate I'd ever been able to charge. Thanks for the money, irony!
Only because those people can't find somewhere to live that's near work. So sick of this incredibly stupid line of thinking from otherwise very smart people who refuse to realize that increased demand on transportation infrastructure is the flip-side of the housing shortage.
Agreed, but I would say that inducing demand is the point of building anything. Nobody uses that term when it comes to building homes people want to live in. They only ever use it to oppose people being able to exercise their freedom of movement.
I said it. Seems pretty straightforward to me that I am inherently less free to move via rail/sea/air than via my automobile unless the train/boat/plane can also take me anywhere, at any time, 24 hours a day, any day. I do prefer to commute via train if I can. In fact my office just moved and I've had to give up my one-shot train commute just in this last month :/
Unfortunately the alternative to divesting in road infrastructure won't be investing in rail infrastructure, it will be telling people to stay home. For sure a lot of demand for rail investment will come once it becomes harder to get around and more people lose their autonomy, but the reality for many people will just become not going anywhere at all. That means segregation-with-extra-steps for all too many places, and I was raised to believe that's a bad thing. Peep the Bay Area for example — it's really bad! http://radicalcartography.net/bayarea.html
Aside: I'm a huge railfan and have actually gotten to drive a locomotive at the Western Pacific Railway Museum even though it was very expensive and confined to a tiny circle of track. Highly highly recommend a trip out there for anyone, even if just to sight-see the gorgeous Feather River Canyon: https://museum.wplives.org/ral/
I'd like to see California consider reducing the total mileage of roads and focus on having a smaller amount of higher quality paved surfaces. My neighborhood street does not need to be 60ft wide, and our freeways do not need more lanes.
I imagine that all states would have more trouble managing more roads than they currently do, and less trouble managing fewer roads than they currently do.
Start with the fire department. They are the ones demanding 60 ft wide residential streets so that their trucks can turn around without having to drive a few blocks out of the way.
I know this hasn't been updated, and I know it's a fork of CoffeeScript, but https://livescript.net/ has had a lot of the "magic" syntax here for quite a while.
Yes, Civet has taken a lot of syntactic inspiration from LiveScript. At this point, I think we have most of the good features, but we might be missing some. Let us know what you think!
The big difference, of course, is that Civet fully supports TypeScript, and is up-to-date with the latest JavaScript and TypeScript features.
The goal you described matches more of an on-ramp meter instead of surface street lights? Unless of course we're talking about an intersection leading to the on-ramp, but now we're into back-off effects as well, which arguably could use more smartness in their schedule.
It's sort of the reverse, in a sense. If drivers adhered strictly to yield signs, those getting onto the highway would wait until there was a space in traffic. There would be times when you could not get on to the highway at all, when traffic was heavy but not so heavy that it slowed. To solve this (again, with strictly following RoW), you would have to either slow speeds on the highway or put stop lights on the highway to let mergers enter the roadway. This doesn't happen because everyone understands that those merging onto the highway are moving fast and running out of space, and prudence dictates that you slow down to make space, rather than finding out if you're driving next to someone who will crash into you. At the far end of the spectrum from that situation, you have people waiting forever to cross, in a marked crossing where they have right of way, because they're stopped (the status quo supports them not going) and they stand to die if the driver doesn't yield properly. Fast unlimited-access roads are somewhere in the middle: the mergers don't have the initiative, but the suffering is more evenly distributed in the case of a crash, so the passing drivers are perhaps more prepared to slam on brakes.
The on-ramp meters provide the service of prioritizing drivers from distant suburbs or out of town at the expense of those who dwell in nearer suburbs. To put a different spin on it, they slightly disincentivize short trips on highways.
> There would be times when you could not get on to the highway at all, when traffic was heavy but not so heavy that it slowed.
The flowing traffic makes space for the merging traffic, which also takes up any existing gaps. The merging traffic ideally zipper merges at traffic speed.
Traffic speed is correlated to gaps between cars. If merging gets tight, gap size is small, traffic is therefore going slower. If merging is impossible, then gap size is tiny, traffic speed is approaching zero, and both the onramp and highway are a traffic jam.
It is the accumulation of new traffic that slows traffic speed. I think you are implying traffic speed remains a fixed constant and merging traffic just waits. Instead there is an interplay.
Which comes to onramp lights. That is just a rate limiter to avoid the highway from going into an extreme bottleneck. The highway capacity is the bottleneck, so adding more traffic to it freely makes it exponentially worse. It is not at all about incentives but preservation of traffic flow.
The idea of prioritizing distant suburbs falls a bit flat when considering the evening counter commute. The idea does hold somewhat for morning rush hour as on ramp meters do prioritize the speed of existing traffic. Regardless, the rate limiting is the purpose.
Though, why are we talking about on ramp meters when the article is not about on ramp meters?
> This doesn't happen because everyone understands that those merging onto the highway are moving fast and running out of space, and prudence dictates that you slow down to make space
Merging traffic should be matching, not exceeding traffic speed. Existing traffic should _speed up_ to facilitate merging. The merging cars merge behind, not in front when cars are side by side. If a merging car does not get space, then they either slow, stop, or shoulder drive. A person might slow to facilitate a merging car that is well ahead of them. Generally that right hand lane should start opening gaps between every car to facilitate a zipper merge. If side by side, the traffic that has space, the existing traffic, should speed up to make space behind and to maintain traffic speeds. If they can't speed up, then there is overall congestion, gap size shrinks and traffic speed slows..
Metering traffic turns clumped up platoons into evenly spaced vehicles, which is exactly what you don't want to see as a driver trying to turn onto a major road. Broadly spaced platoons are much better because the space between platoons is much more likely to be large enough to allow you to safely maneuver onto or across the road.
> And there’s a greater risk that you’ll end up on a travel website advertising a low fare that jumps just before you make a purchase, with a message like “this fare is no longer available.”
Might sound like FUD at first glance, but I do remember this kind of dark patterns once being the norm across the board, especially in the early 2010s. Heck, even with GFlights I still find myself sometimes double-checking the airline's own booking tool (with reasonable attempt at isolation) just to be sure; gladly I never spotted any discrepancy this way.
reply