6 ms·

When are we going to stop writing code?

7 points by gdp 17y ago

philwelch 17y ago
"I believe it is very nearly within our reach to stop writing software and start specifying software instead. Write the specification, press a button and have a full implementation that is mathematically guaranteed to implement your specification." Well, we'd have to write that specification in some sort of consistent formal language. What kind of computer program converts a program specified in formal language into an executable program? Oh, right--a compiler. The most generous I can get here is to suppose he's advocating a declarative high-level programming language. But that wouldn't be nearly as interesting to write an essay about, so let's pretend that your declarative, high-level "specification" language means "no more writing code". Either that, or he honestly believes you can write a compiler for English. But given how most specs are written, I would be even more fearful of the output of an English compiler. So you have to use a formally specified language--oh wait, that's coding again.
- krakensden 17y ago
  The worst part is that he seems to think this is a novel idea.
  - gdp 17y ago
    Who said anything about novelty? Referring to tools that do most of what is described seems to negate any claims of novelty.
- gdp 17y ago
  Sure, the distinction between writing specification and writing code is pretty artificial. A specification may be incomplete or ambiguous. Through stepwise refinement, multiple (formal) steps are taken towards a more concrete implementation, which eventually might result in an efficient implementation capable of being executed. None of this is really new, and I think the differences between a "program" and a "specification" are reasonably well understood in most contexts. Tools already exist to do these sorts of things, they are just restricted to certain problem domains where the expense and overhead are justifiable for the extra safety guarantees. Also, I think you're jumping way back into coder-world by talking about declarative high level languages. Sure, that might be one way of achieving the stated goals (and indeed, many have gone down that path!) however specifications can come in many shapes and sizes. The idea is to reduce the number of abstractions which the programmer must hold in his or her head in order to write programs. The ability to construct ambiguous, incomplete specifications that can be interacted with or validated before anything resembling an executable specification comes about is beneficial in many circumstances, particularly when you are talking about concurrent or distributed systems. Basically what I'm saying is that a specification provides only some of the information required to construct an executable program, and may abstract away specific behavioural information until much later into some refinement process. A "program", as such, does not, and by its nature contains a description of exactly all the behaviour that can be exhibited by execution of said program.
  - philwelch 17y ago
    "Also, I think you're jumping way back into coder-world by talking about declarative high level languages." Not really--"specifications" are usually understood to be expressed in declarative English, and any sort of "specification" that can be programatically translated into a program would simply be high level source code. I'm not against writing specs, I'm simply saying "a spec that can be compiled is code".
    - gdp 17y ago
      But a specification could be ambiguous, with the need for human intervention to resolve ambiguity through the 'compilation' process. And I'm not sure that I'm aware of any production-grade systems that use declarative English as a specification mechanism. Most of the systems that I am familiar with use ASCII-friendly logic notation or mathematical notation in the style of LaTeX or similar. I'm not necessarily suggesting that this is how software should be developed, rather I'm just pointing out that your experience and knowledge of what might pass as a specification is different to mine.
      - philwelch 17y ago
        Here's my point. "You should be able to compile spec" is a useless argument, because anything we can compile would either be English (which we shouldn't compile) or a formal language (and a formal language that can be compiled is a programming language). Useful things to say include "here's a good high-level language that makes it easier to program" or "here's a language and a compiler for it that allows the compiler to ask intelligent questions about ambiguity in the code". "I want to be able to push a button and turn a specification into a program" is too vague to be useful--interpreted literally it already describes the compilers we have today, and interpreted liberally it could mean anything from "languages aren't high level enough" to "programming is too hard" to "I want to express programs with pretty pictures and by answering questionnaires" to "I want to compile English". Now, if we rule out "I want to compile English" as a very bad and stupid idea, we're left with things that, quite frankly, we've been researching the whole time (with the possible exception of compilers that question ambiguous expressions). Forcing us to ultimately conclude, first that the author doesn't know what he's talking about, and second that he isn't asking for anything more than what computer scientists are already working on.
