You lack imagination. Small pox dispersal would cause a lot of problems, and if you are the one dispersing it, you simple shut your borders while it spreads.
Of course, a vaccine would be made pretty quick, so you would reap it's benefits.
Or you create a vaccine before dispersal.
This assume you actual are about who gets it. Maybe you just want to bring death to all infidels because, clearly, your god would protect you.
Well not YOU, but who ever did it.
Al Qaeda did the anthrax attacks. It's pretty much confirmed.
So given all your secret knowledge of what's really going on, imagination and this logic, do you then claim that the US is planning attack with smallpox!?
Yes, I think it's a difference in definitions. There's a lot of redundancy coming up, just to be utterly clear in my understanding of the disconnect.
From our exchange so far I think you are too stuck on mutability, while I insist on using some programming techniques whenever programming language allows them.
I obviously agree that immutable/functional programming style has great benefits, and that most languages do not enforce the style as Haskell does.
I do NOT see the specific language features of anonymous procedures+closures (which is what Lisp "lambdas" really are), recursion, continuation passing style, and the like as having *anything at all to do with functional programming*.
I've no problem in seeing things this way, but the problem in defining things negatively like this is that it does not answer the question: what *does* have to do with (pure or not) functional languages?
An answer I offered was: a purely functional program is made of composition of (no side-effects) functions, and has referential transparency. Category
theory offers us an even more general definition.
I could grant you that referential transparency and immutability are about the same thing (although I prefer referential transparency), but generally you are way too negative:
I've used lots of these (or built-up equivalents) as organizational tools managing *fully mutable state* in C++, Java and other non-"functional" languages, to the same organizational benefit as they yield in functional contexts. None of these require functional programming or are indicators that functional style is being used. You can use them to the exact same benefit without functional programming.
Indeed. The point is clear: LISP, C, C++, Java are all to some extent mixed-paradigm languages, and you can do whatever language allows you to do.
Nobody forces programmer to think about programming he does as being done functionally, imperatively, OO,....
But then mutability is no holly cow either. Consider your example of LISP sort which mutates data. If, for instance, one does sort just to bring data to some canonical order,
then actually it does not matter whether the data is actually mutated or some new sorted data created. The two cases are indistinguishable.
This holds for purely functional Haskell too: if you make some State that has some internal value of some type that represents state, well, you might just as well think of it as being an internal variable that is being mutated as functions dealing with that state are being called.
They're orthogonal concepts.
So the these particular features have nothing to do with being used functionally, nor do their presence in a language make the language any "more" or "less" functional, which was what I started this on.
For example:
It's not just that functional programming restricts, it also offers certain techniques of programming, like continuation-passing.
Continuation-passing style has nothing to do with functional programming, and is available & just as useful in mutable contexts. Functional programming does not "offer" CPS; it's an independent idiom available anywhere, functional or not. Same thing with first-class functions, TCO, etc. They have no connection with functional programming, beyond the connection that the less-than operator has to functional programming (ie, they're used by it, but every style can use it so there's no real link).
I've also used the features in question heavily in strictly immutable contexts in Lisp and Erlang, taking full advantage of MVCC and thread-safety gained from immutability. They're truly general purpose idioms and features, not bound to a particular style. They do not beckon "functional" into their use by their nature and are fully compatible with mutability, offering the *exact* same benefits to both mutable and immutable progra
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors"
It just occured to me that this is not correct definition of monads in Haskell.
Haskell monads are less general than monads in category theory, because Haskell is *not*
describing an arbitrary category, but itself is only an instance of so-called
Cartesian closed categories.
Yeah, it hasn't cleared things up a lot, just a tiny bit up to using category lingo
in a less powerful formalism, so if anybody bothers you again with too much category
stuff in the context of Haskell just send him to me.
Well, there are all kinds of static typing. Already several modern implementations of LISP have it
implemented following the standard (so no extensions) so well that in most cases you get
the speed of C (or, if you will, have to tune the C code to get an edge), and still have all the rest of
high-level construct and GC, and all running fast and stable.
Last I checked, standard Common Lisp doesn't have static typing. It has type hints, which is not the same thing (they are not statically verified - they're only used to optimize). Or are you referring to something else?
Yes, you are right, my bad, it's certainly not a static type system (let alone a-la Haskell or ML),
just type annotations specified by the standard, which some compilers (like SBCL), however,
take more seriously and do type inference and emit warnings about type mismatches during
compiling.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
If only Haskell had some decent tutorials.
I have read a couple, and while reading the second one, I have seen something interesting and I wanted to code it and see how it runs. It was only then I realized that I have read 1.5 Haskell tutorials and I yet can't write/run even Hello World in it. Because none of them even bothered to define what the hell a Haskell program is.
$ ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/:? for help
Loading package ghc-prim... linking... done.
Loading package integer-gmp... linking... done.
Loading package base... linking... done.
Prelude> putStrLn "Hello world!"
Hello world!
Prelude> 1+1
2
Prelude> map (\x -> x*x) [1..10]
[1,4,9,16,25,36,49,64,81,100]
Prelude> foldl1 (+) [1..10]
55
Prelude>:t map
map:: (a -> b) -> [a] -> [b]
Prelude>:t 1
1:: (Num t) => t
Prelude>:t [1..10]
[1..10]:: (Num t, Enum t) => [t]
Prelude>:t \x->x*x
\x->x*x:: (Num a) => a -> a
Haskell might be nice, but judging a language by type of articles about it, both Lisp and Erlang are light years ahead. They explain how to solve problems at hand - and waste much much less pages signing odes how beautiful and concise the syntax is.
Returning to Haskell. I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors". But neither that has advanced my understanding of Haskell or monads any further.
That's very funny stuff! As for category theory, you don't have to
know it to use monads effectively, so I hope the link will be helpful.
I find it a bit difficult to see your responses in terms of the question actually asked, so let's back up a bit. You had originally said that Lisp is "more" functional or "less" functional than other languages,
Yes, I said that,
[...] even though it doesn't have any functional features or assumptions at all. Then you say it's "not functional in the modern sense of the word" (pure functional), implying it's functional in some other sense. I'm asking what sense that is.
I answered, and you got it:
Recursion, first-class functions, recursive data structures, etc, are general purpose programming tools perfectly useful and applicable in any code, including stateful mutating imperative code.
Exactly. Now C doesn't have first class functions, therefore it is less functional than LISP.
The things you list in your 2nd "if" paragraph are focused functional programming tools, but they obviously collide with stateful constructs if they were to coexist in the same language, tending to yield mutually exclusive language features.
Well, they are not just any new cool tools that you can link to or even extend your language with,
they are defining features (of a pure functional programming language.) So they enforce
a certain kind of programming, and exclude as you say some other kinds.
(See also Erlang's tenuous balancing act between the two concepts.)
(it's tenuous alright, I hope it does not fall down!)
Common Lisp's language design doesn't wander into that territory at all. Everything in CL is mutable and there's no mechanisms for communicating functional usage or constraints into the system; they exist purely and solely as programmer discipline, not language features. [italics added]
I agree, and in this sense functional and pure functional differ, as I write in the previous post,
as well as you write in the last and this post. Example:
A single setf inside some optimized loop somewhere in a utility function, or not realizing that something like 'sort' is allowed to trample its parameters, can screw your whole program up if you're trying to stick to functional style, forcing you do manually manage copies for different contexts.
This is then the matter of discipline not to use this technique or to use that technique to
keep coding within a certain style of programming. There's no setf in the functional world,
so one shouldn't use it. For sort one then should always use copy constructor
on the argument.
I'm not aware of any means for the compilers to detect and issue warnings about such intent breaches.
Because it is a matter of style that is not enforced by the language, hopefully that's clear.
And yes, I say this as somebody who develops commercial software using heavily functional style in Common Lisp: There is nothing functional about the language itself.
I'm wondering why you consider it "more functional" than C or other non-pure-functional languages, especially given the age of Lisp and that actual pure functional languages are a recent development.
Apart from the reasons mentioned, it let us program stuff that's hard or impossible in C(++),
for example passing lambdas around (I pass them a lot, it's invaluable). It's not just that
functional programming restricts, it also offers certain techniques of programming, like
continuation-passing.
[LISP is] a strictly ordered, fully mutable language, with some really cool metaprogramming, dispatch, runtime, math, and symbolic features among others. While it's very powerful, it's still completely imperative by nature with no inbuilt concessions to intrinsically support functional discipline. Functional style in Lisp is built on top of ordered
Yes, the metaprogramming and runtime-compiler features are a glaring omission from my post, but other than that it still points towards not being functional. The fact that there are outlier Lisp implementations that don't perform common optimizations yet still conform to the standard simply shows that these are not Common Lisp artifacts but implementation-specific artifacts, so the language itself is not categorized by these.
It is the difference between language specification and language implementation, just as
different C compilers do optimizations differently. If you expect that the tail-recursion is a
must-have feature, then use implementations that support it.
Regarding "the modern sense of the word", has functional ever meant (in a strict sense) anything other than pure functional when it comes to applying the term to a programming language itself?
Yes, people know for the longest time what pure functional means,
but only recently we got purely functional languages. The classic problem was for instance
how to get input-output operations purely functionally.
You can write in functional *style* in any language with a GC (primitive or "userspace"), just like you can write in OO *style* in any language with composite data types (or where it can be faked), but that doesn't mean that the language *itself* is a functional or OO language. When the language itself provides such tools as primitives or actively enforces the programming style, then the language itself bears the title. Lisp really does neither with functional programming, but as a general purpose imperative language (the other styles are substyles of imperative programming in this context due to the strict evaluation order, excluding metaprogramming where you can define your own rules) it's not hard to do functional style even without primitive support for it.
Sure you can use functional style here or there in any language, including assembler.
If, however, by functional language you mean: recursion, functions as objects that can be passed around
like any other objects, recursive data structures, well, a bunch but not all languages qualify.
If, furthermore, by pure functional you mean: everything is a function, referential transparency,
program is a composition of functions and only a composition of functions, well, you can't do it
in LISP, C, C++,...long list..., but you can in Haskell. So they must have solved the problem
of treating I/O purely functionally, and, indeed, there are these monads that melt peoples
brains, so they pass it for devil's work, or, when try to do the same in other modern functional
languages, they just can't do it.
To make things even more interesting, we can't do OO in purely functional languages,
but that's no problem since we don't need to.
But the only way it's "more" functional than C is that it has a GC, allowing functional style without worrying about cleanup. Pretty much everything else in Lisp corresponds to C's functionality, barring the additional primitive datatypes (complex numbers, etc).
Yeah, like C has lists, lambdas, closures, parametric polymorphism, types as
classes, multiple inheritance, macro transformers (I use this expression instead of
saying just macros to avoid readers imagination running wild in thinking that macros
in LISP and in C are somehow similar), then, meta-classes, and probably a few other
things I forgot. (btw, I use complex numbers sometimes in my code, but let's leave
that aside. Let's also leave aside rational numbers, bignums, bit fields (btw, I use
those as well)).
Wait, maybe then we should compare LISP to C++. Well, LISP has all of the above
standardized like 20 years ago.
Even tail-call optimization is not part of the Common Lisp specification and a number of Lisps don't have it.
A number of available and actively maintained LISP implementations, be they commercial
or open-source, have tail recursion implemented.
Haskell is a functional language, with some pseudo-imperative trickery to be able to actually express behavior.
You are obviously well informed about the type system of Haskel, category theory, monads, arrows, etc.
Lisp is an imperative language, though its ease of list creation and GC makes it pretty easy to write in functional style for cons-based data. [...]
LISP is a mixed-paradigm language (imperative, functional, OOP, MOP, generic prog. etc),
so it's not functional in the modern sense of the word, and the word is: purely functional.
Ok, and what do we get then? A program with: functional parts + imperative parts = LISP.
You forget static typing.
Well, there are all kinds of static typing. Already several modern implementations of LISP have it
implemented following the standard (so no extensions) so well that in most cases you get the
speed of C (or, if you will, have to tune the C code to get an edge), and still have all the rest of
high-level construct and GC, and all running fast and stable.
Types are better in OCaml, and even bigger advance was made in Haskell (and other modern FP
languages like Coq.)
Same goes with the latest C++ getting lambdas. I mean great, but is that really an innovation?
C++ lambdas are fairly low-level - e.g. they don't extend the lifetime of variables they capture, so you either have to capture-by-copy or else do your own memory management. So they're much less transparent than lambdas normally are - and that is one of the big selling point of lambdas.
But no, lambdas themselves aren't innovation. Nor is FP. The problem isn't in inventing new stuff - we have loads of it - the problem is getting it into mainstream coding. Sometimes this means dumbing it down.
So the real deal then are purely functional languages. And APL kinds, with their ultra-terseness.
I'm unconvinced that "purely anything" is ever going to be mainstream. Ultimately, different approaches are good for different things. If I'm writing a parser, give me Haskell and Parsec. If I'm writing UI, give me some imperative language, preferably with coroutines or other way to do async yields (e.g. C# 5.0 where async/await is part of the language, or Python where it can be implemented on top of generator methods). And so on. Going forward, languages which combine these techniques, letting you have "islands" of pure functional algorithms in the middle of procedural/OO code are likely to be most popular, in my assessment. That means OCaml, Scala, F# etc - not Haskell.
Sure you can look for mixing of paradigms to get what you want, but mixing language
features (languages) is currently hard to do beyond FFI stuff, which for me is sufficient so
I haven't followed much what's going on in this area, although this direction is interesting.
Mainstream will always lag behind the purists in terms of the theory behind their languages.
This won't matter so long as they invent a language and write the code that does the stuff, until
they start asking questions about the language or their language matures (cases in point: Perl
and Python), when purists will have an upper hand.
The major development here that we see in last, say, 10 years is that languages
like Haskel are getting all the cool theory stuff into writing the "real-life" code for all scales
and domains, so noone can anymore whine "it's academic", and that makes life interesting.
The nice thing with OCaml is that it has all the good old imperative goodness - it even has while and for loops. It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.
So nice! It let's you program imperatively in a purely functional language. Oh, wait..
My favorite code to read is OOP stuff written by coders who understand and make use of functional programming concepts. They know how to write things that are stateless when that makes sense, and use state in an appropriate manner when that makes sense.
And yes, by all means use it when appropriate. But don't think that Lisp is always the right language for scripting your text editor (dodges blow from Emacs partisan).
I don't think functional programming is what you think it is.
Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?
Our brains think imperatively because life is imperative.
Imperative languages dominate computing because the real world is imperative.
Thus spoke Waffle Iron.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
[...]
The big problem is that in a lot of programs you need more than just the pure functions; you need I/O and other side-effects. Functional languages have these but they often feel like odd bits tacked on that corrupt the simple language rules.
Type system of Haskell is powerful enough to do IO, state, "side-effects", etc purely functionally via monads, for instance.
Have all your video transcribed to post it notes. When you want to watch hire a local school kid to flip through the pages real fast and read the dialog aloud.
You're right of course, it's just Apple were the first to make it successful. Perhaps because of the 1-click purchasing they licence from Amazon. Perhaps because searching for apps is easier. Perhaps because developing apps is easy. Perhaps because the app is guaranteed to work on the handful of appliances it's designed to run on. Perhaps because of all of these things... I'm not sure.
Slashdot Mirror
The US also has a Cambridge and built a University there.
Thanks dbill, that was like really insightful and stuff.
Maybe not very well said, but you got good points there...
You lack imagination. Small pox dispersal would cause a lot of problems, and if you are the one dispersing it, you simple shut your borders while it spreads. Of course, a vaccine would be made pretty quick, so you would reap it's benefits. Or you create a vaccine before dispersal.
This assume you actual are about who gets it. Maybe you just want to bring death to all infidels because, clearly, your god would protect you. Well not YOU, but who ever did it.
Al Qaeda did the anthrax attacks. It's pretty much confirmed.
So given all your secret knowledge of what's really going on, imagination and this logic, do you then claim that the US is planning attack with smallpox!?
Yes, I think it's a difference in definitions. There's a lot of redundancy coming up, just to be utterly clear in my understanding of the disconnect.
From our exchange so far I think you are too stuck on mutability, while I insist on using some programming techniques whenever programming language allows them.
I obviously agree that immutable/functional programming style has great benefits, and that most languages do not enforce the style as Haskell does.
I do NOT see the specific language features of anonymous procedures+closures (which is what Lisp "lambdas" really are), recursion, continuation passing style, and the like as having *anything at all to do with functional programming*.
I've no problem in seeing things this way, but the problem in defining things negatively like this is that it does not answer the question: what *does* have to do with (pure or not) functional languages?
An answer I offered was: a purely functional program is made of composition of (no side-effects) functions, and has referential transparency. Category theory offers us an even more general definition.
I could grant you that referential transparency and immutability are about the same thing (although I prefer referential transparency), but generally you are way too negative:
I've used lots of these (or built-up equivalents) as organizational tools managing *fully mutable state* in C++, Java and other non-"functional" languages, to the same organizational benefit as they yield in functional contexts. None of these require functional programming or are indicators that functional style is being used. You can use them to the exact same benefit without functional programming.
Indeed. The point is clear: LISP, C, C++, Java are all to some extent mixed-paradigm languages, and you can do whatever language allows you to do. Nobody forces programmer to think about programming he does as being done functionally, imperatively, OO,....
But then mutability is no holly cow either. Consider your example of LISP sort which mutates data. If, for instance, one does sort just to bring data to some canonical order, then actually it does not matter whether the data is actually mutated or some new sorted data created. The two cases are indistinguishable.
This holds for purely functional Haskell too: if you make some State that has some internal value of some type that represents state, well, you might just as well think of it as being an internal variable that is being mutated as functions dealing with that state are being called.
They're orthogonal concepts.
So the these particular features have nothing to do with being used functionally, nor do their presence in a language make the language any "more" or "less" functional, which was what I started this on.
For example:
It's not just that functional programming restricts, it also offers certain techniques of programming, like continuation-passing.
Continuation-passing style has nothing to do with functional programming, and is available & just as useful in mutable contexts. Functional programming does not "offer" CPS; it's an independent idiom available anywhere, functional or not. Same thing with first-class functions, TCO, etc. They have no connection with functional programming, beyond the connection that the less-than operator has to functional programming (ie, they're used by it, but every style can use it so there's no real link).
I've also used the features in question heavily in strictly immutable contexts in Lisp and Erlang, taking full advantage of MVCC and thread-safety gained from immutability. They're truly general purpose idioms and features, not bound to a particular style. They do not beckon "functional" into their use by their nature and are fully compatible with mutability, offering the *exact* same benefits to both mutable and immutable progra
I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors"
It just occured to me that this is not correct definition of monads in Haskell.
Haskell monads are less general than monads in category theory, because Haskell is *not*
describing an arbitrary category, but itself is only an instance of so-called
Cartesian closed categories.
Yeah, it hasn't cleared things up a lot, just a tiny bit up to using category lingo
in a less powerful formalism, so if anybody bothers you again with too much category
stuff in the context of Haskell just send him to me.
Well, there are all kinds of static typing. Already several modern implementations of LISP have it implemented following the standard (so no extensions) so well that in most cases you get the speed of C (or, if you will, have to tune the C code to get an edge), and still have all the rest of high-level construct and GC, and all running fast and stable.
Last I checked, standard Common Lisp doesn't have static typing. It has type hints, which is not the same thing (they are not statically verified - they're only used to optimize). Or are you referring to something else?
Yes, you are right, my bad, it's certainly not a static type system (let alone a-la Haskell or ML),
just type annotations specified by the standard, which some compilers (like SBCL), however,
take more seriously and do type inference and emit warnings about type mismatches during compiling.
If only Haskell had some decent tutorials.
I have read a couple, and while reading the second one, I have seen something interesting and I wanted to code it and see how it runs. It was only then I realized that I have read 1.5 Haskell tutorials and I yet can't write/run even Hello World in it. Because none of them even bothered to define what the hell a Haskell program is.
$ ghci :? for help ... linking ... done. ... linking ... done. ... linking ... done. :t map :: (a -> b) -> [a] -> [b] :t 1 :: (Num t) => t :t [1..10] :: (Num t, Enum t) => [t] :t \x->x*x :: (Num a) => a -> a
GHCi, version 6.12.1: http://www.haskell.org/ghc/
Loading package ghc-prim
Loading package integer-gmp
Loading package base
Prelude> putStrLn "Hello world!"
Hello world!
Prelude> 1+1
2
Prelude> map (\x -> x*x) [1..10]
[1,4,9,16,25,36,49,64,81,100]
Prelude> foldl1 (+) [1..10]
55
Prelude>
map
Prelude>
1
Prelude>
[1..10]
Prelude>
\x->x*x
Haskell might be nice, but judging a language by type of articles about it, both Lisp and Erlang are light years ahead. They explain how to solve problems at hand - and waste much much less pages signing odes how beautiful and concise the syntax is.
Have you tried Learn You a Haskell for Great Good! ?
Returning to Haskell. I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors". But neither that has advanced my understanding of Haskell or monads any further.
That's very funny stuff! As for category theory, you don't have to
know it to use monads effectively, so I hope the link will be helpful.
I find it a bit difficult to see your responses in terms of the question actually asked, so let's back up a bit. You had originally said that Lisp is "more" functional or "less" functional than other languages,
Yes, I said that,
[...] even though it doesn't have any functional features or assumptions at all. Then you say it's "not functional in the modern sense of the word" (pure functional), implying it's functional in some other sense. I'm asking what sense that is.
I answered, and you got it:
Recursion, first-class functions, recursive data structures, etc, are general purpose programming tools perfectly useful and applicable in any code, including stateful mutating imperative code.
Exactly. Now C doesn't have first class functions, therefore it is less functional than LISP.
The things you list in your 2nd "if" paragraph are focused functional programming tools, but they obviously collide with stateful constructs if they were to coexist in the same language, tending to yield mutually exclusive language features.
Well, they are not just any new cool tools that you can link to or even extend your language with,
they are defining features (of a pure functional programming language.) So they enforce
a certain kind of programming, and exclude as you say some other kinds.
(See also Erlang's tenuous balancing act between the two concepts.)
(it's tenuous alright, I hope it does not fall down!)
Common Lisp's language design doesn't wander into that territory at all. Everything in CL is mutable and there's no mechanisms for communicating functional usage or constraints into the system; they exist purely and solely as programmer discipline, not language features. [italics added]
I agree, and in this sense functional and pure functional differ, as I write in the previous post,
as well as you write in the last and this post. Example:
A single setf inside some optimized loop somewhere in a utility function, or not realizing that something like 'sort' is allowed to trample its parameters, can screw your whole program up if you're trying to stick to functional style, forcing you do manually manage copies for different contexts.
This is then the matter of discipline not to use this technique or to use that technique to
keep coding within a certain style of programming. There's no setf in the functional world,
so one shouldn't use it. For sort one then should always use copy constructor
on the argument.
I'm not aware of any means for the compilers to detect and issue warnings about such intent breaches.
Because it is a matter of style that is not enforced by the language, hopefully that's clear.
And yes, I say this as somebody who develops commercial software using heavily functional style in Common Lisp: There is nothing functional about the language itself.
I'm wondering why you consider it "more functional" than C or other non-pure-functional languages, especially given the age of Lisp and that actual pure functional languages are a recent development.
Apart from the reasons mentioned, it let us program stuff that's hard or impossible in C(++),
for example passing lambdas around (I pass them a lot, it's invaluable). It's not just that
functional programming restricts, it also offers certain techniques of programming, like
continuation-passing.
[LISP is] a strictly ordered, fully mutable language, with some really cool metaprogramming, dispatch, runtime, math, and symbolic features among others. While it's very powerful, it's still completely imperative by nature with no inbuilt concessions to intrinsically support functional discipline. Functional style in Lisp is built on top of ordered
Yes, the metaprogramming and runtime-compiler features are a glaring omission from my post, but other than that it still points towards not being functional. The fact that there are outlier Lisp implementations that don't perform common optimizations yet still conform to the standard simply shows that these are not Common Lisp artifacts but implementation-specific artifacts, so the language itself is not categorized by these.
It is the difference between language specification and language implementation, just as
different C compilers do optimizations differently. If you expect that the tail-recursion is a
must-have feature, then use implementations that support it.
Regarding "the modern sense of the word", has functional ever meant (in a strict sense) anything other than pure functional when it comes to applying the term to a programming language itself?
Yes, people know for the longest time what pure functional means,
but only recently we got purely functional languages. The classic problem was for instance how to get input-output operations purely functionally.
You can write in functional *style* in any language with a GC (primitive or "userspace"), just like you can write in OO *style* in any language with composite data types (or where it can be faked), but that doesn't mean that the language *itself* is a functional or OO language. When the language itself provides such tools as primitives or actively enforces the programming style, then the language itself bears the title. Lisp really does neither with functional programming, but as a general purpose imperative language (the other styles are substyles of imperative programming in this context due to the strict evaluation order, excluding metaprogramming where you can define your own rules) it's not hard to do functional style even without primitive support for it.
Sure you can use functional style here or there in any language, including assembler.
If, however, by functional language you mean: recursion, functions as objects that can be passed around
like any other objects, recursive data structures, well, a bunch but not all languages qualify.
If, furthermore, by pure functional you mean: everything is a function, referential transparency,
program is a composition of functions and only a composition of functions, well, you can't do it
in LISP, C, C++,...long list..., but you can in Haskell. So they must have solved the problem
of treating I/O purely functionally, and, indeed, there are these monads that melt peoples
brains, so they pass it for devil's work, or, when try to do the same in other modern functional
languages, they just can't do it.
To make things even more interesting, we can't do OO in purely functional languages,
but that's no problem since we don't need to.
But the only way it's "more" functional than C is that it has a GC, allowing functional style without worrying about cleanup. Pretty much everything else in Lisp corresponds to C's functionality, barring the additional primitive datatypes (complex numbers, etc).
Yeah, like C has lists, lambdas, closures, parametric polymorphism, types as
classes, multiple inheritance, macro transformers (I use this expression instead of
saying just macros to avoid readers imagination running wild in thinking that macros
in LISP and in C are somehow similar), then, meta-classes, and probably a few other
things I forgot. (btw, I use complex numbers sometimes in my code, but let's leave
that aside. Let's also leave aside rational numbers, bignums, bit fields (btw, I use
those as well)).
Wait, maybe then we should compare LISP to C++. Well, LISP has all of the above
standardized like 20 years ago.
Even tail-call optimization is not part of the Common Lisp specification and a number of Lisps don't have it.
A number of available and actively maintained LISP implementations, be they commercial
or open-source, have tail recursion implemented.
Haskell is a functional language, with some pseudo-imperative trickery to be able to actually express behavior.
You are obviously well informed about the type system of Haskel, category theory, monads, arrows, etc.
Lisp is an imperative language, though its ease of list creation and GC makes it pretty easy to write in functional style for cons-based data. [...]
LISP is a mixed-paradigm language (imperative, functional, OOP, MOP, generic prog. etc),
so it's not functional in the modern sense of the word, and the word is: purely functional.
Ok, and what do we get then? A program with: functional parts + imperative parts = LISP.
You forget static typing.
Well, there are all kinds of static typing. Already several modern implementations of LISP have it
implemented following the standard (so no extensions) so well that in most cases you get
the speed of C (or, if you will, have to tune the C code to get an edge), and still have all the rest of
high-level construct and GC, and all running fast and stable.
Types are better in OCaml, and even bigger advance was made in Haskell (and other modern FP
languages like Coq.)
Same goes with the latest C++ getting lambdas. I mean great, but is that really an innovation?
C++ lambdas are fairly low-level - e.g. they don't extend the lifetime of variables they capture, so you either have to capture-by-copy or else do your own memory management. So they're much less transparent than lambdas normally are - and that is one of the big selling point of lambdas.
But no, lambdas themselves aren't innovation. Nor is FP. The problem isn't in inventing new stuff - we have loads of it - the problem is getting it into mainstream coding. Sometimes this means dumbing it down.
So the real deal then are purely functional languages. And APL kinds, with their ultra-terseness.
I'm unconvinced that "purely anything" is ever going to be mainstream. Ultimately, different approaches are good for different things. If I'm writing a parser, give me Haskell and Parsec. If I'm writing UI, give me some imperative language, preferably with coroutines or other way to do async yields (e.g. C# 5.0 where async/await is part of the language, or Python where it can be implemented on top of generator methods). And so on. Going forward, languages which combine these techniques, letting you have "islands" of pure functional algorithms in the middle of procedural/OO code are likely to be most popular, in my assessment. That means OCaml, Scala, F# etc - not Haskell.
Sure you can look for mixing of paradigms to get what you want, but mixing language
features (languages) is currently hard to do beyond FFI stuff, which for me is sufficient so
I haven't followed much what's going on in this area, although this direction is interesting.
Mainstream will always lag behind the purists in terms of the theory behind their languages.
This won't matter so long as they invent a language and write the code that does the stuff, until
they start asking questions about the language or their language matures (cases in point: Perl
and Python), when purists will have an upper hand.
The major development here that we see in last, say, 10 years is that languages
like Haskel are getting all the cool theory stuff into writing the "real-life" code for all scales
and domains, so noone can anymore whine "it's academic", and that makes life interesting.
It's not a purely functional language.
And yes, it's nice, because it lets you code parts that make more sense imperatively that way, and leave functional for the rest (or vice versa).
Ok, and what do we get then? A program with: functional parts + imperative parts = LISP.
Same goes with the latest C++ getting lambdas. I mean great, but is that really an innovation?
As if nothing changed from the beginning of times.
So the real deal then are purely functional languages. And APL kinds, with their ultra-terseness.
The nice thing with OCaml is that it has all the good old imperative goodness - it even has while and for loops. It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.
So nice! It let's you program imperatively in a purely functional language. Oh, wait..
Lisp is not a functional programming language any more than any other language with a GC is.
Oh, of course. Reading other posts I totally forgot about subtleties of logical reasoning, so, yes, I agree with you.
Lisp is not a functional programming language any more than any other language with a GC is.
It is "more" functional than C and "less" functional than Haskel, but not (only) because of GC. You can have GC also in an imperative language.
[...]
Python is similarly terse, and isn't statically typed. So this isn't about static typing. It's another functional programming fan.
[...]
Wow, what a convoluted reasoning (if this could be called reasoning at all). You must be programming in Python?
This c# code is stupid. [...]
Exactly!
If shorter, more concise code was always better, we'd have switched to APL years ago.
We didn't.
We did.
[...] I've been known to write code so clever and elegant I have no idea what it does just months after I write it.
So one can write then unreadable code in any programming language? What that has to do with functional programming?
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
That was the idea behind APL. You could do amazing things in one line of code.[...]
You still can. Well, maybe not you.
My favorite code to read is OOP stuff written by coders who understand and make use of functional programming concepts. They know how to write things that are stateless when that makes sense, and use state in an appropriate manner when that makes sense.
And yes, by all means use it when appropriate. But don't think that Lisp is always the right language for scripting your text editor (dodges blow from Emacs partisan).
I don't think functional programming is what you think it is.
Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?
Our brains think imperatively because life is imperative.
Imperative languages dominate computing because the real world is imperative.
Thus spoke Waffle Iron.
[...]
The big problem is that in a lot of programs you need more than just the pure functions; you need I/O and other side-effects. Functional languages have these but they often feel like odd bits tacked on that corrupt the simple language rules.
Type system of Haskell is powerful enough to do IO, state, "side-effects", etc purely functionally via monads, for instance.
Have all your video transcribed to post it notes. When you want to watch hire a local school kid to flip through the pages real fast and read the dialog aloud.
Great idea. They must be yellow of course.
You're right of course, it's just Apple were the first to make it successful. Perhaps because of the 1-click purchasing they licence from Amazon. Perhaps because searching for apps is easier. Perhaps because developing apps is easy. Perhaps because the app is guaranteed to work on the handful of appliances it's designed to run on. Perhaps because of all of these things... I'm not sure.
Or perhaps not?