Recently, I was reading David R. Tribble’s annotated version of Dijkstra’s famous letter “Go To Statement Considered Harmful”.  While in the process of reading, it occurred to me that I did not really understand the history of language abstraction.  To remedy this I’ve done some research and put together the following post.  I hope you find it as educational to read as I found to write.

Programming languages are often spoken of in terms of their level of abstraction.  To this end there is a somewhat official classification system.  In said system, each generation in the hierarchy represents another level of abstraction away from the machine hardware. 

 

First-generation programming language (1GL) – Binary

I think there is a world market for maybe five computers.
-Thomas Watson

It makes sense Watson would say this seeing as how the earliest computers were programmed entirely in binary.  These computers were programmed with no abstraction at all.  I, for one, do not envy our forefathers in regard to this task.  While the programs were small, all operations, data and memory had to be managed by hand in binary.

• Introduced in the 1940s
• Instructions/Data entered directly in binary
• Memory must be manually moved around
• Very difficult to edit/debug
• Simple programs only

Examples:

Architecture specific binary delivered on Switches, Patch Panels and/or Tape.

 

Second-generation programming language (2GL) – Assembly

He who hasn't hacked assembly language as a youth has no heart. He who does as an adult has no brain.
-John Moore

Assembly languages were introduced to mitigate the error prone and excessively difficult nature of binary programming.  While still used today for embedded systems and optimization, they have mostly been supplanted by 3GL languages due to the difficulties in controlling program flow.

• Introduced in the 1950s
• Written by a programmer in an intermediate instruction language which is later compiled into binary instructions
• Specific to platform architecture
• Designed to support logical structure, debugging
• Defined by three language elements: Opcodes (CPU Instructions), Data Sections (Variable Definitions) and Directive (Macros)

Examples: 

Almost every CPU architecture has a companion assembly language.  Most commonly in use today are RISC, CISC and x86 as that is what our embedded systems and desktop computers use.

 

Third-generation programming language (3GL) – Modern

“Real programmers can write assembly code in any language.”
- Larry Wall

Third generation languages are the primary languages used in general purpose programming today.  They each vary quite widely in terms of their particular abstractions and syntax.  However, they all share great enhancements in logical structure over assembly language.

• Introduced in the 1950s
• Designed around ease of use for the programmer
• Driven by desire for reduction in bugs, increases in code reuse
• Based on natural language
• Often designed with structured programming in mind

Examples:

Most Modern General Purpose Languages such as C, C++, C#, Java, Basic, COBOL, Lisp and ML. 

 

Fourth-generation programming language (4GL) – Application Specific

"A programming language is low level when its programs require attention to the irrelevant."
-Alan J. Perlis

A fourth generation language is designed with making problems in a specific domain simple to implement.  This has the advantage of greatly reducing development time cost.  At the same time there is the disadvantage of increasing developer learning cost.

• Introduced in the 1970s, Term coined by Jim Martin
• Driven by the need to enhance developer productivity
• Further from the machine
• Closer to the domain

Some examples: SQL, SAS, R, MATLAB's GUIDE, ColdFusion, CSS

 

Fifth-generation programming language (5GL) – Constraint Oriented

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
- Tony Hoare

It has been argued that there is no such thing as a 5GL language.  This seems to me ridiculous as working with domain specific syntax is hardly an abstractional dead end.  This cynicism is likely a result of the many false claims of 5GL for the sake of marketing.

Many researchers speak of 5GL languages as constraint systems.  The programmer inputs a set of logical constraints, with no specified algorithm, and the AI-based compiler builds the program based on these constraints.

• Introduced in the 1990s
• Constraint-based instead of algorithmic
• Used for AI Research, Proof solving, Logical Inference
• Not in common use

Some examples: Prolog, Mercury

 

Conclusion

An interesting history lesson, although, I can’t help but feel that categories beyond 3GL are somewhat arbitrarily defined.  I do agree that 4GL is an abstraction on 3GL.  Perhaps however, there are other directions which are equally abstract in relation to 3GL.  Perhaps after concrete logic based systems, free form natural language should have been fourth.  This could be followed by thought based, which I feel would be the ultimate level of abstraction for human interaction.

Also, to my great disappointment, I was unable to find out who coined most of the “# generation language” etymologies.  As usually in computer science it is possible to gain insight on a concept by examining the author’s other works, in this case that option seems unavailable. 

 

Other References:

Introduction to Assembly Language
Generations of Programming Languages

Michael Feathers, author of the excellent book Working Effectively with Legacy Code, recently tweeted about a paper written by Peter Van Roy entitled Programming Paradigms for Dummies: What Every Programmer Should Know.   I thoroughly enjoyed the paper, despite being initially put off by its title.  It’s written in very accessible language and the vast majority of programmers would benefit greatly from giving it a read. 

Understandably, most won’t take the time to read a 50-odd page academic paper unprompted.   We are all busy professionals with full lives.  With this in mind, I would like to share the core of the ideas contained therein.  Perhaps this short summary might intrigue in so far as to incite the printing of said paper for placement by the bed side, or in the bathroom, for future perusal.

 

