If you’re really outraged at normal, everyday expressions of basic humanity then... maybe it's you that has the problem. Maybe the rest of us should be worrying about what you might do next.
Basic social expressions don't raise red flags for normal people. If #HumpDay seems sinister to you, consider getting some counseling.
You are trying very hard to argue that there's no place for any better tools in programming. And that all problems are already solved, I guess. No new tools or new thinking needed.
And even if someone tried something, he'd assuredly do it wrong, because it's impossible to even create tests that are good enough to specify a secure, robust system.
Lots of things have improved since then. Much of the machine learning stuff that's "the new big thing" is not too much different than the stuff from 25 years ago. One of the main differences is that chips are fast enough to actually do it now.
It doesn't really need to be said, because it is so self evident.
I don't agree. A huge number of software developers don't want new ways of doing things because the old ways let them be the masters.
We have to be honest with ourselves, in practice, test cases don't cover all scenarios. They assume some amount of human intelligence and are there for the 'tricky' cases. If you suddenly had to have test cases for every expected behavior for software to randomly guess algorithms to hit it, it would be as hard as programming, if not harder.
But the implementation you would end up with would be a secure one, because you tested it for insecure inputs. And it would be a robust one, because your input set for testing is thorough and has good coverage. So there's that.
I guess I sholudn't have said 'works' but should have said 'practical'. As above, in most programming, it's *far* easier to just state the things for the computer to do than to tediously describe all sorts of scenarios until random code generation produces something vaguely appropriate. This isn't a matter of refining the techniques, it's just a fundamental reality of that approach.
I never said "random" code generation. Rather something that takes instructions that are more general than very carefully crafted code, and outputs code to pass tests.
For example, I want to loop through a collection to implement a transformation of the contents: - Do I write my loops and worry about the boundaries? Why? Let the software deal with the boundaries. - Do I worry about whether the collection is sorted? Why? Let the software determine whether the collection is sorted and end the looping early if it can. - Did I specify the collection was sorted to begin with? Why? Let the software look at how the items were collected and used and decide whether to maintain them in sorted order or to sort them, and what sorting algorithm to use. - Do I worry about paralyzing the transform operation? Let the software break it up and send it to the GPU to do all in one go. Or not if the transformation can't be compiled for GPU. Or not if it will be slower to use the GPU.
This is not really a great example. But let's have software that helps us -- a lot more than it does already.
And no, the answer isn't I have a new programming language.
Yes, but let's start saying it. Then someone might do it, or part of it. Then we'll have better tools.
Basically creating those 'tests' is going to be programming... again...
Some maybe. Maybe not much if you can gather inputs from users of a previous implementation. Or if you have a random generator to help you make sample inputs.
you could instead... just program...
But your implementation still has to pass tests, even if you just think them and don't write them down. Writing them down means they can be used outside your own brain.
The whole 'software guesses randomly' works in some very useful, but very narrow problem sets.
Let's expand the number of those problem sets. And then break down big problems into parts that fit into this expanded set. And then when software is doing 30% of our work, we can spend more time on the other 70%, empower young and/or mediocre developers, and all get paid more because we can build better implementations in less time.
I currently have an engineer fresh out of college working on making the above for loop actually work. I described it to him and he told me he could get it done in a day or two. That was two weeks ago. Because it turns out, it's a hell of a lot harder than that. Every time he comes to me and tells me he is done, I ask him "what about this edge case?" or "did you check that x is getting set correctly?" or "what if then inputs comes in like this?". And he goes back to his desk to continue trudging through every which way that one simple for loop that is easily described by a three sentence task order can go wrong.
Also, why don’t you have your engineer writing tests for his implementation first? Then he can understand the entire problem domain, then he can write his code to pass the tests. Then he can run regressions when he makes changes. Get the tests right, get the implementation right.
The PROBLEM is expressing "Input the behavior you want" in mathematical terms.
Without that preciseness, there is too many variations... and you can't dictate "do what I mean" when you can't express what that means.
Sure you can. Say "do basically this" and have the software guess the rest. Create tests that tell the software whether it guessed right or it needs to keep guessing. When that fails, give it a more precise instruction.
We are already at the extreme of software not really helping here. Any improvement would be better.
in which case we've already been fixing it for decades... they are called assemblers and compilers.
Yes, but those are first and second level sorts of enabling tools. Beyond that you have the Java and JavaScript JIT compilers which do substantially more. But they are limited because they have to be efficient — they need to execute code in less time counting the overhead of the JIT compiler. What could they do if they had 1000x the time to pre-optimize the implementation?
And that’s the runtime and compile time part. The actual code-writing part is what needs more effort. Why do we still need to worry about writing correct syntax? No one worries about correct spelling any more.
Why do we need to worry about what is scheduled when? Let’s tell the software to do A, B, C,... K things and have it analyze the dependencies and schedule. Unroll loops, fracture it up into whatever bits are needed, as long as the sequence satisfies the dependencies.
He states the problem. He says it should be better. He doesn't go into "how".
The fix should be to have software write the code. Input the behavior you want in any programming language — maybe a new one, but old ones to start with.
Then the software translates it into whatever other language, replaces the easy to understand loops and such with efficient implementations that provide the same result and are provably secure, identifies sequence points, breaks it all up into parrallelizable nuggets, and sends the whole thing to a scheduler that runs it on a set of CPUs.
If you really wanted to solve anything, you'd leave the politics out of it. Making it political is the surest way to tell half the US public not to listen.
Slashdot Mirror
facts win.
Unless the mods can hide them before anyone finds out.
It was much warmer than this before. Then it cooled. Therefore the "irreversible" claim has already been falsified.
That’s an argument against using a very specific imagined implementation.
If you’re really outraged at normal, everyday expressions of basic humanity then ... maybe it's you that has the problem. Maybe the rest of us should be worrying about what you might do next.
Basic social expressions don't raise red flags for normal people. If #HumpDay seems sinister to you, consider getting some counseling.
Organizations that interact with people try to be appealing in public, so it's easier to succeed in interacting with people. Mind blowing, I know.
Incorrect
You are trying very hard to argue that there's no place for any better tools in programming. And that all problems are already solved, I guess. No new tools or new thinking needed.
And even if someone tried something, he'd assuredly do it wrong, because it's impossible to even create tests that are good enough to specify a secure, robust system.
Sounds like a middle manager who doesn't really understand anything but wants it to be cheaper/easier so he doesn't have to pay PhD wages
To be fair, everyone besides PhDs wants this. We would all have a lot better software and gadgets a lot sooner.
Your analogy fails
Analogies fail. No two things are precisely analogous.
No one has found a replacement for a writers brain...
Some news sites have AI writing news. Some stories like company financial reporting are effectively written with no writers.
I still want better programming tools.
Lots of things have improved since then. Much of the machine learning stuff that's "the new big thing" is not too much different than the stuff from 25 years ago. One of the main differences is that chips are fast enough to actually do it now.
Yes. I'd suggest something like that could be the basis for lots of new tools.
It doesn't really need to be said, because it is so self evident.
I don't agree. A huge number of software developers don't want new ways of doing things because the old ways let them be the masters.
We have to be honest with ourselves, in practice, test cases don't cover all scenarios. They assume some amount of human intelligence and are there for the 'tricky' cases. If you suddenly had to have test cases for every expected behavior for software to randomly guess algorithms to hit it, it would be as hard as programming, if not harder.
But the implementation you would end up with would be a secure one, because you tested it for insecure inputs. And it would be a robust one, because your input set for testing is thorough and has good coverage. So there's that.
I guess I sholudn't have said 'works' but should have said 'practical'. As above, in most programming, it's *far* easier to just state the things for the computer to do than to tediously describe all sorts of scenarios until random code generation produces something vaguely appropriate. This isn't a matter of refining the techniques, it's just a fundamental reality of that approach.
I never said "random" code generation. Rather something that takes instructions that are more general than very carefully crafted code, and outputs code to pass tests.
For example, I want to loop through a collection to implement a transformation of the contents:
- Do I write my loops and worry about the boundaries? Why? Let the software deal with the boundaries.
- Do I worry about whether the collection is sorted? Why? Let the software determine whether the collection is sorted and end the looping early if it can.
- Did I specify the collection was sorted to begin with? Why? Let the software look at how the items were collected and used and decide whether to maintain them in sorted order or to sort them, and what sorting algorithm to use.
- Do I worry about paralyzing the transform operation? Let the software break it up and send it to the GPU to do all in one go. Or not if the transformation can't be compiled for GPU. Or not if it will be slower to use the GPU.
This is not really a great example. But let's have software that helps us -- a lot more than it does already.
And no, the answer isn't I have a new programming language.
Cultural references don't work any more. A tiny, tiny, tiny fraction of readers watch NCIS. Most people probably don't even know it's a TV show.
Also, what's wrong with advocating for better tools? Please post your better ideas if you have them. Then it would be an interesting discussion.
Obviously we already have compilers. We need something beyond that now.
Easier said than done.
Yes, but let's start saying it. Then someone might do it, or part of it. Then we'll have better tools.
Basically creating those 'tests' is going to be programming... again...
Some maybe. Maybe not much if you can gather inputs from users of a previous implementation. Or if you have a random generator to help you make sample inputs.
you could instead... just program...
But your implementation still has to pass tests, even if you just think them and don't write them down. Writing them down means they can be used outside your own brain.
The whole 'software guesses randomly' works in some very useful, but very narrow problem sets.
Let's expand the number of those problem sets. And then break down big problems into parts that fit into this expanded set. And then when software is doing 30% of our work, we can spend more time on the other 70%, empower young and/or mediocre developers, and all get paid more because we can build better implementations in less time.
I currently have an engineer fresh out of college working on making the above for loop actually work. I described it to him and he told me he could get it done in a day or two. That was two weeks ago. Because it turns out, it's a hell of a lot harder than that. Every time he comes to me and tells me he is done, I ask him "what about this edge case?" or "did you check that x is getting set correctly?" or "what if then inputs comes in like this?". And he goes back to his desk to continue trudging through every which way that one simple for loop that is easily described by a three sentence task order can go wrong.
Also, why don’t you have your engineer writing tests for his implementation first? Then he can understand the entire problem domain, then he can write his code to pass the tests. Then he can run regressions when he makes changes. Get the tests right, get the implementation right.
You should have software helping your engineer.
The PROBLEM is expressing "Input the behavior you want" in mathematical terms.
Without that preciseness, there is too many variations... and you can't dictate "do what I mean" when you can't express what that means.
Sure you can. Say "do basically this" and have the software guess the rest. Create tests that tell the software whether it guessed right or it needs to keep guessing. When that fails, give it a more precise instruction.
We are already at the extreme of software not really helping here. Any improvement would be better.
in which case we've already been fixing it for decades... they are called assemblers and compilers.
Yes, but those are first and second level sorts of enabling tools. Beyond that you have the Java and JavaScript JIT compilers which do substantially more. But they are limited because they have to be efficient — they need to execute code in less time counting the overhead of the JIT compiler. What could they do if they had 1000x the time to pre-optimize the implementation?
And that’s the runtime and compile time part. The actual code-writing part is what needs more effort. Why do we still need to worry about writing correct syntax? No one worries about correct spelling any more.
Why do we need to worry about what is scheduled when? Let’s tell the software to do A, B, C, ... K things and have it analyze the dependencies and schedule. Unroll loops, fracture it up into whatever bits are needed, as long as the sequence satisfies the dependencies.
He states the problem. He says it should be better. He doesn't go into "how".
The fix should be to have software write the code. Input the behavior you want in any programming language — maybe a new one, but old ones to start with.
Then the software translates it into whatever other language, replaces the easy to understand loops and such with efficient implementations that provide the same result and are provably secure, identifies sequence points, breaks it all up into parrallelizable nuggets, and sends the whole thing to a scheduler that runs it on a set of CPUs.
They are going to make a lot of money countersuing those states for First and Second Amendment violations.
We bicker about every stupid issue under the sun instead of taking the action we know is necessary.
Enacting Net Neutrality?
Specifically to irritate people like you.
If you really wanted to solve anything, you'd leave the politics out of it. Making it political is the surest way to tell half the US public not to listen.
It's not, nobody said it was...
This guy said it:
https://www.theguardian.com/en...