How about Microsoft merge with Oracle and then merge with Comcast and Spectrum and AT&T, and then the whole ball of flaming shit burns a painful ugly death live streaming for everybody to see and dance to. Hell, I might even leave the basement to witness it in person.
I've been waiting for decades to see MS die. I'll do some unmentionable acts on their grave when they do. The downside is some other near-monopoly will move into their place and start the cycle again.
How much can states override the FCC's proclamations? While the Constitution gives the Federal Gov't control over most "interstate commerce", within a state, in theory the state should have a lot of control in terms of privacy, throttling, anti-trust, etc.
Let the red states have choice-free oligopolies that overlord their content and privacy; the fools deserve it.
Before a single line of code hits the IDE, you plan out what you're trying to solve, the problems you have to deal with, and how the logic will have to act. Coding happens after the "hard" work has been done, once you have a good idea of what has to be done and how to do it.
In ideal-land yes. Reality is more nuanced. For one, the customer often doesn't fully know what they want until they actually use it in practice. If you are lucky, you can ask them a lot of questions and play with examples to try to tease out what they really need, but often such interview time is limited for various reasons, and has an upper limit to what it can accomplish because sometimes one just has to see something in action to understand the full implications of it.
Also, one often discovers issues or questions while coding that they otherwise didn't think about earlier. When you mentally immerse yourself in a particular feature or section, you notice things that you didn't while casually contemplating it.
It's kind of like house shopping: despite spending hours walking around the house, some things you just don't notice until after you move in. You may have tested the hot water in the kitchen, but you forgot to test in the restrooms, assuming that if it works in the kitchen then it works everywhere. You'll discover similar oversimplifications that were made while drafting the original plan.
That 100 million lines probably includes Windows or Linux or whatever is being put in the infotainment systems - not in the actual vehicle control systems.
Unless a hacker uses the infotainment and/or navigation system to hack into the direct controllers. Such holes have been discovered, I believe. Making sure the infotainment/nav system doesn't have such holes itself can be a daunting problem. One can perhaps fully separate them, but then some handy UI shortcuts or conveniences may be sacrificed.
For example, if there is an urgent message about the car's condition, you'd like it announced through the infotainment system. In order to do that, you'd need some connection between it and the controllers. And it would probably need a two-way feedback system to know at least if and when to end the message and turn the regular sound back up. As soon as this connection exists, the potential for inter-system hacking appears.
Apple realized there are enough rich people (or wannabe/fake rich) who see high-end phones as a status symbol, and they are more than happy to milk this group for cash. Why not? I'd do the same in Apple's iShoes.
I generally agree and this is why I said, "but as implemented I fail to see it." Even the attribute-driven systems I suggest have separate entities for data definitions (AKA "models"), routing/flow (controller), and UI adapters.
All well-partitioned/designed framework will indeed probably have some form or aspect of MVC in it.
Another thing I didn't mention as that a one-size-fits-all CRUD engine is probably too big of a goal (unless somebody wins the big lottery). One-size-fits-all systems are usually too complex to learn quickly. It would probably have to settle on a practical set of conventions, and one would have to mostly accept the limitations of these conventions or find external work-arounds for the deviant parts.
Or maybe have one framework for new systems and another for existing systems with messy databases behind them. The second would be more complex to handle odd data.
I'm a democrat...Being responsibly able to defend your family is an important part of reality and life.
But statistics don't bare this out. The innocent deaths caused by excessive guns (both quantity and power) is greater than those saved by home or self protection. We can look at other countries to see this.
Plus, a simple gun is usually enough to scare off thieves. They don't visit your house for a shoot-out, they just want goods to sell to feed their drug addiction. As soon as they know there's a gun, most leave quickly. Sure, there are exceptions the right quotes over and over, but they ARE rare. Plus, if enough home-owners start shooting back, the thieves will up their arms also. Arms race.
There's another element. Rural people often have a great fear of the Federal Government turning heavily liberal and ruining their rural and/or religious way of life. They see guns as one of the few insurance policies protecting them from a run-away "Big Govt". The loss of life from mass shootings is not big enough to justify losing this "insurance policy" in their mind.
They do the math and conclude that sometimes "freedom is better than life". It is rational to THEM: the cost of the insurance policy (a lost % of life) is less than the perceived danger of the Big Gov't taking over. They are willing to sacrifice a few percent of the population to events like this to prevent 100% of everybody they know from being ruled by Big Gov't. Nobody can accurately calculate the odds of their "socialist doomsday" scenario, so their guess is as good as yours or mine.
It's similar to what you often see in the middle east: protecting their "way of life" is more important to many than (current) peace. They are willing to die to protect their way of life. NRA thinking is just a variation on this theme.
And it could get a back-up copy and fudge what the observer(s) is seeing, or re-run variations until the observers see something "consistent" with non-simulation.
I've been working on CRUD-centric applications since before the GUI era. And I wonder why we keep reinventing CRUD systems? Most of the "logic" COULD be defined as attributes, such as data dictionaries, and relatively simple "rule tables" that are kept in the database. These could handle roughly 95% of the logic, and most the rest could probably be put in stored procedures to make them app-language-change-proof.
I've seen products that kind of come close, but they get tossed out when the shiny New Thing comes along and kills sales or momentum. People are so scared of being left behind that they throw everything out and start over to keep up with the IT Joneses. I don't really blame them: agism is real and ugly in our industry.
I agree the front-end style keeps changing, such as going from CUI to GUI to Web to mobile etc., BUT most of the principles of CRUD have not changed. Do we really have to throw out the entire CRUD engine to get the latest front-ends?
Techniques like MVC were supposed to separate front-end issues from the rest, but as implemented I fail to see it. They often do or assume data joins in code instead of the database, for example. That's stupid; whey reinvent the database? And they often rely on "scaffolders", which are code generators. If you are relying on an attribute-centric CRUD model, then you don't need to generate app code. Generating code means you failed to abstract ideas into attributes and are implementing low-level attribute handling in app code instead of reading/processing them directly from the attribute/rule tables. They automated bloat, not removed it. (Sure, you'll still need to generate client-side code, such as jquery handlers, but it could be at run-time.)
Maybe CRUD is not as exciting as aerospace and thus has none of the modelling tools and abstraction languages mentioned in the article. It has a reputation as being too simple, which is not really true. Dealing with customer expectations, databases that have built up a lot of tangled cruft over the years, and adapting abstract representations to changing UI fashions is often not easy.
"The serious problems that have happened with software have to do with requirements, not coding errors."
I've seen roughly an even mix of both. Bleep happens.
As far as car control software, back in the days, you had to keep your hardware controls fairly simple for manufacturing costs, repair-ability, and to have tolerances for wear and manufacturing defects.
Software removed many of these constraints and so companies have stretched software to its limits in order to be competitive in terms of performance and fuel efficiency. It does NOT have to be complex, but you likely will be sacrificing metrics to gain simplicity. Perhaps much if it can be reworked to be simpler, but that requires a lot of software and hardware engineering effort, and may delay car models. At least the current code is road-tested.
In short, there's no free lunch. Now that more functionality of an automobile has moved to software, companies are flummoxed because they are used to focusing on hardware. Their cheese moved:
Welcome to the Change Club. The first rule of the Change Club is that the first rule will change.
Slashdot Mirror
Even if your claim were true (cough), it's not illegal for a US corporation to give a political opinion (for good or bad).
How about Microsoft merge with Oracle and then merge with Comcast and Spectrum and AT&T, and then the whole ball of flaming shit burns a painful ugly death live streaming for everybody to see and dance to. Hell, I might even leave the basement to witness it in person.
I've been waiting for decades to see MS die. I'll do some unmentionable acts on their grave when they do. The downside is some other near-monopoly will move into their place and start the cycle again.
Co's won't invest in much automation R&D unless the labor actually does dry up.
Naw, they'll be automated:
They are the VW of credit agencies.
just kidding, lighten up
follow the money, bribery is legal in DC (although not always transparent)
How much can states override the FCC's proclamations? While the Constitution gives the Federal Gov't control over most "interstate commerce", within a state, in theory the state should have a lot of control in terms of privacy, throttling, anti-trust, etc.
Let the red states have choice-free oligopolies that overlord their content and privacy; the fools deserve it.
I got 'em all mixed up and now have drunk horses and old women who take all the money. At least the horses had fun.
I remember it something like, "the plan will probably be useless, but the planning indispensable."
In other words, it helps to think about the problem and contingencies up front even if the original plan fails.
In ideal-land yes. Reality is more nuanced. For one, the customer often doesn't fully know what they want until they actually use it in practice. If you are lucky, you can ask them a lot of questions and play with examples to try to tease out what they really need, but often such interview time is limited for various reasons, and has an upper limit to what it can accomplish because sometimes one just has to see something in action to understand the full implications of it.
Also, one often discovers issues or questions while coding that they otherwise didn't think about earlier. When you mentally immerse yourself in a particular feature or section, you notice things that you didn't while casually contemplating it.
It's kind of like house shopping: despite spending hours walking around the house, some things you just don't notice until after you move in. You may have tested the hot water in the kitchen, but you forgot to test in the restrooms, assuming that if it works in the kitchen then it works everywhere. You'll discover similar oversimplifications that were made while drafting the original plan.
Unless a hacker uses the infotainment and/or navigation system to hack into the direct controllers. Such holes have been discovered, I believe. Making sure the infotainment/nav system doesn't have such holes itself can be a daunting problem. One can perhaps fully separate them, but then some handy UI shortcuts or conveniences may be sacrificed.
For example, if there is an urgent message about the car's condition, you'd like it announced through the infotainment system. In order to do that, you'd need some connection between it and the controllers. And it would probably need a two-way feedback system to know at least if and when to end the message and turn the regular sound back up. As soon as this connection exists, the potential for inter-system hacking appears.
Marketing 101: Most humans are NOT logical
(Unless maybe there's a "social logic" that geeks haven't deciphered yet.)
Apple realized there are enough rich people (or wannabe/fake rich) who see high-end phones as a status symbol, and they are more than happy to milk this group for cash. Why not? I'd do the same in Apple's iShoes.
Inequality lives.
I generally agree and this is why I said, "but as implemented I fail to see it." Even the attribute-driven systems I suggest have separate entities for data definitions (AKA "models"), routing/flow (controller), and UI adapters.
All well-partitioned/designed framework will indeed probably have some form or aspect of MVC in it.
Another thing I didn't mention as that a one-size-fits-all CRUD engine is probably too big of a goal (unless somebody wins the big lottery). One-size-fits-all systems are usually too complex to learn quickly. It would probably have to settle on a practical set of conventions, and one would have to mostly accept the limitations of these conventions or find external work-arounds for the deviant parts.
Or maybe have one framework for new systems and another for existing systems with messy databases behind them. The second would be more complex to handle odd data.
But statistics don't bare this out. The innocent deaths caused by excessive guns (both quantity and power) is greater than those saved by home or self protection. We can look at other countries to see this.
Plus, a simple gun is usually enough to scare off thieves. They don't visit your house for a shoot-out, they just want goods to sell to feed their drug addiction. As soon as they know there's a gun, most leave quickly. Sure, there are exceptions the right quotes over and over, but they ARE rare. Plus, if enough home-owners start shooting back, the thieves will up their arms also. Arms race.
There's another element. Rural people often have a great fear of the Federal Government turning heavily liberal and ruining their rural and/or religious way of life. They see guns as one of the few insurance policies protecting them from a run-away "Big Govt". The loss of life from mass shootings is not big enough to justify losing this "insurance policy" in their mind.
They do the math and conclude that sometimes "freedom is better than life". It is rational to THEM: the cost of the insurance policy (a lost % of life) is less than the perceived danger of the Big Gov't taking over. They are willing to sacrifice a few percent of the population to events like this to prevent 100% of everybody they know from being ruled by Big Gov't. Nobody can accurately calculate the odds of their "socialist doomsday" scenario, so their guess is as good as yours or mine.
It's similar to what you often see in the middle east: protecting their "way of life" is more important to many than (current) peace. They are willing to die to protect their way of life. NRA thinking is just a variation on this theme.
So they finally invented the Flux Decapitator, eh?
We only have one Trump; they may have thousands.
And it could get a back-up copy and fudge what the observer(s) is seeing, or re-run variations until the observers see something "consistent" with non-simulation.
Has anyone here tried TLA+? Any comments?
I've been working on CRUD-centric applications since before the GUI era. And I wonder why we keep reinventing CRUD systems? Most of the "logic" COULD be defined as attributes, such as data dictionaries, and relatively simple "rule tables" that are kept in the database. These could handle roughly 95% of the logic, and most the rest could probably be put in stored procedures to make them app-language-change-proof.
I've seen products that kind of come close, but they get tossed out when the shiny New Thing comes along and kills sales or momentum. People are so scared of being left behind that they throw everything out and start over to keep up with the IT Joneses. I don't really blame them: agism is real and ugly in our industry.
I agree the front-end style keeps changing, such as going from CUI to GUI to Web to mobile etc., BUT most of the principles of CRUD have not changed. Do we really have to throw out the entire CRUD engine to get the latest front-ends?
Techniques like MVC were supposed to separate front-end issues from the rest, but as implemented I fail to see it. They often do or assume data joins in code instead of the database, for example. That's stupid; whey reinvent the database? And they often rely on "scaffolders", which are code generators. If you are relying on an attribute-centric CRUD model, then you don't need to generate app code. Generating code means you failed to abstract ideas into attributes and are implementing low-level attribute handling in app code instead of reading/processing them directly from the attribute/rule tables. They automated bloat, not removed it. (Sure, you'll still need to generate client-side code, such as jquery handlers, but it could be at run-time.)
Maybe CRUD is not as exciting as aerospace and thus has none of the modelling tools and abstraction languages mentioned in the article. It has a reputation as being too simple, which is not really true. Dealing with customer expectations, databases that have built up a lot of tangled cruft over the years, and adapting abstract representations to changing UI fashions is often not easy.
I've seen roughly an even mix of both. Bleep happens.
As far as car control software, back in the days, you had to keep your hardware controls fairly simple for manufacturing costs, repair-ability, and to have tolerances for wear and manufacturing defects.
Software removed many of these constraints and so companies have stretched software to its limits in order to be competitive in terms of performance and fuel efficiency. It does NOT have to be complex, but you likely will be sacrificing metrics to gain simplicity. Perhaps much if it can be reworked to be simpler, but that requires a lot of software and hardware engineering effort, and may delay car models. At least the current code is road-tested.
In short, there's no free lunch. Now that more functionality of an automobile has moved to software, companies are flummoxed because they are used to focusing on hardware. Their cheese moved:
Welcome to the Change Club. The first rule of the Change Club is that the first rule will change.
Galaxy Note 7 Flying Car? You mean rocket.