• Post Reply Bookmark Topic Watch Topic
  • New Topic

relation between functional prg, OOP and procedural prg + defs  RSS feed

 
Grega Leskovšek
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I understand procedural prg is like blocks of code calling each other from main prg in a sequential way.
OOP is like a map: You have the capital, suburb, lakes, rivers, yachting, surfing, traffic and the cities are independent from each other as much as possible, but really independent is only the capital(main prg) depending only on resources.
What should the functional prg be like? What prg languages are meant primevally for functional prg? Python? And is Java also such lang?
What are the relations between the 3? Does anybody know of dev where 2 or 3 approaches are combined?
Am I also correct for proc and OOP def? Any thoughts, suggestions, corrections warmly and most welcome! Still a newbie, Gregor Leskovšek from Slovenia
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Grega Leskovšek wrote:What are the relations between the 3? Does anybody know of dev where 2 or 3 approaches are combined?
Am I also correct for proc and OOP def? Any thoughts, suggestions, corrections warmly and most welcome! Still a newbie.

Which is fine, but do be careful when you use abbreviations - this is a forum, not an SMS service.

I tried looking up 'prg', but it wasn't much help until I realised that you probably meant "program".

It would appear that you're looking for similies to help you to picture the various styles of programming, and languages that support them - and that's fine; but be careful not to overdo it.

About the best I could come up with for functional programming is Algebra. Each component is either a literal, or the result of the output of some operation (or 'function') which can be stacked together as in an expression like 'log((√x) / 2)', where the "functions" would be 'log', 'square root' and 'divide'.

It's not by any means a complete description though (for a quick overview, have a look here); and that's the problem with a lot of these analogies - they break down if you look at them too closely.

But in answer to your other question: No, Java is not a functional language. As of version 8, it does contain some functional characteristics, but these are still very new (and IMO, a bit "clunky"; but that's no reason not to learn them).
Java calls itself an "Object-Oriented" language, which is probably correct - but a lot of the method code you write is still basically procedural. The "Objective" part comes in designing your classes well, and connecting them together to do great things - and that only comes with practise.

TBH, purely functional languages, just like purely "objective" ones, are mostly found in universities and used to teach theory; although a few, like Lisp and Haskell, have made it into the commercial market - albeit, on a very limited basis.

You can use functional patterns in Java though, quite apart from the ones in version 8: For example, my methods almost always return something; and it feels odd to me to write ones that return void.

But that probably has more to do with the way I was taught C - and I don't think anyone would argue that C is a procedural language.

HIH

Winston
 
chris webster
Bartender
Posts: 2407
33
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Grega

You might like to check out some of the information in our Getting started with Functional programming thread - it's a little old now but most of the material is still valid.

I tend to think of OOP as an imperative style of programming where you combine data structures and functions to create an object, so a method is like a function that is attached to a specific object instance. Of course this is very simplistic and there is a lot more to OOP than this!

Functional programming treats functions as independent objects, so they can be passed around separately e.g. you can pass a function as an argument into another function, or return a function from a function, and so on. This shifts the emphasis from objects-as-data-with-behaviour (OOP) to functions-plus-data (FP) i.e. you have lots of functions that may be applied to different types of data. In many functional programming languages, we often use a relatively small set of common data abstractions e.g. various Collections, and have a lot of common functions that can be applied to these data structures e.g. map, reduce, filter etc. You can combine these functions with your own custom functions to create pipelines of processing that transform your data to meet your needs. This encourages a declarative style of programming i.e. you don't write lots of imperative for-loops, but you apply different functions as transformations to your data pipeline to produce the desired results.

"Pure" functions always produce the same result for the same inputs and have no side effects (such as I/O or writing to a DB etc), and the usual goal is to write most of your code as pure functions and limit the side effects as far as possible. Of course, a program that has no side effects (e.g. no I/O) will not do anything useful, but it's important to know where the side effects occur so you know how to manage them and control errors etc.

Another common feature of functional programming languages is immutable data. OOP tends to rely on changing the state of an object - all those "setters" and other methods that change the internal state. This makes it hard to reason about the internal state of an object if somebody else might be changing it at the same time, especially in large multi-threaded systems. FP languages typically have immutable data by default, so these problems do not arise: once you've created an "object" it always stays the same, so if you need to change it, you actually create a new one with different state, which means your new version will not affect anybody who is still using the old one. This makes it much easier to reason about your object, which is why using immutable data where possible is also recommended in Java programming.

This immutability is also one of the reasons why FP languages like Scala are becoming popular for Big Data and concurrent systems.

As for programming languages, Python has some nice functional features e.g. functions can be treated as independent objects and Python supports comprehensions to transform collections of data, but Python also has mutable state by default. Python is not a fully functional programming language, but it is used with FP techniques e.g. the Apache Spark processing engine is written in Scala but has a powerful Python API which has a lot of FP features.

Scala is a hybrid FP/OOP language i.e. it supports all the expected FP features (e.g. variables are immutable by default, functions are first-class objects, etc), but it is also object-based with inheritance and polymorphism etc. This means you can choose to write Scala in a fairly Java-like OOP style, or you can go to the other extreme and write it in a fairly pure functional style - or you can combine both approaches e.g. Scala's case classes are a nice feature that looks OO but is actually designed for functional programming with pattern-matching.

Clojure is based on Lisp, and is a pretty pure FP language with dynamic typing, while Haskell has static types and is famous for being one of the "purest" functional programming languages.
 
Pierre-Yves Saumont
Author
Ranch Hand
Posts: 98
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no definitive answer to this question, because there is no single definition of Functional Programming. And there is no "Functional language" either. I use to say that some languages are more functional friendly than others. Haskell is certainly more functional friendly than Java, but friendliness is mostly subjective.

The truth (well my truth!) is that if the definition of a functional language is "a language which always acts functionally and never let you do things that are not functional", Haskell is not a functional language. For example, applying the head function to an empty list will throw an error. This is not functional at all. In my opinion, in a functional language, the head method should not exist, or should return a Maybe.

By the way, the functional paradigm is in no way to be opposed to the object oriented programming. What may be opposed to functional programming is rather imperative programming. In this paradigm, the programmers says what it want to be done, and how and when he wants it to be done. In other word, he writes a succession of computation mutating a state that is carried along in the process. In the functional paradigm, the programmer write functions that take an argument and return a value. Java programmers may easily write functions. Methods that take an argument and return a value without any other observable effect are indeed pure functions. The fact that you can not pass methods as arguments to other methods is irrelevant. And by the way, you can. So, Java is not a functional language (Haskell neither), but you may write functional programs with it.

The fact is that you can write functional programs much more easily in Haskell is certain, but this does not make Haskell a purely functional language, nor does it make Java unsuitable for functional programming.

Functional programs written in Java are much more verbose that in Haskell, but the situation is much better now with lambdas and method references. But I have been doing functional programming for years with Java 6. (Not that I would like to do it again!)

Many functional constructs are missing in Java 8. But you may create them, and the fact that Java in an object oriented language helps you. This is what I explain in my book. In the end, you may build a functional library in Java that fulfill 90% of the needs. Or you can use an existing one. There are nonetheless things that you can't do. The lack of variance might be a problem for some. The lack of higher kinded types is what I miss the most. The lack of pattern matching is not a problem. It makes programs much more verbose, but we can deal with it. I miss syntactic sugar for tuples and function application, value types (coming in Java 10?) and some other details.

In conclusion, you can do functional programming in any language (even in assembly) but it is easier with some than with others. But you surely can do it in Java, and it's fun.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!