- extension 17y ago
  On somewhat of a tangent, consider a specification such as "sort a list of numbers". After adding a few minor details, this could be an entirely formal and unambiguous specification, yet implementation would require (disregarding prior art) an informal creative process involving significant leaps of intuition. It seems to me that a formal spec need only provide a method of verification and is therefor distinct from the solution, though it's no surprise that the distinction goes unnoticed in our industry, given the dearth of both specs and difficult algorithmic problems.
  - philwelch 17y ago
    But we can already turn "sort a list of numbers" into a program, although instead of "sort a list of numbers", it's called sort() and takes a list of numbers as an argument. By this standard, most programs are closer to specs than they are to solutions--a testament to the abstractions we already have.
    - extension 17y ago
      I had gotten word that the sorting problem has been solved, hence the "disregarding prior art" part. My point, which you don't seem to be contradicting, is that a formal specification of a problem is not the same as a solution. They just seem the same because real world programming problems tend to have obvious solutions, or at least solutions that don't feel much like programming.
      - philwelch 17y ago
        That's cool, but kind of an orthogonal point.
        extension 17y ago
        Somewhat of a tangent, one might even say.
kenshi 17y ago
I was listening to an interesting interview with Dustin Nguyen, a comics artist yesterday. He had a background in CAD work, and for a long time had a pet project of creating locations for scenes in a CAD package. The idea being he and his co-workers would be able to save a load of time when drawing the art, because they could just use rendered backgrounds. He mentioned this idea to his boss (famed comics artist Jim Lee) who apparently just said: "Why? Drawing is fun,". And to this idea of automatically generating code from some formal spec, I can't help but think: "Why? Programming is fun," Sure no one likes tedious, rote programming. I especially don't like the kind of tedious typing statically typed languages tend to require you to write. But if you aren't finding the art of programming fun... I think you are in the wrong line of work. For any interested parties, the interview with Nguyen was from episode 91 of the Sidebar podcasts - http://www.sidebarnation.com/ http://www.sidebarnation.com/
- gdp 17y ago
  Problem solving is fun, and programming is a convenient way to access a large class of problems and express solutions to them. When the problem solving bit is done, the rest is just typing. I'd rather spend more time solving interesting problems and less time typing. Not to mention that I am likely to make mistakes while I'm typing up my solution. I'd rather not have to waste time chasing errors I've made that could have been avoided. Instead, I would rather spend time fixing errors in my solutions to problems, or looking for even better solutions.
CamperBob 17y ago
It's ironic that we've used computers to attack problems and improve processes in virtually every aspect of life except writing computer programs. The process of programming still looks pretty much the same as it did in Grace Hopper's day. I agree with the author: that's just stupid. The question remains, though: what do we do about it?
- tl 17y ago
  When Grace Hopper was programming your choices involved Assembly, FORTRAN and COBOL. Yes, we still have to write code, but 10 lines of Python / Ruby / Lisp / etc... do the work of 100 lines for FORTRAN or 1000 lines of Assembly. I'll call that an "improved process."
  - CamperBob 17y ago
    No, that's an incremental improvement. All we're doing is writing fewer lines of the same damned procedural code. We didn't replace our horse and buggy with a car, we put some Tri-Flow on the bearings and meth in the feed bag and called it a day.
    - DougBTX 17y ago
      Does filling in an Excel worksheet count as programming? Many people do it every day without writing procedural code, but I would wager that it is.
    - philwelch 17y ago
      If you're writing FORTRAN/COBOL style procedural code in high level languages, then (as the kids say) you're doing it wrong. You tell the computer what you want it to do. The computer does it. You can tell it at as high or low a level as you want (within reason). The computer requires a precise formulation of what you want it to do before it can do anything. Can you see a way out of this?
      - CamperBob 17y ago
