The future of programming

[manhobby]

Please all, answer the following question, this subject is fun:

Maybe the future of the programming is the human-language-level programming.

What are the opinions of the programmers about the future of the programming?

[nullplan]

Seeing as my industry (embedded software) is moving as swiftly as a sloth on Valium, I don't think we will be seeing major shifts in programming technique or languages within my lifetime. We have been using C forever and a day, and I don't see any language take it over, except maybe C++. This might not sit well with "safe" language advocates, but no other language has the same market penetration. Yes, it is circular (other languages are unpopular, so we don't use them, so they never get popular), but such is the nature of the beast.

As for entirely different systems (e.g. S0lar talked about a game-ifyed programming system a while back), my bosses would probably recoil in horror. I also see that as far too impractical. Right now, the answer to "how do I do X?" is "here's a snippet". With that you'd have to send a list of instructions.

Edit: As a PM has made me aware, Solar advocated no such thing. In fact, it was Brendan: viewtopic.php?f=13&t=33181&p=285831&hil ... ft#p285831

And yes, I am aware of the irony.

[manhobby]

nullplan,

Thanks you for the your response!

[eekee]

The first post looks like the programming system asks a lot of questions in series. I've used systems like that, from Windows "wizards" to the package management of Source Mage Linux. It's a bad idea. As evidence: "wizards" have got very much shorter since the 90s, sometimes having only 2 pages.

One problem is later questions may make the user realise he wants to make different answers to earlier questions. There might not be any such cause for confusion surrounding a button, but very few things are as simple as a button! Of course, wizards have a back button, but what happens when you realise you need to change an option somewhere around 10 pages back? Modern wizards seem to have a maximum of 5 pages altogether, which is absolutely enough for me, but isn't half-way enough for the example in this thread.

The idea of these question-series is to avoid overwhelming the user with too much information at once. That's sort-of nice, but they always risk hiding information which the user needs to help him understand.

Another problem is the series of questions can become like an unrelenting assault. It goes on, and on, and on, and each. single. question. has. to. be. thought. about! It's like some form of torture! The things which produced this response in me were Source Mage Linux and the Linux Kernel's "make config". I was very very thankful for menuconfig, but even that was sometimes too much to bear. This problem is computers just present too many choices. Sometimes, the physical world presents too many choices for humans to cope with. Configuring computers presents more choices than the physical world, and programming computers presents more choices than configuring them.

Hm... I think there's a better way of hiding the options you don't need or aren't ready for: optional arguments. Try Tcl/Tk.

Natural language programming in general has been dreamed of since the 50s or 60s, maybe even earlier. When I was little, in the 1980s, some books still presented it as The Future, while others declared it impossible.

[Ethin]

Natural language programming seems like overcomplicating easier non-natural language programming tasks. If I'm programming a GUI app, I find it much easier to write (for example):

Code: Select all

global::generateDSPList();
tts::init();
QApplication a(argc, argv);
// ...

And would find it much, much harder (and ridiculous) to write:

Code: Select all

Call the function generateDSPList in the global namespace with no parameters.
Call the function init in the tts namespace with no parameters.
Create a class a of type QApplication, calling the constructor that takes an integer and an array of character pointers and pass it argc and argv.

Or something else ridiculously weird like that. I'll stick with the programming language methodologies we have today, instead of typing (or saying, if we have VUIs) very long sentences to specify what I want the computer to do, when I want it to do it, how I want it to do that, and why I want it to do it.

[StudlyCaps]

I've been pretty vocal about it in the past, while I think natural language programming is interesting as a hobbist or research idea I've never seen any evidence it could be used for anything non-trivial without becoming as specialized of a skill as using any domain-specific language. At that point, why not use a language custom designed to be more expressive, more readable and less ambigious that natural language?

[DavidCooper]

Natural language programming seems like overcomplicating easier non-natural language programming tasks. If I'm programming a GUI app, I find it much easier to write (for example):

Code: Select all

global::generateDSPList();
tts::init();
QApplication a(argc, argv);
// ...

And would find it much, much harder (and ridiculous) to write:

Code: Select all

Call the function generateDSPList in the global namespace with no parameters.
Call the function init in the tts namespace with no parameters.
Create a class a of type QApplication, calling the constructor that takes an integer and an array of character pointers and pass it argc and argv.

What does all that jargon-infested junk mean though? How would you summarise what it does for someone who doesn't know anything about programming? Why are you programming at such a low level instead of letting the intelligent compiler do that job for you?

[Solar]

What does all that jargon-infested junk mean though?

The jargon is in evidence in the "plain English" version just as much as the C++ version. Functions? Namespaces? Global namespace? Parameters? Constructor? Array of character pointers?

It's just hidden behind lots of noise, like "the" and "with" and "in" and "namespace", making it much harder / slower to read.

How would you summarise what it does for someone who doesn't know anything about programming?

Not at all. If you don't "know about programming", you won't be able to make heads or tails out of anything anyway. Because "knowing about programming" isn't about any specific language, it's about thinking a certain way, be that procedural, object-oriented, functional, generic, or something-else-entirely.

Getting a student's mind set up for organizing data and control flow this way is what takes the bulk of time. Whatever language you're using to express those thoughts is entirely secondary, which is why it's dead easy to switch from one programming language to another if they just follow the same "way of thinking".

Why are you programming at such a low level instead of letting the intelligent compiler do that job for you?

Because why are those namespaces taking no parameters? What constructor should the type QApplication call? Why should I, after doing that, create an array of character pointers and pass some argc and argv to that array?

That's not what is meant, of course. But you'll either end up with ambiguity (and confusing error messages), or with a rather large set of "special" rules for your "special" brand of English that is "proper" for programming (i.e., rules for a programming language).

[iansjack]

It strikes me rather like the difference between an artist producing a work of art and someone painting by numbers.

[eekee]

Code: Select all

global::generateDSPList();
tts::init();
QApplication a(argc, argv);
// ...

...

Code: Select all

Call the function generateDSPList in the global namespace with no parameters.
Call the function init in the tts namespace with no parameters.
Create a class a of type QApplication, calling the constructor that takes an integer and an array of character pointers and pass it argc and argv.

Mm... that's not natural language, merely a term substitution for the C++ code. As an experiment, how about trying to make it more natural?

Code: Select all

Generate a DSP list for everyone in the program to see.
Initialize TTS.
Make a copy of QApplication. The builder will want the program arguments, so give them to it.

My thoughts:

• I chose "everyone" over "everything" because I've found common, natural English to be rather poor at ascribing actions to things; I couldn't find the words when roleplaying non-sapient robots. Besides, differentiating between dynamic individuals and passive things helps to distinguish between code and data.
• Note the capitalization of TTS. It's an acronym, capitalize it. Also, capitalize the first letter of sentences. Thus, the language must be case-insensitive, losing the possibility of capitalization carrying info. Of course, sometimes the programmer can use capitalization to highlight things, so maybe it's not all bad, but then there's the question of whether acronyms are emphasised or merely written properly. It's one of those horrible code style issues I can't stand. Actually, I have experience with this one. In different environments (or, I admit, moods,) I get into the habit of capitalizing correctly or not at all. It can be really difficult to switch from one to the other on demand.
• I found it easier to assume pure OO, where class is just an object, and any object may be instantiated as if it were a class. It makes the English form much shorter with less jargon. OO was invented to be easier and more natural to write. If I remember right, impure OO languages were resisted by some because they were less natural. (Some day, I'll get around to learning Smalltalk.)
• We do not separate a list from its length in high-level languages! XD
• Seriously, the arguments to a program are global data. Why are we passing them around explicitly? This especially applies to natural language where the long name, "the program arguments" isn't likely to conflict with anything module-specific. Also, the word "the" may help define it, but if we insist on that I have no idea how the compiler should then interpret "our program arguments".
• The compiler must recognize many ways to describe the same thing. Example: "Make a copy of QApplication," versus, "Have a QApplication built." (And I've just realized how impure OO could work in natural language. Still, "Have X built" is less common and thus less natural. What are we, the Lord High Commissioner?)

Edit: I just realised that last point illustrates a problem with giving orders. Some people are like that, especially in some cultures, such as Britain. We get our point across with silly quasi-rhetorical questions, but I'm sure recognizing those questions would be a huge extra problem for the compiler. It's a problem for me, and I grew up in Britain!

[Korona]

Will the compiler here be a deterministic algorithm or a trained machine learning model? If it's the former, what is the evidence that this will ever be feasible? If it's the later, how would one deal with the fact that retraining the model changes the meaning of existing programs?

This entire thing looks completely unrealistic to me.