|
That's where Monads come in in Haskell.
The IO monad wraps a computation and allows it to have side effects (writing/reading).
getLine = do c <- getChar
if c == '\n'
then return ""
else do l <- getLine
return c : l
Most of that is obvious, it reads individual characters and builds up the line (a list of Char) using the ':' operator (the list constructor - 'a' : "bc" is "abc".
It effectively gives you a small imperative sub-language, but retains functional purity. A benefit of this is that side-effects are localised.
It will be evident from the signature of getLine:
getLine :: IO String
That these side-effects are present.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yeah, but even IO is somewhat "pure" in that it doesn't affect the state of the system.
I had to create a card game for school, but how are you going to keep the drawn cards and scores in memory (no file or database)?
In the end I just put the cards and scores in a variable and passed it to just about every function in my application.
According to the teacher that was fine, but it feels dirty...
|
|
|
|
|
That's exactly what the State monad is for - it allows you to create state that, from that point, is implicitly passed through a series of computations.
Here's a little example of its usage as a stack...
import Control.Monad.State
stackManip :: State Stack Int
stackManip = do
push 3
a <- pop
pop
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
That, quite simply, is not function composition. It is simply wrapping one function in another.
LoggingVersion is not even a function, as it has side-effects (writing to console).
Function composition is much more concise, and pure:
descendingSort = (sort . reverse)
Where ".", in Haskell (the functional language I'm most familiar with) is composition.
No need to specify that arguments must be passed from one to another.
Because the two functions are pure, the compiler can perform quite aggressive optimisation and, if multiple cores are available, arrange for them to be distributed between them.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
This is just a nicer syntax for it!
Don't get me wrong, I think nicer syntax is important. It does reduce error rate and make life easier. It can be a selling point.
But it's simply wrong to say C# doesn't do it.
|
|
|
|
|
OK, C# allows function composition, but only to the extent C supports OOP. It is possible, but without syntactical support, I wouldn't really call it "supported", just possible.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
My story is
C
=(big improvement)=> Objective-C
=(that was a regression :'( )=> Java + C++
=(that was a slight improvement)=> .NET,
=(slight improvement)=> .NET + C++/CLI,
=(yet more improvement)=> .NET,
=(yet more improvement)=> .NET,
=(slight improvements)=> .NET
In all those case it was quite obvious from the get go that the improvement were there...
On the other hand, going the Scala way seems contrived and a regression (Java interop? for god's sake man!)
I would definitely be more excited by Go[^], Rust[^], D[^], if not for the lack of good Windows GUI library!
|
|
|
|
|
I think the "efficient immutable data structures" and "first class functions" are the key.
Immutability allows programs to take better advantage of concurrency.
If you haven't coded in a functional language for any time, I would recommend it - it will change the way you approach problems.
I'm with Uncle Bob on this - the more languages you learn, especially ones quite different from those you're familiar with - will keep making you a better developer.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Those are all great points and I agree with you. I recently watched the Pluralsight video, Applying Functional Principles In C# by Vladimir Khorikov and it was fantastic. For a (long) while I felt like functional programming was just ugly syntax, then after watching that I saw that it is actually a paradigm shift to development thinking.
I really like the idea of methods that have no side effects and which always return expected types.
Fantastic stuff and a completely different way of thinking.
|
|
|
|
|
raddevus wrote: Pluralsight video, Applying Functional Principles In C# by Vladimir Khorikov and it was fantastic.
Cheers. Just added to my playlists.
I'm studying a bit of F# at the moment, prompted by a machine learning book I'm reading that uses F#. I started to get a bit lost with the F#, so I'm returning to it for a while. I've had several attempts. It's difficult to retain if you're not using it day to day.
Kevin
|
|
|
|
|
Keep at it, I've been studying Haskell on/off for a couple of years, some bits (monads especially) are only now really sinking in.
Most of us have spent all our time learning imperative languages, the change to functional thinking is much harder. Happily, I am sure that it has made a better programmer whatever language I am using at the time.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I've had several goes at F#, though not used it commercially. Each time I return to it I understand a bit more. 
Kevin
|
|
|
|
|
That's exactly my experience with Haskell.
Had one of those pleasant moments further up in the thread, when I was able to explain how to use State in functional programs - not that long ago I didn't understand it myself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Super Lloyd wrote: What's the point? What can it do that C# can't?
It's to do with what type of problem you are trying to solve. From your link...
"Scala particularly shines when it comes to scalable server software that makes use of concurrent and synchronous processing, parallel utilization of multiple cores, and distributed processing in the cloud.
Its functional nature makes it easier to write safe and performant multi-threaded code. There’s typically less reliance on mutable state and Scala’s futures and actors provide powerful tools for organizing concurrent system at a high-level of abstraction."
Yes, you can do all this in C# or Java but you can do it more expressively and more robustly in the likes of Scala or F#, often utilising distributed computing and concurrency frameworks such as Akka[^]. Akka is itself written in Scala but can be consumed from Java.
A year or so ago it was ported to .NET (Akka.NET[^]) and can be consumed from C#. So you can stick with C# but the ideas ultimately came from functional programming concepts.
Kevin
|
|
|
|
|
You know JavaScript is sitting over in the corner there going "but...but I can be OOP too! And I'm functional! And future proof and stuff! Guys? Guys...?"
Man - developers are a fickle lot.
Personally it's always seemed that you can do anything with any language: it's the libraries and platform that's the trick. Async and parallelisation are awesome, but they are, essentially, optimisations.
It always seems to me that each language merely has a different way of doing the same thing, and more often than not it's purely up to which features you don't want when picking a language.
Of course there's the mindset of procedural vs (pure) functional vs OO vs list-based etc. That one seems to be either a domain driven choice or a masochist drive choice.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Personally it's always seemed that you can do anything with any language: it's the libraries and platform that's the trick. Async and parallelisation are awesome, but they are, essentially, optimisations.
I think it's that (irrespective of libraries) certain classes of problems are more effectively (or more easily) tackled with specific languages.
A good example is the machine learning I'm studying at the moment. The author tackles the first problem using C#. Then he provides the F# solution and you can easily see that the F# is superior in this context. But you have to see a demo to appreciate it. It's quite hard to tell apriori.
But even if you never use a functional language their influence on the OO languages, both features and libraries, is beneficial.
E.g., you can choose to use an excellent framework such as Akka.NET purely in C#. But this is ported from Akka, which is written in Scala, and is in turn a framework for the Actor Model of concurrency that was first implemented in a big way in Erlang, a functional language.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: the Actor Model of concurrency that was first implemented in a big way in Erlang, a functional language.
Carl Hewitt (Wiki)[^] may disagree with that.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I did say in a big way. I think Erlang was the first well-known or popular implementation.
Kevin
|
|
|
|
|
A jaw-dropping new photo shows a probable alien planet orbiting a star that lies 1,200 light-years from Earth. "Zoom in! Enhance!"
|
|
|
|
|
Kent Sharkey wrote: "Zoom in! Enhance!"
(Accompanied by the sound of Deckard using the video-editing console in Blade Runner)
|
|
|
|
|
If they're more advanced, maybe we can learn their technology. If they're more Risan[^], we'll get a good show.
|
|
|
|
|
|
|
|
.NET ecosystem is dangerously oblivious to distributed computing. "Hey gypsy woman, look in your crystal ball and tell me what my future will be "
OK, it might be a bit too long for some people's attention span, but read on to find out why .NET is doomed because of plate armour, or something
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