tocomment 17y ago
I notice the majority of my corporate programming job lately is just connecting things. Take data out of a table, show it on the screen, take data from the user, put it in the table, Take someone's library, put my values into the function calls. It seems like there should be a way for things to "connect" themselves. Eh, just thinking aloud I guess.
adbachman 17y ago
"When someone says 'I want a programming language in which I need only say what I wish done,' give him a lollipop. " - Alan J Perlis from the article: > Compilers, on the other hand, are generally very good. I have a high degree of confidence in most of the compilers I use. Sure, there are occasional bugs, but as long as you're not doing safety-critical development, most compilers are perfectly acceptable. Which is the same reason that we use Rails, Django, or Cake, etc. We're not doing safety critical development, we're writing CMSes and blogs. This isn't rocket science, but it is code someone will pay for. So why not do it in the most comfortable and convenient way currently possible? It's not necessary for the carpenter to be an expert on the design and manufacture of power tools. Knowing the tools they use, however, will improve the quality of their work. Similarly, the quality of my work as a programmer will improve as I grow into my tools, knowing their uses and imperfections. It is not necessary for me to be constantly focused on how imperfect they are and how I should be building better tools instead of using the ones I have. Along the lines of kenshi's comment: why are people upset that I am enjoying myself and taking pride in my work? I recognize the limits of my tools and I am comfortable with their being limited.
nuweborder 17y ago
Continuing to write code, allows the profession itself to continue to be looked at as a commodity. It keeps people in jobs, and unfortunately keeps many creative thinkers out of the loop. As it is, only programmers can write code effectively enought to produce innovative web sites and therefore, web companies that reinvent the web as we know it, and produce masses of wealth. If we did not use code, not only could we be more efficient with producing these websites, becasue we would not be also producing even greater code errors, and via numerous different types of code that are all used for different things and are not designed to work well together, becasue the programmer wants to keep a monopoly on it, but all creative thinkers that have brilliant ideas on how to utilize software and the web to better the world, and the worlds of business and technology, will be also to contribute their ideas. The bottom line is that tyically, the most creative people are those whom are natural artists. But these artists arenot techies, and therefore cannot translate their creative ideas to the web or software without including the mind of a programmer. This goes for anyone with a great idea. If you have a great idea for software or the web, but then partner with a programmer to carryout your ideas. Make sure you stay on top of your game. Because just like when a story gets passed along through many people, when your idea gets translated into code from someone else, there is a lot of room for error and distortion. Just as it is when a programmer is forced to deal with numerous different programming languages just to express what they want to create. Errors occur. As youtube and digg have both cut out the middleman in video media and news, and allow the consumer to make the choice as to what they like, why not cut out the middle man(main stream media, or programming), and allow all creative people to build and create without code, but via a universal point and click type program? Let the creation come directly from the source. Until we the consumers, and the creative thinkers demand this, we will never stop writing code.
- laut 17y ago
  Good programmers are creative thinkers. "Middle men" are usually doing something of value otherwise there wouldn't be a need for them, and they wouldn't be around. It's not because of a conspiracy that programmers are needed. You could use a "point and click type program", but they just don't work that well. And programming via a visual tool instead of writing code by tapping on a keyboard doesn't change the fact that you are programming.
vicaya 17y ago
Once singularity is reached, our code will write themselves. We'll just sit back and enjoy a latte/beer/whatever.
plinkplonk 17y ago
"I believe it is very nearly within our reach to stop writing software and start specifying software instead. Write the specification, press a button and have a full implementation that is mathematically guaranteed to implement your specification." Talk about stupid ideas. This illusion has been out there for a while and infects non programmers. I am almost tempted to post a "don't feed the troll" ascii art pciture

7 points by gdp 17y ago

"I believe it is very nearly within our reach to stop writing software and start specifying software instead. Write the specification, press a button and have a full implementation that is mathematically guaranteed to implement your specification." Well, we'd have to write that specification in some sort of consistent formal language. What kind of computer program converts a program specified in formal language into an executable program? Oh, right--a compiler. The most generous I can get here is to suppose he's advocating a declarative high-level programming language. But that wouldn't be nearly as interesting to write an essay about, so let's pretend that your declarative, high-level "specification" language means "no more writing code". Either that, or he honestly believes you can write a compiler for English. But given how most specs are written, I would be even more fearful of the output of an English compiler. So you have to use a formally specified language--oh wait, that's coding again.

krakensden 17y ago
The worst part is that he seems to think this is a novel idea.
- gdp 17y ago
  Who said anything about novelty? Referring to tools that do most of what is described seems to negate any claims of novelty.