What Every Programmer Should Know

What exactly constitutes a paradigm? In this paper Peter Van Roy provides the following definition:

“A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles.”

This concept along with Imperative, Object Oriented and even Functional programming are spoken of in many software development circles.  However, little known to the every day software engineer is the family tree of paradigms which has continuously been evolving since the advent of computing.  Each paradigm having been invented to reduce the complexity of solving a particular computational problem.

The basic idea of this paper is that, as Software Engineers, we should take the time to learn paradigms outside the scope of those had in mind by our language’s designers.  Because most languages directly support only one or two paradigms, problems are frequently solved in needlessly computationally expensive, convoluted and difficult to maintain ways. 

Therefore, the best approach language community leaders can take is to learn, retrofit our existing languages and promote knowledge of these paradigms.  In this way we can enjoy many of their benefits and start solving problems in the most manageable way available.

 

Additional Thoughts on The Ideal Multi-Paradigm Language

In the ideal case, a language would directly support all known paradigms well.  However, even given the realization of this currently unrealistic language, it would take a long time to see widespread adoption.  As time passed and the language was adopted, surely new paradigms would be invented and the language would be no longer “paradigm complete”.  Thus the process would likely have to be repeated ad infinitum.

This is not to say the trying to build such a language would not be worthwhile.  Perhaps even some kind of paradigm meta layer could be made to enhance extensibility.  However, I do believe that with any language it would only be a matter of time before a paradigm was invented that violated an underlying assumption of the system, and the processes would need to be restarted from scratch.

With the Visual Studio 2010 launch just days away, the F# community is exploding with fury and excitement.  Come inside and find links to topics ranging from general programming patterns to specific algorithm implementations.

 

Don Syme on the Passing of Robin Milner

It is with sadness that I mention the death of Professor Robin Milner, the great British computer scientist, who passed away 11 days ago.

 

Talbott Crowell’s FSUG Talk – F# and Silverlight

This talk describes building Silverlight 3 applications using F#. Both Visual Studio 2008 and 2010 RC are demonstrated.

 

CodeCast Episode 73: F# with Michael Hale

F# with Michael HaleIn this episode of CodeCast, Ken Levy interviews Michael Hale, a program manager on the F# team at Microsoft. Michael discusses what’s new in F# for both Visual Studio 2008 and Visual Studio 2010, various scenarios for functional programming with F#.

 

IronJS is a Javascript implementation for the DLR written in F# (source)

I just wanted to give a quick notice that I got the new compiler for IronJS to run on both .NET 2.0 and Mono 2.6 today, the goal is for IronJS to be able to run on .NET 2.0, 3.x and 4.x plus Mono 2.6

 

Brian McNamara’s F# async on the client side

Though the killer app for F# async is non-blocking I/O on the server side, F# asyncs are also useful and fun to use for client-side programming on the UI thread.  I’ll show two small examples of F# async lets you do non-blocking loops on the UI thread.

 

Brian McNamara’s F# async on the server side

Last time I talked about cool ways to use F# asyncs to help write client GUIs.  Today I’ll talk about the killer app for F# asyncs, namely, non-blocking I/O on the server side.  Once again, this is material I lifted from a recent talk that Matthew Podwysocki and I gave at TechReady.

 

Brian McNamara’s Nine reasons to use F#

The list is not necessarily distinct (some elements overlap) or complete (this is just a list I came up with today), and not every reason in the list will resonate with every reader.  But they are all ‘real’ reasons, in the sense that they’re representative of individuals or teams out in the world who are already using F# today.

 

Matthew Podwysocki’s Time Flies Like An Arrow in F# and the Reactive Extensions for .NET

Let’s take a look at what would be required for us to make the Time Flies Like an Arrow example work in F# using first class events and the Reactive Extensions for .NET on top of WPF.  I’ll write it in a pseudo-code to give you an idea of how it should be done.

 

Aaron Erickson’s F# Based Discriminated Union/Structural Similarity

Imagine you have a need to take one type, which may or may not be a discriminated union, and see if it “fits” inside of another type.  A typical case might be whether one discriminated union case would be a possible case for a different discriminated union.  That is, could the structure of type A fit into the structure of type B.  For lack of a better word, I am calling this “structural similarity”.

 

Mike Hadlow’s Functional Dependency Injection == Currying

In a functional language like F# we can do the same thing without the overhead of having to declare classes and interfaces. We can also do the same thing in C#, but it requires some jiggery-pokery, so I’m going to show you it in F#.

 

Neil Carrier’s A 32-Bit Computer in One Page of Code,
F# Implementation of Bit-Based Computer,
Bit Computer Addition and Bit Operations from TAoCP in F#,

I want to depart from the lofty world of semantic networks for a few posts, in order to investigate the world of bit-based computers. By bit-based computer, I mean one in which the entire state of the computer is based on an ordered set of bits. The computer I describe below was suggested by Digi-Comp I, a classic bit-based computer made almost entirely of plastic, but mine is based on a somewhat different design.

 

