Live data from Hacker News

Monads are monoids in the category of endofunctors

sambernheim.com

161–170 of 241 posts

Re: Monads are monoids in the category of endofunctors

#161
post #157

Earlier quoted context omitted.

I think you can define it. You just need to be willing to pin down some definitions so there's something you can formally talk about. For example, let's say an "program" (in whatever abstract sense, whether you want to represent it as DAGs of function compositions or as a sequence of instructions or whatever else) takes, by definition, an infinite sequence of input symbols, and produces an infinite sequence of output…

I don't think that captures the aspects people care about most of the "program state" that people care about is unrelated to I/O - particularly in Haskell, people care about programs that are essentially "evaluate this large equation" where there's only one piece of output at the end, but might be a lot of intermediate computation. And the details of what's stored in memory aren't what matters - after all, Haskell ve…

You're muddying the waters here. If you're saying "I/we don't care about a notion of state in Haskell", that's fine; I can't force you to care about something you don't care about. I'm just saying if you did care to, you very well could find a pretty meaningful and useful definition for "state".

The thing is though, the fact that you don't doesn't imply state is meaningless or useless. After all, you're still going to face the fundamental limits on computation that are out there, regardless of the model of computation. It's not like switching to Haskell and beta-reductions suddenly lets you solve every problem instantaneously, right? You're still going to have just as hard of a time (if not harder!) solving a problem like TSP efficiently in Haskell, as you would in Python or Prolog.

Look at it this way: the only reason you wouldn't "care" about state would be that you already know how things are going to turn out, not because the whole notion is itself meaningless. If tomorrow you wrote a Haskell program that factored integers in time & space linear to the input size, you wouldn't toss it into the trash thinking "whatever, time and space are meaningless concepts in FP". You'd absolutely care. Not only would you care, but you'd safely assume everyone else would too. You'd either find a way to profit off those results, or you'd publish them with formal definitions and tell everyone and their grandmother how awesome and meaningful they are. You'd find them as far from meaningless as anything could be. Of course, you're probably not going to get that lucky, but your lack of luck or care for the concepts doesn't render the concepts themselves meaningless.

Re: Monads are monoids in the category of endofunctors

#162
post #26

Earlier quoted context omitted.

> Wait, a functor is just a pure unary function? No. > And an endofunctor is just one of those where the argument type and return type are the same? Yes - "endo" means that in general. E.g. endomorphism. > Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…

> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views. Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being un…

You don’t have to understand category theory to program in FP languages. But if we want to talk about the mathematical basis, you do need a common vocabulary at least to be able to communicate at all.

You could not really explain JIT compilation to someone not knowing anything about computers, could you?

Re: Monads are monoids in the category of endofunctors

#163
post #157

Earlier quoted context omitted.

I don't think that captures the aspects people care about most of the "program state" that people care about is unrelated to I/O - particularly in Haskell, people care about programs that are essentially "evaluate this large equation" where there's only one piece of output at the end, but might be a lot of intermediate computation. And the details of what's stored in memory aren't what matters - after all, Haskell ve…

You're muddying the waters here. If you're saying "I/we don't care about a notion of state in Haskell", that's fine; I can't force you to care about something you don't care about. I'm just saying if you did care to, you very well could find a pretty meaningful and useful definition for "state". The thing is though, the fact that you don't doesn't imply state is meaningless or useless. After all, you're still going t…

> I'm just saying if you did care to, you very well could find a pretty meaningful and useful definition for "state".

I'm not at all convinced. The thing that actually determines the performance of real-word programs these days (after algorithm choice) is cache efficiency, and no mainstream programming model gives you a "state" model that actually lets you reason about that.

> Look at it this way: the only reason you wouldn't "care" about state would be because you already know how things are going to turn out, not because the whole notion is itself meaningless. If tomorrow you wrote a Haskell program that factored integers in time & space linear to the input size, you wouldn't toss it into the trash thinking "whatever, time and space are meaningless concepts in FP". You'd absolutely care. Not only would you care, but you'd safely assume everyone else would too. You'd either find a way to profit off those results, or you'd publish them and tell everyone and their grandmother how awesome and meaningful they are. You'd find them as far from meaningless as anything could be. Of course, you're probably not going to get that lucky, but your lack of luck or care for the concepts doesn't render the concepts themselves meaningless.

Today's programmers put way too much focus on performance given that we as an industry haven't even mastered producing the correct output for any given input. Do I care about how much memory my program will use at runtime? Sure, at some level. Is it something I want front-and-centre in my programming language? No; language features that help me write correct programs are a higher priority.

Re: Monads are monoids in the category of endofunctors

#164
post #163

Earlier quoted context omitted.

You're muddying the waters here. If you're saying "I/we don't care about a notion of state in Haskell", that's fine; I can't force you to care about something you don't care about. I'm just saying if you did care to, you very well could find a pretty meaningful and useful definition for "state". The thing is though, the fact that you don't doesn't imply state is meaningless or useless. After all, you're still going t…

