Programming is the new literacy. It isn't going away, it's 5 years out from being a mandatory high school or middle school topic.
I think you overestimate the intelligence of 99% of people.
The End of Coding
81–90 of 106 posts
Re: The End of Coding
#82Earlier quoted context omitted.
It is funny to me that people extrapolate "code" as just our best way of representing computational instructions we want done that we can express in natural language. I agree with you that sometimes this isn't true. Sometimes I read code and I can't express what it does in English. I could roughly describe what it does, but I can't communicate all of its subtlety. The limitations of "no code" isn't the theoretical li…
Poorly-written code (especially if the reader doesn't have a good grasp of the coding language) can be very confusing, but it will still almost never be ambiguous. If you try taking some well-written code and converting it to natural language with utterly no ambiguity, you'll quickly find that: - the natural language version is far, far longer and harder to read - it takes a lot of work to remove all ambiguities, and…
Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
Re: The End of Coding
#83So far visual coding has just been useful for minting more CS degrees, not actually getting stuff done. Can't really see things going this guy's direction.
Re: The End of Coding
#84Ah yes, the end of coding is inevitable, the PC is dead, and 2013 will surely become the year of the Linux desktop.
> 2013 will surely become the year of the Linux desktop There's still a non-zero chance that this one come true. It does not fit well within the others.
> There's still a non-zero chance that this one come true.
Best joke of the year.
Re: The End of Coding
#85Earlier quoted context omitted.
Poorly-written code (especially if the reader doesn't have a good grasp of the coding language) can be very confusing, but it will still almost never be ambiguous. If you try taking some well-written code and converting it to natural language with utterly no ambiguity, you'll quickly find that: - the natural language version is far, far longer and harder to read - it takes a lot of work to remove all ambiguities, and…
Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away!
(the second sentence is a joke.)
Re: The End of Coding
#86Programming is the new literacy. It isn't going away, it's 5 years out from being a mandatory high school or middle school topic.
5 years? Mandatory?? You're being insanely optimistic.
I would consider that pessimistic. If that becomes true, the tremendous job security I have now would start to evaporate.
Re: The End of Coding
#87Coding is simply telling a computer what to do. Even to a certain degree, entering a term into Google's search engine is a type of coding. And maybe that will be the future, parsers and compilers that can turn plain language into computer instructions. We're not terribly far off with transpilers/compilers that turn Python and other high level languages into C or native code...
Until a computer can program itself (which may never happen), there's going to be a person telling it what to do - and no matter whether it's a formula in a spreadsheet, a programming language, or something higher level, it'll still be code...
Re: The End of Coding
#88Earlier quoted context omitted.
Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away! (the second sentence is a joke.)
Ambiguity is quite frequently between several well-defined states. A significant difference between race conditions and natural language ambiguity is that in the latter we typically expect resolution to happen favorably when the interaction is cooperative - which is not a feature of race conditions in the general or typical case. I think it's still fair to say that this is not an essential feature of ambiguity, though, which is why I included it as an example. In the case of a race condition, the relevant pieces of the language do not uniquely define a single result - additional context may.
Re: The End of Coding
#89Earlier quoted context omitted.
Yup, it's kind of tedious seeing these types of article / blog post. As anyone that works as a programmer knows, it's not the grammar of programming that is hard. It's understanding the hardware and what it can do that is hard. It's encoding nebulous and sometimes conflicting business requirements into something a computer can understand that is hard. It's taking into account all of the different error states that a…
I agree with all the things you say are hard: understanding computation, encoding complex requirements, handling edge cases; but typing code into an editor and then re-running your application doesn't provide much support for making them easier. Better tools could help programmers and non-programmers alike work with that complexity much more effectively.
They could, but those two sets of tools would be completely different and would be built based on completely different principles.
Re: The End of Coding
#90Earlier quoted context omitted.
Code can certainly be ambiguous. We call it unspecified behavior, undefined behavior, or race conditions, depending.
A race condition is a set of (possibly very many) very well defined states - or at least defined as well as everything else in the program. Someone should discover some algebra for working with concurrent processes and the race conditions would go away! (the second sentence is a joke.)
A simple data race in C11/C++11 is undefined behavior, it doesn't have to result in any well-defined state that you might get by interleaving the execution of threads.
I think this has been on HN already: http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.ht...
Essentially it has to be that way, or on some architectures every access to a potentially shared variable would have to be wrapped in fences by the compiler.