9 ms·

I feel like I've been reading this article every year, with some variation but the same yet-unrealized potential every time. I'm not an expert in "human" codin

by jtheory 13y ago

I feel like I've been reading this article every year, with some variation but the same yet-unrealized potential every time. I'm not an expert in "human" coding or AI, but I get the same vibe from both of them -- until you try it yourself, it seems pretty reasonable that someone will solve this problem fairly soon. And it has seemed that way for many years now. Simple CRUD apps can already be built with simple, friendly interfaces. The simple apps will continue to get easier for non-programmers to assemble without "coding". But real life requirements get comlicated soon -- your simple CRUD app now needs to auto-charge customers every time they foo 100 bars, unless it's been less than a month (in which case you charge a prorated total at month end), and early subscribers are grandfathered in to a simple fixed monthly charge. How will you click-and-drag that? Or explain it clearly in natural language, without multiple possible interpretations? People make complicated stuff in Excel spreadsheets, and while it starts off as fairly vanilla, it quickly becomes something as complicated (if not more so) than writing a standard computer program in code. Natural language serves a purpose -- mostly around navigating complicated social situations, including expressing general desires to others (who have motivations of their own, and will interpret according to their own internal rules). It's fuzzy and generally non-specific because that's how we are. Why do we imagine our normal ways of interacting with each other can be applied to instructing a process to execute complex & strict logic? I'm pretty sure we can make progress -- clean up the leakiest abstractions from software to APIs to hardware... -- and sort out the best way to build coding languages so they are as intuitive as possible for humans -- but I don't think "code" generally is going to disappear anytime soon.

300bps 13y ago
You were able to read the website? All I see is: Error establishing a database connection Maybe the OP should hire a coder to fix his site?
- tluyben2 13y ago
  Do as everyone does; keep reloading; you'll catch it :) Besides it being the reason the db is not responding.
- alexnorth 13y ago
  I'm on it. Meanwhile, cache is http://webcache.googleusercontent.com/search?q=cache:qjCebmDnUkcJ:alexn.id.au/2013/10/30/the-end-of-coding/+&cd=2&hl=en http://webcache.googleusercontent.com/search?q=cache:qjCebmD...
floobynewb 13y ago
I honestly don't think you can make it much simpler. That is not to say it is simple, just that it is by nature not simple. You can dress the concepts up, make them look nice with a graphical front end, but really the complexity comes from the abstract notions implicit in functions to be performed. You can tailor things by building libraries of functions to perform common tasks, but these abstractions are never going to be sufficient. What is required is a method of translating from the world we are most familiar with, described by our natural language, into the world described by the language of the computer. The translator needs to understand the context of the natural language requirement and find its correct representation in binary. This is the job of the programmer. An automated solution may well be able to pass the Turing test. That being said, I often think about how to leverage machine learning to help bridge the language gap. Evolving an application is an interesting idea, where the requirements are drip fed to the system through the language of the UI the program should present. Translations from some physical representation, cogs, roads, queues, etc might be useful since it is instinctive to many people yet more precise in its descriptive power than spoken language.
gmjoe 13y ago
Exactly. I remember, once a friend wanted to create a tool for designers to use for creating HTML+CSS visually, without having to know actual CSS properties and such. Then I explained, the hard part of laying out webpages is not the basic layout -- it's how layout reflows when text overflows, when the browser window is too narrow, when image sizes change, what things maintain alignment and what things don't -- and that by the time you've added all these options to your visual tool, the visual tool is now equally complicated as CSS, so you've defeated the whole purpose. At its heart, it's the fact that the specification of the program is the program. The devil is always in the details. (Which, incidentally, is why it's so hard to estimate development time accurately.)
- bluesnowmonkey 13y ago
  It's a good thing you talked your friend down from creating something. The world has too many creators as it is. Don't they know that everything good has been created already? If it hasn't been done then it isn't possible!
  - resu_nimda 13y ago
    Did you have a point here? Do you think he should have just said "sure man, sounds great, go for it!" Did you know that a lot of non-programmers have a lot of great ideas, and that educating them about the difficulties of implementing those ideas isn't actually a bad thing? The particular app in question has been tried a million times and countless hours have been invested into it, perhaps learning from that body of work would be helpful? But hey, maybe that guy is The One who will come out of nowhere and solve the problem in a completely new manner (half-serious - it's technically possible, but I don't think it's useful to put our eggs in that basket).
    - jcoder 13y ago
      > Do you think he should have just said "sure man, sounds great, go for it!" His friend would have made a lot of personal progress in their understanding and abilities.