> I'm just saying if you did care to, you very well could find a pretty meaningful and useful definition for "state". I'm not at all convinced. The thing that actually determines the performance of real-word programs these days (after algorithm choice) is cache efficiency, and no mainstream programming model gives you a "state" model that actually lets you reason about that. > Look at it this way: the only reason you…

> The thing that actually determines the performance of real-word programs these days (after algorithm choice) is cache efficiency

> Today's programmers put way too much focus on performance

So statefulness is a meaningless concept in functional programming because... programmers put too much focus on performance? and cache efficiency is what matters?

Is there a logical chain of implications I'm missing here? I feel like we're not even in the same conversation at this point.

Re: Monads are monoids in the category of endofunctors

#165

Earlier quoted context omitted.

Here's how I like to think about things: Values are things . Concrete. Since we are manipulating computers, a value is really just some abstract symbols--1s and 0s occupying a slot in memory. The meaning of the symbols exists on a higher level, what we usually call semantics . Types are a well-studied method to attach semantics to blocks of otherwise meaningless (but concrete!) symbols. By declaring a variable (which…

> then you can "lift" I would say "sigh", but you have to say what you mean.

The point of the quotes around "lift" are that it's a new concept being defined here?

Re: Monads are monoids in the category of endofunctors

#166
post #154
post #135

Earlier quoted context omitted.

> That's a pretty big "except" - there are no side effects except for all the side effects (and there's nothing unique about JavaScript there, that much is the same as almost any other language) It's not like Haskell doesn't have those either though, I don't think it's a very big except. Discussing synchronous I/O in JavaScript is not interesting, were not littering our Haskell with unsafePerformIO either. > JavaScri…

> No, this is just not true, are we using the same JavaScript? JavaScript's functions change only based on modified application state, not on any other side effect. If you read some file (or remote URL) multiple times, you may get different data each time. Haskell makes "functions" with this property clearly distinct from regular functions. Most languages, including JavaScript, don't. That's what matters, not whether…

> If you read some file (or remote URL) multiple times, you may get different data each time.

True, but just like in Haskell that data is not returned by the function, JavaScript functions are pure for I/O.

Re: Monads are monoids in the category of endofunctors

#167
post #166
post #154

Earlier quoted context omitted.

> No, this is just not true, are we using the same JavaScript? JavaScript's functions change only based on modified application state, not on any other side effect. If you read some file (or remote URL) multiple times, you may get different data each time. Haskell makes "functions" with this property clearly distinct from regular functions. Most languages, including JavaScript, don't. That's what matters, not whether…

> If you read some file (or remote URL) multiple times, you may get different data each time. True, but just like in Haskell that data is not returned by the function, JavaScript functions are pure for I/O.

What do you mean "the function"? One can certainly write functions in JavaScript that return the result of an HTTP request, and that result can change each time the function is run. In Haskell you can't do that.

Re: Monads are monoids in the category of endofunctors

#168
post #167
post #166

Earlier quoted context omitted.

> If you read some file (or remote URL) multiple times, you may get different data each time. True, but just like in Haskell that data is not returned by the function, JavaScript functions are pure for I/O.

What do you mean "the function"? One can certainly write functions in JavaScript that return the result of an HTTP request, and that result can change each time the function is run. In Haskell you can't do that.

You can't do that in idiomatic JavaScript, at least I've never done such a thing in the past 15 years. Maybe you could share an example to show me?

Re: Monads are monoids in the category of endofunctors

#169

Earlier quoted context omitted.

I am a self taught programmer who first learned python and then learned Haskell. A lot of concepts in python were difficult when I was new and the same is true for Haskell. I found the Haskell community to be very welcoming and very willing to explain their terms and the reasoning behind them, and I dont find the negative characterizing from you and others about them to be true at all. That's why it really bothers me…

Good points. But I'd note that Haskell's infrastructure around Functor isn't typical of functional languages. Specifically in Haskell, I think it's pretty important to have an idea what functors, monoids and monads are, because these are typeclasses that you will almost certainly be using at some point. Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and i…

I agree with your overall point, but I want to dig in on this bit:

> Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly.

This is true only in an especially strict sense. Haskell's typeclasses provide two basic mechanisms: one for associating a dictionary of data with a type, and one for automatically picking / deducing such a dictionary based on a given type. Only the latter is specific to Haskell (and Scala); the first can be performed even in Java, but you have to explicitly pass the desired dictionary (called a "trait") at all call sites. [0]

I legitimately use traits all the time in Java, and it even has some built-in ones, like Comparator. There's a great paper on the same fundamental technique at [1] (there called "object algebras").

[0] https://www.haskellforall.com/2012/05/scrap-your-type-classe...

[1] https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf

Re: Monads are monoids in the category of endofunctors

#170
post #168
post #167

Earlier quoted context omitted.

What do you mean "the function"? One can certainly write functions in JavaScript that return the result of an HTTP request, and that result can change each time the function is run. In Haskell you can't do that.

You can't do that in idiomatic JavaScript, at least I've never done such a thing in the past 15 years. Maybe you could share an example to show me?

Sure, synchronous XHTMLHttpRequest.send() is an example

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

Certainly it's not idiomatic but that's not lmm's point. The point is that it's possible. In Haskell it's not possible.

Post reply on HN