Basically, I want to learn lots of programming languages to become a great programmer. I know only a handful to depth and I was hoping someone could elaborate on how many classes or types of programming languages there are. Like how you would lump them together if you had to learn them in groups.

Coming from a Java background, I'm familiar with static typing, but I know that in addition to dynamic typing there has to be such variety in available languages that I would love to see a categorical breakdown if possible.

  • 2
    Wouldn't it better to say "Which type .. " instead of how many? Nov 9, 2010 at 20:16
  • Well I have learned that something like Prolog and C are fundamentally different, so I was thinking each of them corresponds to a different kind of programming language, and I was hoping to get a grasp of how many kinds.
    – sova
    Nov 9, 2010 at 20:26
  • 7
    2: the type that does what you want and the type that doesn't
    – Matt Ellen
    Nov 9, 2010 at 23:22
  • 1
    Learning about different types of programming languages absolutely is constructive! You could potentially argue this should be closed as a duplicate of this but I think they're distinct enough questions to remain separate. Nov 10, 2010 at 12:05
  • 1
    @Sova, I'd recommend making your first choice of new languages to try out something that doesn't use c-based syntax. That will get your head focused more on how it works vs. how it's different from the one you know best. Aug 3, 2012 at 13:58

9 Answers 9


It depends on how you want to classify languages. Fundamentally, languages can be broken down into two types: imperative languages in which you instruct the computer how to do a task, and declarative languages in which you tell the computer what to do. Declarative languages can further be broken down into functional languages, in which a program is constructed by composing functions, and logic programming languages, in which a program is constructed through a set of logical connections. Imperative languages read more like a list of steps for solving a problem, kind of like a recipe. Imperative languages include C, C++, and Java; functional languages include Haskell; logic programming languages include Prolog.

Imperative languages are sometimes broken into two subgroups: procedural languages like C, and object-oriented languages. Object-oriented languages are a bit orthogonal to the groupings, though, as there are object-oriented functional languages (OCaml and Scala being examples).

You can also group languages by typing: static and dynamic. Statically-typed languages are ones in which typing is checked (and usually enforced) prior to running the program (typically during a compile phase); dynamically-typed languages defer type checking to runtime. C, C++, and Java are statically-typed languages; Python, Ruby, JavaScript, and Objective-C are dynamically-typed languages. There are also untyped languages, which include the Forth programming language.

You can also group languages by their typing discipline: weak typing, which supports implicit type conversions, and strong typing, which prohibits implicit type conversions. The lines between the two are a bit blurry: according to some definitions, C is a weakly-typed languages, while others consider it to be strongly-typed. Typing discipline isn't really a useful way to group languages, anyway.

  • 1
    Was going to pose something similar, but will +1 and add comments instead. Each category or combination also has numerous spin-offs created by focusing on particular elements. OOP, for example, begets: Prototype-based OOP, Aspect-Oriented Programming, Component-Based Programming, and so on. Functional paradigms also have spin-offs, such as languages where an asynchronous process or thread is the base unit and you program by composing parallel processes together. Nov 9, 2010 at 20:49
  • How would scripting languages,e.g. VBScript, fit into this? It can be a bit procedural and a bit OO as one can create various types, so would that make it a hybrid?
    – JB King
    Nov 9, 2010 at 20:57
  • This is exactly what I was looking for. Thank you very much.
    – sova
    Nov 9, 2010 at 23:01
  • 3
    @JB King OOP languages usually are procedural, at least within the method bodies. Also, it's a common misconception that OOP means "objects". Lots of languages have data types and objects. There's a lot of debate on what the exact definition of OOP is, but it usually includes inheritance and/or encapsulation (private state) as major themes. A language without either in some form would be difficult to classify as an OOP language. Nov 9, 2010 at 23:40
  • 2
    @sova I can only think of two languages that work kind of like that. Erlang is based heavily on parallel processing, but if you want more like what I was talking about exactly, you should look into Polyphonic C#. It's a research language (now folded into C-omega) based on Pi-Calculus (like how FP is based on lambda calc) Pi-calc is based around the unit of a process, and you declare processes and a combination of synchronous and asych calls into them. Also look into Arrows in FP, especially Haskell. Arrows are very much like that. Nov 9, 2010 at 23:43
  • Assembly
  • Procedural
    • Basic
    • C
  • Object-Oriented
    • C#
    • Java
  • Declarative
    • Prolog
    • SQL
  • Functional
    • Lisp
    • Haskell

These are the main ones, but there's a lot of other paradigms out there, and there's plenty of overlap between them.

  • How about declarative (e.g. Prolog, SQL) ? Nov 9, 2010 at 20:45
  • @Bruce, got em now.
    – user1842
    Nov 9, 2010 at 20:48
  • Yeah this was the general idea I learnt somewhere along the way. Aug 3, 2012 at 1:37
  • 6
    Shouldn't assembly be considered procedural?
    – MattDavey
    Aug 3, 2012 at 10:18
  • 2
    How about concatenative (stack-based) programming languages, such as Forth and Factor? You could consider it a type of Functional programming, but it's probably distinct enough to deserve mention. en.wikipedia.org/wiki/Concatenative_programming_language
    – KChaloux
    Jun 2, 2014 at 14:43

