Several things will happen, as they have happened in the established engineering disciplines. It will take quite a while though. But it has happened to all established engineering disciplines and it works, so it will very likely happen here as well.
1) Competency classes will get firmly established. Example: - "Technician": Uses established components and established techniques to solve known and understood problems. Results are safe and reliable. - "Engineer": Uses mostly established components and mostly established techniques to create solutions to new problems. Results are safe and reliable, if needed by additional measures to ensure that. - "Scientist": Can create everything from scratch if needed, but does not assure reliable or safe result.
2) Standard components with standardized interfaces will become widely available and have assured and dependable characteristics.
At this time, we have few standardized interfaces and mostly on the net: SMTP and HTTP are examples.
3) Liability will become a thing. If any of the competency classes from 1) steps outside of their competency class and messes up or messes up an established technique within their competency class, then the person will become personally liable. Same as an architect becomes liable if he messes up the static calculations of a building and it collapses as a result or an MD that botches a standard procedure. Also, component manufacturers will become liable if the components they sell do not perform as to spec. (A way to handle FOSS that works will be found, e.g. 3rd party certification.)
4) Hardware will stop to evolve fast and may become mostly or entirely static. The same will happen for Operating Systems, languages and compilers, making 2) possible.
There are some other effects, but competency classes, standardized components and procedures and liability are the most important things.
This seems to be the same ages-old call for censorship that authoritarian scum always do when they think they can get away with. The pattern is always the same: Use an event that sparks public outrage and then suggest that certain people using their free speech rights are responsible for the event or something closely connected to it. The authoritarians hope to create a general feeling that free speech is not something everybody has a right to and that is subject to what people will say using this right. This is of course just one thing, thinly disguised: The removal of free speech by trying to establish the censorship that authoritarians are so in love with.
Funny. This stuff currently pays my pretty nice salary and nothing of it is BS. The customer would not accept that. But keep thumping your chest and believing you are superior.
Incidentally, I was not talking about general-purpose allocators. Implementing these is basically a text-book exercise task for students. I was talking about full-custom allocator design, optimized for a specific task. It speaks volumes that you apparently cannot tell the difference.
Mostly. Unless you suddenly run into legal requirements that you have to fulfill and your framework just happens to do things completely violating these requirements and nobody was aware.
No, I am just a few levels above you. In fact you are so outclassed that it is utterly hilarious. First, Divide and Conquer is in no way universal and requires specific conditions to be met in order to work in non-degraded form, i.e. efficiently. I bet you were unaware of that and thought this approach to be a general strategy. It is not, nicely illustrating my earlier point. Second, Divide and Conquer does not reduce complexity, it reduces problem size. That is fundamentally different. Incidentally, if Divide and Conquer can be used to solve a problem efficiently, then that pretty much forms a proof that the problem complexity is at or below the concrete Divide and Conquer pattern used.
So, fail on all counts on your side. The funny thing is, I am actually not a programmer. I have a CS PhD and mostly do security consulting work. Coding is just something I do on the side when an opportunity arises, but apparently a lot more competently than you can ever hope to achieve.
Indeed. And that is why coding (and CS) is still an experimental engineering discipline. The biggest problem we face is that we do experimental engineering with people that do not qualify as engineers and have very partial understanding of what they are doing. Eventually, this will get better, but expect 50 years or longer for that to happen, if history is any indication.
I have gone back to plain text-editor and command-line compiler and debugger. I do not even use DDD or Emacs compiler integration anymore. No need. IDEs would just waste my time. Coding is hard enough when you do it directly.
It is nobodies fault. People have limits and most are most limited when it comes to abstract thinking. That is just the way things are set up in this universe.
I agree. The proof-tools are a bit special (but not so different than the differences between different mathematical disciplines), in particular that you often have more elementary steps, but also a lot more of them. And you care about things like the performance of the proof, which is also a bit untypical, but nor completely outlandish. In essence, it is constructing a mathematical proof under some border-conditions as to the form of the proof.
I also have run into the prototype-madness. My solution is to build a final solution instead of a prototype, and, if I needed one, to not give the prototype to the customer. That does require a situation where you can get the budget needed for that though, but fortunately I do not code at coder-rates, but at full consulting rates. While customers (well, managers there) routinely complain about the rates, nobody has so far complained about the results the get for the money.
There is a difference between a library and a framework. But that you do not get my point just shows you have not yet run into this problem. It currently pays for a substantial part of my work-time.
Fist, they have no clue what computing paradigm would be the basis of such a simulation. The theoretical limits we know are only for digital computers in the absence of "magic". And second, what makes them think all that nice stuff they base their reasoning on is not cleverly faked? Have they forgotten what level of control such a simulation would have?
In the end, they have nothing. Just the same as those people claiming we definitely are in a simulation. It is a valid model, but there is no way to show it is accurate or not.
People think that this great gadget makes them hip and irresistible, and they would spend even more. I mean, look at the cars some men buy just to impress women and look at what some women invest in cosmetics and "body enhancements" just to impress men.
This has noting to do with the phone itself, or Apple would have gone bankrupt a while ago.
These were not really computers in the modern sense. No capability to run general-purpose code. Also, if I remember correctly, they basically had people doing the job of an assembler between the coders and the machines. Might even be were the name comes from.
Well, I have when doing I/O to specific hardware components. But that is about it. For actual code, I always had at least an assembler.
I do agree that the stance of the article is mostly BS, also because you _cannot_ think like a computer. Computers are exceptionally dumb in a very fast fashion. No human can think like that. Smart humans can think in a smart and complex fashion pretty slowly. That is nothing alike computers.
Indeed. You cannot abstract complexity away. You can hide it, often with really bad effects, but it will still be there. The only cases were abstraction makes things easier is if the complexity was created by a bad tool and is not inherent to the task being solved. You will always need to understand that task in order to create an adequate solution. And if that task is complex and cannot be simplified, then the solution must necessarily be complex too. Of course, a major talent for any good engineer is the simplification of tasks.
Ah, yes? The only point of that was marketing and some politicians simulating being "modern" anyways. And some nice rip-off-type business models for "coding schools".
Slashdot Mirror
Several things will happen, as they have happened in the established engineering disciplines. It will take quite a while though. But it has happened to all established engineering disciplines and it works, so it will very likely happen here as well.
1) Competency classes will get firmly established.
Example:
- "Technician": Uses established components and established techniques to solve known and understood problems. Results are safe and reliable.
- "Engineer": Uses mostly established components and mostly established techniques to create solutions to new problems. Results are safe and reliable, if needed by additional measures to ensure that.
- "Scientist": Can create everything from scratch if needed, but does not assure reliable or safe result.
2) Standard components with standardized interfaces will become widely available and have assured and dependable characteristics.
At this time, we have few standardized interfaces and mostly on the net: SMTP and HTTP are examples.
3) Liability will become a thing. If any of the competency classes from 1) steps outside of their competency class and messes up or messes up an established technique within their competency class, then the person will become personally liable. Same as an architect becomes liable if he messes up the static calculations of a building and it collapses as a result or an MD that botches a standard procedure. Also, component manufacturers will become liable if the components they sell do not perform as to spec. (A way to handle FOSS that works will be found, e.g. 3rd party certification.)
4) Hardware will stop to evolve fast and may become mostly or entirely static. The same will happen for Operating Systems, languages and compilers, making 2) possible.
There are some other effects, but competency classes, standardized components and procedures and liability are the most important things.
Actually, it is a possible explanation only. More research is needed before an actual explanation can be found.
Your absolute judgement has no scientific basis in observable facts. Are you a religious fanatic?
This seems to be the same ages-old call for censorship that authoritarian scum always do when they think they can get away with. The pattern is always the same: Use an event that sparks public outrage and then suggest that certain people using their free speech rights are responsible for the event or something closely connected to it. The authoritarians hope to create a general feeling that free speech is not something everybody has a right to and that is subject to what people will say using this right. This is of course just one thing, thinly disguised: The removal of free speech by trying to establish the censorship that authoritarians are so in love with.
Funny. This stuff currently pays my pretty nice salary and nothing of it is BS. The customer would not accept that. But keep thumping your chest and believing you are superior.
Incidentally, I was not talking about general-purpose allocators. Implementing these is basically a text-book exercise task for students. I was talking about full-custom allocator design, optimized for a specific task. It speaks volumes that you apparently cannot tell the difference.
Mostly. Unless you suddenly run into legal requirements that you have to fulfill and your framework just happens to do things completely violating these requirements and nobody was aware.
No, I am just a few levels above you. In fact you are so outclassed that it is utterly hilarious. First, Divide and Conquer is in no way universal and requires specific conditions to be met in order to work in non-degraded form, i.e. efficiently. I bet you were unaware of that and thought this approach to be a general strategy. It is not, nicely illustrating my earlier point. Second, Divide and Conquer does not reduce complexity, it reduces problem size. That is fundamentally different. Incidentally, if Divide and Conquer can be used to solve a problem efficiently, then that pretty much forms a proof that the problem complexity is at or below the concrete Divide and Conquer pattern used.
So, fail on all counts on your side. The funny thing is, I am actually not a programmer. I have a CS PhD and mostly do security consulting work. Coding is just something I do on the side when an opportunity arises, but apparently a lot more competently than you can ever hope to achieve.
Indeed. And that is why coding (and CS) is still an experimental engineering discipline. The biggest problem we face is that we do experimental engineering with people that do not qualify as engineers and have very partial understanding of what they are doing. Eventually, this will get better, but expect 50 years or longer for that to happen, if history is any indication.
I have gone back to plain text-editor and command-line compiler and debugger. I do not even use DDD or Emacs compiler integration anymore. No need. IDEs would just waste my time. Coding is hard enough when you do it directly.
Indeed. And it _is_ reflected in the outcomes. A brain-surgeon with this rate of failure on standard tasks would go to jail.
It gets better when you are a highly-paid tech consultant. You still have to fight for the information, but you can usually get it.
It is nobodies fault. People have limits and most are most limited when it comes to abstract thinking. That is just the way things are set up in this universe.
I do agree on the author of that piece though.
I agree. The proof-tools are a bit special (but not so different than the differences between different mathematical disciplines), in particular that you often have more elementary steps, but also a lot more of them. And you care about things like the performance of the proof, which is also a bit untypical, but nor completely outlandish. In essence, it is constructing a mathematical proof under some border-conditions as to the form of the proof.
I also have run into the prototype-madness. My solution is to build a final solution instead of a prototype, and, if I needed one, to not give the prototype to the customer. That does require a situation where you can get the budget needed for that though, but fortunately I do not code at coder-rates, but at full consulting rates. While customers (well, managers there) routinely complain about the rates, nobody has so far complained about the results the get for the money.
My "elitism" is realism. And a deep understanding of the question at hand. You lack both and you are a coward in addition.
When you work on the same areas long-term so that you can have analysts that stay a long time, then that is a pretty good solution.
There is a difference between a library and a framework. But that you do not get my point just shows you have not yet run into this problem. It currently pays for a substantial part of my work-time.
Fist, they have no clue what computing paradigm would be the basis of such a simulation. The theoretical limits we know are only for digital computers in the absence of "magic". And second, what makes them think all that nice stuff they base their reasoning on is not cleverly faked? Have they forgotten what level of control such a simulation would have?
In the end, they have nothing. Just the same as those people claiming we definitely are in a simulation. It is a valid model, but there is no way to show it is accurate or not.
People think that this great gadget makes them hip and irresistible, and they would spend even more. I mean, look at the cars some men buy just to impress women and look at what some women invest in cosmetics and "body enhancements" just to impress men.
This has noting to do with the phone itself, or Apple would have gone bankrupt a while ago.
Lawmakers are what happens when people think their written word defines reality. Alternatively they start writing holy books, which is even worse.
These were not really computers in the modern sense. No capability to run general-purpose code. Also, if I remember correctly, they basically had people doing the job of an assembler between the coders and the machines. Might even be were the name comes from.
Well, I have when doing I/O to specific hardware components. But that is about it. For actual code, I always had at least an assembler.
I do agree that the stance of the article is mostly BS, also because you _cannot_ think like a computer. Computers are exceptionally dumb in a very fast fashion. No human can think like that. Smart humans can think in a smart and complex fashion pretty slowly. That is nothing alike computers.
Hehehehe, it also solves the problem of what language to make fun of ;-)
Indeed. You cannot abstract complexity away. You can hide it, often with really bad effects, but it will still be there. The only cases were abstraction makes things easier is if the complexity was created by a bad tool and is not inherent to the task being solved. You will always need to understand that task in order to create an adequate solution. And if that task is complex and cannot be simplified, then the solution must necessarily be complex too. Of course, a major talent for any good engineer is the simplification of tasks.
Ah, yes? The only point of that was marketing and some politicians simulating being "modern" anyways. And some nice rip-off-type business models for "coding schools".
What do you think makes your car entertainment system crash and your navigation system hard to use? Fairies?