The article should start by defining what he means by "work". I see mostly functional programming working every day. I even see non-functional programming (grasp!) working every day.
“Mostly functional” programming does not work
41–50 of 58 posts
Re: “Mostly functional” programming does not work
#42I don' understand where he sees the problem in the first C# example? I believe it actually works, the interleaving is OK to happen IMHO. I guess in Haskell it would also happen, as it's also lazy. What am I missing?
Re: “Mostly functional” programming does not work
#43I use Scala for "mostly functional" programming, and it works very well. Sorry, Erik, you are just not where it's at anymore.
Happens to be that Scala is Erik's favorite as well. I must say that the article has a completely different tone than when you'd talk to him personally, though he likes to talk in extremes and only afterwards talks about what is practical yet not in a diminished importance kind of way. I interpret the article just as a big indicator to a fundamental problem how we can express stuff in language and their accompanying…
Talking in extremes is practical, if you want to be heard and/or start a discussion. See this very submission :)
Re: “Mostly functional” programming does not work
#44To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…
That's a good question and a proof that pure FP isn't good for creating "stuff that works". For years the mantra was "bad industry doesn't want to use FP". But nowadays, especially inside a community like HN, this statement doesn't make much sense. There are plenty of side projects and startups, and how many of the successfull ones use pure FP? I think the reason for this is that pure FP replaces classic programming…
[deleted]
Re: “Mostly functional” programming does not work
#45I use Scala for "mostly functional" programming, and it works very well. Sorry, Erik, you are just not where it's at anymore.
[deleted]
Re: “Mostly functional” programming does not work
#46To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…
It does produce results, but the results are probably more hidden. Rumor has it that 50% or more of all telecommunication uses Erlang, a mostly-functional programming language. This is a tremendous success, but few people know of the fact. I like to think that the whole discussion is straw-man. The useful, reusable software can be created in any language. But when every project is a gamble, and most projects starts o…
>It does produce results, but the results are probably more hidden. Rumor has it that 50% or more of all telecommunication uses Erlang, a mostly-functional programming language. This is a tremendous success, but few people know of the fact.
Probably the statement "> 50% of large telecommunications companies have done something with Erlang at some point in time" is correct. I guess you could even make it a 100% considering that parts of routers are often programmed with FP.
However, most stuff is done in imperative languages. ;) Routing and Connection handling is certainly nice using FP, just consider the amazing Hot Code Swapping features in Erlang. On the other hand, writing APIs, connecting those etc. is much more convenient in imperative languages.
Re: “Mostly functional” programming does not work
#47Earlier quoted context omitted.
You need to better learn what you are talking about. Passing data by pointer is perfectly allowable in functional programming, how do you imagine passing something by pointer has side effects? Data.ByteString is basically a pointer to a byte array, and it's one of the most common datastructures in Haskell. Even more importantly, the optimizations the Haskell VM is allowed to do because of the immutability and purity…
I didn't say Haskell. There are numerous programmings languages which only permit pass by value (and no referencing) for "I'm-such-a-smartypants" reasons. I was really bashing the single-paradigm purist approach in general. It's much too rigid and difficult for anyone who isn't a card carrying mensa member.
Do you mean pass-by-value semantics, or copy-values-for-the-caller implementation? If you mean semantics, then yes: FP languages tend to like value semantics. However, I don't see what that has to do with referencing; you can certainly allow only passing things by value, but only pass references: that's what Python and C (and many others!) do, for example.
It sounds like you may be conflating pass-by-reference with passing references.
If you mean implementation: which ones? In the context of immutable and often even persistent data structures, copying them doesn't make a whole lot of sense.
Re: “Mostly functional” programming does not work
#48"It is impossible to make imperative programming languages safer by only partially removing implicit side effects" So when we can call a program safe? My personal definition is that a program is safe when it always gives the right output for the input it was designed for. Of course if you put water in your car won't make it run, the same way if you provide the wrong input to a program might end up in a wrong output. Getting back I do believe in the middle way.
Re: “Mostly functional” programming does not work
#49His argument is that concepts such as laziness lead to unexpected results in imperative languages. However, such problems also occur in pure functional languages: http://stackoverflow.com/questions/5892653/whats-so-bad-abou...
I would like to point out that there are classes of laziness. Haskell's laziness guarantees that an expression will not be evaluated if it is not used. e.g. take_first(42, 42/0) will not return an error. This enables you to construct infinite lists of primes and such.
Some classes of functional languages had lenient evaluation, evaluation is still lazy, but all expressions will be evaluated at some point in the program. You cannot do the infinity tricks, but you can still write the nice recursive functions, those that are used to show off the benefit of laziness.
The Haskell type of laziness bites you in the ass when trying to do parallel evaluation, which is why you need the rpar/rseq constructs to avoid opening the nasty trapdoors that regular evaluation will not hit.
Even besides I/O and parallelism the laziness can bite you. Mainly, it can make it hard to predict memory/processing use, unless you are intimately acquainted with the innards of Haskell.
Re: “Mostly functional” programming does not work
#50It's a shame he's put an introduction to monads smack down in the middle of this otherwise nice argument. If there was ever any objection to pure functional programming it would be that monads are complex and hard to learn and reason about. Putting an explanation of them with all sorts of mathematical terms is not helping the cause.
Not only are monads not the only solution to doing I/O in a pure programming language (stream based I/O or functional reactive being another), they need not such a mathematical explanation.
An I/O monad is a simple class modelling a box. There's two functions for it, one puts something that's not in a box in a box. The other function allows you to give it a function that is applied over the function in the box, without taking it out of the box (this is called a 'bind' operation).
Note that there's no function to take the value out of the box.
The trick is that the only thing that knows how to get the value out of the box is the VM itself. So its task is to at the end of your function, execute whatever function created your monad, and then execute all functions you gave it using the 'bind' functions sequentially over the returned value (which might include unwrapping more i/o monads).
Since every bind function relies on the previous value of the monad, it can naturally only be executed sequentially.
Note that this explanation does not explain monads either in full or very accurately, it's just one of the patterns that monads are used in, and hopefully gives you an idea about how it is that monads are used to enforce encapsulation and sequential execution of effectful functions.