Neil Carrier’s The Estimable Item 175 and Item 175 At Large

This example illustrates a famous “Gosper hack.” There is apparently some controversy over which Gosper hack merits the title THE Gosper hack. Often that title goes to MIT A.I. Laboratory HAKMEM Item 145. The code below is based on Gosper hack 175 from the same document, which is the one Knuth mentions.

 

Neil Carrier’s Easter (Practical Astronomy With Your Calculator)

In honor of the day, I present the following short program for calculating the date of Easter. The method is from Butcher's Ecclesiastical Calendar (1876). I present it in the form given in Peter Duffett-Smith's Practical Astronomy With Your Calculator (Cambridge 1981, the 1988 version is still available from Amazon, et al).

 

Neil Carrier’s Search Routines, Continued and Improved Canonical Search

In the meantime, here is a first try at general purpose depth/breadth-first search routine. It's not really generic yet, being based on a specific data structure. However, my goal is, over the next few days, to turn it into a nice generic search routine that I can use in a number of applications.

 

Julien Ortin’s Technical analysis indicators in F# – Oscillators

The articles of this series are being updated as the series expand. In particular : corrections were made to errors in the algorithms (an example use sample will be published to show what has been checked against either a spreadsheet application or TA-Lib) and modification of the meta information.

 

Julien Ortin’s Technical analysis indicators in F# – Moving Averages

This is part of a series on technical analysis indicators in F#, based on the multi-language TA-Lib.  Quick disclaimer : some of these indicators are not verified.

 

Daniel Mohl’s .NET Remoting in F#: A Start to Distributed a Hash Table (DHT) and A Distributed Hash Table (DHT) in F#: Moving from .NET Remoting to WCF

In my last post I provided a start to a distributed hash table (DHT) using F#, the Chord protocol, and .NET remoting.  In this post, I'll show how that code has changed due to a migration from .NET remoting to WCF.

 

Roger Alsing’s F# + Gold Parser = true

First of all, I have to confess that I’ve started to see the light of F# and AST manipulation.  Anyway, I’ve created a F# skeleton template for Gold Parser and the Calitha .NET engine.

 

Can Erten’s Random number Generation with RNG

I would like to mention a question that posed on stackoverflow a year back, with a slight change: Given a function which produces a random integer in the range 0 to 4, write a function which produces a random integer in the range 0 to 6.

 

Vladimir Matveev’s F# and handling ASP.NET requests

Objective was the following: implement simple socket based application that will listen specified port, parse incoming HTTP requests (extract uri from request treating it as file) and return content of specified file. Roughly speaking it should be primitive http server.

 

Vladimir Matveev’s Evoked by "Patterns of Parallel Programming" (part 1) and Evoking by "Patterns of Parallel Programming" 1.1

One section in excellent article "Patterns of Parallel Programming" is dedicated to idiom "Speculative processing". In brief we can start multiple computation in parallel (utilizing advantages of multiple cores), take first result and ignore others. Unfortunatly F# library doesn't provide builtin primitive for this strategy.

 

From the CCNET Blog: CruiseControl.NET and F#

I’ve been writing some documentation on building plug-ins and recently I expanded it to include some Visual Basic examples. That got me thinking, what other languages can we build plug-ins in? So I thought I’d give it a quick try in one of the new fangled languages that people are raving about – F#.

 

Chris Marinos’ An Introduction to Functional Programming for .NET Developers

But in order for you to take advantage of all of these fantastic features of F#, you need to understand the basics. In this article, I’ll explain these concepts using vocabulary that you are already familiar with as a .NET developer. I will also show you some functional programming techniques that you can apply to your existing code and some ways in which you are already programming functionally.

 

Imperative Programming in F# (From F# in Action)

This article is taken from the book F# in Action. The authors discuss basics of imperative programming in F# and develop a simple application to show how this type of programming works. They also feature some of the interoperability among languages on .NET platform.

 

Wayne Delport’s Introducing F#

The purpose of this article is to introduce you to the F# language - what it is, it's origins, and how it fits into Visual Studio 2010 RC.

 

Anders Hejlsberg on functional programming, programming futures

I will not try and summarise [sic] the whole talk here; but will bring out its unifying thought, which is that programming is moving towards a style that emphasises [sic] the “what” rather than the “how” of the tasks it encodes.

Mike Roberts’ F# Simple Twitter Update

A short while ago I posted some code for a C# twitter update.  I decided to move the same functionality / logic to F#.  Here is what I came up with.

 

Enes Bajramovic’s Yet another page provider but in F#

Since the best way to learn programming language is to use it, I tought I could port the EPiServer XmlPageProvider to F#. FSharpPageProvider  is my first attempt to accomplish that.

 

From The “F# Code” Blog: Generic Monadic Map and Join using statically resolved type variables

A demonstration of how the inline keyword and statically resolved type variables allow for much more robust type inference.