Are new paradigms of programming always driven by a need?

Question

I'm something of a programming language junkie, and examples abound...

• Lisp was originally created as a practical mathematical notation for computer programs
• Simula was designed for doing simulations, and gave us objects and classes
• C was designed for implementing system software (specifically, the Unix operating system)
• Erlang was designed with the aim of improving the development of telephony applications at Ericsson.

Languages like Perl and Ruby also, but these four gave birth to fundamental styles of computer programming, as opposed to "just" implementing an existing methodology or style of solving specific software engineering problems.

Is every new programming paradigm primarily driven by a need to solve a practical problem? Does every new programming language come about from a programmer scratching an itch?

As I plan to dedicate my life to research in new programming languages for AI, I'm wondering whether I should pursue the theory of programming intelligence directly, or attempt to solve practical problems in AI and then "discover" the paradigms to solve them.

Answer 1

I think that every language is designed according to some need. That need of course can just be the language designers own desire for a more elegant language, a language he himself feels more comfortable programming in.

However, the language that are successful will very likely provide some solutions to a more general need. This need my not necesarely be evident at the time the language is designed, but for it to get recognition I think it has to be a need that is shared and gets shelved out as a general desire at some point.

There are probably a lot of languages out there that did not necessarely address a problem that is shared by many others or maybe even adresses needs that have not been wiledly realized as such.

To you concrete question: I think the best way to discover the shortcomings of current languages is to use them. Of course, the theory may help you to come up with appropriate solutions. So I'd say the best way is (as always) to have theoretical knowledge and practical experience.

Answer 2

You'd think nobody would invest time in inventing, refining, implementing, using and spreading a new way of doing things if "the old ways" worked just fine. And the real world, as in your examples, confirms this theory. All this still applies if we broaden the scope beyond programming paradigms. So I'd say it is safe to assume inventions are (partly) driven by a need for the thing invented.

*hits his smartass alter ego with a bat and takes over the talk*

As for the question in the last paragraph: If anyone knows whether you'll have more fun pursuing theory or solving real problems, it's you. I would choose practice any time of the day - but I'm not you. But from looking at (programming language) history I can tell that all no great (i.e. can be used to get things done) language came from theory. It is logical to assume one can't find a good tool for an application without knowing that application throughoutly from daily work.

Answer 3

You forgot FORTRAN, Basic and COBOL, all of which had clear design goals. But yes, I think the best languages are aimed at scratching one itch. Problems arise when they decide to become "everything but the kitchen sink" languages, something C has more or less avoided, but C++, with its recent attempts to become a functional language, unhappily has not.

Answer 4

No, most are. But you're forgetting Esoteric programming languages.

Example: http://www.dangermouse.net/esoteric/piet.html

A language that uses JPG's as code.