Are Databases and Functional Programming at Odds

Are Databases and Functional Programming at odds?

First of all, I would not say that CLOS (Common Lisp Object System) is "pseudo-OO". It is first class OO.

Second, I believe that you should use the paradigm that fits your needs.

You cannot statelessly store data, while a function is flow of data and does not really need state.

If you have several needs intermixed, mix your paradigms. Do not restrict yourself to only using the lower right corner of your toolbox.

Functional Programming better to manipulate lists of database data?

Well, Lisp deals with lists, but the lists are heterogenous, and can well represent a tree. Other languages, like Haskell, give you structured types, named and unnamed, and - in contrast to lisp - allow for static type checking.

One thing that pure functional languages do not have is the notion of stateful variables that can be assigned. Some Lisp implementations provide such state - you get a setq opeator -, while Haskell doesn't. Reading and writing databases, however, is all about having state - and lots of it, that's what databases are for - and about reading from and writing into it. So, operating on a database is quite the opposite of using a functional language.

It does, however, make sense to create a database query language which expresses the DB operations in a non-imperative, but in a declarative, and hence in a functional way. That's how SQL makes sense, and that's also how the way LINQ is defined makes sense.

So, it makes sense to have a database language which is functional, but it's not because of the lists.

Is Functional to Relational mapping easier than Object to Relational?

The hard problems of extending the relational database are extended transactions, data-type mismatches, automated query translation and things like N+1 Select that are fundamental problems of leaving the relational system and -- in my opinion -- do not change by changing the receiving programming paradigm.

How are functional programming constructs in multi-paradigm languages useful?

I use FP constructs in java to process a lot of data, for example:
You get a list of integers and have to apply following operations:

1. Remove uneven numbers
2. Remove each number, that occurs twice
3. Map each one to the square root
4. Sort them in ascending order.
5. Return it as a list of doubles
   In Java, with Streams you can do:

public List<Double> applyOperations(List<Integer> ints){
  return ints.stream()
             .filter(a->a%2==0)
             .distinct()
             .map(Math::sqrt)
             .sorted()
             .collect(Collectors.toList());
}

versus

public List<Double> applyOperations(List<Integer> ints){
  Set<Integer> evenNumbers=new HashSet<>();
  for(Integer i:ints){
    if(i%2==0){
      evenNumbers.add(i);
    }
  }
  List<Double> doubles = new ArrayList<>();
  for(Integer i:evenNumbers) {
    doubles.add(Math.sqrt(i));
  }
  Collections.sort(doubles);
  return doubles;
}

The first one is much more readable and elegant than the latter one.

To which kind of problem is functional programming well suited?

Functional programming is best suited for most kinds of problems, including anything you would normally use object-oriented programming for, except for maybe problems that require the storing of a lot of state or other side effects. Aside from that, FP handles complex problems much more gracefully than OOP, as a lot of it comes from a mathematical background (starting with the lambda calculus). You have much more flexibility as far as abstraction and composition go. An object-oriented program with a lot of design patterns could be refactored using more functional constructs which will allow you to do the same thing without the boilerplate structures that design patterns make you write. In addition to mathematics and parsing, FP has also been extensively used in artificial intelligence (particularly Lisp).

why is functional language good for big data?

One of the reasons is that having immutable variables let's you execute code in parallel and scale very easy.

---

Related Topics