... so many people are wrapped up in the Internet and electronics that they simply don't know how to just sit and converse.
They are sitting conversing with the dozens or hundreds of friends on the Internet that in the old days they would never have any chance of meeting at the boring old pub. Or better yet, telling all their friends: "This place is jumping! Come join me here!" Also known as extra business.
"Look at the kids engrossed in their phones, not talking to each other" is old timer speak for "Waaa! The kids don't want to talk to me! I'm so interesting! Why won't anyone talk to me?" Maybe it's because old timers are utterly boring?
Short version: it's the latest stupid internet fad, interesting only to the circle-jerk of people promoting such things.
Thus speaks someone who probably doesn't work in industrial computing. Sure, the home coffeemaker doesn't make sense connected to the Internet. But the Coke machine in the waiting rooms of thousands of hospitals? Absolutely. "Phone home: Diet Cokes and Snickers are getting low and the cash drawer is almost full, send out a truck to restock".
How about the protection switch on the power pole outside your home? You're the electricity company. When those switches trip during a thunderstorm, do you (a) want to send out dozens of truck crews to reset them all manually, or (b) send out a command remotely and only send a crew when that doesn't work?
These devices may not be on the "Internet Internet", but they will be using TCP/IP on private networks or VPN's and need significant computing power to handle that.
The IoT is a real thing. The problems with the concept are security-related - how to educate the (non-software) engineering world that you cannot just plug a raw device into the network go home. Those guys are used to "plug device A into socket B and it works" and it is going to take a lot of educating to get them to understand how stupid that is without good access controls in place. But it isn't going to stop them wanting to do it for efficiency and productivity reasons. It's happening - don't whine - be part of helping them do it right.
I have yet to come across a problem in my career where googling it reveals Node.js as a recommended solution. Not all of us are building web apps, and frankly the web app people should probably stop and consider whether a proper application is what they really need.
Or the hackers know that they'll be faced with a huge legal shitstorm if their name is ever revealed and need the $1 million to cover their liability just in case.
So are we just ignoring the fact that the father is a Muslim activist and blames Republicans? He also shows up at churches with the Koran and disrupts. This was a clear provocation. Just like Charlie Hebdo and the Texas cartoon contest, a reaction was not only expected but inevitable. At least nobody died this time.
And my father is a Christian preacher. Seriously? Sins of the father? That's what you think is the most important issue to discuss right now? And not that the kind of people who judge based on the sins of the father are the actual real problem that caused this mess in the first place.
My first computer program was little more than 10 PRINT "HELLO WORLD", but young me was damn proud at the time of making a computer do something... anything... and would have loved to share that enthusiasm with others.
It doesn't matter whether Ahmed built the clock from scratch after forging his own components from rocks in a furnace or disassembled something else and made a small change. Who cares. We all had to start somewhere and a little encouragement goes a long way.
Don't let the know-nothings get you down Ahmed. Keep at it.
The power is actually increased, not decreased, by the pregnancy mode. This is to penetrate the womb and let the child surf the net to find a new set of parents to adopt them once born. New parents that aren't afraid of technology.
Why? Because voice processing and searching on the scale of some of the applications such as SIRI require centralized processing. Therefore your voice commands have to be sent someplace else and processed.
At the moment. As the technology improves more and more will be done client side because round-tripping audio is stupid if you could do it locally. If SIRI or something like it was completely local, then there would be no issue. Unfortunately there has been little or no work on practical on-the-spot voice recognition lately because the money is all in spying - be it for surveillance or ads.
It's not like appliance controls are complicated - there's only a handful of "TV: Change channel to ESPN" or "Kettle: Tea, Earl Grey, Hot" phrases that need to be trained in. But since the business models of operators like Nuance are predicated on licensing access to their huge server farms, no other option is even considered except the one that destroys privacy.
We need regulation - no server-side processing of client-side controls. If you could do it locally, then you MUST.
strip clubs...they dont exist in Pakistan, Iran, or North Korea...
Oh, you can be sure strip clubs exist there too. It's just that the average Schmoe is not rich enough or well connected enough to swing an invite. The same economic rules apply everywhere: money can buy anything and corrupt religious hypocrites can usually be found living it up in the local red light district.
Note to Chad: The issue is not how accurate the information is or isn't. This issue is that a truly anonymous service has no need for this information.
If you are providing an anonymous service, then accept the incoming socket, provide the service, and then promptly forget everything about the session. If it is logged, those logs can be requested or outright stolen by the world's TLA's. Even performing a GeoIP lookup without logging it has the potential to leak information from your service that can be collected by mass surveillance and correlated with other information.
Do not collect information that is not relevant to the service being provided. Period.
The next thing is you tell me to test getters and setters...
You damn well better test the getters and setters. In my experience they are usually the buggiest part of a class. To save time, sooner or later you will cut-and-paste the previous getter/setter pair and modify the name... while forgetting to update the variable name behind the API, leaving it side-effecting something else. Now you have a landmine waiting to strike on the rare occasion you set that field. And woe betide you if the setter performs verification on the value, which you will probably get wrong (in fact, I just fixed a verification bug in a setter that was found by a unit test not 5 minutes ago).
Actually I know a little bit about this as I once interviewed for that project before they temporarily lost their funding. Traditional scanners need 2 or more LiDAR emitters on separate axes to build up a 3D scan. They also need to be physically mounted in a stable location which makes it hard to map buildings with staircases and hidden rooms. The purpose of the spring is to flop the scanner around so that a single LiDAR emitter can get a complete view of the environment as the holder walks around along all possible axes. It can also be mounted on unstable platforms like automated farm tractors. The rest is software.
Because while programming by joining prefabricated boxes together with lines sounds awesome, it's what is inside the boxes that is important. If the box you need is not already written, then you need variable assignment, conditionals, and loops to write a new box. And then all of a sudden you are back to writing text code even if it is drag-n-drop "if" statements encoded in XML. At that point you might as well give the programmer a text edit window and get out of the way. The lines are the least interesting part of an application, but they are the only parts that even make sense to do graphically.
Yes, because I would just love having to go through regulatory channels and potentially paying fees in order to publish software that I don't even make any money from.
Depends on the regulations: "Commercial software can pick from one of the 5 following standard commercial licenses:... Any commercial software license that deviates from a Standard License reverts to Standard License Type 1 wherever its EULA conflicts with this regulation. Software that complies with the Open Source Definition or otherwise allows the user to inspect the source code and remove unwanted features independently is exempt from this section."
You are then perfectly free to make money from your software. Pick whichever one of the standard licenses suits your purpose and carry on. But what you cannot do is employ a lawyer to invent a creative way to screw your users in the fine print. If you do, your license is automatically torn up and replaced with something sane.
I wonder if anyone actually takes the responsibility to do this check. Maybe there are GCC binaries in the wild which replicate a backdoor.
Even if there were, you need only recompile your gcc source with llvm, icc, visual studio, or basically anything that isn't gcc to get a new compiler that won't replicate the backdoor any more. For extra fun, randomise the order of this compiling that compiling something else so that even backdoor reinsertions that cross the vendor boundary will eventually fail. Or write your own C++ interpreter in Python/Perl/whatever and use it to (very slowly) run gcc on itself - even if it takes a week you'll have a clean binary at the end. Yes, hiding such a backdoor seems scary to the untrained eye. It's also trivial to get rid of if you're paranoid enough to care.
If you want "networked" configuration nodes, an isolated network should be the only thing accessing equipment. That node should not access anything else, or any other networks...
Because those experts are morons. It ignores the economic cost of companies having to run a separate parallel Internet. Take electricity suppliers that need to monitor and control remote switching devices, for example. GSM/CDMA networks are just there, already deployed by the telecommunications industry. A cheap GSM modem and an account with the local telecomms supplier is economically better at contacting remote stations than running ones own wires out to single-point stations in the suburbs and the bush.
Isolated networks also don't work. Putting a dodgy default-passworded device on an internal network doesn't work when your attacker walks up to the remote station, cuts off the padlock, and installs their own device straight onto your wide-open "no one could possibly hack this because it's disconnected" network. Which is basically how Stuxnet got deployed - direct intervention onto a private network at a weak point.
This problem cannot be solved with simplistic "if you don't want people to hack it, don't connect it to the Internet" solutions. How about building it to be difficult to hack in the first place? Or making VPN layers the default way the Internet works rather than an afterthought? Or teaching (mostly non-software) engineers security techniques that were honed over decades of fighting malware on the open Internet? Or any of a million other practical solutions that don't boil down to "la la, I can't hear you so you can't hear me".
As an Android and iOS developer, it is tough to support all possible screen sizes, aspect ratios, hardware specs and versions of Android. Sometimes not having a newer version of Android(>= 4.0) you miss a lot of features that people come to expect and your code is riddle with backwards compatibility stuff just to support Gingerbread, or worse(ie: Donut).
And none of this would be a problem if PBS would simply publish the specification for whatever JSON/XML/etc back end they are using to transmit information to the clients about shows and episodes, and use standard RFC-compatible video formats and streaming protocols with no DRM or other nonsense.
Why would it not be a problem? Because the next day the app stores would be full of "SparkleVideoPlayer now supports PBS!" updates for all of the existing streaming video apps and their loyal users. Or if my screen size, aspect ratio, blah, blah, blah is not supported, I can write my own app!
I can understand why the commercial TV outfits want to control everything - they think it's the only way to poison the experience with ads. But why are public broadcasters like PBS, BBC, and Australia's ABC doling the same thing? It's idiotic - the solution to "how do I support a million devices" is simple: "publish the spec so that the taxpaying public can write their own apps".
Oh shut up - taking a pass on DRM is not "pick your battles carefully". Flash and Silverlight are dying on their own because they don't run, or run barely, on the current generation of smart phones, tablets, and... wait for it... smart TV's. The content distributors desperately need standardisation because supporting hundreds of device types and dozens of plug-in technologies is a pain in the neck. The problem is they've chosen to outsource the problem by making browser vendors write the proprietary DRM plug-ins for them. Instead of simply adopting the existing specifications for Internet video formats and protocols. Everything they want to do can already be done with AVI/MP4/etc together with HTTP/RTP and a "video" tag in HTML. Everything that is except spy on users and take away people's ability to enjoy the content on a whim. If we resist DRM, they'll either have to adopt open standards or they'll have no business model at all.
Incredible amounts of money and aggravation are wasted every year on this leftover from the age of agriculture.
Speaks someone who has no idea where their food comes from. Hint: agriculture.
Here's one simple example: Every morning the cows come in around dawn to be milked. Several hours later the milk tanker arrives to collect the milk and take it to the bottlers to get it ready to put on the trucks to go to the supermarket for you to buy tomorrow.
The cows will come in a little later in winter. Which pushes the schedules for the tanker drivers and bottlers back by an hour. Now the bottlers who used to work 9-5 are working 10-6. Also shifted are the truck drivers going to the supermarkets. And the stockists in the stores. And so on.
Do you really think it is a good idea to force millions and millions of low-paid truck drivers, milk bottlers, and cheese churners to work idiotic shifts and see their families even less just so that you can avoid having to change your office-worker watch twice a year? There are more people in society than you post-industrial types.
It's not the title, it's the attitude. If you write code the way a civil engineer designs bridges and or an electrical engineer builds circuits, you will build crap.
When building a bridge to take a 10 ton load, you better use 15 ton beams just in case one is under spec. When building a circuit to switch at 10 MHz, use components designed for 12 MHz just in case one is under spec. It's called "tolerances" and is the underpinning of all engineering, and is a great idea for those fields where once it is built the requirements generally stop changing.
Except in software engineering. Tolerances in software are called "fudge factors" or "heuristics", and they always result in unmaintainable spaghetti as requirements constantly change over time.
I use the term "Software Developer" for myself because I refuse to "engineer" software; i.e. build crap. My most recent contract involved fixing problems in embedded systems code written by an EE major. Total nightmare - no unit tests, no code comments to speak off, mysterious algorithms with no explanation as to where they came from, references to "see datasheet" for the component that was used three board revisions ago but not any more, and so on. The circuit? An absolutely beautiful example of balancing requirements and managing tolerances. But the code to run the circuit was rubbish that would get stamped "go back and do that again" by the code reviewers in any software development shop.
The ironic thing is that the term "Software Engineer" was coined to give developers the air of professionalism. Perhaps the engineers could learn something about professionalism from the developers instead? Like how to design a system that won't fail the minute the requirements change.
A whole car may be silly, but the thing about cars is they need repairs. I scraped the side of my car against a concrete pole in a carpark a few years back. Easy enough for the panel beaters to bang out the dings and repaint the doors... except for a scratched-up door handle. They would have had to send away to Korea at great expense to get a completely new injection moulded handle. For now I'm putting up with the scratches. But imagine if my panel beater could just pop the design into a 3D printer and make me a new one on the spot? That's what scares the crap out of traditional car manufacturers... that they can no longer rip you off for replacement parts.
Lua, Python, PHP? All scripting languages, useful for their purpose of quick one-off glue tasks, but not anywhere close to "real programming". Call me when you can write a 300,000 line C++ or Java monster on the thing without ending up with debilitating eye or wrist strain injuries.
Slashdot Mirror
... so many people are wrapped up in the Internet and electronics that they simply don't know how to just sit and converse.
They are sitting conversing with the dozens or hundreds of friends on the Internet that in the old days they would never have any chance of meeting at the boring old pub. Or better yet, telling all their friends: "This place is jumping! Come join me here!" Also known as extra business.
"Look at the kids engrossed in their phones, not talking to each other" is old timer speak for "Waaa! The kids don't want to talk to me! I'm so interesting! Why won't anyone talk to me?" Maybe it's because old timers are utterly boring?
This is why I only use "science TVs"!
Short version: it's the latest stupid internet fad, interesting only to the circle-jerk of people promoting such things.
Thus speaks someone who probably doesn't work in industrial computing. Sure, the home coffeemaker doesn't make sense connected to the Internet. But the Coke machine in the waiting rooms of thousands of hospitals? Absolutely. "Phone home: Diet Cokes and Snickers are getting low and the cash drawer is almost full, send out a truck to restock". How about the protection switch on the power pole outside your home? You're the electricity company. When those switches trip during a thunderstorm, do you (a) want to send out dozens of truck crews to reset them all manually, or (b) send out a command remotely and only send a crew when that doesn't work? These devices may not be on the "Internet Internet", but they will be using TCP/IP on private networks or VPN's and need significant computing power to handle that. The IoT is a real thing. The problems with the concept are security-related - how to educate the (non-software) engineering world that you cannot just plug a raw device into the network go home. Those guys are used to "plug device A into socket B and it works" and it is going to take a lot of educating to get them to understand how stupid that is without good access controls in place. But it isn't going to stop them wanting to do it for efficiency and productivity reasons. It's happening - don't whine - be part of helping them do it right.
I have yet to come across a problem in my career where googling it reveals Node.js as a recommended solution. Not all of us are building web apps, and frankly the web app people should probably stop and consider whether a proper application is what they really need.
Or the hackers know that they'll be faced with a huge legal shitstorm if their name is ever revealed and need the $1 million to cover their liability just in case.
So are we just ignoring the fact that the father is a Muslim activist and blames Republicans? He also shows up at churches with the Koran and disrupts. This was a clear provocation. Just like Charlie Hebdo and the Texas cartoon contest, a reaction was not only expected but inevitable. At least nobody died this time.
And my father is a Christian preacher. Seriously? Sins of the father? That's what you think is the most important issue to discuss right now? And not that the kind of people who judge based on the sins of the father are the actual real problem that caused this mess in the first place.
My first computer program was little more than 10 PRINT "HELLO WORLD", but young me was damn proud at the time of making a computer do something ... anything ... and would have loved to share that enthusiasm with others.
It doesn't matter whether Ahmed built the clock from scratch after forging his own components from rocks in a furnace or disassembled something else and made a small change. Who cares. We all had to start somewhere and a little encouragement goes a long way.
Don't let the know-nothings get you down Ahmed. Keep at it.
The power is actually increased, not decreased, by the pregnancy mode. This is to penetrate the womb and let the child surf the net to find a new set of parents to adopt them once born. New parents that aren't afraid of technology.
Why? Because voice processing and searching on the scale of some of the applications such as SIRI require centralized processing. Therefore your voice commands have to be sent someplace else and processed.
At the moment. As the technology improves more and more will be done client side because round-tripping audio is stupid if you could do it locally. If SIRI or something like it was completely local, then there would be no issue. Unfortunately there has been little or no work on practical on-the-spot voice recognition lately because the money is all in spying - be it for surveillance or ads.
It's not like appliance controls are complicated - there's only a handful of "TV: Change channel to ESPN" or "Kettle: Tea, Earl Grey, Hot" phrases that need to be trained in. But since the business models of operators like Nuance are predicated on licensing access to their huge server farms, no other option is even considered except the one that destroys privacy.
We need regulation - no server-side processing of client-side controls. If you could do it locally, then you MUST.
strip clubs...they dont exist in Pakistan, Iran, or North Korea ...
Oh, you can be sure strip clubs exist there too. It's just that the average Schmoe is not rich enough or well connected enough to swing an invite. The same economic rules apply everywhere: money can buy anything and corrupt religious hypocrites can usually be found living it up in the local red light district.
Note to Chad: The issue is not how accurate the information is or isn't. This issue is that a truly anonymous service has no need for this information.
If you are providing an anonymous service, then accept the incoming socket, provide the service, and then promptly forget everything about the session. If it is logged, those logs can be requested or outright stolen by the world's TLA's. Even performing a GeoIP lookup without logging it has the potential to leak information from your service that can be collected by mass surveillance and correlated with other information.
Do not collect information that is not relevant to the service being provided. Period.
The next thing is you tell me to test getters and setters ...
You damn well better test the getters and setters. In my experience they are usually the buggiest part of a class. To save time, sooner or later you will cut-and-paste the previous getter/setter pair and modify the name ... while forgetting to update the variable name behind the API, leaving it side-effecting something else. Now you have a landmine waiting to strike on the rare occasion you set that field. And woe betide you if the setter performs verification on the value, which you will probably get wrong (in fact, I just fixed a verification bug in a setter that was found by a unit test not 5 minutes ago).
Actually I know a little bit about this as I once interviewed for that project before they temporarily lost their funding. Traditional scanners need 2 or more LiDAR emitters on separate axes to build up a 3D scan. They also need to be physically mounted in a stable location which makes it hard to map buildings with staircases and hidden rooms. The purpose of the spring is to flop the scanner around so that a single LiDAR emitter can get a complete view of the environment as the holder walks around along all possible axes. It can also be mounted on unstable platforms like automated farm tractors. The rest is software.
Because while programming by joining prefabricated boxes together with lines sounds awesome, it's what is inside the boxes that is important. If the box you need is not already written, then you need variable assignment, conditionals, and loops to write a new box. And then all of a sudden you are back to writing text code even if it is drag-n-drop "if" statements encoded in XML. At that point you might as well give the programmer a text edit window and get out of the way. The lines are the least interesting part of an application, but they are the only parts that even make sense to do graphically.
If you won't make your content available in a convenient form in a timely fashion, you lose the right to complain when someone else does.
Yes, because I would just love having to go through regulatory channels and potentially paying fees in order to publish software that I don't even make any money from.
Depends on the regulations: "Commercial software can pick from one of the 5 following standard commercial licenses: ... Any commercial software license that deviates from a Standard License reverts to Standard License Type 1 wherever its EULA conflicts with this regulation. Software that complies with the Open Source Definition or otherwise allows the user to inspect the source code and remove unwanted features independently is exempt from this section."
You are then perfectly free to make money from your software. Pick whichever one of the standard licenses suits your purpose and carry on. But what you cannot do is employ a lawyer to invent a creative way to screw your users in the fine print. If you do, your license is automatically torn up and replaced with something sane.
I wonder if anyone actually takes the responsibility to do this check. Maybe there are GCC binaries in the wild which replicate a backdoor.
Even if there were, you need only recompile your gcc source with llvm, icc, visual studio, or basically anything that isn't gcc to get a new compiler that won't replicate the backdoor any more. For extra fun, randomise the order of this compiling that compiling something else so that even backdoor reinsertions that cross the vendor boundary will eventually fail. Or write your own C++ interpreter in Python/Perl/whatever and use it to (very slowly) run gcc on itself - even if it takes a week you'll have a clean binary at the end. Yes, hiding such a backdoor seems scary to the untrained eye. It's also trivial to get rid of if you're paranoid enough to care.
If you want "networked" configuration nodes, an isolated network should be the only thing accessing equipment. That node should not access anything else, or any other networks...
Because those experts are morons. It ignores the economic cost of companies having to run a separate parallel Internet. Take electricity suppliers that need to monitor and control remote switching devices, for example. GSM/CDMA networks are just there, already deployed by the telecommunications industry. A cheap GSM modem and an account with the local telecomms supplier is economically better at contacting remote stations than running ones own wires out to single-point stations in the suburbs and the bush.
Isolated networks also don't work. Putting a dodgy default-passworded device on an internal network doesn't work when your attacker walks up to the remote station, cuts off the padlock, and installs their own device straight onto your wide-open "no one could possibly hack this because it's disconnected" network. Which is basically how Stuxnet got deployed - direct intervention onto a private network at a weak point.
This problem cannot be solved with simplistic "if you don't want people to hack it, don't connect it to the Internet" solutions. How about building it to be difficult to hack in the first place? Or making VPN layers the default way the Internet works rather than an afterthought? Or teaching (mostly non-software) engineers security techniques that were honed over decades of fighting malware on the open Internet? Or any of a million other practical solutions that don't boil down to "la la, I can't hear you so you can't hear me".
As an Android and iOS developer, it is tough to support all possible screen sizes, aspect ratios, hardware specs and versions of Android. Sometimes not having a newer version of Android(>= 4.0) you miss a lot of features that people come to expect and your code is riddle with backwards compatibility stuff just to support Gingerbread, or worse(ie: Donut).
And none of this would be a problem if PBS would simply publish the specification for whatever JSON/XML/etc back end they are using to transmit information to the clients about shows and episodes, and use standard RFC-compatible video formats and streaming protocols with no DRM or other nonsense.
Why would it not be a problem? Because the next day the app stores would be full of "SparkleVideoPlayer now supports PBS!" updates for all of the existing streaming video apps and their loyal users. Or if my screen size, aspect ratio, blah, blah, blah is not supported, I can write my own app!
I can understand why the commercial TV outfits want to control everything - they think it's the only way to poison the experience with ads. But why are public broadcasters like PBS, BBC, and Australia's ABC doling the same thing? It's idiotic - the solution to "how do I support a million devices" is simple: "publish the spec so that the taxpaying public can write their own apps".
Oh shut up - taking a pass on DRM is not "pick your battles carefully". Flash and Silverlight are dying on their own because they don't run, or run barely, on the current generation of smart phones, tablets, and ... wait for it ... smart TV's. The content distributors desperately need standardisation because supporting hundreds of device types and dozens of plug-in technologies is a pain in the neck. The problem is they've chosen to outsource the problem by making browser vendors write the proprietary DRM plug-ins for them. Instead of simply adopting the existing specifications for Internet video formats and protocols. Everything they want to do can already be done with AVI/MP4/etc together with HTTP/RTP and a "video" tag in HTML. Everything that is except spy on users and take away people's ability to enjoy the content on a whim. If we resist DRM, they'll either have to adopt open standards or they'll have no business model at all.
Any headline where the US is demanding that some other country stop doing something can be simply answered with "You First Sparky!".
Incredible amounts of money and aggravation are wasted every year on this leftover from the age of agriculture.
Speaks someone who has no idea where their food comes from. Hint: agriculture.
Here's one simple example: Every morning the cows come in around dawn to be milked. Several hours later the milk tanker arrives to collect the milk and take it to the bottlers to get it ready to put on the trucks to go to the supermarket for you to buy tomorrow.
The cows will come in a little later in winter. Which pushes the schedules for the tanker drivers and bottlers back by an hour. Now the bottlers who used to work 9-5 are working 10-6. Also shifted are the truck drivers going to the supermarkets. And the stockists in the stores. And so on.
Do you really think it is a good idea to force millions and millions of low-paid truck drivers, milk bottlers, and cheese churners to work idiotic shifts and see their families even less just so that you can avoid having to change your office-worker watch twice a year? There are more people in society than you post-industrial types.
When building a bridge to take a 10 ton load, you better use 15 ton beams just in case one is under spec. When building a circuit to switch at 10 MHz, use components designed for 12 MHz just in case one is under spec. It's called "tolerances" and is the underpinning of all engineering, and is a great idea for those fields where once it is built the requirements generally stop changing.
Except in software engineering. Tolerances in software are called "fudge factors" or "heuristics", and they always result in unmaintainable spaghetti as requirements constantly change over time.
I use the term "Software Developer" for myself because I refuse to "engineer" software; i.e. build crap. My most recent contract involved fixing problems in embedded systems code written by an EE major. Total nightmare - no unit tests, no code comments to speak off, mysterious algorithms with no explanation as to where they came from, references to "see datasheet" for the component that was used three board revisions ago but not any more, and so on. The circuit? An absolutely beautiful example of balancing requirements and managing tolerances. But the code to run the circuit was rubbish that would get stamped "go back and do that again" by the code reviewers in any software development shop.
The ironic thing is that the term "Software Engineer" was coined to give developers the air of professionalism. Perhaps the engineers could learn something about professionalism from the developers instead? Like how to design a system that won't fail the minute the requirements change.
A whole car may be silly, but the thing about cars is they need repairs. I scraped the side of my car against a concrete pole in a carpark a few years back. Easy enough for the panel beaters to bang out the dings and repaint the doors ... except for a scratched-up door handle. They would have had to send away to Korea at great expense to get a completely new injection moulded handle. For now I'm putting up with the scratches. But imagine if my panel beater could just pop the design into a 3D printer and make me a new one on the spot? That's what scares the crap out of traditional car manufacturers ... that they can no longer rip you off for replacement parts.
Lua, Python, PHP? All scripting languages, useful for their purpose of quick one-off glue tasks, but not anywhere close to "real programming". Call me when you can write a 300,000 line C++ or Java monster on the thing without ending up with debilitating eye or wrist strain injuries.