Interesting how when it was top-voted comment it read more as the light-hearted poking of fun which I intended (I really have no problem with Wolfram, I think he's funny). But now it has been demoted to the bottom of the thread it has started getting lots of downvotes and somehow reads (even to me) as being mean and bitter.
Curious example of how the thread position/reaction of others really primes how we receive a comment.
I thought your comment was funny too. But alas we have tons of experience with Wolfram threads collapsing into nothing more than "wolfram wolfram wolfram" in an outraged mirroring of the very thing they're criticizing.
It's just another black hole, and one of the most trivial. And since (Wolfram being Wolfram) there are also interesting things in the submission to discuss, that's what we should focus on.
>A group of friends and I used to do dramatic readings of the About the Author text from the Mathematica Book, which begins thusly:
>About the Author
>Stephen Wolfram is the creator of Mathematica and is widely regarded as the most important innovator in scientific and technical computing today.
>The guy wrote that himself.
>Wait, while searching for that, I see he updated it slightly in later versions:
>About the Author
>Stephen Wolfram is the creator of Mathematica, and a well-known scientist. He is widely regarded as the most important innovator in technical computing today, as well as one of the world's most original research scientists.
>I guess the original didn't fully express the boundless expanse of his awesomeness.
>"Does anyone want to bet as to which will gain self-awareness first: Wolfram Alpha or Wolfram, Stephen?"
He may have the data to make the argument. I suppose if anyone wanted to measure such things which really shouldn’t be measured, I bet Wolfram has a compelling case.
How can I bring a child into the world when it appears likely that the child will suffer greatly?
The West hasn't really grappled with this question yet, but give it 15 years - when climate breakdown starts seriously affecting quality of life - and I expect the birthrate to crash.
> How can I bring a child into the world when it appears likely that the child will suffer greatly?
Suffer from what exactly? In my family, half of my father's siblings and cousins died from war and hunger, the rest also had to hide from constant bombing and assaults, in fact my grandmother's village was wiped completely from the map. Yet they have tried their best to build the country so that now I can type this comment, safe from any kinds of harm. I consider it is my duty to do the same for the next generation. IMO the society should support families with kids more, as they are nurturing the future of mankind, literally.
In Rust, everyone is a print debugger. The only thing that really goes wrong in normal code (once it compiles) is "why is this value not what I expect?". Dropping down into GDB is way overkill.
* Rust code can have memory errors + undefined behavior, because Rust code can say "unsafe". Plenty of real projects use "unsafe". (Alternate reason: because the compiler has soundness bugs.)
* Memory errors + undefined behavior aren't the only reasons people like debuggers. Consider: there are plenty of other memory-safe (GCed) languages in which people find debuggers useful (such as Java). "The only thing that really goes wrong in normal code (once it compiles) is 'why is this value not what I expect?'" is arguably true there as well.
And, for the record, gdb works decently well with Rust code. Not perfectly (yet) but well enough to be useful. I have tried it (although I'm more of a printf debugger myself).
I do the bulk of my programming in Kotlin these days, and I'd say that the primary reason is because IntelliJ's debugging support is so good. Aside from the ones you mention, key advantages of a good IDE debugger include:
1.) Ability to see the value of every variable in scope without needing to decide a-priori which variables are worth looking at.
2.) Ability to traverse the call-stack and identify at what point a computation went wrong without having to instrument every single call & variable.
3.) Ability to interactively try out new code within the context of a stack frame. When I find a bug, oftentimes I'll try 3-4 new approaches just by entering watch expressions until I find an algorithm that works well on the data. This would take 3-4 full runs without the debugger.
4.) Ability to set conditional breakpoints and skip all the data that's working properly, only stopping on one particular record. When your loops regularly have 100k iterations before they fail on one single iteration, that's a lot of log output to sift though (or a lot of unnecessary loop counters & if-statements) for a rarely-encountered case.
Honestly when I'm dealing with memory errors and undefined behaviors I can count on my hands the number of time a debugger saved me and the hundreds of times I've had to printf my way to victory thanks to 2/3/N-order effects that cascade to the final corruption.
Don't get me wrong, they're handy but I find them much more useful for stepping flow than root-causing errors.
Also if you're dealing with race conditions the only way to safely root-cause to to stash away data somewhere in mem and print it later as flushes/fences/etc change behavior. Debuggers make that even worse.
Love my debuggers for behavior issues but each tool has it's place.
>Also if you're dealing with race conditions the only way to safely root-cause to to stash away data somewhere in mem and print it later as flushes/fences/etc change behavior. Debuggers make that even worse.
I'm not sure how Rust's support is here, but in my experience it's the exact opposite. Debuggers with var-watch or conditional breakpoints can do this (and a heck of a lot more) on the fly, and that's almost always faster than re-compiling and running. Even at the extreme-worst case, you can be a print-debugger with a debugger without needing to rebuild each time, just re-run.
Your conditional breakpoint can change execution behavior thought flushing cache/icache in a way that doesn't reproduce.
X86 is pretty orderly so you usually don't see that class of bugs until you start getting on other architectures but when you do man is it nasty. C/C++ volatile comes to mind particularly. MSCV makes it atomic and fenced which isn't the case pretty much anywhere else.
Also debuggers don't help you with the 2nd/3rd order effects when you need to trace something that's falling over across 5-6 different systems. With print based debugging I can format + graph that stuff much faster than a debugger can show me.
Like I said, different tools for different uses. It's just important to know the right tool so that everything doesn't look like a nail.
>Your conditional breakpoint can change execution behavior thought flushing cache/icache in a way that doesn't reproduce.
Yes, that is definitely true. But so does calling a printing func that does IO, since it often involves system-wide locks - I'm sure many here have encountered bugs that go away when print statements are added. But debuggers are definitely more invasive / have stronger side effects, and have no workaround, yea.
Multiple systems: sorta. Past (legitimately shallow) multi-process debugging that I've done has been pretty easy IMO, you just add a conditional breakpoint on the IPC you want and then enable the breakpoints you care about. Only slightly more complicated than multi-thread since the source isn't all in one UI. Printing is language agnostic tho, so it's at least a viable fallback in all cases, which does make it a lot more common.
---
To be clear, I'm not saying there's never a need for in-bin "debugging" with prints, data collection of some kind, etc. You can do stuff that's infeasible from the outside, it'll always have some place, and some languages/ecosystems give you no option. Just that it's far later than most people encounter, when a sophisticated debugger exists. E.g. printf debugging in Java that I encounter is usually due to a lack of understanding of what the debugger can do, not for any real benefit.
You should try it before making uneducated, general comments that don't add anything. Rust in CLion/IntelliJ using LLVM is terrible: breakpoints and stack callers work, but variables, llvm and the rest are 99% broken.
I prefer ASAN/UBSAN to either debuggers or printf-style debugging in such cases, but it's not always available.
I think a lot of debugger vs printf-style debugging is a matter of preference and familiarity. I'm used to debugging embedded or distributed systems where debugger support is not so great, so I've gotten used to other techniques (including printf-style stuff). But a lot of people love using debuggers, and I find it elitist to tell them they're wrong.
Yeah, I've never had that pleasure except in toy scenarios but they are cool tools! Usually I'm dealing with 2-3 vendors worth of cruft and platforms that aren't publicly available.
You'd be impressed with the power of formatted printf + excel. Solved some fun issues like quaternion interpolation normalization via graphing and the like.
I did specifically mention "normal code". `unsafe` is not normal code. Obviously if there is a segfault, I'd fire up a debugger - GDB is just fine for such purposes.
The comparison with Java is interesting. With Java, I have often found that errors occur in a rather non-local fashion, due to dynamic code loading, confusing inheritance trees, and ubiquitous mutations and what have you. Maybe I'm not actually calling the function I thought I was, maybe because I have actually received a subclass of my expected class. Print-debugging is often too narrow to highlight the cause. In such a situation, I would fire up the debugger and inspect the general state of the application (which Java makes relatively easy to do).
In contrast, in Rust things tend to happen in a very constrained fashion. You can't randomly mutate things, you can't (without considerable effort) make complicated graph structures where everything can touch everything else. With the occasional exception of highly generic code, your call sites and function arguments are exactly what you expect. So I can rely on print-debugging to quickly find the cause of my problem.
Incidentally the same is true with Haskell, moreso even, except due to laziness the evaluation order can be harder to ascertain - debug statements can appear in a strange order (or not at all).
You are being overly-pedantic in your interpretation of the comment you are responding to. It isn't claiming that we have absolutely no undefined behaviour or memory errors in rust. The point is that undefined behaviour and memory errors are rare in Rust development, so tools intended to help find memory errors are just a lot less useful.
Parent probably implies "with the exception of unsafe" when he says "normal code". Unsafe code is supposed to lack many of the benefits of Rust's memory model.
And that'd be a totally useful way of looking at it if most real Rust programs didn't have any "abnormal" (unsafe) code in them. They do, though, and it still must be debugged somehow. Maybe the "unsafe" is hidden away in some transitive dependency crate or even in std, but it's there.
It's incredibly useful to limit the regions of unsafety and use them to build reusable, well-tested safe abstractions, but it's a mistake to confuse that with eliminating unsafe entirely or ignore the possibility there could still be errors within them.
> And that'd be a totally useful way of looking at it if most real Rust programs didn't have any "abnormal" (unsafe) code in them. They do, though,
I'm willing to bet that the vast majority of Rust code (outside of std) is safe. I've written unsafe once ever, in years of writing rust.
I agree that it's unfair to generalize that debuggers have no use in rust, but it's fair to generalize and say that most rust developers do not experience segfaults, or other memory corruption issues that often call for a more advanced approach to debugging.
I'd guess that about 1% of Rust code is unsafe (holds true for a project of mine) but almost all Rust projects depend on some crate's unsafe code. And I've hit segfaults caused by unsafe code in crates I depended on several times. (Most commonly, due to FFI code trying to duplicate a C library's ABI in a .rs file and not getting it exactly right for the version/config options it the library was built with on my machine. This is a disturbingly brittle way of doing things but will probably be common until bindgen is distributed with rustup by default or some such.)
You may not use the debugger often, but it's there if you need/want it, which is an important message that I think is lost with "all Rust programmers are print debuggers".
Congrats on only using unsafe once in years. That's pretty neat.
> I'm willing to bet that the vast majority of Rust code (outside of std) is safe. I've written unsafe once ever, in years of writing rust.
It's very much about project choice. I immediately ran into unsafe trying to test some functions marked extern. Then again writing toy VMs and GC algos.
Not when you have a proper IDE setup where building + running it in debugging session are all done with a single action. I've done print debugging for a long time, and here and there it still makes sense, but I've found that it's honestly worth putting in the effort once per (decently sized) project to just set up the IDE properly. And honestly once you have done it once, it's mostly just copy pasting the same config from project to project.
A lot of us believe that we spend a much smaller portion of our time looking at or debugging existing code than we really do. If you don't believe it's a time suck then you have very little incentive to keep pushing to get better at it. So the majority of us quickly reach a point where we are satisfied that we 'know how to debug' but leave a lot of room for improvement on the table.
The best description I've heard for master-level debugging is that it's a process of narrowing down the problem space as cheaply as possible. Your brain is telling you that based on everything you 'know' about the code, the right answer should come out. If the wrong answer is coming out, something you 'know' is wrong.
After the most obvious failure mode doesn't reveal the problem, your next check may not be the second most obvious failure. Instead you're multiplying the cost of verifying an assumption times the likelihood it's correct times the 'area' of the problem space it eliminates. Checking things like "is it plugged in?" sounds stupid but brings down the worst-case resolution time by hours.
Long story short, let's say I'm sitting in an interactive debugger looking at a stack frame, expecting that a particular variable has the wrong value, but it's fine. The cheapest thing for me to do next is to look at all of the neighbors of the suspicious value, and those in the caller and on the return. With println, pretty much every subsequent check costs the same amount as the first one. And if there's no short path from starting the app to running the scenario, that cost could be pretty high.
If you believe that you have a high success rate on your first couple of guesses, then println works great for you. But what if you're wrong? Have you ever tracked how many attempts it usually takes you? Or are you too wrapped up in the execution to step back and think about how you could do better next time?
Also, I want to be clear that I'm not telling anybody how to debug, as long as you aren't making that choice for your whole team. Don't choose tools or code conventions that break interactive debugging because "println was fine for grandpa so it's good enough for me!" That's a big ol' case of Chesterton's Fence.
Having experienced the higher plane of fully integrated IDE / run / debugging with arbitrary expression evaluation, conditional breakpoints, etc, I can't even imagine how anyone could work with "print debugging".
I actually have gone in the opposite direction. I used to use a step-through debugger for all my debugging needs, but at this point I pretty much only do printf debugging.
I find that in most cases it's easier for me to figure out what's going on, because I can quickly scan a log of how different variables changed over time, instead of having to step through one step at a time.
Even if you have everything working just the way it should, in the majority of cases print debugging is enough because problems boil down to the assumptions in your head about what should be a variable not being reflected by what it is in your program.
You write tests? Consider selecting variables of interest (and printing them to STDERR when debug mode is on) like one of many test.
Looking at memory and all the variables has its place, but as you said only "here and there" - because when you have to do that, you have already lost: you are looking for a needle in a (hay)stack, and will lose much more time that just eyeballing the variables of interest you selected before.
Just wanted to say that your rust projects are a blast to watch from afar on twitter. You've done seemingly really crazy things with Rust + Zelda Wind Waker.
I so deeply hate that there is so much good content on Twitter that is simply lost if I don't happen to login on the given day. God forbid I'm not on the platform at all. It's so weird how RSS + Blog is a better experience for everyone, except advertisers.
Anyway, I'm super curious what someone is doing with Rust and Zelda. How do I learn more without Twitter?
I was actually thinking of the crazy stuff the OP does to modify the game (geometry and collision, I think) [1] with rust. I hadn't even seen WindWakerBetaQuest - that's also really cool!
Convenient, easy to access / use debuggers are a boon for logic bugs. Being able to see the flow of the program and snapshots of state reduce the time it takes to identify and fix bugs significantly.
Perhaps everyone being a print debugger in Rust is less a compliment to the language, but a criticism of the tooling. I absolutely adore Rust, but understand there are still some vast gaps in the tooling.
Really it's just because the debugging experience sucks. If you could actually print out the value of local variables in the debugger, using their `fmt::Debug` representation, that would be great, but that just isn't the case yet. Instead, we're stuck with adding print statements and recompiling our code, which depending on the size of the project can take forever.
Tbh I do the same. GDB is just a massive tool that I feel uncomfortable with.
Maybe that is a missing niche of the market; a debugging protocol similar to the language protocol used in VSCode (RLP in Rust provides this).
Then the IDE could integrate with any language and debug it, regardless of the details on how the language functions. And it can provide a better UI than GDB (which isn't a high bar, it's more like trying to dig down to find the bar because GDB UI is horrid)
The left regularly address each other as "comrade", albeit sometimes a little tongue-in-cheek. Solidarity is an important and necessary part of the culture, given the odds are heavily stacked against them.
I had to do a double-take here, I was thinking "I don't think Bernie is all that radical, but I wouldn't describe him as center-right". But of course the US gets the colors backwards.
1. US military is only 16-18% of federal spending. Entitlements like social security, medicaid, and welfare make up 65-70% of federal spending. The majority of military spending is on salaries and benefits anyway, it's essentially a welfare program itself
>delivers the least
2. most major advancements in tech and healthcare are due to the military. Silicon Valley was built on military spending. Self driving cars were initially funded by DARPA. AI was funded by military. If you have a job in the tech industry you can thank the US military
There's also the minor detail of the US navy making global trade possible and the strength of the US military making traditional war pointless which has resulted in the last few decades being the most peaceful in human history in terms of probability of dying in combat
> 2. most major advancements in tech and healthcare are due to the military.
Can you back that up? That military spending has been high gives no guarantee that having spent the same money in the private sector wouldn't have led to even better results and advancements.
private sector doesnt do basic research and has a short view of things because of the drive towards profitability.
gov't-funded R&D is why we have nice things. everyone strategically forgets that silicon valley exists because of bottomless cold war spending, so silicon valley's obsession with the superiority of the private sector is ever ironic
The private sector is generally very, very heavy on short-termism. Even when companies do have internal long-term research initiatives, there is often a strong aversion to pursuing research that could cannibalize high-margin products.
Unequivocally, no, the reasons are stated in the post you're replying to.
Which private, for profit, company would spend five (5) billion dollars (unadjusted for inflation) to launch GPS satellites into space and then allow their unlimited use free of cost to anyone in the world who has a receiver? That cost doesn't even account for ongoing maintenance.
Maybe no company would do exactly that, but that is irrelevant. Companies would do other things with that money. Maybe they would have cured some disease instead. Maybe they would have found another breakthrough technology. Who knows.
And there is nothing free about using those satellites. Tax payers pay for their launch and subsequent maintenance and running costs.
From an economics point of view, an unnecessary job is inefficient not because it gives people money (they can spend it efficiently on themselves), but because it wastes people's time when they could be doing something else. (Not to mention other wasted resources.)
Social security is efficient because it doesn't have this problem.
The mess the US foreign policy of the previous administration caused in Middle East alone ( not counting Ukraine and Libya ) has an immense cost and no real benefit. Of course others are left alone to pay the bill.
I would call that a total failure by any possible interpretation.
You can only call that a total failure if you ignore the entirety of human history and compare it to some fantasy of world peace instead. It's good to thrive for a better world, and notice when things go worse, but when evaluating effectiveness of american military as a whole, you should compare it to a time before Pax Americana.
Also, did I understand you correctly: you not only want to cut american military spending, but also keep US morally responsible for situation in Ukraine?... Now, both these viewpoints are to some extent reasonable, if they come from corresponding first principles. But I can't possibly imagine how the same person can hold these two views at the same time: they completely contradict each other. Either US is responsible for events across the globe, OR it shouldn't have a huge military - how on Earth can you believe both?!
What is the US supposed to do? You literally cited two cases, Ukraine and Libya, which are polar opposites. Ukraine the US is criticized for NOT intervening, middle east and Libya US is criticized FOR intervening.
And now we have Myanmar muslim situation and Yemen where people are begging for US intervention, but in all probability if we intervened we would be getting criticized for it by the same people asking us to intervene in a few years
>and US and their trade partners enjoy safe trade routes
Bingo, and that's from the Navy and the U.S. Coast Guard actively patrolling GLOBAL waters.
Maritime piracy alone is a considerable economic threat, yes in the 21st century. An estimated 2 BILLION dollars a year is spent on naval operations just off the coast of Somalia (PDF WARNING - PDF WARNING - PDF WARNING http://www.ics-shipping.org/docs/default-source/Piracy-Docs/... )
In this article from 2014 ( https://worldmaritimenews.com/archives/134829/annual-global-... ), again just Somalia, "The OEF estimates the total cost of piracy off the coast of Somalia at US$7–US$12 billion in 2010; US$6.6–US$6.9 billion in 2011 42 and US$5.7–US$6.1 billion in 2012".
Military in the US is 18% of the budget. SS and medicare are something like 70%.
If you want to live in a country without a military there are a bunch of them. I wouldn't personally want to live in any of them, but of course everyone is free to do as they see fit.
Iceland has no military spending
Ireland spends 0.4% of it's GDP on military
Switzerland 0.7%
Sweden 1%
Finland (who have actually been invaded in living memory) 1.4%
The U.S. spent $574b on defence and $79b on veterans last year, both increased way above inflation - total of $57b. Education by comparision dropped by 14%, or $9b. Health by 18% or $15b.
The largest slice of the U.S. budget is healthcare (mainly medicare/medicaid). This cost $5,500 per citizen, despite only covering 1/3rd of the population. This is because the U.S. health care system is fundamentally broken, and costs about 3 times as much per person in europe.
Without the US military all of these countries would be required to fund a large military to avoid being conquered. Pax Americana has allowed Europe to shirk their responsibilities, but some people would argue its worth it to the US.
Not entirely true. It has no standing army, but it does have a militarized coast guard, air defense systems and an air force base it maintains, as well as a small Crisis Response Unit that can be deployed internationally. In addition it is a full NATO member for which it has certain costs.
You get to have that system because the US has taken on the role of global police and funds our military at a level commensurate to that role.
If you funded your military appropriately, we wouldn't have to fund your defense.
Your comment about healthcare is so simplistic it's not even worth a reply, but I'll simply note that the vast majority are not on medicare or medicaid and are covered by private insurance. Your assertion that the system is broken is simplistic and uninformed (ETA, I'm not saying the system isn't broken, there are many issues with healthcare in the US, but "just be like Europe" isn't going to work for so many reasons it's not really feasible to list them here).
The US spends $10200 a year per head on healthcare, most of it ($8k a year) government or compulsory spending.
Canada spends $4800 a year on healthcare in total -- under half that of the U.S. Israel spends $2800.
That's a sign of a broken system.
Use Canada's system, cut your mediacare/aid tax, and your companies no longer need to spend money on healthcare when employing them. Using Canada's system removes the tax on jobs that the U.S. loves so much.
> You get to have that system because the US has taken on the role of global police
Why? Who benefitted from invading Iraq? Who benefits from a dozen different aircraft carrier groups around the world?
IIRC The stated goal of our (Sweden) armed forces is something like the ability to defend 1-2 regions for a single week if we are faced with an invasion.
Our defence budget is 1% of GDP because we are betting on the US (and a few others) continuing to spend as it does, and that it will be in their national interest to help us if the time comes.
If the US slashed its defence budget to a 'reasonable' level, we would have to increase ours in turn to the best of our abilities. If the US brought theirs down all the way to 1%, the only people laughing would be the PLA and Putin himself.
Cars must surely be the main cause. There is an interesting phenomenon known as "shifting baseline syndrome" where we tend to compare our environment to what we recall as a child and inevitably conclude that is has gotten nosier/busier/more polluted, not realizing that environment of our childhoods were already heavily degraded.
The world in which we evolved would have been almost silent, almost all of the time, apart from the sounds of birds and insects. And there would have been very little to 'look' at (no text/decor/branding, few hard surfaces, few straight lines, little color and texture variation). And of course no pollution, and very little to 'do'! So it shouldn't be a surprise to find that the sheer sensory intensity of modern living contributes towards depression and schizophrenia [1].
How much time have you spent in the woods? It's definitly far, far from quiet. At least where I grew up. Maybe in the dead of the night, but here in the middle of the city, on a Main Street, it is also so quiet in my room that I can hear my la croix fizzing from 8 feet away.
Some visitors to Copenhagen remark that it's surprisingly quiet for a capital city. Others say it "feels boring", which I think is partly because they associate a noisy city centre (e.g. London or Paris) with fun.
There are far fewer cars in the city centre than most cities the size of Copenhagen; enough roads are restricted to people on foot or bicycles that relatively few people try and drive to, from or through it.
Definitely wait until spring, preferably summer, unless you're attracted to damp weather.
On OpenStreetMap, the pedestrianized roads are marked in a pale blue-grey [1].
They aren't labelled the same way on Google Maps, perhaps because on the smaller pedestrian streets vehicles aren't always completely banned, just strongly discouraged by the signs, surface, layout, and attitude of pedestrians.
The OSM cycle map layer needs a few updates for consistency, but most roads outside the very centre of the city have a separate cycle lane like one of these [2], or else almost no traffic. At school time or weekends I see 5-6 year old children cycling with their parents — other cyclists will overtake more carefully. Older children make similar journeys alone.
The Netherlands is similar. Within cities, the canals lead to some different approaches, and between cities, they provide nice long-distance cycling routes. I think the Netherlands is probably the better destination for a cycling holiday, but the difference between a Dutch and Danish city doesn't matter for a city holiday.
I agree with cars being the problem. I only thought about that when I learned that laws were drafted to force electric cars to make noise - for a brief couple of seconds I realised how different the world would be if all cars were silent... and then I got my hopes crushed.
I truly cannot picture what life would be like without car noise and light pollution.
In the UK at least, there's a good reason behind the law. Electric cars are required to make noise so that visually impaired people know a car is approaching.
They already make plenty of road noise just from the friction of the tires. If visually impaired people can't hear it, then it's likely because of all the OTHER sources of noise pollution around them.
Traffic in a city where every street is cobblestone and they are traveled by horses with iron shoes pulling carts and carriages with iron tired wheels is not going to be very quiet.
I would expect that the noise was in fact less than modern vehicles but the cities of the past were not full of the quiet sounds of nature that people like to whitewash their imagination with.
Cars, industrial equipment, and things like HVAC systems all play a big role.
Racism was definitely the primary motivator of White flight for the cities, but I also wonder to what extent people just wanted to get away from industrial noise pollution, which surely must have been at a peak during that era.
You can be almost certain that LinkedIn knew it was illegal when they did it, and accurately calculated that the fine they would receive (if any) would be much lower than the value derived from increased membership. In fact they would be stupid not to in winner-takes-all markets like social media.
Silicon Valley has a phrase for such flagrantly unethical practice, it is called "growth hacking".
"It was my job to apply The Formula™. [...] Take the number of vehicles in the field, A. Multiply it by the probable rate of failure, B. Then multiply it by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one."
Would you give up more to ensure your children don’t grow up in a dystopian nightmare? What if the necessary amount is 60% of your income? 90%? What if our only hope is to go back to a 18C standard of living? Unfortunately the planet doesn’t care if you have enough cash to pay rent once you account for your environmental externalities.
Most people would gladly give up their income to ensure their children don’t grow up in a dystopian nightmare. The issue is that not everyone agrees on the way how exactly that money should be spent, and how nightmarish the future looks.
What if we can learn how to control climate and have ice free arctic, green sahara and 21st century standard of living?
While we need a way to penalize air polution (not just co2!), implementing that simply as 'extra money that government can spend on war' is not ideal.
Considering Medicare and social security, that doesn't seem to be the case. The older folks basically said: our children can pay that. And kicked the can down the road because it won't be their problem.
> Most people would gladly give up their income to ensure their children don’t grow up in a dystopian nightmare.
People who start off by making an "I'm taxed too much" argument might do this for their own children, but the whole point is that they're not willing to spend a single dollar to save someone else's children.
That never works. You part of your money today and down the line any random reason become an emergency forcing all your taxes into sustaining this or that politicized program which never does anything but help greasing the wheel of the political machine.
So you both lose your money today and you don't do your children future any better.
Taxation is the wrong answer, taxation works to resolve at most the issues of today, never the issues of tomorrow
As of today the best one can do is ethical spending and information campaigns and hope enough people vote with their wallet for sustainable companies.
