You're not trying to steal the truck, you're trying to steal the cargo. You either hook up and haul the trailer off, or just unload what you can and scatter. If it's in a county where the sheriff is the brother of the guy doing the robbery, and the nephew of the guy in charge of the local organized crime, well, the police will get there just in time to not quite catch anyone.
Why would you waste money on a cab for a truck that drives itself?
Why do airliners still have pilots?
Most likely, the driver will still be in the cab for the next 20 years, with fewer husband-wife driver pairs, and more owner-robot driver pairs.
How do the big rigs carrying cars make it up here.
Well, there are definitely problems. The most entertaining of which recently were the guys who hijacked a load of radioactive cargo, but either didn't know what they were doing, or screwed it up badly, as they all ended up in the hospital with radiation sickness, making that the rare hijacking that actually got solved by the police.
so there's no graphic artist trying to make the good guy ships a beautiful white fleet with wings like birds, and the bad guy ships industrial contraptions that are some hideous shade of orange
That's what I loved about the original Star Trek. While, sure, the good-guy ships are white (you need to clue the audience in somehow), the Enterprise was the awkward-looking bunch of parts stuck together to get the job done. It somehow managed a certain elegance, but so can an oil rig. Meanwhile, the Klingon and especially the Romulan warbird were elegantly crafted, sleek warships.
But then, Honor Harrington is just Horatio Hornblower in a different uniform. Most of the naval culture, ship types, and so on were lifted not just from the era, but straight from that series. Though, to be fair, Weber evolved away from that over time and has slowly added his own creativity, especially in the opposition.
People seem to be missing the fact that the main way you make money in hauling is by owning the expensive truck, while driving it is secondary. It's a capital-intensive business with steep costs, both upfront and ongoing.
I would bet this will play out more like airliner autopilots - the driver will still be in the cab for my lifetime, even though he's not usually needed, simply because there's enough other stuff that you need a human to do.
They are, of course. Which is why drivers tend to be armed anywhere that's legal, and don't like to stop anywhere they won't be surrounded by other trucks and truckers. It's not exactly easy to rob one until it stops, movie plots aside (though I'd be surprised if it hasn't happened once or twice in history, especially with moonshiner trucks).
think the transition will take at most 2 to 5 years
That's because you're applying internet logic to real-world infrastructure. Logistics is everything. (Plus, there aren't any real self-driving cars yet - you still need a driver in the seat and will for many years to come.)
Think about over-the-road trucking- remember that owner-operators are a big slice of OTR hauling, and there's little incentive at first to spend even $40k for an auto-driver. Who's going to refuel the truck? Who's going to answer questions about the manifest at a weigh station? Who's going to know how to deal with the cop who pulls you over for a "safety violation", and know whether cops here are honest or this is a shakedown? Who's going to oversee the loading and unloading of cargo, and sign off on any damages?
No worries, millions can move into the "big rig hijacking" business! A semi-trailer full of something easy to sell on the street, or a tanker full of a chemical useful in making meth, or of gasoline (gasoline smuggling was the mafia's most profitable business for years) - all very valuable targets. Today that theft is kept somewhat in check by the real risk of getting shot in the process, or of wrecking the rig if your try a scene out of a Fast and Furious movie. But an AI truck with safety reflexes on a lonely stretch of road? Well, the markets will sort themselves out.
As for the legal trade, driving is a crappy job unless you own your truck, and I rather suspect the owner/operators of today will become the owners of tomorrow. Truckstops may go the way of the buggy whip, but I can't see that happening fast - like all infrastructure changes, the capital outlay is so high this will be a 20-50 year transition.
With other stuff in between, of course. Never occurred to me as a fast approach till I saw it in the object code.
Left shift can be faster or slower, depending on what else the silicon is up to in the near past and future. In my case, where I saw the optimizer doing this, there was another shift operation nearby. Modern optimization is just odd. Division can be the fastest way to accomplish something, as long as you don't need the answer soon, as it's not about the wall clock for any given op an more, it's about making the best use of an oddball heterogeneous set of potentially parallel operations that are related in strange ways. And just about anything's better than a conditional branch, of course.
There's still stuff where the optimizer can't safely make enough assumptions to beat human optimization, of course, but you can manually optimize that stuff in C. I miss the days where caring about that level of performance commonly mattered - now it's down to odd niches.
Depends - did you do a shift or multiply in the previous several instructions? When do you need the result? Do you need to add anything else soon, or is the adding silicon idle? Modern compilers actually keep track of all that. For sure, if you need to shift two values, doing each a different way is faster.
The important stuff the coder can provide to help with optimization comes down to: avoid conditional branches, and emphasize locality of reference (I miss the days when a 256-byte lookup table was the fast answer to most bitwise questions).
Slapping him in maximum security prison for life with no chance of parole might as well be death, but is something like 1/10th as expensive as execution.
Plus, in death he gets to be a martyr and his story paraded around on recruitment drives. But in life he can be forgotten and quietly keel over (after a couple years of a porkrind and bacon diet).
So have his method of execution be "raped to death by pigs". Might be even more expensive, but I'm pretty sure a kickstarter would cover it.
From experience I know that a well-trained, well-weathered assembly hacker can generate code faster than the compiler.
This hasn't been true since instruction pipelining. And it hasn't been true for maintainable assembly source for abut 20 years.
Quick, what's the fastest way to multiply an integer by 8? Did you answer "depends on the previous 20 instructions, but probably 3 adds separated by 3-4 instructions each"? There's just too much state to keep track of with which silicon is doing what for how long following each instruction.
Are you trying to apply the scientific method to climate change predictions? Which oil company do you work for? Something something Fox News argle bargle!
Have you ever taken the time to look at job listings, to see just what businesses are asking for? Keep in mind as you look: If, for whatever reason, a programmer is unfamiliar with any language, tool, development process, framework, or hair-care product listed as a "required skill", said programmer is not "qualified" for the job.
All of which only matters IME if you're new to the industry. Once you've proven yourself, it's a different world. Your problem domain matters a lot, and its damn hard to change disciplines when the time comes (I've had to do it twice now over 24 years, I'm sure I will again). But toolset? I was hired for a Java job despite no Java experience at all, then hired for a C# job with only basic familiarity with C#. In my current job, we only care that mid-career developers have experience with some "curly brace language" (and I'd bet we'd interview a Python dev if we had a referral), and college hires must demonstrate strong coding skills in whatever language they choose. I've never even been asked about the rest of the toolset.
Is this some front-end-web-guy problem? That job market seems saturated, but we're getting desperate for talent in the backend/infrastructure world.
None of that follows from it being written in assembly.
My first 5 years as a dev were spent working on a team that maintained an all-assembly OS, database, print server, and so on. Very fast, very small. But you can get all that in C, and a modern C compiler on full optimization produces object much faster than any sane, maintainable assembly source.
It's a mindset issue, not a toolset issue. Actually using assembly is a great way to keep the right mindset throughout. Plus, learning to read assembly fluently, find bugs by glancing at core dumps, fix bugs with a sector editor to save an assembler pass when you're in a hurry, bugfix a running program in memory - all of that builds your coding muscles, even if it all a bit silly for a modern prod environment.
Well, he's still an EP, I think, but that's just money. You could see the decline starting in 97, when he starting developing Futurama, and by 99 he wasn't really involved creatively with the Simpsons any more, AFAIK. Somewhere in there, Homer jumped a shark on waterskis just to drive to point home. I can't for the life of me remember what season that was, but soon after the show changed format, and stopped being a 30-minute (well, 22-minute) plotline, and went to 2-3 shorts per episode.
The manager should know how? The problem should be raised how? Ideally, whoever you need is immediately available, but in the real world, it's good to have a 15 minute window each day when everyone is there and paying attention.
I've been on several projects over my career where months were spent designing stuff in painful detail, and half the design would inevitably be thrown away as requirements changed during the 18-month release cycle. Throw-away coding work, throw-away design work, throw-away costing and task breakdown work. What crap. And then people would start getting indignant about requirements changes (because no one likes to see work thrown away), and it's all downhill from there.
And then at the end, the PMs are livid that we built what they asked for, instead of what they wanted, and its too late now to change. I've seen some horrific shit under the waterfall. At least there's legitimate cause to say that people who screw up that badly with Agile aren't doing Agile by-the-book, while the people who screw up that badly with waterfall made the mistake that they are doing waterfall by-the-book.
At least the Simpsons had the dignity to literally jump the shark around the time Groening left. For me, that was when the series tanked, but fortunately Groening's humor was there in Futurama soon after.
Not when you have a large project, being delivered by 30 or 100 devs. You don't do scrum at that level (well, some do some silly scrum-of-scrums nonsense), but you do do Agile. The actual teams developing the deliverables, though, need to be kept small for scrum to work. (There are non-scrum flavors of Agile, too).
However big or small your project, however, if you don't accept that requirements will change, and choose some methodology that makes it cheap to change, or if you don't get the smallest V1 you can into actual customer hands as fast as you can, to learn what you really should have built, it's time to get with the century. (Unless you're making an airplane engine or something.) Agile has some strong points here, and I'm sure there are yet better ways, but waterfall is only really suited for projects with immutable and certain requirements (as building the software for some complex hardware project sometimes is).
You should never have more than 8 people in a scrum team. That's a sure sign you're doing it wrong. 5 or fewer devs working together on a set of features, plus the overhead - that's the team - not all the guys who happen to report to the same manager or some shit.
Standups are the one time you're guaranteed to catch everyone on your team, so that you can't be blocked for more than a day on anyone internal - and the scrum master should be taking note of anything external your blocked on.
When scrums say more than "I'm on track, next" or "I'm blocked by X" or "I'm late, sorry", the only real excuse is that you're not using any issue tracking system for tasks, and so the 15 minutes standing around at least saves you the time to keep fiddling with tasks in a DB. If it takes more than 15 minutes, you should just walk away from the standup (I've done this before - it sends a strong signal once multiple people have the courage to do so).
Besides, a daily scrum as they are supposed to be done is meant for team members to get together to tell each other what they are doing. Managers are not supposed to be involved or run them.
A great sign that you're doing Agile right is the absence of weekly status reports. Your boss should learn all he needs by listening to the scrums, and seeing what actually get delivered at the end of each sprint. If you have scrums and also have weekly team meetings or status reports, then you have the worst of both worlds, and should probably fire your boss (economy permitting - lots of hiring in the Seattle area!).
There are 2 sure signs that someone isn't doing Agile, they're just doing "fail fast" (and not in a good way): no Q/A, and no participation of the product owner in the routine process (or even sadder, no product owner even designated).
we the developers were the first ones to go "Woah there, Peaches".
Sexist.
There aren't so many gender-neutral horse names to choose from. You seem quick to judge - perhaps he alternates between fillies and stallions in his horse metaphors.
Slashdot Mirror
Sound fair to me. Only idiots and racists care about race.
You're not trying to steal the truck, you're trying to steal the cargo. You either hook up and haul the trailer off, or just unload what you can and scatter. If it's in a county where the sheriff is the brother of the guy doing the robbery, and the nephew of the guy in charge of the local organized crime, well, the police will get there just in time to not quite catch anyone.
Why would you waste money on a cab for a truck that drives itself?
Why do airliners still have pilots?
Most likely, the driver will still be in the cab for the next 20 years, with fewer husband-wife driver pairs, and more owner-robot driver pairs.
How do the big rigs carrying cars make it up here.
Well, there are definitely problems. The most entertaining of which recently were the guys who hijacked a load of radioactive cargo, but either didn't know what they were doing, or screwed it up badly, as they all ended up in the hospital with radiation sickness, making that the rare hijacking that actually got solved by the police.
so there's no graphic artist trying to make the good guy ships a beautiful white fleet with wings like birds, and the bad guy ships industrial contraptions that are some hideous shade of orange
That's what I loved about the original Star Trek. While, sure, the good-guy ships are white (you need to clue the audience in somehow), the Enterprise was the awkward-looking bunch of parts stuck together to get the job done. It somehow managed a certain elegance, but so can an oil rig. Meanwhile, the Klingon and especially the Romulan warbird were elegantly crafted, sleek warships.
But then, Honor Harrington is just Horatio Hornblower in a different uniform. Most of the naval culture, ship types, and so on were lifted not just from the era, but straight from that series. Though, to be fair, Weber evolved away from that over time and has slowly added his own creativity, especially in the opposition.
People seem to be missing the fact that the main way you make money in hauling is by owning the expensive truck, while driving it is secondary. It's a capital-intensive business with steep costs, both upfront and ongoing.
I would bet this will play out more like airliner autopilots - the driver will still be in the cab for my lifetime, even though he's not usually needed, simply because there's enough other stuff that you need a human to do.
How are these not targets already?
They are, of course. Which is why drivers tend to be armed anywhere that's legal, and don't like to stop anywhere they won't be surrounded by other trucks and truckers. It's not exactly easy to rob one until it stops, movie plots aside (though I'd be surprised if it hasn't happened once or twice in history, especially with moonshiner trucks).
think the transition will take at most 2 to 5 years
That's because you're applying internet logic to real-world infrastructure. Logistics is everything. (Plus, there aren't any real self-driving cars yet - you still need a driver in the seat and will for many years to come.)
Think about over-the-road trucking- remember that owner-operators are a big slice of OTR hauling, and there's little incentive at first to spend even $40k for an auto-driver. Who's going to refuel the truck? Who's going to answer questions about the manifest at a weigh station? Who's going to know how to deal with the cop who pulls you over for a "safety violation", and know whether cops here are honest or this is a shakedown? Who's going to oversee the loading and unloading of cargo, and sign off on any damages?
let the markets sort themselves out.
No worries, millions can move into the "big rig hijacking" business! A semi-trailer full of something easy to sell on the street, or a tanker full of a chemical useful in making meth, or of gasoline (gasoline smuggling was the mafia's most profitable business for years) - all very valuable targets. Today that theft is kept somewhat in check by the real risk of getting shot in the process, or of wrecking the rig if your try a scene out of a Fast and Furious movie. But an AI truck with safety reflexes on a lonely stretch of road? Well, the markets will sort themselves out.
As for the legal trade, driving is a crappy job unless you own your truck, and I rather suspect the owner/operators of today will become the owners of tomorrow. Truckstops may go the way of the buggy whip, but I can't see that happening fast - like all infrastructure changes, the capital outlay is so high this will be a 20-50 year transition.
R1 += R1
R1 += R1
R1 += R1
With other stuff in between, of course. Never occurred to me as a fast approach till I saw it in the object code.
Left shift can be faster or slower, depending on what else the silicon is up to in the near past and future. In my case, where I saw the optimizer doing this, there was another shift operation nearby. Modern optimization is just odd. Division can be the fastest way to accomplish something, as long as you don't need the answer soon, as it's not about the wall clock for any given op an more, it's about making the best use of an oddball heterogeneous set of potentially parallel operations that are related in strange ways. And just about anything's better than a conditional branch, of course.
There's still stuff where the optimizer can't safely make enough assumptions to beat human optimization, of course, but you can manually optimize that stuff in C. I miss the days where caring about that level of performance commonly mattered - now it's down to odd niches.
Not a left shift?
Depends - did you do a shift or multiply in the previous several instructions? When do you need the result? Do you need to add anything else soon, or is the adding silicon idle? Modern compilers actually keep track of all that. For sure, if you need to shift two values, doing each a different way is faster.
The important stuff the coder can provide to help with optimization comes down to: avoid conditional branches, and emphasize locality of reference (I miss the days when a 256-byte lookup table was the fast answer to most bitwise questions).
Slapping him in maximum security prison for life with no chance of parole might as well be death, but is something like 1/10th as expensive as execution.
Plus, in death he gets to be a martyr and his story paraded around on recruitment drives. But in life he can be forgotten and quietly keel over (after a couple years of a porkrind and bacon diet).
So have his method of execution be "raped to death by pigs". Might be even more expensive, but I'm pretty sure a kickstarter would cover it.
From experience I know that a well-trained, well-weathered assembly hacker can generate code faster than the compiler.
This hasn't been true since instruction pipelining. And it hasn't been true for maintainable assembly source for abut 20 years.
Quick, what's the fastest way to multiply an integer by 8? Did you answer "depends on the previous 20 instructions, but probably 3 adds separated by 3-4 instructions each"? There's just too much state to keep track of with which silicon is doing what for how long following each instruction.
Are you trying to apply the scientific method to climate change predictions? Which oil company do you work for? Something something Fox News argle bargle!
Have you ever taken the time to look at job listings, to see just what businesses are asking for? Keep in mind as you look: If, for whatever reason, a programmer is unfamiliar with any language, tool, development process, framework, or hair-care product listed as a "required skill", said programmer is not "qualified" for the job.
All of which only matters IME if you're new to the industry. Once you've proven yourself, it's a different world. Your problem domain matters a lot, and its damn hard to change disciplines when the time comes (I've had to do it twice now over 24 years, I'm sure I will again). But toolset? I was hired for a Java job despite no Java experience at all, then hired for a C# job with only basic familiarity with C#. In my current job, we only care that mid-career developers have experience with some "curly brace language" (and I'd bet we'd interview a Python dev if we had a referral), and college hires must demonstrate strong coding skills in whatever language they choose. I've never even been asked about the rest of the toolset.
Is this some front-end-web-guy problem? That job market seems saturated, but we're getting desperate for talent in the backend/infrastructure world.
None of that follows from it being written in assembly.
My first 5 years as a dev were spent working on a team that maintained an all-assembly OS, database, print server, and so on. Very fast, very small. But you can get all that in C, and a modern C compiler on full optimization produces object much faster than any sane, maintainable assembly source.
It's a mindset issue, not a toolset issue. Actually using assembly is a great way to keep the right mindset throughout. Plus, learning to read assembly fluently, find bugs by glancing at core dumps, fix bugs with a sector editor to save an assembler pass when you're in a hurry, bugfix a running program in memory - all of that builds your coding muscles, even if it all a bit silly for a modern prod environment.
Well, he's still an EP, I think, but that's just money. You could see the decline starting in 97, when he starting developing Futurama, and by 99 he wasn't really involved creatively with the Simpsons any more, AFAIK. Somewhere in there, Homer jumped a shark on waterskis just to drive to point home. I can't for the life of me remember what season that was, but soon after the show changed format, and stopped being a 30-minute (well, 22-minute) plotline, and went to 2-3 shorts per episode.
The manager should know how? The problem should be raised how? Ideally, whoever you need is immediately available, but in the real world, it's good to have a 15 minute window each day when everyone is there and paying attention.
I've been on several projects over my career where months were spent designing stuff in painful detail, and half the design would inevitably be thrown away as requirements changed during the 18-month release cycle. Throw-away coding work, throw-away design work, throw-away costing and task breakdown work. What crap. And then people would start getting indignant about requirements changes (because no one likes to see work thrown away), and it's all downhill from there.
And then at the end, the PMs are livid that we built what they asked for, instead of what they wanted, and its too late now to change. I've seen some horrific shit under the waterfall. At least there's legitimate cause to say that people who screw up that badly with Agile aren't doing Agile by-the-book, while the people who screw up that badly with waterfall made the mistake that they are doing waterfall by-the-book.
At least the Simpsons had the dignity to literally jump the shark around the time Groening left. For me, that was when the series tanked, but fortunately Groening's humor was there in Futurama soon after.
Not when you have a large project, being delivered by 30 or 100 devs. You don't do scrum at that level (well, some do some silly scrum-of-scrums nonsense), but you do do Agile. The actual teams developing the deliverables, though, need to be kept small for scrum to work. (There are non-scrum flavors of Agile, too).
However big or small your project, however, if you don't accept that requirements will change, and choose some methodology that makes it cheap to change, or if you don't get the smallest V1 you can into actual customer hands as fast as you can, to learn what you really should have built, it's time to get with the century. (Unless you're making an airplane engine or something.) Agile has some strong points here, and I'm sure there are yet better ways, but waterfall is only really suited for projects with immutable and certain requirements (as building the software for some complex hardware project sometimes is).
You should never have more than 8 people in a scrum team. That's a sure sign you're doing it wrong. 5 or fewer devs working together on a set of features, plus the overhead - that's the team - not all the guys who happen to report to the same manager or some shit.
Standups are the one time you're guaranteed to catch everyone on your team, so that you can't be blocked for more than a day on anyone internal - and the scrum master should be taking note of anything external your blocked on.
When scrums say more than "I'm on track, next" or "I'm blocked by X" or "I'm late, sorry", the only real excuse is that you're not using any issue tracking system for tasks, and so the 15 minutes standing around at least saves you the time to keep fiddling with tasks in a DB. If it takes more than 15 minutes, you should just walk away from the standup (I've done this before - it sends a strong signal once multiple people have the courage to do so).
Besides, a daily scrum as they are supposed to be done is meant for team members to get together to tell each other what they are doing. Managers are not supposed to be involved or run them.
A great sign that you're doing Agile right is the absence of weekly status reports. Your boss should learn all he needs by listening to the scrums, and seeing what actually get delivered at the end of each sprint. If you have scrums and also have weekly team meetings or status reports, then you have the worst of both worlds, and should probably fire your boss (economy permitting - lots of hiring in the Seattle area!).
Well put.
There are 2 sure signs that someone isn't doing Agile, they're just doing "fail fast" (and not in a good way): no Q/A, and no participation of the product owner in the routine process (or even sadder, no product owner even designated).
we the developers were the first ones to go "Woah there, Peaches".
Sexist.
There aren't so many gender-neutral horse names to choose from. You seem quick to judge - perhaps he alternates between fillies and stallions in his horse metaphors.