I then asked him if he could name an example, which he couldn't. I'm guessing that's because there are none, (feel free to prove me wrong) but why is that? Education among developers (or lack thereof)? Lack of performant implementations? No significant advantage? Solution looking for a problem?

It is an interesting question.

Given that both imperative (FORTRAN) and functional (LISP) came on the scene at about the same time (very early 1950) the question can be reduced to "why is the use of imperative programming so much more widespread than functional programming?"

I think there are two possible answers.

Firstly, imperative languages were effectively "higher level" versions of the machine code used to program computers at the time when they were invented, whereas functional languages were effectively an implementation of a fairly obscure branch of mathematics (Church's lambda calculus, which McCarthy was teaching at the time). Thus, imperative programming came naturally to the "old hands" then working the altar of big iron and functional programming limited to a few interest courses in better universities. When CODASYL was struck to determine the way forward for the next several decades, it consisted mostly of "old hands." Thus the foundation for the supremacy of imperative programming languages was laid.

A second possibly answer is that imperative languages are easier for Joe Bitpack to pick up: you don't need to understand about partially-enumerable functions to understand "make this box blue". Since most pointy-haired bosses see all code monkeys as interchangeable, grabbing the first guy to apply who has the right TLAs on his CV and can wipe the drool off his chin most of the time is seen as cost-effective. Natural selection in such an environment gives the reproductive advantage to a paradigm that does not tire out the lips as quickly.

Be thankful. When I was in university I was told that all the old languages were dead and everything would be programmed using 5th-generation languages like Prolog. I am sure my flying car is programmed using Prolog today.

A second possibly answer is that imperative languages are easier for Joe Bitpack to pick up: you don't need to understand about partially-enumerable functions to understand "make this box blue".

Almost any real-world problem that needs to be encoded is nothing remotely close to pure. While it can be converted into mathematical form, it won't reduce to a nice equation.

Consider a very trivial thing - clicking on a button. Windows feels different from Linux or Mac UIs. Even though point-in-rect math is exactly the same, Windows has a few extra checks looking something like this: "if user hovered over second--to-last item for more than 1600ms then accept +3 pixels to left, unless there are less than 3 items in menu or there is a separator and only if US or UK English is selected, under Germanic locales adjust border to +5 and for LTR IME have border on left, but also adjust left window offset by 4."

And these details are the difference between software worth billions and college projects flooding open source repositories. The code above does not come from deep mathematical derivation but from user testing over period of years in real world situations.

Be thankful. When I was in university I was told that all the old languages were dead and everything would be programmed using 5th-generation languages like Prolog. I am sure my flying car is programmed using Prolog today.[/quote]

A lot of business actually is, just not in the way it was imagined.

UX and A/B testing, applied on everything from trivial UIs to business processes is the 5th gen language. It's not automated, but it's how, for example, Google, Facebook, most of newer games work. Programmers no longer make decisions no more than they do in original button click question. They merely shape the data they gather. The syntax this is done in is mostly inconsequential.

Prolog was about: "Is X human?". Development today is: "Will changing button to blue improve revenue?". Applied AI is not only in use today, but is just about only profitable programming venue left, outside of monopolies. And this approach is absurd. People start with some dumb app, then follow the flow into profitability, never being any the wiser as to what or why they are doing it.

We are living in the future.

Andrew111, check out SWIG. I haven't had an opportunity to use it yet, but it looks like a solid project for auto-generating wrappers. A quick check shows that they support Racket.

[quote name='andrew111' timestamp='1324266690' post='4895176']
The disadvantages are that you have to write interfaces to c shared libraries to do anything useful, e.g. latest version of opengl, physics, sound, window etc. Though some of the other lisps might have bindings for those things already (I know common lisp does, but I prefer scheme).

I'm currently in the process of writing a library that auto generates bindings from c header files (nearly complete), it uses macros so that you just make a module and call a macro from my library which when compiled will auto generate the bindings for you.

[/quote]
Thanks! I'd heard of it but had totally forgotten about it.

I did a mapgen in F# once as a 'real' project since the problem fit the language fairly nicely and it could integrate with the rest of the C# game. I don't remember really how it went. Probably not so well given my inexperience with F# at the time.

In general, it's a solution looking for a problem. People, even programmers, just don't think in that sort of 'cascading series of functions' manner; certainly not for anything sizable.

I did a mapgen in F# once as a 'real' project since the problem fit the language fairly nicely and it could integrate with the rest of the C# game. I don't remember really how it went. Probably not so well given my inexperience with F# at the time.

In general, it's a solution looking for a problem. People, even programmers, just don't think in that sort of 'cascading series of functions' manner; certainly not for anything sizable.

Well, referential transparency and deep immutability are quite generally useful tools in my opinion that deserve to be used a lot more. Tools, that is, that I would wish to be able to opt into whenever I want, instead of getting them shoved down my throat, after which I have to take a doctorate in CS to relearn how to print to the command line using monad-magic.

I am quite eagerly waiting for D 2.0 to mature. It is still buggy at present, but it has the right idea: being able to mark functions as pure, and being able to declare data as deeply immutable. That, plus functions as first class citizens, is basically all I want from the functional world.

On an unrelated note, I heartily despise the terseness of most functional languages. I dont care if you can reduce the syntax of your language to lambda-calculus, I want to be able to see the structure of my code at a glance. I think python has the right idea there. Make whitespace a rule rather than a convention, ditch the damn braces, and use descriptive names for operators rather than cryptic symbols. Code gets read a lot more often than it is written, and writing do_useful_operation isnt really that much more work than writing '%^, but its a lot easier to parse to the human eye. Functional language designers seem to have all the wrong ideas here, that kind of hacker mentality which boils down to not realizing brainf*ck was never anything but an example of what not to do.

Keep in mind that Scheme is not a functional language -- It may prefer functional constructs and share some other features, but the macro system in Scheme and Lisp make it a very different beast, allowing you, essentially, to build up your own language moreso than with any other -- in fact, Scheme was created with the goal of taking that ability to its logical conclusion, wherein most of what you think is Scheme itself, is really just Scheme code running on the very core of Scheme itself. You can effectively build scheme into all sorts of paradigms.

Scheme and functional languages map pretty clearly to problems that are fundamentally a transformation -- though efficiency can be difficult. They tend also to map well to problems that can be defined with a declarative style (good functional APIs often read as declarative statements).

The graphics pipeline is essentially a functional one, so its something of a shame that the first high-level shader languages were modeled on C. In the earliest shader models, the C-like model actually broke down, though today the hardware is evolving upwards to meet the language model that was foisted upon it. Many shaders become exceedingly short if you remove all the cruft that's modeled after C.

Paging Associat0r. I repeat, Associat0r to the lounge forum, there is a thread here for you to ruin.

I used F# for one of my tech test. It uses C# / SlimDX for the graphics side while I used F# for the entire car dynamics module.
It was incredibly smooth, bug free and a very rewarding programming experience overall. The ability of F# to keep that "imperative door" open sort of makes you feel safe you'll never find yourself trapped in some pure functional nonsense lockdown, at the same time it gives you the challenge to implement it functionally.

It is incredible how true is the claim that once you get the thing to compile, you'll hardly need to debug it.. it sounds like a marketing slogan, it really isn't. You just switch around the development time, investing more time designing a functional solution to the problem (this might get better with experience) rather than chasing bugs later in the development stage.

Learning functional languages was one of the best thing that happened to me in the last 2 years of programming, the influence even in my production C++ is huge, and more and more of my classes are now immutable right from the start. I wish C++ added a "readonly" keyword just as C# did.

So I would say, regardless of its present or future use in production code, I would recommend learning functional languages to every programmer interested in an whole new approach to problem solving.

I used F# for one of my tech test. It uses C# / SlimDX for the graphics side while I used F# for the entire car dynamics module.
It was incredibly smooth, bug free and a very rewarding programming experience overall. The ability of F# to keep that "imperative door" open sort of makes you feel safe you'll never find yourself trapped in some pure functional nonsense lockdown, at the same time it gives you the challenge to implement it functionally.

It is incredible how true is the claim that once you get the thing to compile, you'll hardly need to debug it.. it sounds like a marketing slogan, it really isn't. You just switch around the development time, investing more time designing a functional solution to the problem (this might get better with experience) rather than chasing bugs later in the development stage.

Learning functional languages was one of the best thing that happened to me in the last 2 years of programming, the influence even in my production C++ is huge, and more and more of my classes are now immutable right from the start. I wish C++ added a "readonly" keyword just as C# did.

So I would say, regardless of its present or future use in production code, I would recommend learning functional languages to every programmer interested in an whole new approach to problem solving.

I'm curious, what does F# bring to the table over C# now with linq & lambdas? I haven't toyed with F# at all but i'm wondering what the craze is about as the few i've seen was things that were done before they were implemented in C# but now the same is available on both sides.

What does C# miss that F# has, in today's .NET 4 world?

I'm curious, what does F# bring to the table over C# now with linq & lambdas? I haven't toyed with F# at all but i'm wondering what the craze is about as the few i've seen was things that were done before they were implemented in C# but now the same is available on both sides.

What does C# miss that F# has, in today's .NET 4 world?

I don't consider myself an expert in F#. Being C# a very modern language I don't think there is a single thing that you can do with F# and you can't in C#. But the default assumptions are different, in C# you can make an immutable value by declaring it readonly, in F# it's just the opposite, you need to mark it "mutable" if you dont want immutability.. most, if not all, bugs in F# come from mutable values. so, in a way, you're marking yourself the places where anything can go wrong. So it is no what you can or cant do, but it is more about how the language "wants" you to use it and how the language drives you towards a certain style of solution.


Plus F#'s syntax is much more clean and simple.. if that's an added value. I hope MS will invest in better tools to navigate F#'s source code and improves intellisense with it.