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 11 years ago.
as an engineering student with a strong mathemathical background, i dealing some problems like this at university:
(numerical) Simulations
AI Problems
Robotics
Control Systems
and some more
as you can see some are just numerical ones, others have to process some kinds of symbols.
currently i'm working with java, but i'm not very pleased with it (can't say exactly why, probably a personal taste) and now i'm searching for a programming language, in which i can easily prototype new algorithms, like for example in python, and don't care about low level stuff, but has the ability to speed things up if neccessary, e.g. with concurrent/parallel programming, etc. (writing it in python and rewrite it in C/C++ isn't really a option i prefer...)
to sum it up:
easy to prototype, but
the ability to speed algorithms up
syntax without boilerplate stuff like in java
syntax which is easy to read (i know this could be achived with the most, but some language encourage you more...)
i've looked around at sites, like http://rosettacode.org/ and picked 2 or 3 favorites: Go, Lisp (and maybe Haskell) but other recommandations are welcome
Common Lisp using SBCL is pretty fast if you take the time to make it fast.
Why does this fit what you want?
symbolic computations
good number handling
compiles to native on demand by default.
I would use python together with cython: http://www.cython.org for speeding up your code. For symbolic computations you have http://code.google.com/p/sympy/
Try Clojure; it fulfills most of your requirements.
Uses Java libraries, compiles to Java bytecode, and has plugins for Java IDEs, so some of your existing knowledge about Java and its ecosystem will come in handy.
Very concise, readable, and ease of prototyping is extremely high.
Great support for different concurrency strategies.
Performance is getting better fast; typical stuff is within a speed factor of 2 of Java, and slow things can typically be made fast with minimally confounding changes (e.g. a few type hints here and there to use Java primitives.)
An alternative to Common Lisp would be a implementation of scheme. My favorite so far is Racket.
http://racket-lang.org/
When I first got into Lisp I started with scheme and ended up being able to learn it within a matter of days. Also Lisp-wise Racket is a pretty complete language and has a decent IDE in DrRacket.
How about F#?
F# is a remarkable language for prototyping for the following reasons:
F# has an interactive mode allowing you to evaluate blocks of code directly, without compiling your entire project.
Type inference helps keep code small, and makes refactoring your type hierarchy relatively painless. This may not be so important in production code, but I found that to be very valuable during prototyping.
F# integration with .NET makes it easy to prototype extensions of your existing products. In the all-too-common case when a prototype becomes a product (due to time constraints), it's also easy to integrate your F# code within your .NET product.
If prototyping makes up a significant part of your overall development process, then F# can really help you speed up your coding.
I don't think F# will produce code that is significantly faster than other .NET languages. The functional style of programming, in particular purity (no side-effects), can be applied to other programming languages, meaning it is just as easy to write concurrent programs in other languages as well. It does however "feel more natural" to do so in F#.
F# has the Option type, which can be used in place of null values. Code reliability with respect to null-pointer exceptions can be guaranteed at compile time, which is a huge benefit.
Finally, be advised that F# is still in development, and suffers issues, some of which may disappear over time, but not all. See for instance what devhawk and Oliver Sturm have to say about it (in particular about linear scoping and interdependent classes, other issues like overloading, better Visual Studio integration have already been addressed).
this is stated in article: https://stackoverflow.com/questions/328329/why-should-i-use-f
by JOH
Related
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 11 years ago.
I am seeking concrete and unique features that Lisp (any dialect) offers to a project, compared to the other primarily functional languages.
For example, Haskell offers lazy-evaluation, purity and a type-system which helps build more correct programs. Erlang makes concurrent programming easier by using message passing exclusively, lightweight processes, and so on.
What does LISP bring to the table? What makes it a better suite than other languages for certain projects? What are its features that the other languages lack to make it suitable?
I am not bashing at Lisp; I want to learn more about it and what advantages it offers if used today. Please be specific :)
When I asked my self questions similar to yours, I searched and found this article:
http://www.defmacro.org/ramblings/lisp.html
It doesn't go too much into details, but gives a coarse picture of why Lisp makes sense. I found it very useful (and the whole http://www.defmacro.org/ site for that matter - like the posts there a lot, e.g. this one).
Haskell offers lazy evaluation
Clojure sequence functions are lazy. You can work with infinite lists just like in haskell:
(take 10 (cycle ["odd" "even"]))
purity
Clojure types are immutable. That makes large parts of your program pure without forcing you to climb the ivory tower :) Plus it has STM, just like haskell.
and a type-system
Unfortunately here lisps cannot compete with haskell. Mosts lisps are dynamic.
But dynamic nature of lisps and their VM (image) makes them an awesome choice for a server side programs, like web applications. It is very easy to connect to a running instance of your web app, and change functions or even entire modules on the fly, without restarting application or kicking out users. That is either not possible or very cumbersome with haskell.
Most lisps provide a very easy way to write macros. You write macros in the same language.
With Haskell you will have to learn yet another language (Template Haskell) which is much more complicated and to this day is not even properly documented. You will have a hard time learning it.
Having said that, i use and love both lisp (clojure) and haskell. I prefer haskell because it has the most powerful type system of any available for practical development language.
Plus it bends your mind better than mushrooms :)
Scheme provides hygenic macros and continuations. I'm not sure what other fp languages also provide these features.
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 10 years ago.
Given that a persona has extensive experience in different imperative programming languages right from C to JAVA. Whats the learning curve for functional programming languages such a Haskell ?
Before taking on Haskell you may find it easier to learn something that isn't purely functional, like a Lisp or ML. Given your Java experience, Clojure, a Lisp that runs on the JVM, might be a good place to start.
Like the OP, I came from an OOP/imperative background before jumping to functional programming around 2006ish.
I had lots of C# and Java under my belt, and wanted to learn a new language. I started on Python, picked up on Perl, and cut my teeth on C++. It was all fine and dandy, but there wasn't anything new to learn, I was basically re-learning the same language over and over again with a little different syntax. By accident, I stumbled on Paul Graham's classic article Beating the Averages, where he talks about Lisp and functional programming.
I thought it'd be fun to learn one of these "obscure" functional programming languages. So, between Erlang, Lisp, Haskell, and OCaml, I picked up OCaml for no particular reason except that camels are wicked cuteness (totally!). Lots and lots of new stuff to struggle with here:
Graaaaah, why I have to fight the compiler to get type-inference to work right?
Arrrragh, why aren't there any decent IDEs for this language? Why doesn't emacs have a GUI editor? Where's my intellisense!
Currying? Is that just a gimmick, or is it supposed to be useful?
Waaaaah, how can I do anything practical with algebraic data types?
[] -> ... | x::xs -> ..., WTF does that mean?
For me, moving from Java to Python was easy: similar architectural idioms, similar programming style, etc. The hardest part was really learning a new library, which takes all of 6 weeks to go from n00b to pro.
Moving from Java to OCaml was really really hard, because there's nothing build on, its like starting from step 0. It took about 6 months of waffling around with the language before I stopped saying to myself "now how would I do this in OCaml?"
In retrospect, I probably wouldn't have struggled as much had I started with Haskell. Optional mutability + OOP makes OCaml seem superficially like familiar territory, and monads are still a mystery to me.
Taken from link
Users of a procedural or object-oriented language like C, Java, or Python should beware, however: You'll have to forget most of what you already know about programming. Haskell is completely different from those languages, and requires a different way of thinking about programming. It's best to go into this tutorial with a blank slate and try not to compare Haskell to imperative languages, because many concepts in them (classes, functions, return) have a significantly different meaning in Haskell.
I haven't developed anything practical in functional programming languages, but I did not have very much trouble adapting to it.
Before starting, I'd suggest improving your thinking recursively, because that's what you're going to need to do, whether in a familiar or unfamiliar language.
Also, you'll need to adapt to the idea that functions are objects, you can pass them to functions, and functions can return them.
Haskell's learning curve is somewhat higher than other functional languages (like OCaml), though it is my personal favorite.
The key, IMO, is to think in terms of composition and inputs and outputs (if you come from OO, you probably think almost entirely in terms of inheritance -- this can hamper your learning).
Try to separate pure (no side effects) from impure (side effect -- example IO, state, etc).
Remember that functions are first-class citizens.
And learn the trick of partial function application. It is quite handy once you get used to it.
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 10 years ago.
I have been researching and playing with functional programming lately, solely to broaden my thinking about programming, because I find thinking "functionally" difficult.
I have downloaded Glasgow Haskell and experimented with that.
What I am wondering is, what is the best platform for Windows to experiment with FP? I would prefer a JVM based approach, but another post on SO has indicated that a real FP language cannot be implemented on the JVM due to a lack of support for tail recursion. What say you?
EDIT: As I've said, I've experimented a fair bit with Haskell; on the advice of one of the answers I've been reviewing the Scala website. Looking over the Scala examples, the code seems more "familiar" (my background is C and Java), but it seems decidedly more OO/procedural and less functional. A huge advantage of Scala would be that it gives me another language tool to use side by side with Java and could become another arrow in my current professional quiver, as opposed to solely being a learning exercise. When I get further into Scala, will the functional aspects become more predominant, or will I tend to end up just writing OO code with some functional influence? In other words, will Haskell challenge my preconceptions harder and faster than Scala?
Check out F#. The CLR has a .tail instruction so you can write F# code with tail calls that don't cause a StackOverflow (the exception, not the web site). Here is an intro video about F# from PDC.
If you really want to learn how to think in a functional way, Haskell is definitely the right choice. Just about every other language out there lets you slip into an imperative style much too easily. Haskell will force you into a functional mindset. I found this indispensible when learning. (You may certainly be more disciplined than I am, of course, but why push your luck?)
When you're satisfied with what you've learned from Haskell (which will be a lot!), you're set to go out and evaluate more liberal functional languages like Clojure or Scala. Or you can stay with Haskell, whose library situation isn't actually all that bad, either. At that point, it's a question of circumstance and personal preference. But in order to make such a choice, having learned how to think in a “pure” functional way first is, I think, vital.
I recommend PLT Scheme and SICP. The language is so simple that you can get on to the important concepts very quickly.
No way is Scala going to bend your mind anywhere near as much as Haskell will. The main reason to choose Scala over Haskell when learning FP is to give yourself a more gentle introduction to the dangerous wilds of monads, functors and higher-order goodness. Scala is great if you're coming from an object-oriented background trying to transition that knowledge into functional-land. It's not so great if you want to just dive head-first into the deep end.
Given what you're asking, I would recommend GHC Haskell. Nothing is going to warp your head quite as much as that. :-) With that said though, I think you should still keep an eye on Scala. There are many aspects of the language which are positively unique, particularly its type system (structural+nominal subtyping == sweet). It's not going to hurt your head quite so much as Haskell, but it will give you an insight into some concepts you may not find anywhere else, particularly the so-called "typeful programming" methodology.
Oh, and to answer the second part of your question (FP vs OO in Scala), I tend to write my code in a functional style within an object-oriented framework. It's a bit difficult to describe, but that's the way it is. Think of it like designing an API from an object-oriented standpoint but implementing everything in a functional style. I keep things immutable and spend a lot of time using higher-order methods, but I do it all within the confines of inheritance and conventional nominal subtyping. Every so often, I'll still write something imperative, but only when it is cleaner to do so than to use the functional style.
Also look at Clojure.
In other words, will Haskell challenge my preconceptions harder and faster than Scala?
Yes.
If you really want to learn, get far outside your comfort zone.
Are you really going to use Scala for production code in the next 3 months, anyway?
Look at Scala. It targets the JVM, interoperates with Java, and has many state of the art functional programming features.
I love using Haskell and GHC. GHC includes an interactive interpreter (GHCI) and has wonderfully helpful error messages. Plus Haskell's one of the best examples of a truly functional language, and not too bad to use once you experiment with it a bit. Plus it has an awesome type system.
ever tried Prolog? ... that'll
?- bend(your_mind).
Yes
?- bend(X).
X = your_mind
It gave me a whole new perspective anyway ...
plenty info out there
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 10 years ago.
What do you think the benefits of functional programming are? And how do they apply to programmers today?
What are the greatest differences between functional programming and OOP?
The style of functional programming is to describe what you want, rather than how to get it. ie: instead of creating a for-loop with an iterator variable and marching through an array doing something to each cell, you'd say the equivalent of "this label refers to a version of this array where this function has been done on all the elements."
Functional programming moves more basic programming ideas into the compiler, ideas such as list comprehensions and caching.
The biggest benefit of Functional programming is brevity, because code can be more concise. A functional program doesn't create an iterator variable to be the center of a loop, so this and other kinds of overhead are eliminated from your code.
The other major benefit is concurrency, which is easier to do with functional programming because the compiler is taking care of most of the operations which used to require manually setting up state variables (like the iterator in a loop).
Some performance benefits can be seen in the context of a single-processor as well, depending on the way the program is written, because most functional languages and extensions support lazy evaluation. In Haskell you can say "this label represents an array containing all the even numbers". Such an array is infinitely large, but you can ask for the 100,000th element of that array at any moment without having to know--at array initialization time--just what the largest value is you're going to need. The value will be calculated only when you need it, and no further.
The biggest benefit is that it's not what you're used to. Pick a language like Scheme and learn to solve problems with it, and you'll become a better programmer in languages you already know. It's like learning a second human language. You assume that others are basically a variation on your own because you have nothing to compare it with. Exposure to others, particular ones that aren't related to what you already know, is instructive.
Why Functional Programming Matters
http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
Abstract
As software becomes more and more complex, it is more and
more important to structure it well. Well-structured software is easy
to write and to debug, and provides a collection of modules that can
be reused to reduce future programming costs.
In this paper we show
that two features of functional languages in particular, higher-order
functions and lazy evaluation, can contribute significantly to
modularity. As examples, we manipulate lists and trees, program
several numerical algorithms, and implement the alpha-beta heuristic
(an algorithm from Artificial Intelligence used in game-playing
programs). We conclude that since modularity is the key to successful
programming, functional programming offers important advantages for
software development.
A good starting point therefore would be to try to understand some things that are not possible in imperative languages but possible in functional languages.
If you're talking about computability, there is of course nothing that is possible in functional but not imperative programming (or vice versa).
The point of different programming paradigms isn't to make things possible that weren't possible before, it's to make things easy that were hard before.
Functional programming aims to let you more easily write programs that are concise, bug-free and parallelizable.
I think the most practical example of the need for functional programming is concurrency - functional programs are naturally thread safe and given the rise of multi core hardware this is of uttermost importance.
Functional programming also increases the modularity - you can often see methods/functions in imperative that are far too long - you'll almost never see a function more than a couple of lines long. And since everything is decoupled - re-usability is much improved and unit testing is very very easy.
It doesn't have to be one or the other: using a language like C#3.0 allows you to mix the best elements of each. OO can be used for the large scale structure at class level and above, Functional style for the small scale structure at method level.
Using the Functional style allows code to be written that declares its intent clearly, without being mixed up with control flow statements, etc. Because of the principles like side-effect free programming, it is much easier to reason about code, and check its correctness.
Once the program grows, the number of commands in our vocabulary becomes too high, making it very difficult to use. This is where object-oriented programming makes our life easier, because it allows us to organize our commands in a better way.
We can associate all commands that involve customer with some customer entity (a class), which makes the description a lot clearer. However, the program is still a sequence of commands specifying how it should proceed.
Functional programming provides a completely different way of extending the vocabulary. Not limited to adding new primitive commands; we can also add new control structures–primitives that specify how we can put commands together to create a program. In imperative languages, we were able to compose commands in a sequence or using a limited number of built in constructs such as loops, but if you look at typical programs, you'll still see many recurring structures; common ways of combining commands
Do not think of functional programming in terms of a "need". Instead, think of it as another programming technique that will open up your mind just as OOP, templates, assembly language, etc may have completely changed your way of thinking when (if) you learned them. Ultimately, learning functional programming will make you a better programmer.
If you don't already know functional programming then learning it gives you more ways to solve problems.
FP is a simple generalization that promotes functions to first class values whereas OOP is for large-scale structuring of code. There is some overlap, however, where OOP design patterns can be represented directly and much more succinctly using first-class functions.
Many languages provide both FP and OOP, including OCaml, C# 3.0 and F#.
Cheers,
Jon Harrop.
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 10 years ago.
It seems to me from my experimenting with Haskell, Erlang and Scheme that functional programming languages are a fantastic way to answer scientific questions. For example, taking a small set of data and performing some extensive analysis on it to return a significant answer. It's great for working through some tough Project Euler questions or trying out the Google Code Jam in an original way.
At the same time it seems that by their very nature, they are more suited to finding analytical solutions than actually performing practical tasks. I noticed this most strongly in Haskell, where everything is evaluated lazily and your whole program boils down to one giant analytical solution for some given data that you either hard-code into the program or tack on messily through Haskell's limited IO capabilities.
Basically, the tasks I would call 'practical' such as
Aceept a request, find and process requested data,
and return it formatted as needed
seem to translate much more directly into procedural languages. The most luck I have had finding a functional language that works like this is Factor, which I would liken to a reverse-polish-notation version of Python.
So I am just curious whether I have missed something in these languages or I am just way off the ball in how I ask this question. Does anyone have examples of functional languages that are great at performing practical tasks or practical tasks that are best performed by functional languages?
Regarding languages, I think F# is an example of a languages that's primarily 'functional' but also 'practical'. Scala and Clojure are probably others in this category.
(Going one level deeper, I think the 'formula for success' here is a language that leans strongly towards 'functional', but has access to vast practical libraries (e.g. .Net/JVM/some C FFI) and has good tooling (e.g. IDE support).)
I at least somewhat agree with the implicit premise of the question, namely that there is a tension between 'succinct/beautiful analytical power' and 'pragmatics'.
Does anyone have examples of functional languages that are great at performing practical tasks or practical tasks that are best performed by functional languages?
Our business runs on F# code, for everything from on-line credit card transactions to web analytics. These LOB apps are composed of tiny F# scripts that do everything required quickly and simply using .NET's seamless interop and automation of applications like Outlook and Excel.
Our business makes most of its money selling software written in F# that solves practical problems to customers from many sectors from embedded software for medical equipment to maritime internet service providers.
IMO, Scheme is too minimalistic to be practical- it is used in several courses for teaching (see Structure and Interpretation of Computer Programs). However, modern Lisp languages like Common Lisp, and especially Clojure are gaining importance. Erlang is used by several large industries for high concurrency applications, and I personally haven't seen it being used by end-user programmers. Haskell on the other hand is quite a real-world language, and has been used to write a lot of wonderful software including:
XMonad is an X Window System window manager written purely in Haskell.
Leksah, an IDE for Haskell is written in Haskell itself.
Pugs, one of the leading implementations of Perl 6 is written in Haskell.
Lastly, the Glasgow Haskell Compiler is written in Haskell.
Funny, you and I have very different notions of "practical tasks". You say it's:
Aceept a request, find and process
requested data, and return it
formatted as needed
This is pretty much what a functional language is made for: functions that take data and return new data without preserving any state in-between calls (ie no side effects). This is what you have here and it's also called piping.
Now this isn't what I'd call a practical task. In modern programs you have to deal with GUI's, multithreaded functions and network I/O. All these have state that is required to hold data in-between function calls. Data isn't piped into a function and the result piped out, the functions affect the "global" state too.
And it's this definition of "practical task" where functional programs start to fail. Writing a GUI in a functional program is pretty much impossible if you don't use their imperative extensions for example.
So in conclusion, the answer you're asking for is a heart-felt yes, functional programs are up to the task. The answer you're really looking for however, is that it's a bit more complicated than that.
Have you ever used LINQ?
If so, congratulations. You have used a functional language in a practical context. This is what functional development is about.
And yes, F# is VERY useful.
Erlang is well known for its robustness and features for writing highly-concurrent servers.
It also has a DBMS out-of-box.
Functional Programming in the Real World
Basically, the tasks I would call
'practical' such as
Aceept a request, find and process
requested data, and return it
formatted as needed
You experimented with Erlang and couldn't find a practical task for it under this description of practical?
Accept a request.
You mean like receive. Or just being called straight up as a function.
Find and process requested data.
I'm not entirely sure what you mean here, but for finding data there's file I/O, networking I/O, (distributed) inter-process communication, etc. etc. etc. For finding subsets of that data there's regular expressions, pattern matching, etc.
For processing there's a whole bunch of stuff for strings, lists, mathematics, sets, graphs, etc. Is this not enough for processing? What else are you looking for?
Return it formatted as needed.
I can return the resulting data as atoms, lists, binary blobs, formatted strings, numbers, etc. What was missing from Erlang in this regard? I'm really honestly confused here.
I'm not sure about 'Practical Tasks' definition and what it refers to.
but in other words I think you are talking about solving problems by algorithms that need to be represented by a programming language. if so then the functional language is very useful and practical.Specially when you have limits in time to find the solution and implement it.
for me I still use non-functional languages when participating in solving complex algorithmic contests like Google CodeJam .
I'm planning to learn a functional language that will be better for me for these kind of tasks or problems.