ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
In the last few weeks, I've been learning some of the important points behind functional programming. It started because I wanted to learn the finer points of Emacs, and I wound up learning Lisp. I've enjoyed it so much I'm learning Haskell and OCaml now too. As I'm coming to understand closures, lambda functions, pattern matching, and lazy evaluation, there's something new I can't understand. Why isn't functional programming more popular?
For those not initiated into the functional programming circle, at its lowest level it basically boils down to this: your program is a single function, which calls other functions and uses the results to return a value. To facilitate this, a lot of new ideas were introduced, like lambda functions (functions without names) and lazy evaluation (things which are only evaluated when their results are needed). The ideas behind functional programming mean that completely different styles of programming are used to reach the goal.
The funny thing is that functional capabilities are creeping into imperative programming, too. Several modern dynamic popular languages have support for closures, generators, and first-class functions. But nobody really seems to acknowledge that these came from old functional languages. Even garbage collection, popularized largely by Java and the JVM, was invented for use in Lisp almost fifty years ago. While these features are certainly known and appreciated, the languages in which they originated seem somewhat forgotten.
But it's not just the raw features that make functional programming great. It's also the revelation that comes with recognizing the structure that code can take. Functional programming emphasizes recursion, which makes for very elegant and simple algorithms. Lisp allows you to write macros which expand to create new code, just as if you had written it yourself. In addition, Lisp uses the same structure to refer to both code and data; they can be manipulated in the same ways.
Of the languages I've cited above, Haskell is probably the most functional. Both OCaml and Lisp include imperative features, but still allow you the full power and flexibility of functional evaluation. And while no particular paradigm or language is best suited for everything, functional programming contributes useful and unique capabilities to the landscape of computer languages.
So I submit the question for discussion, to my esteemed comrades of LinuxQuestions: why isn't functional programming more popular?
I learnt ML at university and really enjoyed it (mostly cos all the geeks resented deviationg from OOP...) But after the set problems like concurrency are done, imagining how a fully functional application could exist within it was a total headf***. The format and layout of imperative languages lends itself so so much more towards a natural way to learn to program, and once in that mindset escaping to using functional ideas instead is just a nightmare. Programs which use user interaction and so forth do not feel able to be described by a single function and, whilst i didn't personally head furhter into this direction, making a proper application from something like ML did require breaking the ideology of the functional language.
In my experience, nice idea, made me smile and laugh at times, but not something i felt i could be useful with.
Well, really pure functional language (the?) - Haskell - is convenient only when it fits (and purely functional IO doesn't make too much trouble). By the way, it has no macros, and really no kill-feature.. LISP, OCaml, Erlang - they are used by those who can appreciate them and has tasks for their great capabilities. They are not designed for big turnover of randomly qualified programmers in project, so they cannot be too widespread. There are languages tuned to be excellent for their fans (LISP), languages tuned for one class of tasks (Erlang) and languages tuned to be popular (not to be very good in the first place, though there are strong sides - C++). By now there are languages created to be popular with much more functional bias - Ruby, for example, and there is also a C#-like language (needs mono as well..) Nemerle with full functional capabilities and macro language intended for use not to seem abuse.
Shortly: Mainstream needs less quality and more marketing. But if you have good quality you can do without mainstream.
Good points, all. I think two of the primary difficulties are exactly as you both mentioned: past experience and marketing. Recently I read Bruce Tate's Beyond Java, which essentially looks at Java's rise to popularity and tries to determine what the next big thing will be. The author mentions that while languages like Smalltalk and Lisp have the features that he thinks will really be in demand for future programmers, they have two flaws. The first is a history of academia, and the second is an almost complete lack of marketing. This helps show why these two languages (and nearly all languages somewhat within the functional paradigm) are not really accepted by the corporate community.
Another thing (going along with what acid_kewpie said) is that most programmers are taught imperative programming in school. I've been at two universities in the United States, one of them a pretty major engineering and technology school, and I'd not even heard of Lisp at the university until I took a language design course. Next semester I'm taking an AI course, where we will also be using Lisp, but these aren't required classes. Some (maybe most) students looking primarily to get out in the workforce and make some money probably aren't taking more high-level, more theoretical classes like that. Or if they are, they may not be taking them for the purpose of learning the art of computer science or how certain largely unknown ideas can benefit their community.
But I think that's a shame because if you want to be good at what you do, it's important to expose yourself to as much experience as you can. Some of the more powerful features gaining exposure today are language dynamicism and metaprogramming, ideas pioneered by the functional style. Programmers are really starting to embrace these ideas (for example, Rails gets its power and flexibility from Ruby's metaprogramming features) but unfortunately, for the most part it seems like they are unfamiliar with the environments which originally created these capabilities.
Part of it is because there is only a subset (perhaps a very small subset) of all programmers who are really striving to push their knowledge as far as possible. I often get over idealistic about the programmer community at large because of the work I see being done in open source, and forget that most people are just trying to make money so they can feed their families. I guess there's nothing wrong with that, but just think of what we could accomplish if we could successfully synthesize the powerful features of functional programming with the capabilities found in other paradigms.
I think we have pretty much all been brought up with our minds geared to the imperative style. But there's still a lot we can learn by coming to grips with the alternatives, and with the methodologies we can apply to our existing techniques to create better programs. However, if we don't go back and investigate the unsung environments that created these ideas, we're unfortunately unable to reap the full benefit of their progress. I wish these possibilities were enough to prompt more programmers to more thoroughly investigate the functional style and its capabilities.
Distribution: Debian Wheezy/Jessie/Sid, Linux Mint DE
I don't understand the heck what you are talking about with those functional langauges. But I see you are really excited by an idea which is not mainstream, and you want to put effort in something which is difficult, and only understood by a few. Not only that, but you want to start a discussion about it as well, and make people think about it. I appreciate that.
I think that is great. Too many on this world just walk blindly after what the majority does, just like lemmings.
We need people in this world who think differently. The only problem is that once something is widely accepted, it becomes mainstream, and then the mass market ...
If you think this reply is sarcastic, you are wrong. I am serious.
I'd say that if Cincom's VisualWorks (the actual Smalltalk vendor - they had booths at recent LinuxWorld expos) would come with a really great package, then it could catch on. And they are partly there. They have lots of documentation profssionaly done in PDF format. Their VisualWorks is free. They have lots of add-ons. But there are some drawbacks unless you're really into learning Smalltalk (which is great just to get a pure handle on OOP since Smalltalk is just about 100% OOP with only five keywords). Like the IDE, which is standard Smalltalk, doe snot let you resize the fonts. Which makes it quite hard to work with on a large 21" screen. They could update the examples to show more pratical angles and more apps that combine modern fucntionalities looked-at by curious developers.
This being said, Smalltalk is no functional programming.
Functional programming is possible is Perl. See the Mark-Jason Dominus book 'Higher Order Perl'. Perl, according ot the author, shares most of its qualities and features with lisp. And as you know, Perl can be used from command-line one-liners to full OOP projects with a choice of GUIs ranging from wxWidgets, Prima, to GTK. Now, I'm reading the book, so I'm only curious about functiional programming at the moment and did not include any of its concepts in projects so far. But by using Perl I have the possibility to eventually use it while keeping all the other functionalities and moreover, all of the thousands CPAN modules.
@carcassonne: Higher-Order Perl is a great book; every Perl programmer who wants to truly maximize his use of the language would do well to read it. And as you point out, many modern dynamic languages implement functional ideas. Which is a great thing, because developers will finally be able to use those capabilities in wider domains. But still, the full effect cannot quite be appreciated with Perl alone. And it's always best to get as many perspectives on an idea as possible, to really be able to get the most out of it. That said, Perl does do an excellent of combining the facilities of several different paradigms. As do Python and Ruby, in my opinion. (And yes, I know Smalltalk isn't considered functional. [I mean, not considered to be part of the functional paradigm.] That was just an example I took from Bruce Tate's book.)