(Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
(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.
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...?
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.
It doesn't work so well 6 months later when you're editing that code.
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 => 'tres@sogetthis.com'
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.