Programming Paradigms for Languages
Written by Mike James   
Thursday, 02 September 2010
Article Index
Programming Paradigms for Languages
Declarative systems
Dynamic

 

Dynamic

Now we come to a sideline in the language paradigm story. There is a lot of talk about dynamic languages at the moment. This is partly because until quite recently the dominant languages Java, C++ and C# were static languages - so it's quite a lot about a reaction to the old guard. The static/dynamic distinction is a very difficult one to pin down precisely. In the old days it could be summed up as the split into compiled and interpreted languages but today it is more about a split in the approach to how object oriented programming should be done.

The current meaning of Dynamic when applied to languages usually refers to typing. When you create an object oriented language you have to decide if it is going to be strongly or weakly typed. Every object defines a type and in a strongly typed language you specify exactly what type can be used in any given place. If a function needs parameters that of type Apple you can't call it used parameters that are Oranges. The alternative approach is to allow objects of any type to be used anywhere and just let the language try to do the best job it can with what it is presented - this is weak typing.

Now in a strongly typed language you can choose to enforce the typing when the language is compiled or at run time. This is the main distinction between static and dynamic typing. In a static typed language you can look at a variable and see that it is being assigned to an Apple just by reading the code. In a dynamically typed language you can't tell what is being assigned to a variable until the assignment is done at run time.

Clearly there is an interaction between strong and weak typing and static and dynamic. A weakly typed language really doesn't have much choice but to use what looks like dynamic typing.

Weak typing or dynamic typing has the ability to make programmer easier to write but the loss of the discipline of controlling type makes it more likely that a runtime error will occur and arguably makes it harder to find bugs.

There is a wider meaning to the term dynamic when applied to languages. Right back at the start the first languages didn't really distinguish between instructions and data and this allowed programs to modify themselves. Later on self modifying code acquired a reputation for being dangerously unstable and buggy. As a result languages put up barriers between code and data. A program could manipulate data but not its own code. However interpreted languages such as early Basic and Javascript blurred the distinction. They generally allowed the code to modify itself and hence became dynamic languages in a broader sense.

As you can guess languages that allow self modification are powerful but also dangerous unless the facility is controlled in some way. Modern dynamic languages such as Ruby do attempt to control how the language can be extended but some commonly used script languages such as Javascript are still something of a free for all.

Dynamic languages my have something to offer the future but there is a sense in which we are simply returning to the wild primitive expression of programming that existed in a time before we learned better. Perhaps every so many generations programmers need to experience programming in the raw.

Graphical

The final paradigm is the graphic language - if they can be called languages. This is a strange mix of the object-oriented approach and the declarative with a little procedural thrown in. However to classify the approach in this way is to miss the bigger picture - no just to miss the picture. The idea is that if code objects are to mimic real world objects let's give them a physical appearance. In the world of the user interface we are very well accustomed to this approach - a button that you drag and drop onto a page is a physical representation of the button code object. You get to work with the button as if it was a real button - you can click it, drag it, size it, change its color and so on. Graphical objects in the UI lead to the component revolution which we are still developing - from ActiveX to WPF, Widgets and so on.

scratch14

Scratch

Now consider using the same approach to building programs in general. You could have a loop component, a conditional component, a module component and so on. This could be assembled just like a user interface by a drag-and-drop designer and "writing the code" would be a matter or connecting them together in a flow of control graph. Some components would need you to write a few lines of procedural code to specify their actions more precisely but mostly components fit together naturally without extra code, just specify a few properties.

This approach to building programs has to date mostly been used in languages such as Scratch and the Lego Mindstorms robots to get children interested in programming. However, what is easy for children should be very easy for us and the method could well translate to more ambitious projects. Only recently Google announced a graphical programming environment for the Android - but it's still in the early stages of testing.

Of all the techniques described so far it is graphical programming that I'd bet was the way of the future - but how far in the future is another matter.

The rest

There are a large number of other approaches to programming that we haven't considered but they are mostly side issues and special environments. For example, there is the whole issue of synchronous v asynchronous or event driven programming. Then there is the big question of sequential v parallel programming and so on. There is also the convergence of AI and programming. For example, using genetic algorithms you can evolve a program rather than writing it.

If you have a favourite approach that has been left out, or want to request an article about an approach or any aspect of programming theory, then email the editor:

editor@i-programmer.info

If you would like to be informed about new articles on I Programmer you can either follow us on Twitter, on Facebook , on Digg or you can subscribe to our weekly newsletter.

 

<ASIN:0387333754>

<ASIN:1402075812>

<ASIN:0262570955>

<ASIN:0321547985>

<ASIN:0978739256>

<ASIN:0954300696>

<ASIN:0262011530>

<ASIN:1423901401>

<ASIN:0201853930>



Last Updated ( Thursday, 02 September 2010 )
 
 

   
RSS feed of all content
I Programmer - full contents
Copyright © 2014 i-programmer.info. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.