 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interesting. Even if you don't care about monads per se, if you know C#
syntax, this explains what they are, why they are, why you want them, etc.
It's really little to do with functional programming after all. Or at least,
certainly not only functional programming.
What is a monad, in terms an OOPL programmer would understand:
http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background
Also, how monads are already part of C# and you didn't know it:
http://blogs.msdn.com/b/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/06/2011 09:25 PM, Darren New wrote:
> It's really little to do with functional programming after all.
Lots of people seem to have this idea that monads are something that
only exist in functional programming. (And, further, that it only exists
as some sort of "hack" to get around the fact that functional programs
aren't supposed to have side-effects, yet the entire point of running a
computer program is to produce side-effects.)
That's a bit like saying that monoids are only important in FP. Or that
only FP cares about rings or fields. This is of course nonsense.
(For those that don't know, a "monoid" is simply anything that's
combinable. So numbers are monoids. Anything supporting arithmetic is a
monoid. Anything supporting concatenate or append is a monoid. Anything
that transforms data (to the same result type) is a monad. And so on and
so forth. Similarly, a "field" is, loosely, anything that supports
number-like arithmetic.)
> What is a monad, in terms an OOPL programmer would understand:
> Also, how monads are already part of C# and you didn't know it:
A monad is just a particular way of chaining commands together. I
imagine it's quite common around the place.
What's perhaps telling is that Haskell calls something "Maybe" when C#
apparently calls it "Nullable", and Haskell calls it "Functor" when C#
calls it "IEnumerate"...
(Not to mention "Monoid" verses "Composable"...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/1/2011 1:48, Invisible wrote:
> A monad is just a particular way of chaining commands together. I imagine
> it's quite common around the place.
Yes. But this blog post tells you *what* particular way, as well as why
you'd care, in a way one can understand without functional programming.
> What's perhaps telling is that Haskell calls something "Maybe" when C#
> apparently calls it "Nullable",
In C#, you have some types that are value types (like integers) and some
types that are reference types (like strings, user classes, etc.).
"Nullable" is a generic that lets you take a value type and also let it be null.
The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If you
have a SQL column holding "INT NOT NULL", that's an integer in C#. If you
have a SQL column holding "INT", what is that in C#? Nullable<int>. (Which
you can also write as "int?")
> and Haskell calls it "Functor" when C# calls it "IEnumerate"...
IEnumerable says "I can give you back an object that you can use to iterate
over this collection of values one at a time." It's not the collection, it's
not the enumeration itself. It's the thing that holds the state telling you
how far you have gotten, basically.
> (Not to mention "Monoid" verses "Composable"...)
I don't know what "Composable" is. I don't think C# is meta enough to have
that as a specific language-level concept.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/07/2011 06:55 PM, Darren New wrote:
> On 7/1/2011 1:48, Invisible wrote:
>> A monad is just a particular way of chaining commands together. I imagine
>> it's quite common around the place.
>
> Yes. But this blog post tells you *what* particular way, as well as why
> you'd care, in a way one can understand without functional programming.
Sure. I get that.
>> What's perhaps telling is that Haskell calls something "Maybe" when C#
>> apparently calls it "Nullable",
>
> In C#, you have some types that are value types (like integers) and some
> types that are reference types (like strings, user classes, etc.).
> "Nullable" is a generic that lets you take a value type and also let it
> be null.
>
> The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If
Fair enough. But the net effect appears to be similar.
>> and Haskell calls it "Functor" when C# calls it "IEnumerate"...
>
> IEnumerable says "I can give you back an object that you can use to
> iterate over this collection of values one at a time." It's not the
> collection, it's not the enumeration itself. It's the thing that holds
> the state telling you how far you have gotten, basically.
And a Functor isn't necessarily a container. It's just anything you can
enumerate over, loosely speaking.
>> (Not to mention "Monoid" verses "Composable"...)
>
> I don't know what "Composable" is. I don't think C# is meta enough to
> have that as a specific language-level concept.
It's something you sometimes find implemented in specific application
programs. Write a class with an abstract "combine()" method. Write
subclasses which implement this. Works for strings and containers
[although you'd probably have a more specific name], coordinate
transformations, product orders, command objects...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/1/2011 15:15, Orchid XP v8 wrote:
> Sure. I get that.
You realize that of all the people who might read that, you're pretty much
the bottom of the list of target audience, right? :-)
>> The real use of nullable in C# isn't for "Maybe" cases, but for SQL. If
> Fair enough. But the net effect appears to be similar.
Yeah. You just use it for different things. More like, it's similar in SQL
to Maybe, and you use C#'s Nullable to talk to SQL, so ...
>>> (Not to mention "Monoid" verses "Composable"...)
>>
>> I don't know what "Composable" is. I don't think C# is meta enough to
>> have that as a specific language-level concept.
>
> It's something you sometimes find implemented in specific application
> programs.
That's what I'm saying. "Composable" is a design pattern, not something
actually in the language or libraries.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Interesting. Even if you don't care about monads per se, if you know C#
> syntax, this explains what they are, why they are, why you want them, etc.
> It's really little to do with functional programming after all. Or at least,
> certainly not only functional programming.
> What is a monad, in terms an OOPL programmer would understand:
>
http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background
> Also, how monads are already part of C# and you didn't know it:
> http://blogs.msdn.com/b/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx
Even after reading those, I still don't understand what a "monad" is,
and how it's different from plain inheritance. The articles talk about
composition as if it was some kind of magic trick. I don't get it.
It's a bit like the magical term "currying". There seems to be something
very special about it, but I just fail to understand what it is.
In neither case do I fully understand what exactly is the problem they
are solving, how they are used or why they are useful. In fact, they are
both the strange feature that they seem to be both trivial and extremely
hard to comprehend, at the same time.
And then some people wonder why functional programming isn't more popular.
How can it be, when it's full of trivial-sounding concepts which are, somehow,
almost impossible to understand at the same time?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/07/2011 08:19 AM, Warp wrote:
> Even after reading those, I still don't understand what a "monad" is,
> and how it's different from plain inheritance. The articles talk about
> composition as if it was some kind of magic trick. I don't get it.
And if you sat and read a text on abstract algebra, you would probably
come away thinking that a "field" is some very special, really complex
entity that's almost incomprehensible. And yet actually, you use fields
all the time.
The formal specification of what makes a field is very technical and
abstract. Fields and the theory behind them are of fundamental
importance in a wide range of mathematical disciplines. To say that
"fields are important" is a major understatement.
And yet, lots of people *use* fields all the time. Actually using a
particular field usually isn't complicated at all. (It's the theory
concerning /all possible fields/ which is complicated.)
> It's a bit like the magical term "currying". There seems to be something
> very special about it, but I just fail to understand what it is.
Currying is a simple short-cut, which also allows you to handle
functions of varying numbers of arguments polymorphically. Anyone who
claims it's something more magical than that is just over-excited.
> In neither case do I fully understand what exactly is the problem they
> are solving, how they are used or why they are useful. In fact, they are
> both the strange feature that they seem to be both trivial and extremely
> hard to comprehend, at the same time.
Like one guy said, LINQ is a monad. LINQ solves a real-world problem.
Point is, you don't have to actually *care* that it's a monad in order
for it to be useful - any more than you need to care that Int forms a
subset of a ring with unity, or that Double spectacularly fails to be a
field.
In Haskell it's slightly different, since you can actually define the
concept "this is a monad", and then write functions which work for /any
possible monad/. As far as I can tell, C# can't do that, so knowing that
something is a monad isn't quite so useful. (It doesn't enable you to
apply a whole army of existing functions to something just because it's
a monad.)
> And then some people wonder why functional programming isn't more popular.
> How can it be, when it's full of trivial-sounding concepts which are, somehow,
> almost impossible to understand at the same time?
This is approximately like saying "The Turning machine makes no sense to
me. I have no idea what its purpose is. It seems trivial-sounding and
yet somehow impossible to understand. No wonder computers aren't more
popular!"
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > And then some people wonder why functional programming isn't more popular.
> > How can it be, when it's full of trivial-sounding concepts which are, somehow,
> > almost impossible to understand at the same time?
> This is approximately like saying "The Turning machine makes no sense to
> me. I have no idea what its purpose is. It seems trivial-sounding and
> yet somehow impossible to understand. No wonder computers aren't more
> popular!"
Monads and currying come up all the time when discussing haskell.
Turing doesn't come up when using computers.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/07/2011 05:12 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull> wrote:
>>> And then some people wonder why functional programming isn't more popular.
>>> How can it be, when it's full of trivial-sounding concepts which are, somehow,
>>> almost impossible to understand at the same time?
>
>> This is approximately like saying "The Turning machine makes no sense to
>> me. I have no idea what its purpose is. It seems trivial-sounding and
>> yet somehow impossible to understand. No wonder computers aren't more
>> popular!"
>
> Monads and currying come up all the time when discussing haskell.
> Turing doesn't come up when using computers.
Currying, not so much. (Other than that it's something people often do,
so they use the technical term for it. Rather like inheritance gets
mentioned a lot in OO languages, even though it's just a short cut for
duplicating code.)
Monads get mentioned quite a bit, and in fact there's an almost
embarassing array of monad tutorials - most of them written by people
who just figured out how it works, or by people who think that everyone
understands category theory. There's general agreement that monads are
over-hyped.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Currying, not so much. (Other than that it's something people often do,
> so they use the technical term for it. Rather like inheritance gets
> mentioned a lot in OO languages, even though it's just a short cut for
> duplicating code.)
The difference, to me, is that I understand what inheritance is and why
it's useful. I can't say the same about currying or monads.
Btw, in the articles mentioned in the original post the example is
given of making an int "nullable" via a monad (or something along those
lines). I can't comprehend what this has to do with I/O (or, more precisely,
I can't understand what this kind-of "inheritance", which is what it looks
like to me, has to do with I/O), as the I/O monad seems to be one of the
main concepts of haskell.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
