"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.
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.
"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".
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.
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.
I think you're still fundamentally understanding what makes a specification different from "code".
A specification is to a program as a building plan is to a house.
I spend less effort on drawing the plan that I do into the house, although I wouldn't put anything into the plan that I don't want to end up in the house that will (eventually) be built.
Similarly, once the house is built, I can verify (presumably using a tape measure) that my house implements my building plans. But I can't live inside a blueprint.
So, while this is not a formal definition, I think a good (informal) means of distinguishing a specification from a program is that if the specification could be substituted for the program it is specifying, then it's probably not a specification in any useful sense. This is to negate the usual argument that "my poorly-hacked C code is the specification for my program".
The "push a button" argument is a bit of a red herring. "Pushing a button" is a convenient metaphor for "perform some low-effort, largely-mechanised process". If your complaint is that it's an over-simplification, perhaps it is worth thinking about what the intention of the article was. It's not a work of serious theoretical value - it's simply advocating an ideological position to an audience of programmers who don't already know about specification and think that it's a good idea.
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.
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.
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.
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/
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.
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?
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."
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?
It's true that the computer requires a precise formulation of what you want it to do, but I'd submit that current programming methods are very far from the so-called minimum description length limit, where we'd be telling the computer nothing but what we want it to do. A framework for encapsulating different problem domains would help, as there are far fewer problem domains than there are programs.
If anyone seriously thinks that traditional procedural languages (even the more concise ones ones like Python and Ruby) are going to scale for another fifty years, they're on glue. We can't go on like this.
We have frameworks for encapsulating different problem domains--they're called frameworks, libraries, DSL's, sometimes full-fledged languages of their own.
Sometimes they are called operating systems: if you want to tell the computer "play chess with me" it's a simple matter of opening a chess program.
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.
"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.
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.
"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.
That's the point. Can we develop a program that is more efficient and effective than the present point and click programs? I know this wont change the fact that programming technically is going on. The point of the original question is, can we accomplish this without code? Not without programming. Think bigger. Can you program without code? Or atleast without code on the front end (i.e. Dreamweaver). But in a much better, more effective and dynamic way. Think about it. Programming was originally done on a black screen with green typing, and no mouse. We've improved the technology greatly. Why can't it be improved upon even more, or increase productivity, and ease of use? Check out http://www.yola.com, http://www.wix.com, http://www.weebly.com, or the new http://flooha.com/. They all have the right idea, just need to take it to new heights. Automate the code on the backend, for many to be able to focus on being creative on the front end as they see fit to their site liking and their own vision.
You're saying programmers aren't creative people. I disagree--programmers, like good musicians, are intensely creative people with a remarkable degree of technical ability. "allow all creative people to build and create without code"? That's like saying "allow all creative people to play songs and paint beautiful landscapes without having to strum guitar strings or wave paintbrushes around". And as it turns out, that's possible--you can play other instruments, or draw with computer rendering tools, if you don't mind a slightly tone or a different "look", and still end up with good art. But good art is hard in and of itself.
Knowing how to express an idea in code is easy. It's easier as languages get more high-level but it's easy enough now. But knowing what ideas to express, and having ideas that are consistent enough, have the right tonality and the right balance and the right leanness to express, is the difficult part. Playing piano is about knowing what keys to hit, not how to hit the keys. Same with programming. If your fingers are too short, slow, and fat to play the piano, play trumpet. If the incidental parts of one programming language are difficult or useless to you, use another.
Programmers are definately creative and very skilled. What I mean is that there is often something lost in translation anytime you take a creative idea from one person to another, just as happens when a story is told. In my opinion, programming language needs itself, can hinder the creative ideas of many whom do not know programming, and do not have time to learn it all. By the time they take valuable years to learn, their idea is lost in translation and is now old. If that person could have developed their idea without code, we'd have much greater choice in creative sites and software because the process of creation is easier. Its the same as how YouTube has allowed millions to upload their own videos and choose whats important and interesting, or how Digg has allowed users to choose what news is of relevance. In this case, am I saying that mainstream media professionals are not cretive? No. But that's exactly what these two companies have done. They have cut newpaper companies and mainstream broadcasters out, and allowed the user to be creative and broadcast and post directly to other users. Thats what having a program that would allow non programmers to create would offer. Because of YouTube and Digg, we as individual online users, are able to see and experience a much greate variety of entertainment and relevant information chosen upon by our peers and not those that control media, and allows many creative people that are not typical movie stars, music artists or celebrities, to become well known, famous and express themselves and their ideas directly to the masses, without the mainstream media controllers (or programmers), and with absolutely nothing lost in translation. We should treat programming the same as we are not treating web 2.0. How can we push a true web 2.0, with the main aspect of the building of these sites still functioning as web 0.0? Programmers are great and creative. And presently, without them, there would be not web, and my companywould not exist, and nor would google, digg, youtube, or any other site. I work directly with my programmer for my startup daily. But if this was in place, it would help to harbor much creater creativity because everyone could get involved directly.
Just a note--if you use paragraph breaks and try to structure your thoughts instead of spewing long stream-of-consciousness comments, it makes it easier to understand what you're saying.
YouTube and Digg simplified distribution, not creation. Distributing software is no more difficult than distributing anything else. What you're talking about isn't analogous to allowing non-celebrities to create music, what you're talking about is allowing people who don't know how to sing, play an instrument, or compose a song to create music.
I've looked over your business's website. It seems like you have a good idea and a useful target market, but the web implementation is questionable, and there's nothing stopping someone from taking your same basic idea, executing it better, and eating your lunch.
Thanks for the constructive feedback on the site. Point well taken. I have thought about that very issue. Too bad I'm not a programmer. I am working with my programmer in implementing the site as I invision it. Will be sure to communicate that to him, and get back on the drawing board to address those issues. Have any specific suggestions? Or, any recommendations on programmers? Thanks again.
"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
33 comments
[ 3.4 ms ] story [ 82.3 ms ] threadWell, 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.
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.
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".
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.
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.
A specification is to a program as a building plan is to a house.
I spend less effort on drawing the plan that I do into the house, although I wouldn't put anything into the plan that I don't want to end up in the house that will (eventually) be built.
Similarly, once the house is built, I can verify (presumably using a tape measure) that my house implements my building plans. But I can't live inside a blueprint.
So, while this is not a formal definition, I think a good (informal) means of distinguishing a specification from a program is that if the specification could be substituted for the program it is specifying, then it's probably not a specification in any useful sense. This is to negate the usual argument that "my poorly-hacked C code is the specification for my program".
The "push a button" argument is a bit of a red herring. "Pushing a button" is a convenient metaphor for "perform some low-effort, largely-mechanised process". If your complaint is that it's an over-simplification, perhaps it is worth thinking about what the intention of the article was. It's not a work of serious theoretical value - it's simply advocating an ideological position to an audience of programmers who don't already know about specification and think that it's a good idea.
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.
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.
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/
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.
The question remains, though: what do we do about it?
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.
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?
If anyone seriously thinks that traditional procedural languages (even the more concise ones ones like Python and Ruby) are going to scale for another fifty years, they're on glue. We can't go on like this.
Sometimes they are called operating systems: if you want to tell the computer "play chess with me" it's a simple matter of opening a chess program.
It seems like there should be a way for things to "connect" themselves. Eh, just thinking aloud I guess.
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.
"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.
Knowing how to express an idea in code is easy. It's easier as languages get more high-level but it's easy enough now. But knowing what ideas to express, and having ideas that are consistent enough, have the right tonality and the right balance and the right leanness to express, is the difficult part. Playing piano is about knowing what keys to hit, not how to hit the keys. Same with programming. If your fingers are too short, slow, and fat to play the piano, play trumpet. If the incidental parts of one programming language are difficult or useless to you, use another.
YouTube and Digg simplified distribution, not creation. Distributing software is no more difficult than distributing anything else. What you're talking about isn't analogous to allowing non-celebrities to create music, what you're talking about is allowing people who don't know how to sing, play an instrument, or compose a song to create music.
I've looked over your business's website. It seems like you have a good idea and a useful target market, but the web implementation is questionable, and there's nothing stopping someone from taking your same basic idea, executing it better, and eating your lunch.
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