The "be a big boy" argument dodges the real question here: can a programming language be efficient (stay close to the metal) yet have sufficient checks and balances on itself? Would making it safer automatically make it more resource intensive*?
If there is an inherent and fundamental trade-off, and C (as it is) merely chooses the close-to-metal far spot on this spectrum, then the be-a-big-boy argument makes sense (assuming you want Linux "fast"). However, I've yet to see anyone make a strong argument that there is a fundamental trade-off. If there is not a fundamental trade-off, then the question of C being the wrong tool for the job carries more weight, and the be-a-big-boy argument deflates.
Using the pre-initialize example given, if a language automatically pre-initializes all variables, that adds to execution time. One may want that for some applications/domains but not others. For example, for gaming, you might not care much if there's a risk some execution paths might use garbage bits in order to get the most speed. (Distorted aliens may even add to the game's fun.)
I wonder if C or another language could not rely on API's or API-like expansion macros. A given shop would select the API's that fit its trade-off profile. If you wanted to skip pre-initialization for speed, you'd use the skipping version of an initializer API. And on the flip side, don't include the non-init API in the shop stack if you don't want accidental naked bits.
The API approach allows control over risky trade-offs without having to make a new language for each domain or shop. I just wonder if using or allowing such a layer itself hurts performance. Does the "choice layer" itself have to hurt performance? It's back to the unanswered "fundamental" question above. If you prove it one way or the other, you deserve a Turing Award.
* Including possibly having unpredictable execution speed, which in some domains is as bad as "slow".
We will eventually give up writing algorithms altogether... "because the machines will be able to do it far better than we ever could. Software engineering is in that sense perhaps a dying profession.
Which would free us up to vacation in our flying car and date Rosy the Robot.
lane tracking software is still hard. Not all roads are well marked
On unfamiliar roads, I often have that problem also. (I'm a human, by the way.) CA roads are still recovering from the Great Recession, so I often have to guess around faded lines.
If there are cars in front of me, I simply follow them, hoping they know from prior experience on the same road. If not, I keep an eye on the cars around me for cues. If there are no cars around me, then guessing wrong has minimal risk anyhow.
As much as I rely on that algorithm myself, the thought of a bot having a similar algorithm bothers me. But faded is faded. Driving on unfamiliar roads is a hard problem for humans also. Roughly 90% of our trips are on familiar roads such that we are sort of cheating. If we were forced to drive on unfamiliar roads, I'm sure our accident rates would spike. (Sure, there are expert drivers, but I'm considering average here.)
I wonder how much the bot drivers use info from prior visits to the same road, versus using a generic algorithm each time. And do they share this info across drivers. I suppose a road may be repainted or reworked, but usually the new paint or dark asphalt gives it away such that a human knows to re-calibrate, almost instinctively.
There's a lot of practical little heuristics like this that humans use. Bots could also, but it may take years to include and tune them. If you put too many in, it could over-complicate the system, producing complexity-induced side-effects.
Probably one of the most important course(s) a student will ever take. Pay and value are not necessarily the same. "Mob rule" democracies, demagogues, ethnic cleansing, wars gone sour, etc. are all scenarios that have played out in history and we may be repeating.
My high school buddy wanted to be a history teacher. He loved pontificating about history, and especially WWII. But he faced the reality that money and opportunity were better as a math teacher, and thus got a STEM degree. He may someday turn to teaching history when he feels financially stable.
I'm not sure where this Julia language will fit in yet
Yip, it's probably impossible to be all things to all people. For example, computing infrastructure and systems programming (such as making an OS) typically needs to emphasize different things than application programming.
My scenario wasn't a branch staying on the road, but just temporarily bending in the way of the road so that the driver, human or bot, temporarily pauses until they understand what's happening.
But in general, the bot-driver will probably lack "common sense" in many situations, and present "odd" behavior, at least from a human perspective.
For example, it may slam on the breaks because a plastic bag is tumbling across the road. Most human drivers would probably slow down a bit but not outright stop because the humans know a plastic bag poses no risk.
Bot programmers may add a "plastic bag" subroutine to mirror such behavior, but some new situation will come up they didn't anticipate. Over time, the bot-car will get better, though, as more sub-cases are added to its "experience bank".
I don't believe lack of common sense is a reason to give up on bot-cars, for they do better than humans on other metrics. They don't have to be perfect, just better than human drivers on average. They just "fail differently", to mis-borrow Apple's old motto.
Python is [also] a clusterfuck. Not enough people recognize it in time.
Almost all programming languages that end up in common use become messy as features and adjustments based on practical experience and industry changes are added over time. The originators cannot anticipate all future needs and trends/fads*.
C# used to be relatively simple because it applied to hard lessons of Java, but has grown screwier over time to keep up with the Jones' (along with Java).
Just try to do reflection on nullable C# types, for example. It's a WTF moment. When you investigate why it's that way, you learn that nullable types are an ugly hack on top of the existing dynamic type sub-engine. (Reflecting on nullable types is a common need when you want to automate class/schema mapping between layers, per DRY.)
* Some fad-driven features are just plain stupid. Some fads should be ignored, and language builders often lack the discipline to wait out fad storms.
Suddenly breaking for [no] reason is illegal in many places.
A key reason for such laws is that some dirtbags were caught purposely getting into accidents by suddenly stopping in order to collect big settlements. Entire crime operations formed around the practice.
On the flip side, a portion of the population may be more likely to try to confuse and sue bot-cars because of their hatred of the technology.
The bot-cars may have to save video of the scene when they suddenly break to avoid such lawsuits. But I suspect sometimes the reasons will look silly to the jury, such as wind suddenly bending a tree branch temporarily over the road.
I've also have breaked for things that turned out to be trivial like that. But if it a bot does it, a judge or jury may be more likely throw the book at a conglomerate then a regular-Joe. Judges and juries can personally relate to the problems of regular folks, but it's harder to have feelings for faceless conglomerates and their billionaire boards.
I also avoid left turns across double lanes if there's no traffic light, no center lane, and visibility is questionable. I'll still do it if in a hurry or traffic is otherwise light, but those are hair-raising. There's a lot of jerks on the road who drive too fast, are texting, etc, creating risks. If something goes wrong, there's not a lot of ways out.
I suppose one gets better over time when they do such turns often, just like any task, and by mostly avoiding them I'm not getting enough practice. But I'm at the age where I say, screwit, my approach has kept me alive for decades. A bot does have the ability to "look" both ways at once, though, so it has an advantage over a lone driver.
Slashdot Mirror
Begun, the trade wars has. -Yoda
Anyone can do it. Doing it right is another matter.
Any management system that depends on each part running nearly perfect is probably either bullshit or doomed or both.
Sure, you can have tons of auditors to make sure everything works according to the mantra, but auditors and their interaction cost money.
There's a lot of borderlline people. Plus, some get more mature and thus have better study habits as they age.
The "be a big boy" argument dodges the real question here: can a programming language be efficient (stay close to the metal) yet have sufficient checks and balances on itself? Would making it safer automatically make it more resource intensive*?
If there is an inherent and fundamental trade-off, and C (as it is) merely chooses the close-to-metal far spot on this spectrum, then the be-a-big-boy argument makes sense (assuming you want Linux "fast"). However, I've yet to see anyone make a strong argument that there is a fundamental trade-off. If there is not a fundamental trade-off, then the question of C being the wrong tool for the job carries more weight, and the be-a-big-boy argument deflates.
Using the pre-initialize example given, if a language automatically pre-initializes all variables, that adds to execution time. One may want that for some applications/domains but not others. For example, for gaming, you might not care much if there's a risk some execution paths might use garbage bits in order to get the most speed. (Distorted aliens may even add to the game's fun.)
I wonder if C or another language could not rely on API's or API-like expansion macros. A given shop would select the API's that fit its trade-off profile. If you wanted to skip pre-initialization for speed, you'd use the skipping version of an initializer API. And on the flip side, don't include the non-init API in the shop stack if you don't want accidental naked bits.
The API approach allows control over risky trade-offs without having to make a new language for each domain or shop. I just wonder if using or allowing such a layer itself hurts performance. Does the "choice layer" itself have to hurt performance? It's back to the unanswered "fundamental" question above. If you prove it one way or the other, you deserve a Turing Award.
* Including possibly having unpredictable execution speed, which in some domains is as bad as "slow".
Which would free us up to vacation in our flying car and date Rosy the Robot.
It's hard to know if you will fail until you try.
How do they deal with road changes/repairs?
On unfamiliar roads, I often have that problem also. (I'm a human, by the way.) CA roads are still recovering from the Great Recession, so I often have to guess around faded lines.
If there are cars in front of me, I simply follow them, hoping they know from prior experience on the same road. If not, I keep an eye on the cars around me for cues. If there are no cars around me, then guessing wrong has minimal risk anyhow.
As much as I rely on that algorithm myself, the thought of a bot having a similar algorithm bothers me. But faded is faded. Driving on unfamiliar roads is a hard problem for humans also. Roughly 90% of our trips are on familiar roads such that we are sort of cheating. If we were forced to drive on unfamiliar roads, I'm sure our accident rates would spike. (Sure, there are expert drivers, but I'm considering average here.)
I wonder how much the bot drivers use info from prior visits to the same road, versus using a generic algorithm each time. And do they share this info across drivers. I suppose a road may be repainted or reworked, but usually the new paint or dark asphalt gives it away such that a human knows to re-calibrate, almost instinctively.
There's a lot of practical little heuristics like this that humans use. Bots could also, but it may take years to include and tune them. If you put too many in, it could over-complicate the system, producing complexity-induced side-effects.
I must confess, I don't get the parentheses joke.
Maybe the US gov't doesn't shut it down because it sends China fake experts to muck them up by say putting them on Oracle Cloud and Comcast.
To be a B1H?
Probably one of the most important course(s) a student will ever take. Pay and value are not necessarily the same. "Mob rule" democracies, demagogues, ethnic cleansing, wars gone sour, etc. are all scenarios that have played out in history and we may be repeating.
My high school buddy wanted to be a history teacher. He loved pontificating about history, and especially WWII. But he faced the reality that money and opportunity were better as a math teacher, and thus got a STEM degree. He may someday turn to teaching history when he feels financially stable.
Let me try to rephrase it: if you grew up being surrounded by more people, you generally have better skills for getting along and compromising.
Can't we use that against him? Example:
1. "A secret sample confirmed Trump's hair is infested with flesh-eating mutant fleas. Donald should shave bald to survive."
2. "Eating 50 bacon-cheeseburgers a day proven to lengthen lifespan."
3. "Putin and Brett Kavanaugh have cooties."
4. "Space aliens hand out large gold medals to planet leaders who get along well with Hispanics and Muslims."
5. "CNN copyrighted 'Space Force' in 1990's."
6. "Tall walls cause gall-stones and shrunken hands. Nicknamed 'wallstones' by leading researchers."
7. "Russian 'pee' video copy found on Hillary's server."
Overall, we better respect the norms needed to get along and compromise in civilization because we have direct experience in it.
Fair enough, both Google and Oraangle need a good long old-fashioned spanking.
But Trump is doing to the world what Hillary did to emails.
Representative democracy:* many are similar to him and can relate to him. Truth is, America is chalk full of Yosemite Sams.
* minus electoral college slant
First the red/blue culture wars, now the human/bot culture wars?
Yip, it's probably impossible to be all things to all people. For example, computing infrastructure and systems programming (such as making an OS) typically needs to emphasize different things than application programming.
My scenario wasn't a branch staying on the road, but just temporarily bending in the way of the road so that the driver, human or bot, temporarily pauses until they understand what's happening.
But in general, the bot-driver will probably lack "common sense" in many situations, and present "odd" behavior, at least from a human perspective.
For example, it may slam on the breaks because a plastic bag is tumbling across the road. Most human drivers would probably slow down a bit but not outright stop because the humans know a plastic bag poses no risk.
Bot programmers may add a "plastic bag" subroutine to mirror such behavior, but some new situation will come up they didn't anticipate. Over time, the bot-car will get better, though, as more sub-cases are added to its "experience bank".
I don't believe lack of common sense is a reason to give up on bot-cars, for they do better than humans on other metrics. They don't have to be perfect, just better than human drivers on average. They just "fail differently", to mis-borrow Apple's old motto.
Almost all programming languages that end up in common use become messy as features and adjustments based on practical experience and industry changes are added over time. The originators cannot anticipate all future needs and trends/fads*.
C# used to be relatively simple because it applied to hard lessons of Java, but has grown screwier over time to keep up with the Jones' (along with Java).
Just try to do reflection on nullable C# types, for example. It's a WTF moment. When you investigate why it's that way, you learn that nullable types are an ugly hack on top of the existing dynamic type sub-engine. (Reflecting on nullable types is a common need when you want to automate class/schema mapping between layers, per DRY.)
* Some fad-driven features are just plain stupid. Some fads should be ignored, and language builders often lack the discipline to wait out fad storms.
A key reason for such laws is that some dirtbags were caught purposely getting into accidents by suddenly stopping in order to collect big settlements. Entire crime operations formed around the practice.
On the flip side, a portion of the population may be more likely to try to confuse and sue bot-cars because of their hatred of the technology.
The bot-cars may have to save video of the scene when they suddenly break to avoid such lawsuits. But I suspect sometimes the reasons will look silly to the jury, such as wind suddenly bending a tree branch temporarily over the road.
I've also have breaked for things that turned out to be trivial like that. But if it a bot does it, a judge or jury may be more likely throw the book at a conglomerate then a regular-Joe. Judges and juries can personally relate to the problems of regular folks, but it's harder to have feelings for faceless conglomerates and their billionaire boards.
I also avoid left turns across double lanes if there's no traffic light, no center lane, and visibility is questionable. I'll still do it if in a hurry or traffic is otherwise light, but those are hair-raising. There's a lot of jerks on the road who drive too fast, are texting, etc, creating risks. If something goes wrong, there's not a lot of ways out.
I suppose one gets better over time when they do such turns often, just like any task, and by mostly avoiding them I'm not getting enough practice. But I'm at the age where I say, screwit, my approach has kept me alive for decades. A bot does have the ability to "look" both ways at once, though, so it has an advantage over a lone driver.