Are we looking at the same video? The turn signal is on long before, the lane change of the car starts long before.. you don't see any reaction of the following driver even when the Tesla's tires finally cross the line, which is the latest point where the following driver must adapt apeed and distance, but nothing happens?
I am not sure about the US, but in most countries I have driven in, putting a turn signal on is asking for permission to enter another lane, and there is no 'right' to go into the other lane or expect drivers currently there to slow down for you.
If there is an obstruction ahead, the safest scenario is to change to an empty lane ('empty' including safety distance) or brake in your lane to avoid hitting it. If you have some other problem you should probably brake slowly and change lanes to the outer edge of the road whenever there are safe gaps.
I would probably be off the gas or braking based on movement of the car in the other lane as part of driving defensively, though i don't think there is any 'obligation' for me to do so.
The behavior of the Tesla would also strike me as rather odd (assuming a right hand drive country unless there is a off-ramp coming up on the left) as it appears to be pulling over to the wrong side of the road.
You don't, but as soon as you see the car in front of you change the lane (or just indicating via turn signal), you should?
And to be honest, this looks more like slowing down and not a hard break, and at least the first following driver slept quite a bit... agreed the stopping had no reason, so (as someone quoted German laws) for that you would be too blame... but for crashing into the car with that video footage, I'm sure the following driver would get at least 80% if not 100% blame.
Yes tracability etc... but to be honest: For such a trivial thing, this thing called commit message right before or after the ticket reference can do the job as well with one less indirection ;)
I think two things play into this: Layers.. it is just easier for people to add layers around something, not touching and understanding the original code and doing it right there. And then profs or someone else always says layering is good!
(It may sure be, or also sometimes such "hacks" are the right thing to do, but if that is always the default mode... uhh oh).
And second, university training: OOP, design patterns, software layers, all claimed to lead to structured good programming automatically still taught in 2023, which is just not true. By untrained or unexperienced personnel leads to worse than 80s spaghetti code..
Just yesterday I exercised with relative who is in university for exam.. Java, design patterns, arggh. Imo it just makes no sense at all to try to teach students inheritance and design patterns with Cat/Dog/Animal et al, it is so backwards. You need to program for a while bigger real systems to see some patterns emerge and their usefulness, and then can relate to the formal way and maybr use some patterns reasonably. But starting with those on toy examples just leads to what you describe:
People going in with their trained knowledge and applying that to everything without rhyme or reason. What could be a simple five liner function already becomes a convoluted abomination. Just one concrete example, but this then on many levels of software engineering.
Who or what will save our future? :D No, it won't be ChatGPT.
(Second lol btw, relative really showed me how likely all of then may use ChatGPT i. their online exams...)
I'm not too hopeful. In my experience, functional programming adoption is divided into two categories:
1) Proper FP languages with good enough semantics and necessary features to write functional code effectively. Those languages all fall into category of "too difficult" for the majority of industry, which seems to suffer from severe allergy to learning anything beyond "Intro to programming in Java 6" freshman class.
Even things like lambdas only recently stopped being too complicated for a typical programming shop that follows well-known best practices, such as "Programs must be written for inexperienced non-programmers with no prior exposure to the problem space to read, and only incidentally for machines to execute.", and "Would somebody think of the juniors?". Closures? Nah, the zeitgeist is still on the fence with this.
Yes, I have a sore spot for this. I've heard this reasoning many times in real life, and once was even target of it - an otherwise competent programmer and a good manager once asked me to stop using lambdas for event handlers in Java 8 (which the company had only recently adopted), for the sake of the juniors who won't understand. In fact, he meant specifically his favorite evergreen junior (who's been in that company a couple years longer than I was then). But guess what, couple juniors actually asked me to explain the how-and-why of lambdas to them and got it near-instantly. Said evergreen junior probably spotted the lambdas in the codebase too, or otherwise got interested in this, read up on the topic independently, and three months later was evangelizing basic functional programming in Java and otherwise upskilling his fellow coworkers.
But yeah, it's too difficult, your co-workers won't understand. Anyway, where was I? Oh right:
2) The other, arguably larger, kind of FP adoption: library-level and code style level implementation of FP features in languages with little or no natural support for them. This doesn't mean people understand FP extra well - they're barely aware of it at all. But every now and then some library gets popular - say, a sum type for error handling (typically known as Result, Either, Expected, or something similar) that's "obviously" "better" than exceptions. Except, that library is doing a half-baked implementation of a concept (e.g. monads) that doesn't fit the language, and the users don't understand what the approximated concept is, nor are they supposed to try (remember, FP is too abstract for a freshman after "Java 6 101" class).
The result is, as expected, an ugly mess in the codebase, displaying all the bad sides of imperative and functional styles, and leveraging none of the good sides.
Anyway, what is my proposed solution to this? For the industry to stop hating education and professionalism. To embrace the idea that the job of a junior is to learn, not to be the yardstick for complexity of the codebase. To encourage a culture of learning, of professionalism, at every level. To stop dismissing or banning techniques that reduce size and complexity of the codebase by large factors, just because one has to invest a couple hours of learning up-front to be able to use them. Etc.
Radiation deaths? Lol guys, I get it, but please don't try to make a bigger fool out ouf you by ridiculing about a point noone ever made.. it is like someone would tell you that our lethargic sitting life styles makes us sick and you stand up and shout: "But noone died from sitting, while tons of people die from sports a lot!!!"
There was recently a foot found in a pond. Lake was acidic and hot. Someone jumped in.
Please don't fuck with nature for fun. It's all great memories, but one of 100 of you will die and someone else has to find your body and clean up your mess.
This so much and to hear it often is similar annoying as those "and if they want to eat a burger/sausage then why don't they eat a real one"... People just not understanding that you do not eat no meat because of taste or disgust, but for ethical andor environmental reasons and just still like similar spice/composition or even just form or type of meal from previous times.
Hey grandposter, we even make burgers at home in many different styles without needing to fit into any social settings, but we also like to just try any offering that is out there, unimaginable!