gdp 17y ago
Sure, the distinction between writing specification and writing code is pretty artificial. A specification may be incomplete or ambiguous. Through stepwise refinement, multiple (formal) steps are taken towards a more concrete implementation, which eventually might result in an efficient implementation capable of being executed. None of this is really new, and I think the differences between a "program" and a "specification" are reasonably well understood in most contexts. Tools already exist to do these sorts of things, they are just restricted to certain problem domains where the expense and overhead are justifiable for the extra safety guarantees. Also, I think you're jumping way back into coder-world by talking about declarative high level languages. Sure, that might be one way of achieving the stated goals (and indeed, many have gone down that path!) however specifications can come in many shapes and sizes. The idea is to reduce the number of abstractions which the programmer must hold in his or her head in order to write programs. The ability to construct ambiguous, incomplete specifications that can be interacted with or validated before anything resembling an executable specification comes about is beneficial in many circumstances, particularly when you are talking about concurrent or distributed systems. Basically what I'm saying is that a specification provides only some of the information required to construct an executable program, and may abstract away specific behavioural information until much later into some refinement process. A "program", as such, does not, and by its nature contains a description of exactly all the behaviour that can be exhibited by execution of said program.
- philwelch 17y ago
  "Also, I think you're jumping way back into coder-world by talking about declarative high level languages." Not really--"specifications" are usually understood to be expressed in declarative English, and any sort of "specification" that can be programatically translated into a program would simply be high level source code. I'm not against writing specs, I'm simply saying "a spec that can be compiled is code".
  - gdp 17y ago
    But a specification could be ambiguous, with the need for human intervention to resolve ambiguity through the 'compilation' process. And I'm not sure that I'm aware of any production-grade systems that use declarative English as a specification mechanism. Most of the systems that I am familiar with use ASCII-friendly logic notation or mathematical notation in the style of LaTeX or similar. I'm not necessarily suggesting that this is how software should be developed, rather I'm just pointing out that your experience and knowledge of what might pass as a specification is different to mine.
    - philwelch 17y ago
      Here's my point. "You should be able to compile spec" is a useless argument, because anything we can compile would either be English (which we shouldn't compile) or a formal language (and a formal language that can be compiled is a programming language). Useful things to say include "here's a good high-level language that makes it easier to program" or "here's a language and a compiler for it that allows the compiler to ask intelligent questions about ambiguity in the code". "I want to be able to push a button and turn a specification into a program" is too vague to be useful--interpreted literally it already describes the compilers we have today, and interpreted liberally it could mean anything from "languages aren't high level enough" to "programming is too hard" to "I want to express programs with pretty pictures and by answering questionnaires" to "I want to compile English". Now, if we rule out "I want to compile English" as a very bad and stupid idea, we're left with things that, quite frankly, we've been researching the whole time (with the possible exception of compilers that question ambiguous expressions). Forcing us to ultimately conclude, first that the author doesn't know what he's talking about, and second that he isn't asking for anything more than what computer scientists are already working on.
extension 17y ago
On somewhat of a tangent, consider a specification such as "sort a list of numbers". After adding a few minor details, this could be an entirely formal and unambiguous specification, yet implementation would require (disregarding prior art) an informal creative process involving significant leaps of intuition. It seems to me that a formal spec need only provide a method of verification and is therefor distinct from the solution, though it's no surprise that the distinction goes unnoticed in our industry, given the dearth of both specs and difficult algorithmic problems.
- philwelch 17y ago
  But we can already turn "sort a list of numbers" into a program, although instead of "sort a list of numbers", it's called sort() and takes a list of numbers as an argument. By this standard, most programs are closer to specs than they are to solutions--a testament to the abstractions we already have.
  - extension 17y ago
    I had gotten word that the sorting problem has been solved, hence the "disregarding prior art" part. My point, which you don't seem to be contradicting, is that a formal specification of a problem is not the same as a solution. They just seem the same because real world programming problems tend to have obvious solutions, or at least solutions that don't feel much like programming.
    - philwelch 17y ago
      That's cool, but kind of an orthogonal point.
      - extension 17y ago
        Somewhat of a tangent, one might even say.

kenshi 17y ago

I was listening to an interesting interview with Dustin Nguyen, a comics artist yesterday. He had a background in CAD work, and for a long time had a pet project of creating locations for scenes in a CAD package. The idea being he and his co-workers would be able to save a load of time when drawing the art, because they could just use rendered backgrounds. He mentioned this idea to his boss (famed comics artist Jim Lee) who apparently just said: "Why? Drawing is fun,". And to this idea of automatically generating code from some formal spec, I can't help but think: "Why? Programming is fun," Sure no one likes tedious, rote programming. I especially don't like the kind of tedious typing statically typed languages tend to require you to write. But if you aren't finding the art of programming fun... I think you are in the wrong line of work. For any interested parties, the interview with Nguyen was from episode 91 of the Sidebar podcasts - http://www.sidebarnation.com/ http://www.sidebarnation.com/

gdp 17y ago
Problem solving is fun, and programming is a convenient way to access a large class of problems and express solutions to them. When the problem solving bit is done, the rest is just typing. I'd rather spend more time solving interesting problems and less time typing. Not to mention that I am likely to make mistakes while I'm typing up my solution. I'd rather not have to waste time chasing errors I've made that could have been avoided. Instead, I would rather spend time fixing errors in my solutions to problems, or looking for even better solutions.

CamperBob 17y ago

It's ironic that we've used computers to attack problems and improve processes in virtually every aspect of life except writing computer programs. The process of programming still looks pretty much the same as it did in Grace Hopper's day. I agree with the author: that's just stupid. The question remains, though: what do we do about it?

