> When we become proficient in describing the result in terms of the argument, using only the present tense of the verb <i>to be</i>, we could experiment with writing the description in a different language (French, Latin, Esperanto, ...) before transliterating it into code.<p>This is going to be a funny exercise for languages that <i>don't</i> have the forms of the verb <i>to be</i> for the present tense.
Declarative programming is quite elegant, but it is not the same as prompting. I recently had an argument with someone who claimed our declarative code for running analyses over documents was "hard coded". In our product, our approach is to use a functional language approach for analyzing documents. He was an expert in NLP and said that his users required the ability to instruct the system in natural language - English. It still was weird that someone call our declarative program - "hard coded". My, how times have changed.
> One significant downside of is-y programs is that in general they run slower than
corresponding do-y programs.<p>I wonder about this. It seems like the ultimate in declarative programming is prompt engineering: just describe the problem and let the computer decide how to break it down. As of now, humans can still find more efficient ways to break down problems than computers can.