Functional VS Object??!!!

What is the difference between functional and object orientated programming? Witch one will be used more in the future? And finally witch would be better to learn ruby or F#?

 

Hi gfxrelay,

Both functional and object-oriented programmings share the same goals :
- prevent tedious duplications of coding that may be sources of mistakes,
- make the coding more fit to maintenance and reusability.
In object-oriented concepts, everything is object : a computer, a screen, a financial transaction, a FTP connection, a college, a library, and so on ...
Even functions can be objects.
An object is described by its template which is called a class and a class has properties and methods.

For example, I want to use a Parabole object which represents the function :
f(x) = a * (x**2) + b * (x) + c
and I want a method that computes the result for a given value of x and another method that gives the value of the discriminant : (b**2) - 4 * a * c
Here's an example of the class what I will obtain in Java :

Code:

[SIZE=2]
public class Parabole {
    // properties
    private double a;
    private double b;
    private double c;

    // constructor = a special method to build or instantiate the object 
    public Parabole(double a, double b, double c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }
    
    // the methods (notice that methods can be functions too)
    public double getF(double x) {
        return (a * x * x) + (b * x) + c;
    }

    public double getDiscriminant() {
        return (b * b) - (4 * a * c);
    }
}[/SIZE]

I may build a whole application using a lot of Parabole objects and 10 months later, the project manager may ask me to add a new method to generate, for example, the derivative which is a stright line.
The upgrade of the class won't have any incidence in the coding of my application. This is one of the main benefits of object-oriented programming.

To summarize, functional programming and also procedural programming may be considered as integrative parts of object-oriented programming as methods are mainly functions and procedures.

I guess nobody can't answer this as languages are evolving in the same way than hardwares and OS's.

If I had sufficient time, I would have a try with both of them. They both look interesting.

 

Depends on the application of the application

Larger projects tend to be Object Oriented, whilst smaller home projects or kludges would tend to be Proceedural, although there are always exceptions.

Neither. I'd start with Python or C/C++. The thing with both Ruby and F# is they run ontop of frameworks, meaning decreased performance.

 

The future - hmmm, with multi-cores proliferating, I would look for an entirely new paradigm for software programming that takes advantage of new conceptual models that are born out of new approaches to parallel programming. Huh! What did I just say?

Here's a link to get you started Project COSA: To Drastically Improve Software Reliability and Productivity.

Also: COSA Parallel QuickSort Example.

Plus, read all of the Nightmare on Core Street series articles starting here including all of the links internal to the articles to provide you more context about the issues.

The merging of software programming into something more akin to hardware design would be proper preparation for anyone wanting to excel at system software engineering in the foreseeable future IMHO.

Hardware engineers have for a long time had TTL Data books with components, and the design process has become simplified for hardware using that approach - it means more time is spent on overall system design using proven building blocks from the bottom up - why not software engineers too? Because nobody's invented it, yet! Maybe COSA will take off someday - its an idea that wants to be born, and take over the industry by storm, only I would expect that not only legacy code, status quo, not-invented-here, and the unwilling to take the risk will assert itself to prevent rapid progress until new venues are created to let this kind of approach flower and bloom on its own.

-- Tom

 

To drill down and understand the above post may be challenging, but the following article corrals the notion of where functional languages (Erlang is one such language) fit into the overall scheme of things:

Parallel Programming, Math, and the Curse of the Algorithm.

My take on this is that the author treats only the notions of fine-grain and course-grain parallelism, but entirely misses the opportunity to tie in medium-grain parallelism.

Fine-grain parallelism is usually considered to be at the instruction level - however, the author seems to infer a greater association of it with memory caching. Course-grain (or so the author claims) is at the thread level of an algorithm, and claims that multi-cores are at that level. While true that threads are the usual scheduled entities to run at a multi-core level for one of the cores, there are other levels of graininess - i.e. medium grain.

The lowest level of parallelism is that inherently designed into the hardware at the instruction pipeline level - i.e. what hardware instructions can be run concurrently - i.e. having no data dependencies (reference) and able to run independently to conclusion. Often hardware engineers design the instruction set and pipelines with hardware design languages with a massive assist by CAD (Computer Aided Design) systems.

The next level up is that provided by instruction scheduling by a compiler to take advantage of parallel mechanisms built into the hardware - this is a fine-grain approach to optimizing code.

The next level up are the runtime systems, and it is here that a medium-grain approach is available. When a processor (any number of cores) supplies an atomic instruction for locking, then runtime threads can provide the necessary synchronization means between tasks that are not entirely independent in their data flow - provided that a large shared memory cache exists between the multi-cores.

The author points out that Erlang disallows shared memory and provides message passing to do the job, where it is assumed that on multi-core processors each having its own memory cache, message passing is required to support network mesh architectures. And so, the author makes the case that functional languages such as Erlang do not support a better model for parallelism.

I don't know if multi-cores already have or could have in addition to their own local memory caches a large shared memory cache between all of them with the atomic instruction support, but that would certainly make it easier to do parallel programming IMHO.

All in all, the author makes his case in his own style - worth the read to help get a handle on some of the issues about the parallel programming crisis and multi-core processors.

-- Tom

 

Actually, I think that as with many CPU functions still in it's infancy, the control of parallel computing will be moved off to the CPU itself, as with more mature technologies such as memory management and virtualization. If you remember both these technologies started out as programatically controlled, but CPUs began to offer built in functions for managing the IDTs, GDTs, and the virtualization aspects. I think in the future we'll see CPUs which are able to accept a instruction from a program coded with 1 core in mind, and distribute the load equally among their 4 or 8 or however many cores. It's the only true way to keep software backwards compatible and still maintain the functionality of all of the cores.

 

The major impediment to all of that is that each core encompasses a Von Neuman bottleneck - you have to break through that barrier first in order to have true parallel programming.

CPU functions are a moving target hardly in infancy which is by design at the hardware level where all the action takes place and the most bang for the buck exists to parallelize.

Cache memory shared between cores might be a good way around all of this if it can be shrunk enough onto a multi-core. Eventually, nanotechnolgy will be applied to solve these problems, and a new paradigm will result with a new set of tools for parallel programming.

At some point, new hoisting tools to bridge vastly different technologies will be needed to finally put backwards compatibility to bed as an issue.

-- Tom

 

In keeping with the original question of functional vs object, I refer you all to the following web page on the question of Can Programming Be Liberated From The Von Neumann Style.

In particular, the gem inside is a link to the 1977 Turing Award lecture by John Backus, the inventor of Fortran (link to PDF download - 3MB): Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs.

Note: John Backus's classic TuringAwardLecture, introduces the functional programming language FP which has no variables. The paper does not propose using FP. It proposes using extensions of it that do have variables.

Reading the bolded introduction to the the paper will give you a flavor of its contents.

I'll have to look around to see if there are any similar papers on object oriented programming languages.

Note: functional and object-oriented programming are considered a programming paradigm.

In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in functional programming a program can be thought of as a sequence of stateless function evaluations.

-- Tom