It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance.
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.
> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head.
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.
Does not follow. Holding stuff in our heads is not the only bottleneck in programming. For example, it's not the bottleneck when solving almost any Olympiad style problem, and yet those exams seem to do a good job of stratifying people.
Those types of problems are not programming problems per se, but more like riddles for math inclined. Once you know the solution, the coding tends to be rather trivial with regard to control and data structures.
Olympiad programs are pure algorithms, which I agree are more math intensive than most "normal" programming done today (though I wouldn't dismiss math as "riddles"). But that's my whole point: most problem domains have some mathy parts, whether in the algorithms or from the problem domain. As we reduce the cognitive burden of plumbing and architecture that exists in programming today, these meaty parts will take up a larger portion of the programmers workload. The required skillset will shift somewhat, rather than rewarding the same mental juggling process at a larger scale.
Oh, but they are riddles. Hanoi tower, permutations, travelling salesman kind of problems. Algorithmically tricky (not hard, the problems are in textbooks for ages), but trivial from a programming perspective. The kind of problems that a physics major would think constitutes programming, but mostly irrelevant to complexity met in either the industry or CS academia.
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.
I think programming tools and technology have become much better over the decades (more expressive and easier to interact with). Programmers today are building far larger and more complex software than ever before.
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.
> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head.
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.)
Feynman had a neurological condition called synesthesia [1], which is when senses get mixed together in the same neurological pathway and you can "taste" a sound or "hear" a color. Which is very interesting since Feynman was said to have a "frightening" ease with equations, like an intuitive understanding of what they meant.
> Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.
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.
I have no idea what you're talking about here with the mumbles; but I can see that you're getting upvoted, so I suppose there's some hidden context here that I'm not aware of. Someone care to clarify?
He's probably referring to the idea that much of the complexity around today is not particularly useful - in particular, that programming with values rather than variables makes understanding a program substantially easier.
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.
I have a number of such idea, sadly I'm short on time so I never got to write them down in detail. Besides, my friends don't seem to "get" it so I worry I will waste my time inventing the newest developer tools but not being able to gain any traction due to thinking inertia (or me being a crank - you can never tell :) ).
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.
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.
The closest experience I've had to this is using RSpec and Capybara to do test-driven development.
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.
Some Lispers have been doing something similar for some time. There's even a saying that "Any sufficiently well-documented Lisp program contains an ML program in its comments."
Literate Programming - another 30 years old "technology". And it's good. As you say, the problem is not the tools, but rather mentality of rediscovering the wheel at best, and staying ignorant to the history of our field at worst.
One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them.
Thanks, interesting! Not mentioned on that page, but a notable natural language which is similar in its goals is Lojban [1]. It's actually based on predicate language, which is actually what Inform 7 uses as well in order to derive the actual meaning from natural language sentences. It manages this because it is based on a limited subset of English.
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.
I'd just like to point out that Lojban is a constructed language, not a natural language. It was designed and built from the ground up, as opposed to the GP's controlled natural languages which are pre-existing human languages with a bunch of stuff stripped out of them.
Hm, I have never really thought about NLP, but I guess maintaining an NLP program somebody else has written must be even more of a nightmare than what we have now...
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.