For types of programming languages (Paradigms), look here:

For other characteristics of programming languages (e.g. Type Systems), look here: http://en.wikipedia.org/wiki/Programming_language

  • ah! "paradigm" what a good word! thank you
    – sova
    Nov 9, 2010 at 20:24
  • @sova I would accept this as the best answer, because there are simply too many paradigms to list in a P.SE answer, much less to describe the nuances of each. Jun 16, 2011 at 19:26

Click the image to see PDF. Programming paradigms poster

You should look at Programming Paradigms for Dummies: What Every Programmer Should Know by Peter Van Roy. This will give you an overview about how it is going on outside.

If you want to go further, you can read Concepts, Techniques, and Models of Computer Programming. You will not learn a banch of languages by this way, but you will learn paradigms which lie behind different kinds of languages. So, learning a new language will be more easy for you.

  • Procedural: Assembly, Java, C#, F#, Lisp, Fortran.

  • Set based: SQL.

  • Pattern based: Perl, Regex, Snobol.

  • Tree based: XSLT.

  • Array based: APL.

  • 3
    +1 for using a different type of classification, and also for recognizing that 'procedural' in fact contains most of the other people's classifications. (of course that only means that the word has very little meaning, and the meat is in such subdivisions)
    – Javier
    Nov 9, 2010 at 22:02

I tend to think in terms of features:


C-Based or what-have-you. Java has a C-based syntax. I highly recommend trying out something like Python or Ruby to get your head out of the syntax and thinking more in terms of fundamentals of how a given language works. I'm of the opinion that no syntax needs to get bulkier than C-based and have no problem building blocks around white-space.

Compiled vs. interpreted w. Build-Process vs. Interpreted/Console:

I have very little familiarity with compile time vs. run-time environment concerns but I get that there's a whole bag of concerns there that I rarely think about.

Likewise there are plenty of interpreted languages that still have something of a compile-ish process for running inside a virtual machine like Java does. You still have to rebuild to see changes to things.

And then there's JavaScript and Python which you can execute on the fly, command by command in a console in a live environment. All three can lead to very different ways of writing code.

Dynamic vs. Strict typing:

I tend to see the two as design tradeoffs. When you are at a much lower level and performance is critical, static typing makes a lot of sense. I've never understood this notion of one being "safer" than another somehow but I came up in a very plastic/dynamic language where you just learn how the typing system works and what to expect, basically. Type shenanigans are rarely a concern for me in JS. In some ways the flexibility can make things more robust, although admittedly a touch more arcane for a more Jr. level dev if you don't know about some of the pot-holes in the language.

Block-Level Scope vs. Function Scope vs. ?:

Block-Level is the most common (anything between {} in most c-based syntax languages). JavaScript scope is built around functions (which are also used to build objects so effectively objects too). There's also a great deal variation in what kind of access you have from inner scope to an outer-scope. I'm not familiar with other scoping schemes but I'm sure they exist.

Classical OOP vs. Prototypal OOP vs Almost-OOP(structs in C?) vs Non-OOP:

Even in class-based OOP there is a great deal of room for variation. Whether you can do multiple inheritance (ew, well in excess, ew), define interfaces, etc...

In JavaScript we have a sort of stunted hybrid prototypal OOP where objects are considerably more simple, highly mutable, but we still have the ability to separate interface from internal concerns, which IMO, is the important aspect of encapsulation.

The thing about OOP is that there really is a lot of stuff you can pull off that is essentially OOP-oriented without technically being OOP. There are purists of course but at the end of the day, Design Patterns are about achieving certain abstractions that work well in certain situations. Don't be too quick to assume ideas from an OOP-based language have no use in something that's more procedurally-oriented. And I'm not talking about JavaScript. It's not at all limited by its goofy version of a prototype based OOP paradigm.

First-Class Functions:

Not having these in a language is a hard thing for me to give up. You can pass functions around like they were data for use in other contexts. This makes event handling schemes in particular very easy to implement but it also makes it very easy to adapt the language to work the way you'd like it to. It is, more than anything I suspect, the thing that has made JavaScript the success that it ultimate has been in spite of being designed in two weeks and getting Java-approximate syntax slapped on to it as a marketing scheme.


I'm not sure where the debate is at for Java, but I know a lot of Java devs were clamoring for this feature a year or two ago. In a non-closure language, when a function closes, anything that is somehow able to reference stuff from inside that function won't be able to access it because it was garbage collected. In a closure, execution context is bound such that if you're able to reference stuff inside that closed function from another scope like in a returned object or function you basically get those vars as they were when the function closed. It's like a jamming your foot in the door of garbage collection, although I suspect it's implemented more like copies of those vars made into local vars of the referring entity.

