101–110 of 112 posts
Earlier quoted context omitted.
Giving descriptive names just harms intuition building in the long run. I've been writing Haskell for over 5 years and to this day when I see , , >>= in my code I don't substitute English words for them.
> Giving descriptive names just harms intuition building in the long run. Citation needed
Citation needed.
Earlier quoted context omitted.
> Giving descriptive names just harms intuition building in the long run. Citation needed
(In my experience)
Earlier quoted context omitted.
(In my experience)
Like seriously isn't it obvious that I'm stating my opinion? And that the citation is my personal professional Haskell experience? We're talking about intuition building here it's not like I'm gonna be able to Debate You with Hard Facts -__-
Earlier quoted context omitted.
(In my experience)
Like seriously isn't it obvious that I'm stating my opinion? And that the citation is my personal professional Haskell experience? We're talking about intuition building here it's not like I'm gonna be able to Debate You with Hard Facts -__-
Earlier quoted context omitted.
This comment is a textbook example of the Blub Paradox.
For the record, the Blub Paradox is wrong. It hinges on being able to rank computer languages on a one-dimensional axis labeled "power". It turns out that you can't actually do that. For example, the Lisp people are sure they're looking down when they look at Haskell - no macros. But the Haskell people are also sure they're looking down when they look at Lisp - no decent type system. But if they're both looking down…
John A De Goes - A Glossary of Functional Programming
Earlier quoted context omitted.
Like seriously isn't it obvious that I'm stating my opinion? And that the citation is my personal professional Haskell experience? We're talking about intuition building here it's not like I'm gonna be able to Debate You with Hard Facts -__-
Yes it's clear that you're stating your opinion. I asked for supporting evidence because I'm not persuaded by your opinion since I have the opposite opinion.
Calling Functor "Mappable" and Monad "Thenable" doesn't really add much to understanding.
The best advice I ever got was that a Functor is `f` with a function `fmap :: (a -> b) -> f a -> f b` that follows its laws. Same goes for Monad. If it has the type signature & follows the laws, it's a Monad. That's the definition. No need for a cute analogy-oriented name like FlatMap-able or Then-able.
Once you do that, you realize that the way to understand these things is to play type tetris with highly-generic type signatures. You stop needing English/real-world analogies to understand them and instead use the type system to understand the world (the reverse of using "nice" names)
It works really well but it is a steep hill to climb. It helps to talk to others who have climbed it, and it helps to just grind on a project and use Monads without being an expert. You can go a long way just knowing how `do`, `traverse`/`mapM`, etc work and not having big Monad intuition.
Earlier quoted context omitted.
It's weird to call it anomalous ML came first in the programming sphere. What you said is that it's not powerful or expressive enough, but my impression was that they were both expressible in terms of System Fω, an understanding I would like to correct if it's wrong.
> It's weird to call it anomalous ML came first in the programming sphere. Eilenberg and Lane introduced functors (in the sense more or less used by Haskell) in the 40s. > my impression was that they were both expressible in terms of System Fω This is not correct anymore - Fω is insufficient to describe GADTs. You need coercions and equality constraints as well. It's also approximately as useful a claim as "the langu…
Yes.
>This is not correct anymore - Fω is insufficient to describe GADTs. You need coercions and equality constraints as well.
Of course, OCaml has GADTs these days. I suppose neither of them are really Fω anymore, then.
>It's also approximately as useful a claim as "the languages are equally powerful because they're both Turing complete".
Agree to disagree. I think when discussing how powerful a language is, a rigorous notion like Turing completeness or position on the lambda cube is still significant, even if it's not the most immediately visible.
>I'm referring to practicability, not theoretical possibility (and I've clarified as much several times now).
Fair enough, I'll chalk this up to a misunderstanding.
Earlier quoted context omitted.
I can't think of any way for 1 * 1 to be concatenation. I think the point GP was making is that a monoid has something to do with a function f that takes two arguments a and b where there is a single value for b such that f(a, special_value) == a. I think. As someone who doesn't really understand FP concepts I would probably call those functions "functions that can sensibly be used in a call to array.reduce"
It doesn't need to have a perfect metaphor for all possible cases, just something you can picture in an instant: 'behaves like a concating variable length box sequences'. It's a mnemonic / learning aid, not a formal spec. But I can stretch it :) +: concat marbles sequence * : concat prime factors sequence ++: concat box sequence For * , it can also be reduced to + via logarithms. I just don't have a good metaphor for…
Given that this is a thread on functional jargon, it might be interesting to note list metaphors as being useful for thinking about monoid might derive from lists being free monoids (in many contexts). This means that all functions from a collection elements to a monoid can be thought of as functions from that collection into a list with the appropriate type of elements and then a fold (also called a reduction) over that list. This knowledge can be super useful for thinking about program structure e.g. conceptually mapreduce is a general tool for large-scale distributed computation over monoids.
*it’s actually called “mappend”[0], short for monoid append, but I think the point still stands (and there is, in fact, a function called “mconcat”[1] but folds of a list of monoidal values using “mappend” to combine them.)
[0] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-M...
[1] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-M...
Practice programming in a functional language. They enforce a lot of restrictions that you won't be used to, and in overcoming these restrictions, you'll begin to learn and understand the reason for the jargon. It's really hard to explain "abstraction over type constructors" in a pithy manner despite being a relatively simple statement because the obvious follow-up is "but why?" And the answer to that question isn't…