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 3 years ago.
Improve this question
Trying to learn functional programming approach I was faced with both lambda calculus and Category theory terms.
Could you please explain in layman's terms what are the differences between them, in the scope of FP.
What do they mean for FP?
Thank you!
It's hard to fully answer such a broad question. Below, I tried to provide some insights, but I can not describe these vast topics in only a few paragraphs.
The lambda calculus is the mathematical core of any functional programming language. It can be seen as a very minimalistic programming language, where the key properties of FP can be studied without being distracted by an heavy syntax.
Any programmer, especially if they are FP programmers, should be able to learn the basics of lambda calculus within a few hours of study. Note that, even if the basics are rather simple, the underlying theory is incredibly vast: there's a huge amount of scientific literature dedicated to the lambda calculus. One does not need to know all of this for everyday FP, but reading a few results here and there once in a while can provide some insights on FP. For instance, reading about Church encodings can make one realize how powerful can be a lambda abstraction.
Category theory is one of the most abstract parts of mathematics. Compared with the lambda calculus, it is much harder to study. It can be very challenging.
CT is connected with the lambda calculus mostly because it provides a nice way to understand types. Types in FP have an underlying algebraic structure which can be best understood by categorical means. For instance, in Haskell the types (A, Either B C) and Either (A,B) (A,C) are isomorphic (ignoring bottoms, at least; because a*(b+c) = (a*b)+(a*c) ), roughly meaning that they carry the same amount of information. As another example, currying and uncurrying form the fundamental idea of cartesian closed categories, the "standard" way to interpret simple types.
If you have a programmer's background, you can try Bartosz Milewski's online book Category Theory for Programmers. Still, I would recommend to start from learning some FP and the lambda calculus first.
Related
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 6 years ago.
Improve this question
Haskell is a purely functional language, breaking from traditional object-oriented languages. However, consider the following quote from Alan Kay on the "true" meaning of OOP:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them. -- Alan Kay
and later on:
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).
I'm curious to what extent this style of programming can be achieved in Haskell. In particular, is it possible to structure a Haskell program as a sequence of (something resembling) encapsulated objects passing messages back and forth to each other?
NOTE: I'm looking for examples specific to Haskell, not functional languages at large (when in conflict).
only messaging, local retention and protection and hiding of
state-process
like biological cells and/or individual computers on a network, only
able to communicate with messages
I believe certain Haskell programming patterns do resemble Kay's description, to a degree.
In streaming libraries like conduit, pipes or streaming, it is common to build a computation as a pipeline composed of different stages. Each part of the pipeline is quite independent of the others and can maintain its own private state (you can have "shared" state in the pipeline as well).
The topologies tend to be linear and unidirectional. That said, abstractions like conduit's ZipSink—and the Applicative instance for Folds in the foldl package—let you build "tree-like" topologies that branch out. And pipes can be bidirectional, although I haven't seen many examples that make use of it.
Then there's arrowized functional reactive programming. It lets you build "circuits" of automaton arrows that can even include loops. Each part of the circuit can maintain its own state. As the description of the netwire FRP library states:
This library provides interfaces for and implements wire arrows useful
both for functional reactive programming (FRP) and locally stateful
programming (LSP).
And from the docs of the auto library:
auto works by providing a type that encapsulates value stream
transformers, or locally stateful functions; by specifying your
program as a (potentially cyclic) graph of relationships between value
streams, you create a way of declaring a system based simply on static
relationships between quantities.
Instead of a state monad type solution, where all functions have
access to a rigid global state, auto works by specifying relationships
which each exist independently and on their own, without any global
state.
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 never programmed in a "pure" functional language. I earned my stripes on C and C++, tried Java, C#, PHP etc... but always I found myself going back to C++. Perhaps I'm a bit of a masochist, but I love the low level stuff.
I also find that I can accomplish rapid development quickly through the embedding of LUA, Python or other scripting languages (along with their focus on rapid development).
Long story short, I'm not quitting C/C++ so don't talk me out of it. However I've had little time to learn C++11 and I'm starting to feel the acceleration of the curve towards functional programming happening in the future.
My question is twofold. What language was C++11's concept of lambda functionality "borrowed" from, and what language would be the ideal one, if not that one, or if any to get a feel for "the way" to use C++11's new lambda functionality (no pun intended).
PS: I'm honestly not too happy about the new "bloated" additions to C++. I liked C++ how it was, it's starting to feel like the language is becoming bloated. I won't clam that to be a fact; I hear you have to have experienced a functional language to "get it".
It honestly seems like there is a new heavyweight in town. First it was just "procedural" programming, then came the OOP paradigm shift, while now it seems like things are heading towards the "functional" way of doing things.
Of course procedural programming is still alive and well (inside classes), I have to wonder where the lambda way will fit in (properly used) to class/oop design. Will it just be a replacement for the procedural part? Make OOP a thing of the past (pfft)? Or something else entirely (say, a functional event system generating events for objects encapsulating procedural code)?
I would try to curtail your opinions until you have more rigorous experience of the issues involved.
To paraphrase Bjarne Stroustrup: Functional programming has had a lot of airtime in academia over the last several decades, yet the number of deployed functional systems in industry remains about zero.
More concretely to your question, a lambda is just a short-hand syntactic way to declare a singleton functor object (a class with an operator() function) that captures variables from its enclosing scope as member variables. I wouldn't consider it a "functional programming" concept, any more so than any other entity in C++.
Functional programming generally involves immutable data types (objects that dont change once constructed) and pure functions (functions that have output that depends purely on their input, and nothing else).
If you are interested in functional programming there is a free online course (MOOC) starting right now called Functional Programming Principles in Scala, that serves as a very good and highly regarded introduction to the subject from one of the top Swiss universities.
I can't speak about lambdas in C++11, but I know that part of the rationale for adding lambdas to Java 8 is to enable transparent concurrency support out of the box. How? It provides a (lazy) Stream interface where you can switch between parallel and sequential processing simply by calling parallel and sequential (these methods return new streams, and do not have side effects on existing streams).
If you look at the methods in Stream, you'll quickly notice that without a lambda facility, they would be an extreme pain to use. Have a look at some examples of what you can do with streams in combination with lambdas.
It should be possible to implement a similar library for C++11, if there isn't already such a library.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When I'm developing an understanding of some concept, I find it very unsatisfactory not to be able to see how the apparent etymology of the concept name relates to what I think I'm understanding about the concept. If I can't see the connection, I'm left with the feeling that there's some significant insight the name is trying to convey that I haven't yet discovered.
Monad: From Greek for unity. Mon = one; ad = a group or unit comprising a certain number. This composes to "A group or unit composed of one thing".
http://www.haskell.org/haskellwiki/All_About_Monads says:
"A monad is a way to structure computations in terms of values and sequences of computations using those values. Monads allow the programmer to build up computations using sequential building blocks, which can themselves be sequences of computations." ... "Other monads exist for building computations that perform I/O, have state, may return multiple results, etc"
Nothing much there about one-ness.
http://www.haskell.org/haskellwiki/Monad claims that the one-ness in term monad refers to the one output that a monad will produce. But given that any function produces one output, (and the above reference says "may return multiple results", not to mention out-of-band/error results), and there's nothing about the "group or unit", that explanation seems unconvincing.
Is there some better explanation?
[Edit: Responding to the "off topic" flag. My question is not about the etymology of the word "monad" per se. It is about the Haskell concept of monad, and how the roots of the word monad do or do not inform us about that concept, or perhaps actually misdirect us from understanding the topic. Given that monad is a famously hard-to-communicate concept in Haskell, this is certainly a question about programming.
That this is a salient issue is reinforced by the variation in respondent suggestions regarding how the roots in "monad" might relate to the topic at hand, including the observation that the explanation in Haskell's own documentation is highly suspect.
That said, I'm pretty satisfied with the answers given (thanks all!), so no need to reopen the topic. But I'd advocate not moving it elsewhere, so that others with the same confusion about an important Haskell concept can find it here.]
Is there some better explanation?
Short answer: No, there really isn't.
Slightly less short answer: It's almost certainly related to "monoid", and not related to any other use of "monad" (there are at least two), and the term was coined at a gathering of mathematicians so there's likely not even a written source that's the first use of the term.
Longer answer with quotes and citations: The one I wrote here.
That claim on the wiki about the alleged meaning seems very dubious to me, incidentally.
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.