tl 17y ago
When Grace Hopper was programming your choices involved Assembly, FORTRAN and COBOL. Yes, we still have to write code, but 10 lines of Python / Ruby / Lisp / etc... do the work of 100 lines for FORTRAN or 1000 lines of Assembly. I'll call that an "improved process."
- CamperBob 17y ago
  No, that's an incremental improvement. All we're doing is writing fewer lines of the same damned procedural code. We didn't replace our horse and buggy with a car, we put some Tri-Flow on the bearings and meth in the feed bag and called it a day.
  - DougBTX 17y ago
    Does filling in an Excel worksheet count as programming? Many people do it every day without writing procedural code, but I would wager that it is.
  - philwelch 17y ago
    If you're writing FORTRAN/COBOL style procedural code in high level languages, then (as the kids say) you're doing it wrong. You tell the computer what you want it to do. The computer does it. You can tell it at as high or low a level as you want (within reason). The computer requires a precise formulation of what you want it to do before it can do anything. Can you see a way out of this?
    - CamperBob 17y ago

tocomment 17y ago

I notice the majority of my corporate programming job lately is just connecting things. Take data out of a table, show it on the screen, take data from the user, put it in the table, Take someone's library, put my values into the function calls. It seems like there should be a way for things to "connect" themselves. Eh, just thinking aloud I guess.

adbachman 17y ago

"When someone says 'I want a programming language in which I need only say what I wish done,' give him a lollipop. " - Alan J Perlis from the article: > Compilers, on the other hand, are generally very good. I have a high degree of confidence in most of the compilers I use. Sure, there are occasional bugs, but as long as you're not doing safety-critical development, most compilers are perfectly acceptable. Which is the same reason that we use Rails, Django, or Cake, etc. We're not doing safety critical development, we're writing CMSes and blogs. This isn't rocket science, but it is code someone will pay for. So why not do it in the most comfortable and convenient way currently possible? It's not necessary for the carpenter to be an expert on the design and manufacture of power tools. Knowing the tools they use, however, will improve the quality of their work. Similarly, the quality of my work as a programmer will improve as I grow into my tools, knowing their uses and imperfections. It is not necessary for me to be constantly focused on how imperfect they are and how I should be building better tools instead of using the ones I have. Along the lines of kenshi's comment: why are people upset that I am enjoying myself and taking pride in my work? I recognize the limits of my tools and I am comfortable with their being limited.

nuweborder 17y ago

Continuing to write code, allows the profession itself to continue to be looked at as a commodity. It keeps people in jobs, and unfortunately keeps many creative thinkers out of the loop. As it is, only programmers can write code effectively enought to produce innovative web sites and therefore, web companies that reinvent the web as we know it, and produce masses of wealth. If we did not use code, not only could we be more efficient with producing these websites, becasue we would not be also producing even greater code errors, and via numerous different types of code that are all used for different things and are not designed to work well together, becasue the programmer wants to keep a monopoly on it, but all creative thinkers that have brilliant ideas on how to utilize software and the web to better the world, and the worlds of business and technology, will be also to contribute their ideas. The bottom line is that tyically, the most creative people are those whom are natural artists. But these artists arenot techies, and therefore cannot translate their creative ideas to the web or software without including the mind of a programmer. This goes for anyone with a great idea. If you have a great idea for software or the web, but then partner with a programmer to carryout your ideas. Make sure you stay on top of your game. Because just like when a story gets passed along through many people, when your idea gets translated into code from someone else, there is a lot of room for error and distortion. Just as it is when a programmer is forced to deal with numerous different programming languages just to express what they want to create. Errors occur. As youtube and digg have both cut out the middleman in video media and news, and allow the consumer to make the choice as to what they like, why not cut out the middle man(main stream media, or programming), and allow all creative people to build and create without code, but via a universal point and click type program? Let the creation come directly from the source. Until we the consumers, and the creative thinkers demand this, we will never stop writing code.

laut 17y ago
Good programmers are creative thinkers. "Middle men" are usually doing something of value otherwise there wouldn't be a need for them, and they wouldn't be around. It's not because of a conspiracy that programmers are needed. You could use a "point and click type program", but they just don't work that well. And programming via a visual tool instead of writing code by tapping on a keyboard doesn't change the fact that you are programming.

vicaya 17y ago

Once singularity is reached, our code will write themselves. We'll just sit back and enjoy a latte/beer/whatever.

plinkplonk 17y ago