No, it's not, because we will keep looking for the limits. Once a programming tool allows you to do alone what you need 10 engineers for now, some genius will use those tools to do what you need 10 engineers for then, and then teams of 10 engineers will try to copy that. We'll always be driven to meet the limits of what fits in one engineers' head.
I do some machining as a hobby; there are decades old teasers like turning a cube inside a hollow cube on a lathe from a piece of round stock. I feel like those are very much like Olympiad problems in nature, and just as remote from real-life machining exercises.
Programmers will always be working at the limit of their abilities -- if the tools make anything easier then we'll just start tackling harder problems.
Reminds me of a misconception a vocal student I met had about math. She thought she could understand the attraction of math because the symbols and equations could look pretty. I had to explain that the beauty was not in the symbols, but in the pictures and concepts they could evoke in your mind, much as the beauty of music wasn't in notes on a page, but the sounds they represent.
Feynman once said something about how equations evoked animations in his mind.
This is the value of things like Lisp, Python, Ruby, Smalltalk, Light Table -- by interacting with systems in a tight feedback loop, you can start to form pictures and understandings in your mind. It also shows where those environments and other current tools are lacking. Instead of having to reconstruct relationships in our minds, we should have a way of navigating an explicit diagram of them. Even IDEs like Eclipse, for all their complexity, still require you to read then form relationships in your mind. (It's like we're all still doing word processing with non WYSIWYG word processors.)
[1] http://en.wikipedia.org/wiki/List_of_people_with_synesthesia...
I don't think it's shameful. APL is close to 50 years old now, and it's most recent incarnations (J and K) are 20 years old - and they're still avant-garde, even though the world is slowly catching up to them (with LINQ and friends), although not as elegantly or cleanly.
What exactly are you missing about the "state of the art"? Entire K modules usually fit on one screen; Reportedly, kOS http://kparc.com/ is an operating system in 5 screenfuls of text.
Simple Made Easy is a talk by Rich Hickey, the author of the Clojure programming language which encodes a lot of these ideas into the language.
http://www.infoq.com/presentations/Simple-Made-Easy
[EDIT: ambiguous comma :)]
I believe in what Hickey's doing though.
(Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
Briefly, I think I understood how to properly build an interactive data-driven application in the highest level of abstraction. If I were build out the tools, one would be able to create such app by defining data models, view models, derivation logic (for deriving view model from data model), viewmodel-bound layout for individual stages, and stage-linking workflow, all in their respective domain-specific languages. It all looks very neat in my head, and I have even programmed a couple of pieces in my iOS apps to great effect.
Oh well. Back to work now.
I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know.
A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that it's not general purpose. But you can try reading about it if you think natural language is too ambiguous to ever possibly be a programming language.
I want to write down all my thoughts about this idea, but I thought I'd get some more meat on it before I do that. Also, I haven't mentioned here why I think natural language programming can help, but I'll leave that to your imagination for now.
This exists. It's "Write each step of an algorithm in comments before writing any code, and (only when you're finished writing each step in English in comments) fill in the code each comment represents".
But it's impossible to convince anyone to try that, though, even though it gives all the benefits you are imagining NLP would give.
The mentality "Don't repeat yourself under any circumstances, even if it adds no complexity and increases clarity!" is unfortunately why this is undiscovered. Also, people generally go overboard with the "commenting" part -- the purpose is to be pseudocode in the way Python is executable pseudocode, while retaining the ambiguity that is necessary for natural language to be natural. So it gets a bad reputation, and its power is hidden despite it being powerful.
Here's an actual snippet of a test I wrote before writing the corresponding code for an app that's now in production:
describe "adding participants" do
context "when user has created a new event" do
before :each do
visit root_path
click_link 'Get Started'
fill_in 'Name', :with => 'Tres'
fill_in 'E-mail', :with => '[email protected]'
click_button 'Next'
end
it "should prompt for more participant info" do
page.should have_field 'Name'
page.should have_field 'E-mail'
page.should have_button 'Add Participant'
end
it "shouldn't let you enter an invalid e-mail" do
fill_in 'Name', :with => 'Tres'
fill_in 'E-mail', :with => '#)(*)($*#)($*'
click_button 'Add Participant'
page.should have_content 'invalid'
end
end
end
It's been an absolute joy to work this way. I'd love to see this level of abstraction make its way into the mainstream in other languages and environments.It doesn't work so well 6 months later when you're editing that code.
But I'll note that we humans manage to understand each other just fine without resorting to a controlled natural language. We solve the ambiguity problem basically by taking the most likely interpretation of a given sentence, given the context, or asking questions if too confused. And in fact, there are natural language parsers out there that can predict the mostly like parse reasonably well for single sentences.
The biggest problem here is that programmers like having full control of what's going on, whereas this sort of idea brings in a large dose of unpredictability: how will the parser interpret this sentence? I think this can be solved to some extent by having the parser tell you what it parsed in less ambiguous terms. In fact, you might ask the parser to present a normalized version of the code that is more specific about exactly what's going on (and probably more verbose), and also expanding out phrases to show you exactly what they mean for debugging purposes. Also, when a clear parse cannot be made, the parser can simply ask you to clarify, presenting the multiple parses that it could not decide between.
> There's even some work to encode legal knowledge using them
Where do I learn more about this? What's the name of that language, or research project, or...?
The Fred Brooks essay "No Silver Bullet" is a good place to start:
http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...
Completely true. That is exactly the Bret Victor's point in "Inventing on Principle":
http://worrydream.com/#!/LearnableProgramming
Programming tools (languages, APIs, IDEs) needs to reduce the problem you need to hold in your head.
pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp for that very reason, but Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.