antimagic 13y ago
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 process can get into that is hard. Learning the syntax of a programming language? Not hard. We as programmers have weird brains, compared to most of the population. You give a programmer the list of road rules, and they will probably immediately identify, instinctively, several rules that are mutually exclusive / in conflict with each other. You're able to understand how a home entertainment system needs to be set up, even though that's really not what most programmers do. You identify loopholes in legal frameworks / contracts, because the lawyers that wrote them aren't used to thinking about what has to happen for edge cases.
- alexnorth 13y ago
  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.
  - barce 13y ago
    Tools are designed for certain requirements. As the commenter, antimagic, noted, these requirements can conflict. A better tool would definitely have to sort out those conflicts, but at this point we're talking about something like AI. To talk down the scope of lots of projects, I've always educated a client by saying if certain types of thinking were automated then we'd have to say we were creating AI and that the cost of the project would grow exponentially.
  - freshhawk 13y ago
    They could, but those two sets of tools would be completely different and would be built based on completely different principles.
wes-exp 13y ago
The belief that better tools will obsolete the need for all that coding effort is probably as old as computer programming itself. Fred Brooks, author of The Mythical Man-Month, dismissed the idea in his 1986 paper No Silver Bullet: "... building software will always be hard. There is no silver bullet." http://en.wikipedia.org/wiki/No_silver_bullet http://en.wikipedia.org/wiki/No_silver_bullet
- wpietri 13y ago
  It's certainly at lest 30 years old. Before my voice changed I went to my first computer conference. People were selling tools there that would let business types do "programming" via just writing what they want in English. For minicomputers. Of course, they had to write in a minimal, highly structured pseudo-English. And the problem domain was highly restricted. So it was basically programming, except less effective. A fine example of the phenomenon that if enough people want something, somebody will come along and sell it to them, whether or not it actually works. I used to think this was malice, but as far as I can tell, greed, narcissism, and the Dunning-Kruger effect can explain it perfectly well.
  - gbhn 13y ago
    It's probably good to try every so often, anyway, even though it's impossible. :-)
    - wpietri 13y ago
      Trying is excellent. Trying and failing is also excellent, in that it's how we learn. Trying and failing and then selling the product as if it's a success? Less excellent. :-)
crusso 13y ago
Right. By the time this problem is truly solved with software sophisticated enough to eliminate the need for programmers, most people will be fairly useless in any endeavor.
hacknat 13y ago
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 limits of AI it's human!
- jtheory 13y ago
  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 you will find yourself wanting to put a dictionary with strict rules and extensions -- totally unlike a REAL dictionary. => Word "allow" will always mean generally the 1st (verb) definition in Mirriam-Webster online, and will further imply that if the subsequent test (see below for definition) succeeds (definition below), then execution (see below) will continue; if the test fails (see below) then standard error (see below) handling procedure (see below) will be followed, in which... It's ridiculous, isn't it? You'd be inventing a new (but probably horrible) coding language, not using natural language at all any more. The thing about natural language code -- it does exist, sort of. Think about the checklists that airline pilots run through before takeoff, for a good example. That's sort of natural language process execution... but it's the same every time, the context is known (it's being executed by an airline pilot sitting in the cockpit of a specific airplane), the pilot is trained such that s/he has practiced running the checklist many, many times before doing it "for real". And: it's a friggin' checklist. Is logic in there whatsoever, beyond "if this is true, continue; if not, abort"? The limitations on it are incredible, and we still have human beings executing that "code"; they are not automated. The answer to one of the questions might unexpectedly be "sort of", or "yes, value in the safe range, but why is it steadily dropping?"
  - dllthomas 13y ago
jes5199 13y ago
Code will disappear just as quickly as legalese disappeared after we were able to write clear and concise agreements in common, natural language.

by jtheory 13y ago

300bps 13y ago

You were able to read the website? All I see is: Error establishing a database connection Maybe the OP should hire a coder to fix his site?

tluyben2 13y ago
Do as everyone does; keep reloading; you'll catch it :) Besides it being the reason the db is not responding.
alexnorth 13y ago
I'm on it. Meanwhile, cache is http://webcache.googleusercontent.com/search?q=cache:qjCebmDnUkcJ:alexn.id.au/2013/10/30/the-end-of-coding/+&cd=2&hl=en http://webcache.googleusercontent.com/search?q=cache:qjCebmD...

floobynewb 13y ago

I honestly don't think you can make it much simpler. That is not to say it is simple, just that it is by nature not simple. You can dress the concepts up, make them look nice with a graphical front end, but really the complexity comes from the abstract notions implicit in functions to be performed. You can tailor things by building libraries of functions to perform common tasks, but these abstractions are never going to be sufficient. What is required is a method of translating from the world we are most familiar with, described by our natural language, into the world described by the language of the computer. The translator needs to understand the context of the natural language requirement and find its correct representation in binary. This is the job of the programmer. An automated solution may well be able to pass the Turing test. That being said, I often think about how to leverage machine learning to help bridge the language gap. Evolving an application is an interesting idea, where the requirements are drip fed to the system through the language of the UI the program should present. Translations from some physical representation, cogs, roads, queues, etc might be useful since it is instinctive to many people yet more precise in its descriptive power than spoken language.

gmjoe 13y ago

