|
Note: Following complaints, the adjective "bread-and-butter" has been replaced by "ordinary".
Imperative programmers, that is, ordinary programmers, use computer languages such as Java, C#, Cobol, or Php to group statements, conditions, and iterations into programs.
The compiler that will translate such programs into executable machine language, is itself also a program.
We all know, however, that the average imperative programmer usually cannot write a compiler, a script engine, a database engine, a web layout engine, or any other functional engine. Why is this so?
Functional engines: the Achilles heel of the ordinary programmer
What do compilers, script engines, database engines, and web layout engines have in common?
Programming them in imperative Dijkstra style, just by grouping statements, conditions, and iterations, is theoretically possible, but practically unfeasible. Even though every decidable program can be written as an imperative program, it is extremely hard to build correctly functioning functional engines in this way.
In other words, if a programmer can only write programs in imperative style, there are quite a few problems that -- in practical terms -- he will not be able to solve.
At the same time, we also know that every program beyond a particular size, will contain problems that in practical terms can only be solved by building an appropriate specialized functional engine.
This is one of the reasons why large projects tend to fail. The ordinary programmers will inadvertedly start building, that what should have been a specialized functional engine, in plain imperative style, and engage in a massive effort that will produce lots of buggy and unreadable imperative source code.
Many ordinary programmers think that the reason they are not be able to build something like a compiler, is because it would require hand-crafting large amounts of source code. This is, of course, just a myth. Any programmer who understands how to write functional engines, can build a simple compiler in less than a week.
The waterfall principle
Users wait for ordinary programmers to write their user interfaces and underlying imperative programs, so that they can do their jobs.
Ordinary programmers wait for the functional programmers to write the functional engines that they, in turn need, to do their jobs.
Everybody's progress, therefore, depends on functional programmers to come up with new ideas for new functional engines, program them, expose them as black boxes to ordinary programmers through imperative APIs, so that the ordinary programmers can start using them in their own programs.
No common language means: no communication
Ordinary programmers use strictly imperative languages such as Cobol, Basic, Pascal, Php, Java, C#, and so on. Unfortunately, functional programmers cannot do their jobs and cannot build functional engines in these languages.
The number one requirement for functional programmers, is the availability of first class functions. Without first class functions, no functional programming is possible, and from there, writing anything such as a compiler, a script engine, or any other functional engine, becomes a nightmare.
It is not that functional programmers are cocky, and therefore look down on strictly imperative languages such as Cobol, Basic, php, Java, C#, and so on. The job of constructing new functional engines can simply not be done in those languages. That is the problem.
No imperative programming style possible in purely functional languages
Lisp and scheme are languages with first-class function support. They are popular with functional programmers. Unfortunately, imperative programming is notoriously hard in these languages.
Ordinary programmers may want their functional engines, but not if that comes with the struggle to shoe-horn their imperative programs into lisp or scheme.
Ordinary programmers do not want to program in these languages. Get over it.
C is too low-level
In spite of being quite a low-level language, it is perfectly possible to do functional programming in C, thanks to its full support for first-class functions.
However, ordinary programmers prefer higher-level languages such as Php, C#, or Java. These languages lend themselves perfectly to an imperative style of programming, and this is what ordinary programmers need.
But then again, these high-level languages almost invariably fail to provide the support for the first-class functions without which functional programmers are unable to do their jobs. So, functional programmers cannot use these high-level imperative languages either.
Python could have saved the day, but didn't
There has been a certain raprochement possible between ordinary programmers and functional programmers by both joining the Python community. The Python language supports both imperative and functional programming styles relatively well.
Unfortunately, Python also introduced its own ideosyncratic syntax, that is reprehensible to programmers used to the C-style syntax. Consequently, the general verdict on Python has predictibly been: thanks, but no thanks. Straying from the C-style syntax is simply a non-starter.
But then again, Python is the language that undoubtedly came the closest to solving the issue of joining both types of programmers. It must have missed its target by just an inch.
Javascript
Javascript is a high-level language with full support for first-class functions. Ordinary programmers can completely use it in imperative style, while functional programmers have all the constructs they need to build functional engines.
What was lacking up till now, were fast embeddable javascript engines such as Google v8, that could be used outside the browser. These engines are finally coming along.
An example: the polymorphic currying function call
As I argued in a previous post, object-oriented programming is just one particular way -- certainly not the only way, or even always the best way -- to create polymorphic functions.
Object-oriented expressions involve invoking a function, itself returned through a function call:
polymorphic method call: x1->f(x2,x3,...,xn) == (find_function(F,x1)) (x1,x2,...,xn)
g=find_function(F,x1)
with F the integer or string key symbol, referring to function f.
From lambda calculus, we know that there are many useful ways to polymorphize functions, other than object-orientation. One interesting way is the polymorphic currying function call:
polymorphic currying call: f(x1,x2,...,xN) == (curry(f,x1)) (x2,x3,...,xN)
g=curry(f,x1)
An example of currying a general sum() function into a more specialized increment() function:
var sum = curry(function( x, y ){ return x + y; });
var increment = sum(1); //--> defines the "increment" function
print increment(5); //--> prints: 6
The curry() function-function is a useful construct. For example, it would be a very natural way to obtain database query function, bound to particular database:
var query=queryBind2Db('db.john.com', 'johndb', 'john', 'secret' );
var rows=query('select * from users order by username');
The currying function style is a much more natural way to supply configuration parameters to a function than the object-oriented style.
It is absolutely possible to implement the curry() function-function in Javacript thanks to its support for first-class functions and closures. You can find a Javascript implementation for the curry() function-function on Ariel Flesler's blog site.
For ordinary programmers, it is absolutely not an issue that they may be unable to create the curry() function by themselves. The functional programmers are able -- and willing -- to use Javascript, and provide all of us with their source code.
Javascript provides a way of communication between ordinary and functional programmers
Functional programmers regularly experiment with new polymorphization strategies. Some of these will inevitably become incredible hits.
They can also build their new ideas for new, specialized functional engines in Javascript, where ordinary programmers can find them, and use the ones they like, in their own programs.
Better communication between ordinary programmers and functional programmers will eventually materialize in higher quality software and faster development of the ordinary programs that the users need to do their work.
Therefore, both ordinary programmers and functional programmers should move more of their workloads to Javascript.
Note: I hope that nobody will equate the term "functional engine" with "I am smart" to the extent that even the smallest program must get littered with wannabe functional engines. Nobody wants a repeat of the disasters that occurred when everybody and their little sister started cargo-culting the Gang of Four.
|
