Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is there a rigorous way to classify programming languages ?

If so, can the various "dimensions" be quantified ? (degree of purity)

For instance, I just went on the Shade language website (I am not affiliated with it in any way) and saw :

  • "semi-functional" -> But how much is that language semi-functional ? -> quantification need
  • "full type checking" -> So type checking can be partial -> can be quantified too ?
  • Objectif model / no object model...
share|improve this question
6  
"Compiled" is not a property of a language. It's a property of a language implementation! There is interpreted C and there is compiled Python. –  Joachim Sauer Jan 17 '13 at 10:42
    
@Joachim Sauer: Definitely right. I will remove it to make the question more focused. –  Skippy Fastol Jan 17 '13 at 10:43
    
Much of the classifications stem from the type system: strong/weak, dynamic/static, nominal/structural, ... –  Joachim Sauer Jan 17 '13 at 10:48
    
@JoachimSauer: interesting. Would you see any means of 'quantifying' each of those classification dimensions ? Can the typing degree of various languages be compared ? –  Skippy Fastol Jan 17 '13 at 10:53
    
this sounds to me like a Wikipedia question, just look there –  Yusubov Jan 17 '13 at 19:13

1 Answer 1

You can find a lot of information here:
http://en.wikipedia.org/wiki/Programming_language
http://en.wikipedia.org/wiki/Comparison_of_programming_languages

I am not going to rewrite the Wikipedia here, just a few simple explanations, so you may better understand what the Wikipedia articles are trying to say.

One thing is how the programs are constructed. Sometimes it is about the programmer's style, but the programming language or the library can make styles easier, harder, or impossible. Multiple styles can be used in the same program.

  • imperative programming -- "first do this, then do this, then do that". You always write what is supposed to happen next. Even if there are more choices, e.g. based on the user's input, it is always: you ask about the input when you want to ask, then you choose what happens next based on the answer you received. This programming style is nice for short non-interactive programs; but with large programs it becomes very difficult to read and maintain. Also this is how the computer works on the hardware level (all other programming languages have to be compiled or interpreted to this), therefore this is what many programming languages use.

  • event-based programming -- you are not doing the whole program, but rather some part of it, which must fit into a given framework. The framework tells you "now this happened", and you are supposed to react on the event. You don't decide what happens later. The framework calls you when your reaction is needed, and you only react to that. (For example, if you make a computer game, you react on "game started", "mouse clicked", "key pressed", "screen needs to be displayed" and "game is quitting" events. You can remember e.g. the coordinates of your spaceship; the reaction to pressing a key would be changing the coordinate, and the reaction to screen needing to be display would be drawing the spaceship on the current coordinates.)

  • object-oriented programming -- you split the program into many smaller parts, and you describe each part separately; from inside: what data it contains, and from outside: what actions it can do. (For example, your object Spaceship has data: x coordinate, y coordinate, number of lives. It can: move up, move down, move left, move right, return the number of lives, remove one life.) The important part is polymorphism, which means that multiple objects can have the same interface, i.e. can do the same kind of action. (E.g. Spaceship, Missile, and Asteroid all have coordinates, and can paint themselves on a screen.) So a part of program can treat all of them in a unique way. (E.g. a gravity field could influence the coordinates of all MovableObjects without having to know their details.)

  • aspect-oriented programming -- another way to split the program into smaller pieces, but this time the pieces represent the functionality of the program. (Sorry, I don't know much about this.)

  • functional programming -- most natural for mathematical calculations. You define what "f(x)" means and what "g(x, y)" means, and then you ask program to calculate "g(f(3), f(5))". Each function depends only on its input data, nothing else; e.g. the function "f(x)" can only use the value of "x", so if you call "f(7)" twice, you get the same result. Also the function "f(x)" cannot modify the value of "x". If you want to make a program where data change in time, you have to somehow include the time or other events as parameters of the functions. (For example, the position of spaceship in time T+1 could be described as a function of position of the spaceship in time T and the state of keyboard buttons.) These limitations give the advantage of avoiding come bugs and making concurrent programming (multiple processors or even computers running parts of the same program) much easier.

Another thing is how you use the data. Do you use only input and output values of the functions, or can you also store the values in variables a access them randomly? If you specify a value, can you change it later? If you have multiple types of data (e.g. texts, numbers, coordinates, spaceship description), can any kind of data go to any kind of a variable, or do you have to specify which variable contains which kind of data? -- Typically, the more freedom you have here, the more opportunities you have to make bugs.

But I guess that to understand this fully, one has to become familiar with a few programming languages representing the various styles, see the advantages and disadvantages of each, and also how each language can try to overcome its specific problems. Some languages give you more choices. (For example in Java you can write imperative, event-based, object-oriented and even kind-of-functional programs. The language itself is object-oriented, some objects use events, and there is nothing preventing you to put all your code in one function. If you use immutable objects and avoid side effects, you get some advantages of functional programming.)

share|improve this answer
    
But are there formal definitions which can be used to objectively decide whether a language exemplifies X? I don't think so. And then there's the problem of hybrids and such. –  delnan Jan 17 '13 at 13:30
    
@Villam Bur : thanks but you are replying to another question, which would be "what are the various programming langage paradigms about ?" What I am asking is : how is it possible to quantify how much a given language is of such & such type. And what are the different possible characteristics of a programming language. –  Skippy Fastol Jan 17 '13 at 13:42
1  
I guess if the language supports objects and polymorphism, it is object-oriented; and if it forbids side-effects, it is functional. On the other hand, in some languages objects are possible but optional, or objects don't exist on the language level but can be added e.g. using a library -- in this case, it is not about the language, but how it is used. Making a bulletproof formal definition might be impossible, because at the end, all those Turing-complete languages can simulate each other. –  Viliam Búr Jan 17 '13 at 13:46
1  
@SkippyFastol -- for each trait we could say whether it is mandatory, optional or impossible in a given language. Instead of complex traits like "imperative" or "functional" we should ask directly whether e.g. side effects are allowed. I don't think there would be a way to specify e.g. "semi-functional" more precisely; it seems to mean that both functional and non-functional aspects are available, and how much you use them, that depends on your code, which depends on your coding style and the type of application. There is no way to say "this language is 74.5% functional". –  Viliam Búr Jan 17 '13 at 14:11
    
@ViliamBúr: you summed it up pretty well. –  Skippy Fastol Jan 17 '13 at 14:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.