I often find developers use the terms functional language and dynamic language together, and wonder why are they always being put together.
What are the differences between them? Can a language be both dynamic and functional? Do they complement each other? Why do we need them anyway?
I'm a C# programmer and don't yet understand this whole dynamic/functional thing (C# is going to have some dynamic features in ver 4. Will it also be functional? what's going on here?).
Thanks,
Abraham
To put it in a simple (but not accurate) answer
Dynamic languages are ones in which the Type (Name of the Class) is not as important as compared to its nemesis statically typed languages. A variable may have objects of different types assigned to it at any given point of time. Method invocations are resolved at run-time. This means you lose the benefits of static typing (compiler warnings) but simple methods turn generic - sort(list) works for a list of strings as well as list of ints. e.g. Ruby et. all
Functional languages value immutability. The programs are written in terms of bigger and bigger functions (usually bottom up). The concept of object state and mutability is frowned upon. A function in this context is self-sufficient (The term is Pure as per Wikipedia): everything it needs to produce output, lies in the input that it receives. It also produces no side-effects (unless it explicitly mentions it) and returns consistent output for a given input. This can lead to elegant code (see: fluent interfaces), where input data is pipelined through diff functions to produce the eventual output e.g. LISP et.all
However the boundaries are being muddied with languages picking up the best of all worlds... You could have a language which is both, one or neither.
e.g. predominantly static C# picking up lambda expressions in 3.0 and bringing in dynamic capabilities with 4.0
Dynamic typing, a type system, is orthogonal to 'functional', a programming paradigm.
Dynamic 'languages' are actually dynamically typed. This means that you don't have compile-time checking of your variable types.
Functional languages offer loads of support for e.g. lambda calculus - anonymous functions.
An example of a language that does dynamic typing, and supports anonymous functions: javascript. Ruby has some functional style support, too. And there are others.
Dynamic typing and functional programming are independent concepts. You can have either, neither or both in a language.
Static typing means that types of objects are known at compilation time. In dynamic typing they are known at runtime.
Functional programming means programming style where computation is done by evaluating functions while avoiding state changes. (example: you use recursion instead of for-loops, because a loop would need changing of a counter variable, etc.) This helps to avoid bugs and makes concurrent programming easier. Pure languages require you to program in functional style, others just enable it.
Example languages:
|----------------+---------+---------|
| | Dynamic | Static |
|----------------+---------+---------|
| Functional | LISP | Haskell |
| Not functional | PHP | Java |
|----------------+---------+---------|
Dynamic languages on the other hand are a broader concept. There is no exact definition, but usually the more features of the compiler are moved to the runtime, more dynamic the language is. This means that in dynamic languages you can usually evaluate expressions, change object structure etc. at runtime.
If you're interested in paradigms, the paper Programming Paradigms for Dummies: What Every Programmer Should Know covers them.
In functional programming, state is implicit - the program executes by calling functions which call other functions. In imperative programming and object oriented programming, state is explicit - you change the value of a variable or object's field.
In a way, functional and imperative systems can be seen as duals - what's fixed in one is a dynamic value in the other.
Closures - which trap some explicit, mutable state in an object which can be called as a function - sit somewhere between, being neither pure functional programming but not quite fully fledged objects; they are more like anonymous objects than functions.
'Dynamic languages' is vague term, usually meaning one of the following:
Dynamically Typed Languages - languages which delay determination of type to runtime, but the set of types is fixed. Examples are Smalltalk, Lisps, current Fortress implementations. Some otherwise statically typed languages also allow some dynamic type checks - Java, C#, C++ and Ada. ( it was a failed dynamic type cast from float to int in Ada that crashed Ariane 5 )
Languages with dynamic types - languages where new types can be created at runtime. The most popular is JavaScript. Because you have to run the program to determine the types, it's harder to make IDEs for these with type aware autocompletion.
Languages which are dynamically compiled - languages where new scripts can be compiled at runtime. This is true of bash, JSP, PHP and ASP at the page scale, and true for at a finer scale for lisps and JavaScript which support an 'eval' function which compiles and runs an expression.
Functional languages which are strongly typed often perform a large amount of type inference, so it's common for their programs to have less explicit typing than poorly implemented static typed languages. This can confuse people who have only seen the lack of explicit typing in dynamic typed languages into believing that type inference is the same as dynamic typing.
xtofl has already offered a good overall picture. I can speak to the C# point.
C# has been becoming easier to work with in a functional way for a while now:
C# 2 introduced anonymous methods, which made it easier to create delegates which used state which was otherwise local to a method
C# 3 introduced lambda expressions which are mostly like anonymous methods but even more compact
LINQ support in both C# 3 and .NET 3.5 made it easier to query data in a functional way, chaining together predicates, projections etc
None of the C# 4 features directly contributes to functional programming IMO, although named arguments and optional parameters may make it easier to create/use immutable types, which is one of the biggest features missing from the functional picture IMO.
(There are other things functional languages often have, such as pattern matching and more impressive type inference, but you can write a lot of functional-style code reasonably easily in C#.)
C# 4 will gain some dynamic abilities through the dynamic type (which itself is effectively a static type you can do anything with). This will be somewhat "opt in" - if you never use the dynamic type, C# will still be fully static language. There's no language support for responding dynamically, but the DLR has support for this - if you implement IDynamicMetaObjectProvider or derive from DynamicObject, for example, you can add dynamic behaviour.
I would say that C# isn't becoming a functional language or a dynamic language, but one in which you can code in a functional style and interoperate with dynamic platforms.
Related
I am aware that declarative programming just passes the input and expects the output without stating the procedure how it is done. In functional programming, is a programming paradigm, which takes an input and returns an output. When I checked the Higher order functional programming, we pass a function to map/reduce, which does not reveal the procedure how it is done. So is higher order functional programming and declarative programming the same thing??
Short answer: No.
Wikipedia defines declarative programming as:
In computer science, declarative programming is a programming
paradigm - a style of building the structure and elements of computer
programs - that expresses the logic of a computation without describing
its control flow.
Or to state it a bit boldly: "Say what you want, not how you want it.".
This is thus in contrast with imperative programming languages where a program is seen as a set of instructions that are done one after another. The fact that map, etc. do not reveal the procedure does not make it declarative: one can use a lot of C libraries that are proprietary and do not allow you to inspect the source code. That however, does not mean that these are declarative.
The definition of functional programming on the other hand is:
In computer science, functional programming is a programming paradigm
- a style of building the structure and elements of computer programs - that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative
programming paradigm, which means programming is done with expressions
or declarations instead of statements.
Based on these definitions one could say that functional programming is a subset of declarative programming. In a practical sense however if we follow the strict definitions, no programming language nowadays is purely, and un-ambigously declarative or functional. One can however say that Haskell is more declarative than Java.
Declarative programming is usually considered to be "safer" since people tend to have trouble managing side-effects. A lot of programming errors are the result of not taking all side effects into account. On the other hand it is hard to
design a language that allows a programmer to describe what he wants without going into details on how to do it;
implement a compiler that will generate - based on such programs - an efficient implementation; and
some problems have inherent side effects. For instance if you work with a database, a network connection or a file system, then reading/writing to a file for instance is supposed to have side effects. One can of course decide not to make this part of the programming language (for instance many constraint programming languages do not allow these type of actions, and are a "sub language" in a larger system).
There have been several attempts to design such language. The most popular are - in my opinion - logic programming, functional programming, and constraint programming. Each has its merits and problems. We can also observe this declarative approach in for instance databases (like SQL) and text/XML processing (with XSLT, XPath, regular expressions,...) where one does not specify how a query is resolved, but simply specifies through for instance the regular expression what one is looking for.
Whether a programming language is however declarative, is a bit of a fuzzy discussion. Although programming languages, modeling languages and libraries like Haskell, Prolog, Gecode,... have definitely made programming more declarative, these are probably not declarative in the most strict sense. In the most strict sense, one should think that regardless how you write the logic, the compiler will always come up with the same result (although it might take a bit longer).
Say for instance we want to check whether a list is empty in Haskell. We can write this like:
is_empty1 :: [a] -> Bool
is_empty1 [] = True
is_empty1 (_:_) = False
We can however write it like this as well:
is_empty2 :: [a] -> Bool
is_empty2 l = length l == 0
Both should give the same result for the same queries. If we however give it an infinite list, is_empty1 (repeat 0) will return False whereas is_empty2 (repeat 0) will loop forever. So that means that we somehow still wrote some "control flow" into the program: we have defined - to some extent - how Haskell should evaluate this. Although lazy programming will result in the fact that a programmer does not really specify what should be evaluated first, there are still specifications how Haskell will evaluate this.
According to some people, this is the difference between programming and specifying. One of my professors once stated that according to him, the difference is that when you program something, you have somehow control about how something is evaluated, whereas when you specify something, you have no control. But again, this is only one of the many definitions.
Not entirely, functional programming emphasises more on what to compute rather than how to compute. However, there are patterns available in functional programming that are pretty much control flow patterns you would commonly associate with declarative programming, take for example the following control flow:
let continue = ref true in
while !continue do
...
if cond then continue := false
else
...
done
Looks familiar huh? Here you can see some declarative constructs but this time round we are in more control.
Functional programming attempts to ensure freedom from side-effects when invoking functions. Passing a mutable object as a parameter that is NOT returned gives a developer the ability to modify a non-returned object. In other words, side-effects are possible. If you pass primitive or immutable types, you are free from this extra layer of complexity when reasoning about a program. So does good Functional Programming practice dictate anything when you have the choice between passing a mutable object vs passing primitive types?
I am aware of the following properties of PURE functional programming:
If all your types are immutable, it doesn't matter whether they are object types
The mutable object cannot exist outside the scope where it is expected to be mutated
but in reality when you are dealing with huge code bases that have existed prior to Functional Programming gaining a newfound respect, you will often be dealing with data structures that have no corresponding immutable representation, and code will be a mixture of functional and imperative styles.
(Background - I am exposing C++ logic via Java Native Interface and am wondering when to avoid passing objects, but I'm not looking for an answer that directly applies to this use case. I just want some help applying good programming practice in a situation such as this)
I think the only thing that functional programming has to say about this matter is that you should ideally wrap all impure stuff that you expose, in a monad, such as the famous IO monad.
But this is probably too radical for your users.
Over at http://diditwith.net, I see that, in F#, it isn't strictly necessary to pass out parameters to a function that otherwise requires them. The language will auto-magically stuff the result and the output parameter into a tuple. (!)
Is this some kind of side effect (pardon the pun) of the general mechanics of the language, or a feature that was specifically articulated in the F# specification and deliberately programmed into the language?
It's an awesome feature, and if it was expressly put into F#, then I'm wondering what other nuggets of gold like this are lurking within the language, because I've pored over dozens of web pages and read through three books (by D. Syme, T. Petricek, and C. Smith) and I hadn't seen this particular trick mentioned at all.
EDIT: As Mr. Petricek has responded, below, he does mention the feature in at least two places in his book, Real-World Functional Programming. My bad.
This is not a side-effect of some other, more general, mechanism in the F# language.
It has been added specifically for this purpose. .NET libraries often return multiple values by adding out (or ref) parameters at the end of the method signature. In F#, returning multiple values is done by returning tuple, so it makes sense to turn the .NET style into the typical F# pattern.
I don't think F# does many similar tricks, especially when it comes to interoperability, but you can browse through some of the handy snippets here and here.
(I quickly checked and Real-World Functional Programming mentions the trick briefly on pages 88 and 111.)
This is a specific feature to make interop with .NET methods more pleasant - all trailing out parameters can instead be treated as part of the return value (but note that this only affects trailing out parameters, so a method with the C# signature like void f(out int i, int j) can't be called this way).
Arguably, out parameters are just a way to work around the lack of tuples in .NET 1.0, anyway. It seems likely that many methods that use them would be written differently if they targeted later versions of the framework (by using Nullable<_> types or tuples as return types).
I read somewhere where rich hickey said:
"I think continuations might be neat
in theory, but not in practice"
I am not familiar with clojure.
1. Does clojure have continuations?
2. If no, don't you need continuations? I have seen a lot of good examples especially from this guy. What is the alternative?
3. If yes, is there a documentation?
When talking about continuations, you’ll have to distinguish between two different kinds of them:
First-class continuations – Continuation-support that is deeply integrated in the language (Scheme or Ruby). Clojure does not support first-class continuations.
Continuation-passing-style (CPS) – CPS is just a style of coding and any language supporting anonymous functions will allow this style (which applies to Clojure too).
Examples:
-- Standard function
double :: Int -> Int
double x = 2 * x
-- CPS-function – We pass the continuation explicitly
doubleCPS :: Int -> (Int -> res) -> res
doubleCPS x cont = cont (2 * x)
; Call
print (double 2)
; Call CPS: Continue execution with specified anonymous function
double 2 (\res -> print res)
Read continuation on Wikipedia.
I don’t think that continuations are necessary for a good language, but especially first-class continuations and CPS in functional languages like Haskell can be quite useful (intelligent backtracking example).
I've written a Clojure port of cl-cont which adds continuations to Common Lisp.
https://github.com/swannodette/delimc
Abstract Continuations
Continuations are an abstract notion that are used to describe control flow semantics. In this sense, they both exist and don't exist (remember, they're abstract) in any language that offers control operators (as any Turing complete language must), in the same way that numbers both exist (as abstract entities) and don't exist (as tangible entities).
Continuations describe control effects such as function call/return, exception handling, and even gotos. A well founded language will, among other things, be designed with abstractions that are built on continuations (e.g., exceptions). (That is to say, a well-founded language will consist of control operators that were designed with continuations in mind. It is, of course, perfectly reasonable for a language to expose continuations as the only control abstraction, allowing users to build their own abstractions on top.)
First Class Continuations
If the notion of a continuation is reified as a first-class object in a language, then we have a tool upon which all kinds of control effects can be built. For example, if a language has first-class continuations, but not exceptions, we can construct exceptions on top of continuations.
Problems with First-Class Continuations
While first-class continuations are a powerful and useful tool in many cases, there are also some drawbacks to exposing them in a language:
Different abstractions built on top of continuations may result in unexpected / unintuitive behavior when composed. For example, a finally block might be skipped if I use a continuation to abort a computation.
If the current continuation may be requested at any time, then the language run-time must be structured so that it is possible to produce some data-structure representation of the current continuation at any time. This places some degree of burden on the run-time for a feature which, for better or worse, is often considered "exotic". If the language is hosted (such as Clojure is hosted on the JVM), then that representation must be able to fit within the framework provided by the hosting platform. There may also be other features a language would like to maintain (e.g., C interop) which restrict the solution space. Issues such as these increase the potential of an "impedence mismatch", and can severely complicate development of a performant solution.
Adding First-Class Continuations to a Language
Through metaprogramming, it is possible to add support for first-class continuations to a language. Generally, this approach involves transforming code to continuation-passing style (CPS), in which the current continuation is passed around as an explicit argument to each function.
For example, David Nolen's delimc library implements delimited continuations of portions of a Clojure program through a series of macro transforms. In a similar vein, I have authored pulley.cps, which is a macro compiler that transforms code into CPS, along with a run-time library to support more core Clojure features (such as exception handling) as well as interop with native Clojure code.
One issue with this approach is how you handle the boundary between native (Clojure) code and transformed (CPS) code. Specifically, since you can't capture the continuation of native code, you need to either disallow (or somehow restrict) interop with the base language or place a burden on the user of ensuring the context will allow any continuation they wish to capture to actually be captured.
pulley.cps tends towards the latter, although some attempts have been made to allow the user to manage this. For instance, it is possible to disallow CPS code to call into native code. In addition, a mechanism is provided to supply CPS versions of existing native functions.
In a language with a sufficiently strong type system (such as Haskell), it is possible to use the type system to encapsulate computations which might use control operations (i.e., continuations) from functionally pure code.
Summary
We now have the information necessary to directly answer your three questions:
Clojure does not support first-class continuations due to practical considerations.
All languages are built on continuations in the theoretical sense, but few languages expose continuations as first-class objects. However, it is possible to add continuations to any language via, e.g., transformation into CPS.
Check out the documentation for delimc and/or pulley.cps.
Is continuation a necessary feature in a language?
No. Plenty of languages don't have continuations.
If no, dont you need continuations? I have seen a lot of good examples especially from this guy. What is the alternative?
A call stack
A common use of continuations is in the implementation of control structures for: returning from a function, breaking from a loop, exception handling etc. Most languages (like Java, C++ etc) provide these features as part of the core language. Some languages don't (e.g: Scheme). Instead, these languages expose continuatiions as first class objects and let the programmer define new control structures. Thus Scheme should be looked upon as a programming language toolkit, not a complete language in itself.
In Clojure, we almost never need to use continuations directly, because almost all the control structures are provided by the language/VM combination. Still, first class continuations can be a powerful tool in the hands of the competent programmer. Especially in Scheme, continuations are better than the equivalent counterparts in other languages (like the setjmp/longjmp pair in C). This article has more details on this.
BTW, it will be interesting to know how Rich Hickey justifies his opinion about continuations. Any links for that?
Clojure (or rather clojure.contrib.monads) has a continuation monad; here's an article that describes its usage and motivation.
Well... Clojure's -> implements what you are after... But with a macro instead
In my second year of University we were "taught" Haskell, I know almost nothing about it and even less about functional programming.
What is functional programming, why and/xor where would I want to use it instead of non-functional programming and am I correct in thinking that C is a non-functional programming language?
One key feature in a functional language is the concept of first-class functions. The idea is that you can pass functions as parameters to other functions and return them as values.
Functional programming involves writing code that does not change state. The primary reason for doing so is so that successive calls to a function will yield the same result. You can write functional code in any language that supports first-class functions, but there are some languages, like Haskell, which do not allow you to change state. In fact, you're not supposed to make any side effects (like printing out text) at all - which sounds like it could be completely useless.
Haskell instead employs a different approach to IO: monads. These are objects that contain the desired IO operation to be executed by your interpreter's toplevel. At any other level they are simply objects in the system.
What advantages does functional programming provide? Functional programming allows coding with fewer potentials for bugs because each component is completely isolated. Also, using recursion and first-class functions allows for simple proofs of correctness which typically mirror the structure of the code.
What is functional programming
There are two different definitions of "functional programming" in common use today:
The older definition (originating from Lisp) is that functional programming is about programming using first-class functions, i.e. where functions are treated like any other value so you can pass functions as arguments to other functions and function can return functions among their return values. This culminates in the use of higher-order functions such as map and reduce (you may have heard of mapReduce as a single operation used heavily by Google and, unsurprisingly, it is a close relative!). The .NET types System.Func and System.Action make higher-order functions available in C#. Although currying is impractical in C#, functions that accept other functions as arguments are common, e.g. the Parallel.For function.
The younger definition (popularized by Haskell) is that functional programming is also about minimizing and controlling side effects including mutation, i.e. writing programs that solve problems by composing expressions. This is more commonly called "purely functional programming". This is made possible by wildly different approaches to data structures called "purely functional data structures". One problem is that translating traditional imperative algorithms to use purely functional data structures typically makes performance 10x worse. Haskell is the only surviving purely functional programming language but the concepts have crept into mainstream programming with libraries like Linq on .NET.
where would I want to use it instead of non-functional programming
Everywhere. Lambdas in C# have now demonstrated major benefits. C++11 has lambdas. There's no excuse not to use higher-order functions now. If you can use a language like F# you'll also benefit from type inference, automatic generalization, currying and partial application (as well as lots of other language features!).
am I correct in thinking that C is a non-functional programming language?
Yes. C is a procedural language. However, you can get some of the benefit of functional programming by using function pointers and void * in C.
May be worth checking out this article on F# "101" on CoDe Mag recently posted.
Also, Dustin Campbell has a great blog where he has posted many articles on his adventures on getting up to speed with F#..
I hope you find these useful :)
EDIT:
Also, just to add, my understanding of functional programming is that everything is a function, or parameters to a function, rather than instances/stateful objects.. But I could be wrong F# is something I am dying to get in to but just dont have the time! :)
John the Statistician's example code does not show functional programming, because when you're doing functional programming, the key is that the code does NO ASSIGNMENTS ( record = thingConstructor(t) is an assignment), and it has NO SIDE EFFECTS (localMap.put(record) is a statement with a side effect). As a result of these two constraints, everything that a function does is fully captured by its arguments and its return value. Rewriting the Statistician's code the way it would have to look, if you wanted to emulate a functional language using C++:
RT getOrCreate(const T thing,
const Function<RT<T>> thingConstructor,
const Map<T,RT<T>> localMap) {
return localMap.contains(t) ?
localMap.get(t) :
localMap.put(t,thingConstructor(t));
}
As a result of the no side-effects rule, every statement is part of the return value (hence return comes first), and every statement is an expression. In languages that enforce functional programming, the return keyword is implied, and the if statement behaves like C++'s ?: operator.
Also, everything is immutable, so localMap.put has to create a new copy of localMap and return it, instead of modifying the original localMap, the way a normal C++ or Java program would. Depending on the structure of localMap, the copy could re-use pointers into the original, reducing the amount of data that has to be copied.
Some of the advantages of functional programming include the fact that functional programs are shorter, and it is easier to modify a functional program (because there are no hidden global effects to take into account), and it is easier to get the program right in the first place.
However, functional programs tend to run slowly (because of all the copying they have to do), and they don't tend to interact well with other programs, operating system processes, or operating systems, which deal in memory addresses, little-endian blocks of bytes, and other machine-specific, non-functional bits. The degree of noninteroperability tends to be inversely correlated with the degree of functional purity, and the strictness of the type system.
The more popular functional languages have really, really strict type systems. In OCAML, you can't even mix integer and floating-point math, or use the same operators (+ is for adding integers, +. is for adding floats). This can be either an advantage or a disadvantage, depending on how highly you value the ability of a type checker to catch certain kinds of bugs.
Functional languages also tend to have really big runtime environments. Haskell is an exception (GHC executables are almost as small as C programs, both at compile-time and runtime), but SML, Common Lisp, and Scheme programs always require tons of memory.
Yes you are correct in thinking that C is a non-functional language. C is a procedural language.
I prefer to use functional programming to save myself repeated work, by making a more abstract version and then using that instead. Let me give an example. In Java, I often find myself creating maps to record structures, and thus writing getOrCreate structures.
SomeKindOfRecord<T> getOrCreate(T thing) {
if(localMap.contains(thing)) { return localMap.get(thing); }
SomeKindOfRecord<T> record = new SomeKindOfRecord<T>(thing);
localMap = localMap.put(thing, record);
return record;
}
This happens very often. Now, in a functional language I could write
RT<T> getOrCreate(T thing,
Function<RT<T>> thingConstructor,
Map<T,RT<T>> localMap) {
if(localMap.contains(thing)) { return localMap.get(thing); }
RT<T> record = thingConstructor(thing);
localMap = localMap.put(thing,record);
return record;
}
and I would never have to write a new one of these again, I could inherit it. But I could do one better than inheriting, I could say in the constructor of this thing
getOrCreate = myLib.getOrCreate(*,
SomeKindOfRecord<T>.constructor(<T>),
localMap);
(where * is a kind of "leave this parameter open" notation, which is a sort of currying)
and then the local getOrCreate is exactly the same as it would have been if I wrote out the whole thing, in one line, with no inheritance dependencies.
If you are looking for a good text on F#
Expert F# is co-written by Don Syme. Creator of F#. He worked on generics in .NET specifically so he could create F#.
F# is modeled after OCaml so any OCaml text would help you learn F# as well.
I find What Is Functional Programming? to be useful
Functional programming is about writing pure functions, about removing
hidden inputs and outputs as far as we can, so that as much of our
code as possible just describes a relationship between inputs and
outputs.
Prefer explicit when param
public Program getProgramAt(TVGuide guide, int channel, Date when) {
Schedule schedule = guide.getSchedule(channel);
Program program = schedule.programAt(when);
return program;
}
over
public Program getCurrentProgram(TVGuide guide, int channel) {
Schedule schedule = guide.getSchedule(channel);
Program current = schedule.programAt(new Date());
return current;
}
A functional language is actively hostile to side-effects. Side-effects are complexity and complexity is bugs and bugs are the devil. A functional language will help you be hostile to side-effects too.