Rigid/Strict/Safe vs. Giving You all The Rope You Want:

JS devs and Java devs tend to not understand each other at all and I think it has a lot to do with the two languages falling on near-opposite sides of this particular design spectrum. I don't want you to protect me from myself or from the other devs on my team. I want to do a lot more in a lot less code and to do it all in very different (but consistent for a given domain) ways depending on the situation. There are absolutely tradeoffs to both and a lot of languages tend to fall more in the middle.

  • Gee thanks. It's really nice to go through the effort for a down-vote with no explanation. Aug 3, 2012 at 13:24

There are different ways to answer this, but in terms they can be categorized as:

Machine language: Machine language is a low-level programming language. It is easily understood by computers but difficult to read by people. This is why people use higher level programming languages. Programs written in high-level languages are also either compiled and/or interpreted into machine language so that computers can execute them.

Assembly language: Assembly language is a representation of machine language. In other words, each assembly language instruction translates to a machine language instruction. Though assembly language statements are readable, the statements are still low-level. A disadvantage of assembly language is that it is not portable, because each platform comes with a particular Assembly Language.

High-level language: High-level languages are what most programmers use nowadays. Languages such as C, C++ and Java are all high-level languages. Advantages of high-level languages are that they are very readable and portable. A disadvantage of high-level languages is that they are less powerful than Assembly Languages. Because a single statement in a high-level language is translated into many machine language statements.

High-level languages can further be classified as:

  1. Functional languages: In Functional language, a program is divided into function definitions. Functional languages are a kind of declarative language. They are mostly based on the typed lambda-calculus with constants. Some of the famous Function languages are Scala, F#, Clojure and Lisp.

  2. Procedural languages: In Procedural Languages, a program is written in a sequences of steps that should be followed to produce a result. COBOL, FORTRAN and C are some Procedural languages.

  3. Object Oriented Programming languages: In OOP languages, a program is divided into Object that contain data as well as methods that operate on the data. Java, C# and C++ are OOP languages.

  4. Logic Programming languages: Logic Languages are used to create programs that enables the computer to reason logically. eg: Logic language

For in-depth study, check out:


I think a short-cut to all these is to learn enough Lisp to do some semi-useful things. Most of these paradigms started out as ways of using Lisp, so it's a simple way to try things.

There are a number of "kinds" of languages around, but new ones can always appear. Basically, the purpose of a language is to permit encoding of ideas, concepts, or requirements, as directly as possible. To that end, there can be situations where existing paradigms are wanting, and a new one might be needed.

One way to look at is in terms of surface structure. How directly does it allow you to encode ideas concisely, so that if you change your mind about what you want, the corresponding change to the code is also easy, with little chance to introduce bugs.

Another way to look at it is in terms of control structure. When the language is executed (if it is) what is the order in which things happen, to accomplish what you want? Examples are: simple straight-through execution, recursion, backtrack, parallelism. One I (modest cough) discovered was differential execution.

Another useful viewpoint is that any time a data structure is designed, a language is born. Data is "executed" by the application programs that comb through it and do things, just as a program is just a bunch of data (like byte codes) that are used by an interpreter to do things.

  • Cool. I will learn LISP and be enlightened. Exciting :D
    – sova
    Nov 10, 2010 at 7:24
  • However, if you say that the act of using a data structure creates a new intermediate language then you could also argue a new language is born in every algorithm (all operations are necessarily done on a data structure), and with reduction, a new language is born in every line of code. I think you mean something else though but I'm not quite sure I understand yet?
    – sova
    Nov 10, 2010 at 7:31
  • @sova: For me, information theory was a great revelation (both Shannon and Kolmogorov). It's about how meanings are encoded and passed through channels, with concepts of bandwidth, error-detection, minimal coding, randomness, etc. So, data encodes information, and algorithms are channels. Programs encode information, and programming is a channel. So, what information is encoded? where does it come from and when? where is it going to? what are the sources of errors (noise)? how are they corrected? I found that a useful perspective. Nov 10, 2010 at 13:12
  • @sova: (continued) You don't have to master all the off-putting math. For me, what mattered was the framework it gave me for thinking about things. Nov 10, 2010 at 13:15

I have to add that there are programming languages for specific applications. The one that comes to mind is APT (Automatic Programmed Tool) a language used in manufacturing for machine tools.

  • I remember that one. I may have even used it. Boy, that was state-of-the-art. You didn't have to manually guide the milling machine, just push the start button. And if there was a bug, all hell would break loose. Nov 10, 2010 at 14:20
  • I've worked on programs that generate gcode for milling machines. I've literally held and seen the results of programming bugs, frequently mine. Nov 10, 2010 at 19:27
  • I spent 20 years installing postprocessors on gobs of systems.
    – Dave
    Nov 10, 2010 at 23:30

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