sdetoni wrote:I still fail to see how functional programming is any better than normal C/Java etc type languages. You may condense your program/problem smaller, but in doing so add extra complexity to the syntax of the language. While the other hand languages like C have a small and elegant syntax (can't say the same for C++ though) but its abilities are great.
Functional programming has nothing to do with the syntax. Haskell's syntax is enigmatic and offputting, as is Lisp's to a lesser degree. The problem is that functional programing languages have historically been developed by mathematicians so they tend to be a bit twisted.
Javascript, Lua and Ruby all allow functional programming to a reasonable degree. Anything with a flexible syntax and lambda. But having said that, I work with a custom imperative language with a very readable BASIC-like syntax and structure that translates almost directly into bytecode - about as far from a functional programming language as you can get - and like I've said before, writing in a quasi-functional style helps me to write clear, bug-free code.
If you want to write your program that looks more like some made up math code as oppose to simple logic, data flow, then more power to you. I prefer to be able to understand a function's program/data flow as oppose to decrypting code.
The difference between the functional style and the imperative style is that with the functional style you make the implementation as abstract as possible, stick with the logic, then work your way down only if necessary. Once the logic is sound then the rest of the program will follow naturally and quickly. If you work in a purely functional style then you can actually prove mathematically that a program will do what you intend it to.
If you're writing a sort algorithm, you don't want to be mucking about with memory allocation or how you're going to insert numbers into a sorted array - you just want to work on the logic. If speed becomes a problem you can optimise it later and the structure should mean that refactoring is minimal.
Even a simple program in Haskell is confusing .... why does it need to be, what are you actually saving programming in Haskell instead of perl/C/java ... keystrokes?
Code: Select all
--
-- written in Haskell 1.4 (Hugs 1.4 for Windows)
-- by Michael Neumann
--
module Squares (main) where
square :: [Int] -> String
square [] = "\n"
square (h:t) = show (h*h) ++ " " ++ square t
main = putStr (square [1..10])
This code creates a Squares module containing two functions. square takes a list of integers ([Int]) and outputs a string (String). If square has no arguments (an empty list - []) it returns a newline, otherwise it calls the first list element h and dumps the rest in a list called t. It then formats the value of h*h into a string, adds a space and recursively adds the rest of the parsed list. When there's no numbers left the t list will be empty and so that's the end of the string. The main function dumps it to the output.
Where Haskell differs from other languages is that the list of numbers [1..10] is a purely abstract term - it's not actually an array of 10 integers, it's a description of an array where the elements only become real when needed. You can easily work over a list of millions of elements and not run out of stack space.
