Related
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
To me, I think F# is a bad choice due to the fact that it uses threads behind the scenes. To me, threads are too "heavy" due to things like context switching.
I can see why Erlang is a good choice because it uses light weight processes.
Am I wrong?
I don't understand what you are asking.
F# does not use 'threads behind the scenes', or at least no more than any .NET process does. In fact F#'s async facilities make it much easier to write non-blocking I/O programs that do not consume threads (as compared to C#/VB which has a more difficult threadless/non-blocking programming model).
(And, of course, typically you don't just pick one arbitrary aspect to compare two things and then decide 'X is better than Y'. There is more to a programming language than just a threading/process model.)
You may enjoy reading
http://blogs.msdn.com/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx
The final three paragraphs are worth quoting:
Indeed, there are few other .NET or
JVM-based languages that support
lightweight reactive agents at all –
in early .NET it was said to be
“impossible” because of the costs of
threads. In this context, F#’s
integration of “async { ... }” in 2007
can be seen as somewhat of a
breakthrough in applied language
design – it allows lightweight,
compositional async programming and
reactive agents in the context of an
industrially accepted and
interoperable programming platform.
Along with the Axum language prototype
(which has been influential on F#), F#
has proven that an asynchronous
language feature is a feasible way to
break through the logjam of “do we
make threads lightweight or not” that
currently bedevils industrial runtime
system design.
F# async programming can be seen as an
implementation of resumptions, and
there are many precursors here, for
example OCaml delimited continuations,
Haskell embeddings of monadic
concurrency and papers emphasising the
importance of resumptions with regard
to concurrency.
You can use F# asynchronous agents on
.NET 2.0, 3.5, 4.0, on Linux/Mono/Mac
and on Silverlight. Indeed, you can
even use F# async programming when F#
is translated to Javascript using the
WebSharper platform. Enjoy!
Since 2006 erlang has had SMP, so it too 'uses threads behind the scenes'. Neither a process in erlang nor (AFAIK) asynchronous tasks in F# correspond to an OS thread; both runtimes use threads as and when required, and lighter-weight mechanisms where appropriate.
If you want to get some useful feedback, you should specify the scenario you are interested in. However, functional programming isn't about threads or processes - it is more about expressing algorithms and using different programming patterns, so the use of threads/processes is a really weird criteria for comparing functional languages.
Most importantly, in F# concurrent programming is just a matter of library and there are many choices:
F# async mentioned by Brian allows you to implement light-weight message-passing concurrency
PLINQ allows you to write declarative data-parallel computations
Tasks give you a fine-grained primitive for executing a large number of small tasks in parallel
Threads (used rarely) give you the full control over closer to the operating system level
On the other hand, Erlang pretty much forces you to use a single library for concurrent programming (which is directly supported by the language). That may be a good choice for many areas (such as telecommunication applications), but it may be too restrictive for some other cases.
I'm not saying anything bad about Erlang - you can certainly use it to encode many other higher-level concurrent programming paradigms as well. I'm just saying that binding the language to a single concurrency programming model (and using this to compare the languages) is a wrong approach in general.
I know of several functional languages - F#, Lisp and its dialects, R, and more. However, as I've never used any of them (although the three I mentioned are on my "to-learn" list), I was wondering about the pros/cons of the various functional languages out there. Are there significant pros/cons, both in learning the language and in any real-world applications of said language?
Haskell is "extreme" (lazy, pure), has active users, lots of documentation, and makes runnable applications.
SML is "less extreme" (strict, impure), has active users, formal specification, many implementations (SML/NJ, Mlton, Moscow ML, etc.). Implementations vary on how applications are deployed wrt the runtimes.
OCaml is ML with attitude. It has an object orientation, active users, documentation, add ons, and makes runnable applications.
Erlang is concurrent, strict, pure (mostly), and supports distributed apps. It needs a runtime installed separately, so deployment is different from the languages that make runnable binaries.
F# is similar to OCaml with Microsoft backing and .NET libraries.
Scala runs on the JVM and can be used as a functional language with advanced features, or as simply a souped-up Java, or both. The flexibility is cited as a drawback for learning a functional language because it's easy to slip back into imperative Java ways. Of course it is also an advantage if you want to use existing JVM libraries.
I'm not sure if your question is to functional languages in general, or differences between them. For general info on why functional:
http://paulspontifications.blogspot.com/2007/08/no-silver-bullet-and-functional.html
Why Functional Programming Matters
As far as differences between functional languages:
Distinctive traits of the functional languages
The awesome thing about functional languages is that base themselves off of the lambda calculus and other math. This results in being able to use similar algorithms and thoughts across languages more easily.
As far as which one you should learn: Pick one that will have a comfortable environment for you. For example, if you're using .NET and Visual Studio, F# is an excellent fit. (Actually, the VS integration makes F# a strong contender, period.) The book "How to Design Programs" (full text, free, online) with PLT Scheme is also a good choice.
I'm biased, but F# looks to have the biggest "real-world" potential. This is mainly because of the nice IDE/.NET integration, allowing you to fully tap .NET and OO, while keeping a lot of functional power (and extending it in ways too). Scala might be possible contender, but it's more of an OO language that has some functional features; hence Scala won't be as big a productivity gain.
Edit: Just to note JavaScript and Ruby, before someone comments on that :). Ruby is something else you could take a look at if you're doing that type of web dev, as it has a lot of functional concepts in, although not as polished as other languages.
The biggest downside is that once you see the power you can have, you won't be happy using lesser languages. This becomes a problem if you're forced to deal with people who haven't yet understood.
One final note, the only "con" is that "it's so complicated". This isn't actually true -- functional languages are often simpler -- but if you have years of C or whatnot in your brain, it can be a significant hurdle to "get" the functional concept. After it clicks, it should be relatively smooth sailing.
Lisp has a gentle learning curve. You can learn the basics in an hour, though of course it takes longer to learn idioms etc. On the down side, there are many dialects of Lisp, and it's difficult to interact with mainstream environments like Java or .NET.
I would not recommend R unless you need to do statistics. It's a strange language, and not exactly functional. You can do functional programming in R, but most people don't.
If you're familiar with the Microsoft tool stack, F# might be easy to get into. And it has a huge, well-tested library behind it, i.e. the CLR.
You can use a functional programming style in any language, though some make it easier than others. As far as that goes, you might try Python.
ML family (SML/OCaml/F#):
Pros:
Fairly simple
Have effective implementations (on the level with Java/C#)
Easily predictable resource consumption (compared to lazy languages)
Readable syntax
Strong module system
(For F#): large .Net library available
Has mutable variables
Cons:
Sometimes too simple (no typeclasses => problems with overloading)
(Except F#): standard libraries are missing some useful things
Has mutable variables :)
Cannot have infinite data structures (not lazy language)
I haven't mentioned features common to most static-typed functional languages: type inference, parametric polymorphism, higher-order functions, algrebraic data types & pattern matching.
I have learnt Haskell at the university like a pure functional languaje and I can say that's really powerful, but also I couldn't find a practical use.
However, i found this: Haskell in practice . Check it, is amazing.
The characteristics of functional paradigms sometimes are pros, and sometimes cons, depending on the situation / context.
Some of them are:
high level
lambda functions
lazy evaluation
Higher-order functions
recursion
type inference
Cite from wikipedia:
Efficiency issues
Functional programming languages have
been perceived as less efficient in
their use of CPU and memory than
imperative languages such as C and
Pascal.[26] However, for programs that
perform intensive numerical
computations, functional languages
such as OCaml and Clean are similar in
speed to C. For
programs that handle large matrices
and multidimensional databases, array
functional languages (such as J and K)
were designed with speed optimization
in mind.
Purely functional languages have a
reputation for being slower than
imperative languages.
However, immutability of data can, in
many cases, lead to execution
efficiency in allowing the compiler to
make assumptions that are unsafe in an
imperative language, vastly increasing
opportunities for inlining.
Lazy evaluation may also speed up the
program, even asymptotically, whereas
it may slow it down at most by a
constant factor (however, it may
introduce memory leaks when used
improperly).
With regards to making a game server, it seems Erlang always comes up as a language that is "built for this kind of thing" with its scalability and concurrency features. I don't have experience in either Haskell nor Erlang, but on the surface they seem the same. Looking into Haskell's docs it seems like it has support for multiprocessor scalability and concurrency, and Haskell is said to be a more solid language and has a visibly better community. My question is, then, is Haskell considered to be as good of a solution to server building as Erlang supposedly is?
It depends what you want to do with your server. As might be expected from a telecoms application, Erlang excels at doing simple tasks with very high concurrency. If your server will need a bazillion connections per second, or at once, Erlang is your friend. Erlang also offers better support for distributing load over multiple servers.
Haskell excels at complex, symbolic computation and as of April 2009 can also handle a great many threads (see update below). Moreover, Haskell has more tools for getting complicated code right: things like QuickCheck, SmallCheck, and the static type system. So if your server is doing complicated, interesting things and you can get by with just one server, you're probably better off with Haskell.
Update 13 April 2009: Don Stewart, a reliable source, reports that "the last thread-scaling bug in the Glasgow Haskell Compiler was squished a few months ago", and that some users report using a million Haskell threads without trouble. As of January 2009, there is a new, unpublished paper from the implementors which may describe how this is achieved.
Update 21 February 2012: John Hughes's company, QuviQ, now makes QuickCheck for Erlang. They have found a number of very interesting bugs. You can download "QuickCheck Mini" for free; it is comparable to the Haskell QuickCheck. There is also a more powerful commercial version.
The benchmarks of these papers show that Haskell can compete with Apache:
Developing a high-performance web server in Concurrent Haskell
— Simon Marlow
Combining Events And Threads For Scalable Network Services:
Implementation And Evaluation Of Monadic,
Application-level Concurrency Primitives
— Peng Li Stephan A. Zdancewic (see Figure 19)
I don't have experience in either Haskell nor Erlang, but on the surface they seem the same.
There are some pretty stark differences between Haskell and Erlang. Erlang is specifically designed for concurrent systems. The language and virtual machine are both designed to support many, many processes, and Erlang uses an actor-style system to manage communication between all of them. Haskell also supports concurrency fairly easily, due to its functional nature, but it's still a bit harder to do concurrent programming in Haskell, and the language isn't specifically set up to facilitate this.
Like Haskell, Erlang doesn't share state between processes, so it's easy to write multi-process software. But the programming style between Haskell and Erlang is a bit different, since Erlang emphasizes the use of small processes to perform concurrent processing.
I love Haskell -- it's one of my favorite languages -- but if I was going to write server software, I'd probably use Erlang. But it's certainly possible to write a server in Haskell, if you know Haskell better or find the library support to be superior.
Now there is a new option: use the Haskell/Erlang FFI to write your logic in Haskell and communicate using Erlang.
Last time I looked, the libraries and frameworks for building scalable servers in Erlang looked a bit more mature than those for Haskell. I'd suggest looking at Programming Erlang: Software for a Concurrent World for information on those.
It is a lot easier to introduce memory leaks in your Haskell application due to laziness. Long-running servers are precisely the kind of programs where you really don't want to have any memory leaks.
While I agree that Haskell is a more solid language and nicer to program in, Erlang is much easier and has many libraries specifically intended for uses like these.
I don't think there is a Haskell equivalent to, say, Mnesia, and writing it is going to be difficult. You can write Haskell versions of gen_server, gen_event, etc. but they won't have been optimised and tuned for over a decade.
The question of whether Haskell is as good as Erlang depends on what people want from a language. I think both would do quite well as a game server, but it depends mainly on what you want or expect from a programming language. One of the easiest differences to note is that Haskell is a statically typed language with type inference, and Erlang is a dynamically typed language. Overall, I would say that Haskell requires a bit more "sophistication" for those not accustomed to functional programming.
I'm sure you can find people who think so, but I think you're mistaken about the ability of Erlang to support this kind of use; it's widely used in telephony applications, and is actually quite robust. Erlang is very much optimized to highly reliable, high concurrency servers.
Lisp developed a set of interesting language features quite early on in the academic world, but most of them never caught on in production environments.
Some languages, like JavaScript, adapted basic features like garbage collection and lexical closures, but all the stuff that might actually change how you write programs on a large scale, like powerful macros, the code-as-data thing and custom control structures, only seems to propagate within other functional languages, none of which are practical to use for non-trivial projects.
The functional programming community also came up with a lot of other interesting ideas (apart from functional programming itself), like referential transparency, generalised case-expressions (ie, pattern-matching, not crippled like C/C# switches) and curried functions, which seem obviously useful in regular programming and should be easy to integrate with existing programming practice, but for some reason seem to be stuck in the academic world forever.
Why do these features have such a hard time getting adopted? Are there any modern, practical languages that actually learn from Lisp instead of half-assedly copying "first class functions", or is there an inherent conflict that makes this impossible?
Are there any modern, practical
languages that actually learn from
Lisp instead of half-assedly copying
"first class functions", or is there
an inherent conflict that makes this
impossible?
Why aren't lisp, haskell, ocaml, or f# modern?
You might just need to take it on yourself and look at them and realize that they are more robust, with libraries like java, then you'd think.
A lot of features have been adopted from functional languages to other languages. But vice versa -- (some) functional languages have objects, for example.
I suggest you try Clojure. Syntactically beautiful dialect, functional (in the ML sense), and fast. You get immutability, software transactional memory, multiversion concurrency control, a REPL, SLIME support, and an inexhaustible FFI. It's the Lisp (& Haskell) for the Business Programmer. I'm having a great time using it daily in my real job.
There is no known correlation between a language "catching on" and whether or not is has powerful, well researched, well designed features.
A lot has been said on the subject. It exists all over the place in technology, and also the arts. We know artist A has more training and produces works of greater breadth and depth than artist B, yet artist B is far more successful in the marketplace. Is it because there's a zeitgeist? Is is because artist B has better marketing? Is it because most people won't take the time to understand artist A? Maybe artist B is secretly awful and we should mistrust experts who make judgements about artists? Probably all of the above, to some degree or another.
This drives people who study the arts, and people who study programming languages, crazy.
Scala is a cool functional/OO language with pattern matching, first class functions, and the like. It has the advantage of compiling to Java bytecode and inter-operates well with Java code.
Common Lisp, used in the real-world albeit not wildely so, I guess.
Python or Ruby. See Paul Graham's thoughts on this in the question "I like Lisp but my company won't let me use it. What should I do?".
Scala is the absolute king of languages which have adopted significant academic features. Higher kinds, self types, polymorphic pattern matching, etc. All of these are bleeding-edge (or near to it) academic research topics that have been incorporated into Scala as fundamental features. Arguably, this has been to the detriment of the langauge's simplicity, but it does lead to some very interesting patterns.
C# is more mainstream than Scala, but it also has adopted fewer of these "out-there" functional features. LINQ is a limited implementation for Wadler's generalized list comprehensions, and everyone knows about lambdas. But for all that, C# (rightfully) remains a bit conservative in adopting research features from the academic world.
Erlang has recently gained renewed exposure not only through being used by Twitter, but also by the rise of XMPP driven messaging and implementations such as ejabberd. It sports many of the ideas coming from functional programming being a language designed with that in mind. Initially used to run Telephone switches and conceived by Ericson to run the first GSM networks. It is still around, it is fully functional (as a language) and used in many production environments.
Lua.
It's used as a scripting/extension language for a number of games (like World of Worcraft), and applications (Snort, NMAP, Wireshark, etc). In fact, according to an Adobe developer, Adobe's Lightroom is over 40% Lua.
The guys behind Lua have repeatedly listed Scheme and Lisp as major influences on Lua, and Lua has even been described as Scheme without the parentheses.
Have you checked out F#
Lot's of dynamic programming languages implement ideas from functional programming. The newer .Net languages (C# and VB) have what they call lambda's but these aren't side effect free.
It's not difficult combining concepts from functional programming and object oriented programming for example but it doesn't always make a lot of sense. Object oriented languages (try to) encapsulate state inside objects while functional languages encapsulate state inside functions. If you combine objects and functions in one language it gets harder to make sense of all this.
There have been a lot of languages that have combined these paradigms by just throwing them together (F#) and this can be usefull but I think we still need a couple of decades of playing with languages like this untill we can create a new paradigm that succesfully will combine the ideas from oo and functional programming.
C# 3.0 definitely does.
C# now has
Lambda Expressions
Higher Order Functions
Map / Reduce + Filter ( Folding?) to lists and all types which implement IEnumerable.
LINQ
Object + Collection Initializers.
The last two list items may not fall under proper functional programming, anyways the answer is C# has implemented many useful concepts from Lisp etc.
In addition to what was said, a lot of LISP goodness is based on guaranteed lack of side-effects and using built-in data structures. Both rarely hold in real world. ML is probably better functional base.
Lisp developed a set of interesting language features quite early on in the academic
world, but most of them never caught on in production environments.
Because the kind of people who manage software developers aren't the kinds of people who you can have an interesting chat comparing different language features with. Around 2000, I wanted to use LISP to implement XML-to-HTML transforms on our corporate website (this is around the time of Amazon implementing their backend in LISP). I didn't get to. This is mildly ironic seeing as the company I was working for made and sold a Common LISP environment.
Another "real-world" language that implements functional programming features is Javascript. Since absolutely everything has a value, then high-order functions are easily implemented. You also have other tenants of functional programming such as lambda functions, closures, and currying.
The features you refer to ("powerful" macros, the code-as-data thing and custom control structures) have not propagated within other functional languages. They died after Lisp taught us that they are a bad idea.
Modern functional languages (OCaml, Haskell, Erlang, Scala, F#, C# 3.0, JavaScript) do not have those features.
Cheers,
Jon Harrop.