Functional Programming Languages

[NickFitz]

What if I need to loop through that data you've shown on top and then inside the loop do some other look ups in some other arrays in order to calculate what I need...

The second highlighted bit of your post ("inside the loop") begs the question raised by the first ("What if I need to loop through that data"), and the first begs the fundamental question. (Note to knee-jerk pedants: I am in fact using "beg the question" correctly here.)

Why do you assume that the only way to process a set of data is by "looping through" it? Such an assumption betrays your inability - or refusal - to understand the nature of declarative programming. "Looping" is an implementation issue; one should merely need to state "For every member of the set S, apply the function F" (that's why it's called a "statement"). If the function F needs to consult the set T ("do some other look ups") in order to determine what to do with a given member of S, it can do so by applying the function G with the current member of S and the related member of T as members of the set of sets to which G should apply itself - or as "arguments" to G, if you prefer that terminology (although arguments to a function are still a set of sets, whatever you may call them).

Note that the application of a function to a set does not imply or require looping of any kind. It is merely a declaration that all members of the set should be transformed by said function. Hence the terms "declarative" and "functional" programming (although the set of functional languages is a subset of the set of declarative languages, and a number of programming languages that are members of the set of functional languages are also members of one or more other sets, such as the set of object-oriented languages, the set of imperative languages, and the set of prototype-based languages).

Your point about optimised code for a given architecture is a worthwhile one. However, you seem to be missing the point that declarative (and functional) languages exist to provide a level of conceptual abstraction that makes for more efficient programming, where the word "efficient" is used in relation to lines of code produced over time, debuggability (horrid neologism - my apologies to the English language) of such code on its initial creation, readability and understandability of such code for maintenance purposes, debuggability of such code for maintenance purposes, and - guess what? - optimisation of such code at runtime. Tail-call optimisation means that some function that is represented with clarity by a recursive definition in the high-level source will often, even usually, be resolved at runtime into... well, lookyhere: a tight loop that fits into the processor's instruction cache

[NotAllThere]

... and the first begs the fundamental question. (Note to knee-jerk pedants: I am in fact using "beg the question" correctly here.)

That'd be "beggars the question" then... and "Debuggability" - "ease of debugging" would do.

What many people forget - programmers and non-programmers alike - is that performance of the program isn't usually a critical factor. The users don't care if they have response times of 0.01s or 0.00001 s. Processing power and memory is cheap, so in most cases you can throw power at it. (Unless you've implemented an NP algorithm). While the initial development of a program is a significant factor in the cost of development, what really affects TCO is maintenance - i.e. fixing problems, and making enhancements. So a well-written program takes longer, but ends up being cheaper. And if you have used a language where it easy to debug and make changes with minimal effect on other parts of the system, that also reduces the expense. Otherwise, we'd all still be programming in assembler.

[threaded]

Tail-call optimisation means that some function that is represented with clarity by a recursive definition in the high-level source will often, even usually, be resolved at runtime into... well, lookyhere: a tight loop that fits into the processor's instruction cache

And if you 'Curry' your code, at the bottom you end up with a set of 'Pure functions', with that you'll find a surprising amount of stuff just ends up in caches, and hence a database. So you don't even need to keep running loops, usually after the first run it'll become a straight lookup.

[d000hg]

one should merely need to state "For every member of the set S, apply the function F"

I've worked on a language with that syntax... anyone heard of G2?

[AtW]

What many people forget - programmers and non-programmers alike - is that performance of the program isn't usually a critical factor. The users don't care if they have response times of 0.01s or 0.00001 s.

Most programmers work on simple problems that even VB could solve years ago, yet alone now.

Proper programmers work on massive datasets like web graph with trillions of edges

[d000hg]

I thought where you are from had good education about computer science - Eastern Europe dominates competitive programming/algorithm/math contests doesn't it?

[AtW]

I thought where you are from had good education about computer science

You were not wrong - I've got the best kind of computer science edukation - self taught ability to solve complex real world problems.

[Churchill]

I thought where you are from had good education about computer science - Eastern Europe dominates competitive programming/algorithm/math contests doesn't it?

Only in Soviet Era! Now major export of Russia is meerkats and other small furry face mammals.

Ooops, wrong login...

Ok, own up, who's changed AtW's password?

[AleksandrMeerkat]

Only in Soviet Era! Now major export of Russia is meerkats and other small furry face mammals.

[threaded]

This might help you AtW

As software becomes more and more complex, it is more and more
important to structure it well. Well-structured software is easy to write,
easy to debug, and provides a collection of modules that can be re-used
to reduce future programming costs. Conventional languages place con-
ceptual limits on the way problems can be modularised. Functional lan-
guages push those limits back. In this paper we show that two features of
functional languages in particular, higher-order functions and lazy eval-
uation, can contribute greatly to modularity. As examples, we manipu-
late lists and trees, program several numerical algorithms, and implement
the alpha-beta heuristic (an algorithm from Artificial Intelligence used in
game-playing programs). Since modularity is the key to successful pro-
gramming, functional languages are vitally important to the real world.