Exactly. I remember, once a friend wanted to create a tool for designers to use for creating HTML+CSS visually, without having to know actual CSS properties and such. Then I explained, the hard part of laying out webpages is not the basic layout -- it's how layout reflows when text overflows, when the browser window is too narrow, when image sizes change, what things maintain alignment and what things don't -- and that by the time you've added all these options to your visual tool, the visual tool is now equally complicated as CSS, so you've defeated the whole purpose. At its heart, it's the fact that the specification of the program is the program. The devil is always in the details. (Which, incidentally, is why it's so hard to estimate development time accurately.)

bluesnowmonkey 13y ago
It's a good thing you talked your friend down from creating something. The world has too many creators as it is. Don't they know that everything good has been created already? If it hasn't been done then it isn't possible!
- resu_nimda 13y ago
  Did you have a point here? Do you think he should have just said "sure man, sounds great, go for it!" Did you know that a lot of non-programmers have a lot of great ideas, and that educating them about the difficulties of implementing those ideas isn't actually a bad thing? The particular app in question has been tried a million times and countless hours have been invested into it, perhaps learning from that body of work would be helpful? But hey, maybe that guy is The One who will come out of nowhere and solve the problem in a completely new manner (half-serious - it's technically possible, but I don't think it's useful to put our eggs in that basket).
  - jcoder 13y ago
    > Do you think he should have just said "sure man, sounds great, go for it!" His friend would have made a lot of personal progress in their understanding and abilities.

antimagic 13y ago

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 process can get into that is hard. Learning the syntax of a programming language? Not hard. We as programmers have weird brains, compared to most of the population. You give a programmer the list of road rules, and they will probably immediately identify, instinctively, several rules that are mutually exclusive / in conflict with each other. You're able to understand how a home entertainment system needs to be set up, even though that's really not what most programmers do. You identify loopholes in legal frameworks / contracts, because the lawyers that wrote them aren't used to thinking about what has to happen for edge cases.

alexnorth 13y ago
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.
- barce 13y ago
  Tools are designed for certain requirements. As the commenter, antimagic, noted, these requirements can conflict. A better tool would definitely have to sort out those conflicts, but at this point we're talking about something like AI. To talk down the scope of lots of projects, I've always educated a client by saying if certain types of thinking were automated then we'd have to say we were creating AI and that the cost of the project would grow exponentially.
- freshhawk 13y ago
  They could, but those two sets of tools would be completely different and would be built based on completely different principles.

wes-exp 13y ago

The belief that better tools will obsolete the need for all that coding effort is probably as old as computer programming itself. Fred Brooks, author of The Mythical Man-Month, dismissed the idea in his 1986 paper No Silver Bullet: "... building software will always be hard. There is no silver bullet." http://en.wikipedia.org/wiki/No_silver_bullet http://en.wikipedia.org/wiki/No_silver_bullet

wpietri 13y ago
It's certainly at lest 30 years old. Before my voice changed I went to my first computer conference. People were selling tools there that would let business types do "programming" via just writing what they want in English. For minicomputers. Of course, they had to write in a minimal, highly structured pseudo-English. And the problem domain was highly restricted. So it was basically programming, except less effective. A fine example of the phenomenon that if enough people want something, somebody will come along and sell it to them, whether or not it actually works. I used to think this was malice, but as far as I can tell, greed, narcissism, and the Dunning-Kruger effect can explain it perfectly well.
- gbhn 13y ago
  It's probably good to try every so often, anyway, even though it's impossible. :-)
  - wpietri 13y ago
    Trying is excellent. Trying and failing is also excellent, in that it's how we learn. Trying and failing and then selling the product as if it's a success? Less excellent. :-)

crusso 13y ago

Right. By the time this problem is truly solved with software sophisticated enough to eliminate the need for programmers, most people will be fairly useless in any endeavor.

hacknat 13y ago

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 limits of AI it's human!

jtheory 13y ago
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 you will find yourself wanting to put a dictionary with strict rules and extensions -- totally unlike a REAL dictionary. => Word "allow" will always mean generally the 1st (verb) definition in Mirriam-Webster online, and will further imply that if the subsequent test (see below for definition) succeeds (definition below), then execution (see below) will continue; if the test fails (see below) then standard error (see below) handling procedure (see below) will be followed, in which... It's ridiculous, isn't it? You'd be inventing a new (but probably horrible) coding language, not using natural language at all any more. The thing about natural language code -- it does exist, sort of. Think about the checklists that airline pilots run through before takeoff, for a good example. That's sort of natural language process execution... but it's the same every time, the context is known (it's being executed by an airline pilot sitting in the cockpit of a specific airplane), the pilot is trained such that s/he has practiced running the checklist many, many times before doing it "for real". And: it's a friggin' checklist. Is logic in there whatsoever, beyond "if this is true, continue; if not, abort"? The limitations on it are incredible, and we still have human beings executing that "code"; they are not automated. The answer to one of the questions might unexpectedly be "sort of", or "yes, value in the safe range, but why is it steadily dropping?"
- dllthomas 13y ago

jes5199 13y ago

Code will disappear just as quickly as legalese disappeared after we were able to write clear and concise agreements in common, natural language.