Is there any newer language than Prolog specialized for logical programming?
Mercury is nice and modern, and resembles prolog.
Mercury is a new logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs.
There is a quite promising functional logic programming language called Curry. In spite of its newness it should be easy to get used to Curry if you already know Haskell and Prolog as it was directly influenced by these two languages.
Curry combines in a seamless way
features from functional programming
(nested expressions, higher-order
functions, lazy evaluation), logic
programming (logical variables,
partial data structures, built-in
search), and concurrent programming
(concurrent evaluation of expressions
with synchronization on logical
variables).
Don't forget that Prolog is the host for many newer extensions which can be considered languages in their own right. In particular constraint languages like CLP(R), CLP(Q), CLP(FD). More general extensions like CHR, but also many typed approaches.
These languages usually ship as a library in an existing Prolog system. What you get in that setting is often a significantly more mature and stable implementation than from-scratch system can offer. After all, many Prolog systems are almost 30 years old.
Logtalk is an object-oriented logic programming language that extends and leverages the Prolog language with a feature set suitable for programming in the large, focusing in code encapsulation and reuse mechanisms. It's highly portable supporting as a backend compiler most actively maintained Prolog implementations. Other noteworthy features include support for both prototypes and classes, protocols (interfaces), coinduction, component-based programming, event-driven programming, and high-level multi-threading programming. The current distribution include a large set of programming examples, programming tools, libraries, and text editors and syntax highlighters support for programming and publishing source code.
Oz/Mozart is a Multi-paradigm programming language that supports Logic programming as one of it's features. I've never used it so I can't say if it's good. It certainly seems interesting though.
Disclaimer: I work on the Mercury project and would choose Mercury in a choice between Oz/Mozart and Mercury.
None of the other answers has mentioned Picat:
Picat is a simple, and yet powerful, logic-based multi-paradigm programming language aimed for general-purpose applications. Picat is a rule-based language, in which predicates, functions, and actors are defined with pattern-matching rules. Picat incorporates many declarative language features for better productivity of software development, including explicit non-determinism, explicit unification, functions, list comprehensions, constraints, and tabling. Picat also provides imperative language constructs, such as assignments and loops, for programming everyday things. The Picat implementation, which is based on a well-designed virtual machine and incorporates a memory manager that garbage-collects and expands the stacks and data areas when needed, is efficient and scalable. Picat can be used for not only symbolic computations, which is a traditional application domain of declarative languages, but also for scripting and modeling tasks.
Picat looks somewhat similar to Prolog but Picat is a multi-paradigm language:
import util.
input_data(Tri) =>
Lines = read_file_lines("triangle.txt"),
Tri = new_array(Lines.length),
I = 1,
foreach(Line in Lines)
Tri[I] = Line.split().map(to_integer).to_array(),
I := I+1
end.
I've been coding for a few years now, nothing too complicated. C++ is what I know best. I recently stumbled into Paul Graham's site, coding horror, and now here.
What do I learn to "enlighten myself with the ways" of functional programming? Haskell, Scheme or CLisp?
If you're interested in functional programming, Haskell is the only purely functional language on that list. Common Lisp is a weakly functional mixed-paradigm language, and Scheme is more strongly functional but still not pure. Lisps are interesting for other reasons, but Haskell is pretty much the state of the art for functional programming.
Incidentally, the reason I encourage more strongly functional languages like Haskell is because a large part of "learning functional programming" is learning how to think of your program in a different way. If your language makes it feel natural to write imperatively, it's too easy to fall into that way of thinking and never realize there's a different way to do it.
Of the three, I'd say Scheme is the simplest overall, if that's your main concern. SICP uses Scheme, and is itself a great resource for learning to program the functional way.
However, Common Lisp has many advanced features that make it quite expressive, such as powerful error handling (more powerful than exceptions), multimethods and support for aspect oriented programming.
You might start with one but, in the end, you should study many languages.
All three are good, depends on each person.
If you decide on haskell, this is a great ressource : learnyouahaskell and also real world haskell
As other answers say, all three are good.
But if you decide on Lisp, then I'd suggest you go for Clojure which is perhaps its most recent reincarnation.
'enlighten myself with the ways' of functional programming?
Haskell's the strongest exemplar of the functional style, emphasizing purely functional programming (no side effects), strong static typing, and with a pragmatic implementation with an emphasis on multicore parallelism, while also having a huge community (around 2000 libraries available on http://hackage.haskell.org , and many online resources).
It's somewhat famous for retraining how people think about programming.
But this is advocacy, and not a useful stackoverflow question and answer session. You'll have to decide for yourself what you're looking to learn.
Have you heard of F#, ML or OCaml? These three languages belong to the ML family.
F# is a new ML dialect supported by Microsoft and will be shipped with Visual Studio 2010. The good thing about F# (or other ML languages) is that when you first start you could write imperative code and learn good functional style gradually.
Here's an example I wrote for Project Euler #2. When I first did it, I used imperative style. Later on, I know how to use lazy sequence, which is a powerful functional programming concept.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What kind of problems is better solved in Prolog than in Haskell? What are the main differences between these two languages?
Edit
Is there a Haskell library (kind of a logical solver) that can mimic Prolog functionality?
Regarding the logic library question: If it doesn't exist, it should be possible to build one a variety of ways. The Reasoned Schemer builds logical reasoning capabilities into Scheme. Chapters 33-34 of PLAI discuss Prolog and implementing Prolog. These authors are building bridges between Scheme and Prolog. The creators of PLT Scheme have built as one of their languages a Lazy Scheme after the lazy evaluation feature of Haskell. Oleg Kiselyov's LogicT paper is brilliant as usual--he pushes the boundary for what is possible in many languages. There is also a logic programming example on the Haskell Wiki.
The Reasoned Schemer by Daniel P. Friedman, William E. Byrd, and Oleg Kiselyov
Programming Languages: Application and Interpretation by Shriram Krishnamurthi
LogicT - backtracking monad transformer with fair operations and pruning
Logic programming on Haskell Wiki
Prolog is mainly a language targeted at logical problems, especially from the AI and linguistic fields. Haskell is more of a general-purpose language.
Prolog is declarative (logical) language, what makes it easier to state logical problems in it. Haskell is a functional language and hence much better suited to computational problems.
Wikipedia on declarative programming:
In computer science, declarative
programming is a programming paradigm
that expresses the logic of a
computation without describing its
control flow. It attempts to minimize
or eliminate side effects by
describing what the program should
accomplish, rather than describing how
to go about accomplishing it. This is
in contrast from imperative
programming, which requires a detailed
description of the algorithm to be
run.
Declarative programming consider
programs as theories of a formal
logic, and computations as deductions
in that logic space. Declarative
programming has become of particular
interest recently, as it may greatly
simplify writing parallel programs.
Wikipedia on functional programming:
In computer science, functional
programming is a programming paradigm
that treats computation as the
evaluation of mathematical functions
and avoids state and mutable data. It
emphasizes the application of
functions, in contrast to the
imperative programming style, which
emphasizes changes in state.
Functional programming has its roots
in the lambda calculus, a formal
system developed in the 1930s to
investigate function definition,
function application, and recursion.
Many functional programming languages
can be viewed as embellishments to the
lambda calculus.
In short a declarative language declares a set of rules about what outputs should result from which inputs and uses those rules to deduce an output from an input, while a functional language declares a set of mathematical or logical functions which define how input is translated to output.
As for the ADDED question : none that I know of but you can either translate Haskell to Prolog, or implement Prolog in Haskell :)
Prolog is a logic programming language, whereas Haskell is a functional language. Functional languages are based on the concept of a function which takes a number of arguments and computes a value.
Prolog, on the other hand, does not have functions. Instead, predicates are used to prove a "theorem". Prolog predicates do not compute a value, they can answer "yes" or "no" and optionally bind input variables to values:
The usefulness of functional and logic programming often overlap. Functional programming has gained quite a bit of traction lately, while Prolog is still much a niche language, much due to the fact that it is much more different from the common concepts of functions and methods of mainstream OOP than functional programming is, and often considered (very) difficult to learn.
Certain problems become almost trivial to implement in Prolog, especially in combination with constraint solvers.
You can read more about logic programming on Wikipedia.
You might find the paper Escape from Zurg: An Exercise in Logic Programming an interesting read. It shows a side-by-side comparison of the implementation of a simple search problem in Prolog and Haskell, along with a little typeclass framework for representing search problems more generally. The conclusion that the authors come to is that expressing at least some of these types of problems in Haskell is easier than in Prolog, primarily because the Haskell type system makes it easier to come up with nice representations of search states and moves from state to state.
In reality there are only 2 languages:
Machine language
Human language.
All other languages in between are merely translators and nothing more. When we use the machine language we must think like the machine and when using human languages we think like humans.
The true job of a programmer is to think both ways. Some programming tools like the assembler force the programmer to spend a lot more time thinking like the machine. Other tools like Prolog allows us to spend more time thinking like a human.
There is a penalty to be paid at each extreme either in performance or in cost.
If the business logic of your application can be reduced to a set of rules and its output to a set of goals (for example writing a game of Chess) then Prolog is ideal. On the other hand if you need to take the input and tell the computer how to compute the output then a functional language would be more appropriate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've learned several languages, but now I want to choose one. The language that I most liked was Haskell, which is like an interpreted language but is a compiled.
What are the pros and cons of Haskell?
Just a couple of ideas I've got in my head at the moment.
Pros
Learning Haskell will change the way you think about programming. (People often find themselves writing Haskell-like code in other languages once they learn Haskell.)
Type safety is miles above mainstream languages (null pointer exceptions, anyone?)
Type inference means you don't have to worry about types, unless absolutely necessary.
It produces high performant executables.
Parallelism is almost trivial with the par and pseq combinators
The interactive environment (hugs/ghci) allow you to prototype ideas quickly
Has a nice supportive community (IRC, mailing lists, etc.)
Very expressive and concise syntax
GHC is actively being developed and improved, including support for code execution on GPU for that extra kick of high-performance computing
QuickCheck > unit testing
Cons
Learning Haskell will ruin all other languages for you.
It's quite complicated to get into
Very easy to write cryptic programs that no-one understands, not even yourself a few days later
There are cons to using Haskell for certain projects, but there are no cons to learning Haskell. It takes time, but it is worth it. You will be a better programmer.
I would also like to stress some of the practical features of Haskell, despite its mere beauty:
Gets in your way exactly where it should, and keeps out of your way otherwise. That's one of the interesting features, which is responsible for why Haskell just works.
Has a great concurrency system, which is ready for high performance applications.
Provides the basis for new, innovative abstractions and design patterns, among them my personal favorite, functional reactive programming.
Makes even very complicated problems easy to tackle, because a lot of the things, which you need to think about in other languages (proper sequencing, locking, initialization, etc.), are much less of an issue in Haskell.
Laziness is not simply an optimization. It allows you to solve problems in entirely new ways, which are much easier on the brain. No destructive updates, yet the same result with about the same performance.
If you have the choice, I totally recommend learning Haskell over any other language. It seems to make the optimal tradeoff between safety, level of abstractness and practicality among the existing languages.
Pros:
1) Haskell is the most state-of-the-art programming language.
I did some research and haskell seems to be the only real state-of-the-art programming language. There are others like agda and coq, but those are quite experimental and lack features for real world programming (e.g. library support). It’s best to invest in a state-of-the art programming language.
(note: I don't argue about the details why haskell is state-of-the-art, and almost any other programming language is not. This would take too much time. So it's simply my subjective opinion. Same is true for the other statements.)
(note: some features I mention later are probably GHC specific, but I still write only haskell)
2) Haskell programmers are typically very smart. The code quality of the libraries is exceptionally high. Further, tips on stackoverflow are very well written, and also on a high level (thanks to people like Don Stewart, just to name one). I think one of the best ways to improve in programming is by learning from other peoples' code. Haskell is very good in that regard.
3) Imperative programming in moste OOP languages is obsolete. So is usual way of programming with side effects. But there are very few programming languages for declarative programming without side-effects. For instance Scala, F#, Ocaml and Erlang are not side effect free. (However, there is work, also in the academic field on OOP languages that are clearly not obsolete. Consider the work of Alan Kay in the past or for instance current state-of-the art academic work in the realm of Smalltalk.)
4) Haskell supports programming with abstract mathematical concepts (e.g. monads, functors, combinators, GADT, etc.). I think this boosts programming productivity.
5) The Haskell type system is very flexible, and supports type inference. This reduces the possible errors a lot. The type system is checked at compile time. The type systems helps as documentation.
6) Some state-of-the art concepts are implemented in haskell first (like the QuickCheck library). There are a lot of interesting extensions.
7) The haskell syntax is very well designed. There are no unnecessary parenthesis. The code is compact and the synatax for pattern matching and list comprehension is quite nice. People like Knuth advocate literate programming, and haskell/GHC supports it.
8) haskell supports lazy evaluation
Cons:
1) It's very hard to learn, and it takes hours, months to master haskell. It’s even harder without a proper computer science background. Things like Monads and Functors are hard to understand, especially without mathematical background. So most programmers probably don’t have the ability or will to learn haskell. Haskell is not ‘simple’. Howevery it’s impossible to have a simple language that supports all the advanced features.
2) The IDE options are not as good as those for other programming languages. I use leksah as my IDE, it’s very good, but it’s not comparable to Eclipse for java development.
3) Haskell cannot be used for android or Iphone development. In contrast Scala can be used for android development, and it’s also compatible to java, which is a huge advantage.
4) I think some libraries lack supporting people who maintain and improve them. I do semantic web programming in haskell, and the library support could be better.
Haskell is not suited for all projects. If you need every millisecond of performance, C/C++ is still probably the best option. So haskell is suited for many projects, but not all.
Haskell has many technical advantages over other programming languages. However, there might be political reason against using haskell. For example Scala integrates better with existing java infrastructure.
What do you want to write, what type of applications? What problems do you want to solve?
There are some problem types that Haskell will excel in, but, if you write a program that requires constantly changing state then Haskell is a bad choice.
If while modeling the problem it doesn't fit well with functional programming, such as writing a CAD (computer-aided design) program, OOP would be a better choice, just because the programming paradigm fits better with the model.
But, if you are not affected by these problems then Haskell can be a great language to use.
but now I want to choose one
...
Then I want to know the pros and cons of this powerfull language(just to make the correct choice).
If you will permit me to generalize, the choice of a language really depends on the problem you are trying to solve. There is no one choice that will work for everything, and
there will always be some language that will look better than the one you are using now.
Keep learning new languages, however, since the experiences will heighten your abilities to know when a language is wrong for a project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I see a lot of talk on here about functional languages and stuff. Why would you use one over a "traditional" language? What do they do better? What are they worse at? What's the ideal functional programming application?
Functional languages use a different paradigm than imperative and object-oriented languages. They use side-effect-free functions as a basic building block in the language. This enables lots of things and makes a lot of things more difficult (or in most cases different from what people are used to).
One of the biggest advantages with functional programming is that the order of execution of side-effect-free functions is not important. For example, in Erlang this is used to enable concurrency in a very transparent way.
And because functions in functional languages behave very similar to mathematical functions it's easy to translate those into functional languages. In some cases, this can make code more readable.
Traditionally, one of the big disadvantages of functional programming was also the lack of side effects. It's very difficult to write useful software without I/O, but I/O is hard to implement without side effects in functions. So most people never got more out of functional programming than calculating a single output from a single input. In modern mixed-paradigm languages like F# or Scala this is easier.
Lots of modern languages have elements from functional programming languages. C# 3.0 has a lot functional programming features and you can do functional programming in Python too. I think the reasons for the popularity of functional programming is mostly because of two reasons: Concurrency is getting to be a real problem in normal programming, because we're getting more and more multiprocessor computers; and the languages are getting more accessible.
I don't think that there's any question about the functional approach to programming "catching on", because it's been in use (as a style of programming) for about 40 years. Whenever an OO programmer writes clean code that favors immutable objects, that code is borrowing functional concepts.
However, languages that enforce a functional style are getting lots of virtual ink these days, and whether those languages will become dominant in the future is an open question. My own suspicion is that hybrid, multi-paradigm languages such as Scala or OCaml
will likely dominate over "purist" functional languages in the same way that pure OO language (Smalltalk, Beta, etc.) have influenced mainstream programming but haven't ended up as the most widely-used notations.
Finally, I can't resist pointing out that your comments re FP are highly parallel to the remarks I heard from procedural programmers not that many years ago:
The (mythical, IMHO) "average" programmer doesn't understand it.
It's not widely taught.
Any program you can write with it can be written another way with current techniques.
Just as graphical user interfaces and "code as a model of the business" were concepts that helped OO become more widely appreciated, I believe that increased use of immutability and simpler (massive) parallelism will help more programmers see the benefits that the functional approach offers. But as much as we've learned in the past 50 or so years that make up the entire history of digital computer programming, I think we still have much to learn. Twenty years from now, programmers will look back in amazement at the primitive nature of the tools we're currently using, including the now-popular OO and FP languages.
The main plus for me is its inherent parallelism, especially as we are now moving away from higher CPU clock frequency and towards more and more cores.
I don't think it will become the next programming paradigm and completely replace OO type methods, but I do think we will get to the point that we need to either write some of our code in a functional language, or our general purpose languages will grow to include more functional constructs.
Even if you never work in a functional language professionally, understanding functional programming will make you a better developer. It will give you a new perspective on your code and programming in general.
I say there's no reason to not learn it.
I think the languages that do a good job of mixing functional and imperative style are the most interesting and are the most likely to succeed.
I'm always skeptical about the Next Big Thing. Lots of times the Next Big Thing is pure accident of history, being there in the right place at the right time no matter whether the technology is good or not. Examples: C++, Tcl/Tk, Perl. All flawed technologies, all wildly successful because they were perceived either to solve the problems of the day or to be nearly identical to entrenched standards, or both. Functional programming may indeed be great, but that doesn't mean it will be adopted.
But I can tell you why people are excited about functional programming: many, many programmers have had a kind of "conversion experience" in which they discover that using a functional language makes them twice as productive (or maybe ten times as productive) while producing code that is more resilient to change and has fewer bugs. These people think of functional programming as a secret weapon; a good example of this mindset is Paul Graham's Beating the Averages. Oh, and his application? E-commerce web apps.
Since early 2006 there has also been some buzz about functional programming and parallelism. Since people like Simon Peyton Jones have been worrying about parallelism off and on since at least 1984, I'm not holding my breath until functional languages solve the multicore problem. But it does explain some of the additional buzz right about now.
In general, American universities are doing a poor job teaching functional programming. There's a strong core of support for teaching intro programming using Scheme, and Haskell also enjoys some support there, but there's very little in the way of teaching advanced technique for functional programmer. I've taught such a course at Harvard and will do so again this spring at Tufts. Benjamin Pierce has taught such a course at Penn. I don't know if Paul Hudak has done anything at Yale. The European universities are doing a much better job; for example, functional programming is emphasized in important places in Denmark, the Netherlands, Sweden, and the UK. I have less of a sense of what's happening in Australasia.
I don't see anyone mentioning the elephant in the room here, so I think it's up to me :)
JavaScript is a functional language. As more and more people do more advanced things with JS, especially leveraging the finer points of jQuery, Dojo, and other frameworks, FP will be introduced by the web-developer's back-door.
In conjunction with closures, FP makes JS code really light, yet still readable.
Cheers,
PS
Most applications are simple enough to be solved in normal OO ways
OO ways have not always been "normal." This decade's standard was last decade's marginalized concept.
Functional programming is math. Paul Graham on Lisp (replace Lisp by functional programming):
So the short explanation of why this
1950s language is not obsolete is that
it was not technology but math, and
math doesn’t get stale. The right
thing to compare Lisp to is not 1950s
hardware, but, say, the Quicksort
algorithm, which was discovered in
1960 and is still the fastest
general-purpose sort.
I bet you didn't know you were functional programming when you used:
Excel formulas
Quartz Composer
JavaScript
Logo (Turtle graphics)
LINQ
SQL
Underscore.js (or Lodash),
D3
The average corporate programmer, e.g.
most of the people I work with, will
not understand it and most work
environments will not let you program
in it
That one is just a matter of time though. Your average corporate programmer learns whatever the current Big Thing is. 15 years ago, they didn't understand OOP.
If functional programming catches on, your "average corporate programmers" will follow.
It's not really taught at universities
(or is it nowadays?)
It varies a lot. At my university, SML is the very first language students are introduced to.
I believe MIT teaches Lisp as a first-year course. These two examples may not be representative, of course, but I believe most universities at the very least offer some optional courses on functional programming, even if they don't make it a mandatory part of the curriculum.
Most applications are simple enough to
be solved in normal OO ways
It's not really a matter of "simple enough" though. Would a solution be simpler (or more readable, robust, elegant, performant) in functional programming? Many things are "simple enough to be solved in Java", but it still requires a godawful amount of code.
In any case, keep in mind that functional programming proponents have claimed that it was the Next Big Thing for several decades now. Perhaps they're right, but keep in mind that they weren't when they made the same claim 5, 10 or 15 years ago.
One thing that definitely counts in their favor, though, is that recently, C# has taken a sharp turn towards functional programming, to the extent that it's practically turning a generation of programmers into functional programming programmers, without them even noticing. That might just pave the way for the functional programming "revolution". Maybe. ;)
Man cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts. Following rules only permits development up to a point in technique and then the student and artist has to learn more and seek further. It makes sense to study other arts as well as those of strategy.
Who has not learned something more about themselves by watching the activities of others? To learn the sword study the guitar. To learn the fist study commerce. To just study the sword will make you narrow-minded and will not permit you to grow outward.
-- Miyamoto Musashi, "A Book of Five Rings"
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 I/O: monads. These are objects that contain the desired I/O 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.
I don't think most realistic people think that functional programming will catch on (becomes the main paradigm like OO). After all, most business problems are not pretty math problems but hairy imperative rules to move data around and display them in various ways, which means it's not a good fit for pure functional programming paradigm (the learning curve of monad far exceeds OO.)
OTOH, functional programming is what makes programming fun. It makes you appreciate the inherent, timeless beauty of succinct expressions of the underlying math of the universe. People say that learning functional programming will make you a better programmer. This is of course highly subjective. I personally don't think that's completely true either.
It makes you a better sentient being.
I'd point out that everything you've said about functional languages, most people were saying about object-oriented langauges about 20 years ago. Back then it was very common to hear about OO:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
Change has to come from somewhere. A meaningful and important change will make itself happen regardless of whether people trained in earlier technologies take the opinion that change isn't necessary. Do you think the change to OO was good despite all the people that were against it at the time?
I must be dense, but I still don't get it. Are there any actual examples of small application's written in a functional language like F# where you can look at the source code and see how and why it was better to use such an approach than, say, C#?
F# could catch on because Microsoft is pushing it.
Pro:
F# is going to be part of next version of Visual Studio
Microsoft is building community for some time now - evangelists, books, consultants that work with high profile customers, significant exposure at MS conferences.
F# is first class .NET language and it's the first functional language that comes with really big foundation (not that I say that Lisp, Haskell, Erlang, Scala, OCaml do not have lots of libraries, they are just not as complete as .NET is)
Strong support for parallelism
Contra:
F# is very hard to start even if you are good with C# and .NET - at least for me :(
it will probably be hard to find good F# developers
So, I give 50:50 chance to F# to become important. Other functional languages are not going to make it in near future.
I think one reason is that some people feel that the most important part of whether a language will be accepted is how good the language is. Unfortunately, things are rarely so simple. For example, I would argue that the biggest factor behind Python's acceptance isn't the language itself (although that is pretty important). The biggest reason why Python is so popular is its huge standard library and the even bigger community of third-party libraries.
Languages like Clojure or F# may be the exception to the rule on this considering that they're built upon the JVM/CLR. As a result, I don't have an answer for them.
It seems to me that those people who never learned Lisp or Scheme as an undergraduate are now discovering it. As with a lot of things in this field there is a tendency to hype and create high expectations...
It will pass.
Functional programming is great. However, it will not take over the world. C, C++, Java, C#, etc will still be around.
What will come of this I think is more cross-language ability - for example implementing things in a functional language and then giving access to that stuff in other languages.
When reading "The Next Mainstream Programming Language: A Game Developer’s Perspective" by Tim Sweeney, Epic Games, my first thought was - I got to learn Haskell.
PPT
Google's HTML Version
Most applications can be solved in [insert your favorite language, paradigm, etc. here].
Although, this is true, different tools can be used to solve different problems. Functional just allows another high (higher?) level abstraction that allows to do our jobs more effectively when used correctly.
Things have been moving in a functional direction for a while. The two cool new kids of the past few years, Ruby and Python, are both radically closer to functional languages than what came before them — so much so that some Lispers have started supporting one or the other as "close enough."
And with the massively parallel hardware putting evolutionary pressure on everyone — and functional languages in the best place to deal with the changes — it's not as far a leap as it once was to think that Haskell or F# will be the next big thing.
It's catching on because it's the best tool around for controlling complexity.
See:
- slides 109-116 of Simon Peyton-Jones talk "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" by Tim Sweeney
Check out Why Functional Programming Matters.
Have you been following the evolution of programming languages lately? Every new release of all mainstream programming languages seems to borrow more and more features from functional programming.
Closures, anonymous functions, passing and returning functions as values used to be exotic features known only to Lisp and ML hackers. But gradually, C#, Delphi, Python, Perl, JavaScript, have added support for closures. It's not possible for any up-and-coming language to be taken seriously without closures.
Several languages, notably Python, C#, and Ruby have native support for list comprehensions and list generators.
pioneered generic programming in 1973, but support for generics ("parametric polymorphism") has only become an industry standard in the last 5 years or so. If I remember correctly, Fortran supported generics in 2003, followed by Java 2004, C# in 2005, Delphi in 2008. (I know C++ has supported templates since 1979, but 90% of discussions on C++'s STL start with "here there be demons".)
What makes these features appealing to programmers? It should be plainly obvious: it helps programmers write shorter code. All languages in the future are going to support—at a minimum—closures if they want to stay competitive. In this respect, functional programming is already in the mainstream.
Most applications are simple enough to
be solved in normal OO ways
Who says can't use functional programming for simple things too? Not every functional program needs to be a compiler, theorem prover, or massively parallel telecommunications switch. I regularly use F# for ad hoc throwaway scripts in addition to my more complicated projects.
Wow - this is an interesting discussion. My own thoughts on this:
FP makes some tasks relatively simple (compared to none-FP languages).
None-FP languages are already starting to take ideas from FP, so I suspect that this trend will continue and we will see more of a merge which should help people make the leap to FP easier.
I don't know whether it will catch on or not, but from my investigations, a functional language is almost certainly worth learning, and will make you a better programmer. Just understanding referential transparency makes a lot of design decisions so much easier- and the resulting programs much easier to reason about. Basically, if you run into a problem, then it tends to only be a problem with the output of a single function, rather than a problem with an inconsistant state, which could have been caused by any of the hundreds of classes/methods/functions in an imparative language with side effects.
The stateless nature of FP maps more naturally to the stateless nature of the web, and thus functional languages lend themselves more easily to more elegant, RESTFUL webapps. Contrast with JAVA and .NET frameworks that need to resort to horribly ugly HACKS like VIEWSTATE and SESSION keys to maintain application state, and maintain the (occasionally quite leaky) abstraction of a stateful imperative language, on an essentially stateless functional platform like the web.
And also, the more stateless your application, the more easily it can lend itself to parallel processing. Terribly important for the web, if your website happens to get popular. It's not always straightforward to just add more hardware to a site to get better performance.
My view is that it will catch on now that Microsoft have pushed it much further into the mainstream. For me it's attractive because of what it can do for us, because it's a new challenge and because of the job opportunities it resents for the future.
Once mastered it will be another tool to further help make us more productive as programmers.
A point missed in the discussion is that the best type systems are found in contemporary FP languages. What's more, compilers can infer all (or at least most) types automatically.
It is interesting that one spends half the time writing type names when programming Java, yet Java is by far not type safe. While you may never write types in a Haskell programm (except as a kind of compiler checked documentation) and the code is 100% type safe.
I agree with the first point, but times change. Corporations will respond, even if they're late adopters, if they see that there's an advantage to be had. Life is dynamic.
They were teaching Haskell and ML at Stanford in the late 1990s. I'm sure that places like Carnegie Mellon, MIT, Stanford, and other good schools are presenting it to students.
I agree that most "expose relational databases on the web" applications will continue in that vein for a long time. Java EE, .NET, Ruby on Rails, and PHP have evolved some pretty good solutions to that problem.
You've hit on something important: It might be the problem that can't be solved easily by other means that will boost functional programming. What would that be?
Will massive multicore hardware and cloud computing push them along?
Because functional programming has significant benefits in terms of productivity, reliability and maintainability. Many-core may be a killer application that finally gets big corporations to switch over despite large volumes of legacy code. Furthermore, even big commercial languages like C# are taking on a distinct functional flavour as a result of many-core concerns. Side effects simply don't fit well with concurrency and parallelism.
I do not agree that "normal" programmers won't understand it. They will, just like they eventually understood OOP (which is just as mysterious and weird, if not more so).
Also, most universities do teach functional programming , many even teach it as the first programming course.
In addition to the other answers, casting the solution in pure functional terms forces one to understand the problem better. Conversely, thinking in a functional style will develop better* problem solving skills.
*Either because the functional paradigm is better or because it will afford an additional angle of attack.