We really take two approaches to this. The first is we're trying to build tooling to convince you that this is a good idea. For instance, something as simple as a table of contents generated from headings in your code. It's a great overview of your program, a convenient form of navigation, and it takes hardly any time write. I mean, I've seen tons of programmers do this anyway, with fancy ascii headings. Let's just make stuff like that easy for programmers, and I think that our propensities to keep things organized and logical will work in our favor. So in terms of keeping code in sync, we're hoping these tools will convince you that you want to do it. There is value in doing it. Not just feel-good value of well documented code, but tangible value in easily and logically navigable code, for instance.
So the tooling is the first part. The second part is the actual design of the language. Eve programs are written as a series of code blocks, each one with a very specific purpose of querying data, and then doing a transformation on that data. You create computations just by chaining together these interconnected blocks, each data from another and reshaping it in some way. It's this design that leads to writing very short, single purpose blocks of code. In Eve, you don't reference blocks of code, you only reference the data they create. So blocks don't have names. If you write an Eve program without writing any prose at all, it will be kind of confusing. We find that our users so far tend to write a simple declarative sentence before each block, explaining its purpose. They treat it kind of like an extended function name.
If this becomes convention, you could imagine tooling that actually attempts to keep code and prose in check, by noting changes in code and a lack of change in the associated description. Even further down the line, I'm imagining integrating some of our previous NLP research [1] into the editor. Imagine if the editor itself could tell you that your code isn't doing what you think it is.
Anyway, I think the bottom line for me is this: if we're going to get more people to code, we need to treat programming as a more human-centric endeavor. What if a programmer and an accountant could write accounting software together. Not just with the accountant advising the program, but actually participating in the design and development of the program. Sure, he might not be able to understand all of your code, but he can read the paragraph you wrote and see the output of the code underneath, and with his domain expertise he can understand that the output isn't quite right.
This is interesting. I have one follow up question:
If Eve gets smart enough to understand that the code and the prose diverge from each other, shouldn't it also be able to generate the correct code from the prose? That way you'd eliminate the duplication that is happening. It also should allow you to modify the generated code by modifying either the prose or the code, whatever the programmer prefers.
So the tooling is the first part. The second part is the actual design of the language. Eve programs are written as a series of code blocks, each one with a very specific purpose of querying data, and then doing a transformation on that data. You create computations just by chaining together these interconnected blocks, each data from another and reshaping it in some way. It's this design that leads to writing very short, single purpose blocks of code. In Eve, you don't reference blocks of code, you only reference the data they create. So blocks don't have names. If you write an Eve program without writing any prose at all, it will be kind of confusing. We find that our users so far tend to write a simple declarative sentence before each block, explaining its purpose. They treat it kind of like an extended function name.
If this becomes convention, you could imagine tooling that actually attempts to keep code and prose in check, by noting changes in code and a lack of change in the associated description. Even further down the line, I'm imagining integrating some of our previous NLP research [1] into the editor. Imagine if the editor itself could tell you that your code isn't doing what you think it is.
Anyway, I think the bottom line for me is this: if we're going to get more people to code, we need to treat programming as a more human-centric endeavor. What if a programmer and an accountant could write accounting software together. Not just with the accountant advising the program, but actually participating in the design and development of the program. Sure, he might not be able to understand all of your code, but he can read the paragraph you wrote and see the output of the code underneath, and with his domain expertise he can understand that the output isn't quite right.
[1]: http://incidentalcomplexity.com/2016/06/14/nlqp/