On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin
<[hidden email]> wrote: > > As an aside, the integers form two different monoids. Haskell can't [easily] > handle that. Does anybody know of a language that can? Some of the ML-derived languages can do that. Essentially, your code takes another module which implements a monoid as an argument. The catch is that you have to explicitly provide the monoid implementation in order to use your code. -- Dave Menendez <[hidden email]> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
John Goerzen ha scritto:
> Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: > > > One thing that does annoy me about Haskell- naming. I'm fine with current names. However I would like to see better documentation, and examples. You can't just have in the documentation: this is xxx from yyy branch of mathematics, see this paper. You should explain how (and why) to use xxx. > [...] Regards Manlio Perillo _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cale Gibbard
On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard <[hidden email]> wrote:
> However, "Appendable" carries baggage with it which is highly > misleading. Consider, for instance, the monoid of rational numbers > under multiplication (which, by the way, is quite useful with the > writer transformed list monad for dealing with probabilities) -- you > can claim that multiplication here is a sort of "appending", perhaps, > but it's not really appropriate. It's rather funny that there's a mathematical sense in which all monoid operations *are* appending. The free monoid on a set has appending as its operation, and the free monoid is initial in the category of monoids on that set (by definition), so all monoid operations are appending, modulo some equivalence relation. :) --Max _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, 2009-01-15 at 15:25 -0800, Max Rabkin wrote:
> On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard <[hidden email]> wrote: > > However, "Appendable" carries baggage with it which is highly > > misleading. Consider, for instance, the monoid of rational numbers > > under multiplication (which, by the way, is quite useful with the > > writer transformed list monad for dealing with probabilities) -- you > > can claim that multiplication here is a sort of "appending", perhaps, > > but it's not really appropriate. > > It's rather funny that there's a mathematical sense in which all > monoid operations *are* appending. The free monoid on a set has > appending as its operation, and the free monoid is initial in the > category of monoids on that set (by definition), so all monoid > operations are appending, modulo some equivalence relation. Right. So we start explaining that to new Haskellers. We already have participants in this discussion who can never quite remember where the term Monad comes from; and now we need them to remember some complicated argument about quotients of free monoids justifying the term `Append'? jcc _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by David Menendez-2
On Thursday 15 January 2009 6:21:28 pm David Menendez wrote:
> On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin > > <[hidden email]> wrote: > > As an aside, the integers form two different monoids. Haskell can't > > [easily] handle that. Does anybody know of a language that can? > > Some of the ML-derived languages can do that. Essentially, your code > takes another module which implements a monoid as an argument. > > The catch is that you have to explicitly provide the monoid > implementation in order to use your code. You can do that in Haskell, as well, although it will end up uglier than ML. You can write your own dictionary type: data Monoid a = Monoid { unit :: a , bin :: m -> m -> m } And pass that around: twice :: Monoid m -> m -> m twice mon m = bin mon m m And even manually simulate locally opening the dictionary with a where clause twice mon m = m ++ m where (++) = bin mon This is, after all, what GHC translates type classes into behind the scenes (although that isn't necessarily how they must be implemented). Some folks even argue that type classes are overused and this style should be significantly more common. -- Dan _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
2009/1/15 Andrew Coppin <[hidden email]>:
> OK, well then my next question would be "in what say is defining > configuration files as a monoid superior to, uh, not defining them as a > monoid?" What does it allow you to do that you couldn't otherwise? I'm not > seeing any obvious advantage, but you presumably did this for a reason... I can't speak from the perspective of the Cabal developers, but combining configurations with partial information using a monoid operation is generally a good way to structure things. Basically, this would be analogous to the way that the First monoid (or the Last monoid) works, but across a number of fields. You have an empty or default configuration which specifies nothing that serves as the identity, and then a way of layering choices together, which is the monoid operation. - Cale _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Thomas DuBuisson
Thomas DuBuisson wrote:
>> How does forcing them to learn proposed terminology such as `Appendable' >> help here? Learners of Haskell do still need to learn what the new word >> means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. Intuition tells me: * 'Appendable' add an element to the back of a (finite) linear collection. * There is a 'Prependable' somewhere that add the element to the front. * There is an inverse 'pop' or 'deque' operation nearby. Absolutely none of those things are true. Let's try for 'Mergeable' * mconcat joins two collections, not a collection and an element. * Is should be a split operation. The above is true for the list instance, but false in general. Look at the instances already given that violate the "collection" idea: > Monoid Any > Monoid All > Monoid (Last a) > Monoid (First a) > Num a => Monoid (Product a) > Num a => Monoid (Sum a) And I don't even see an (Ord a)=>(Max a) or a Min instance. So the original article, which coined 'Appendable', did so without much thought in the middle of a long post. But it does show the thinking was about collections and there is one ONE instance of Monoid at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#t%3AMonoid that is about a collection (Monoid ([] a)) that has a split operation. ONE. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
On Thu, 2009-01-15 at 14:11 -0600, John Goerzen wrote:
> On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote: > > John Goerzen wrote: > > > > If we *must* insist on using the most obscure possible name for > > everything, can we at least write some documentation that doesn't > > require a PhD to comprehend?? (Anybody who attempts to argue that > > "monoid" is not actually an obscure term has clearly lost contact with > > the real world.) > > Several people have suggested this, and I think it would go a long way > towards solving the problem. The problem is: this documentation can > really only be written by those that understand the concepts, > understand how they are used practically, and have the time and > inclination to submit patches. Experience suggests there may be no > such people out there :-) > > > As somebody else said, it basically comes down to this: Who the hell is > > Haskell actually "for"? If it's seriously intended to be used by > > programmers, things need to change. And if things aren't going to > > change, then let's all stop pretending that Haskell actually cares about > > real programmers. > > It might surprise you to see me say this, but I don't see this > discussion as necessarily a weakness. I know of no other language > community out there that has such a strong participation of both > academics and applied users. This is a great strength. And, of > course, Haskell's roots are firmly in academia. > > I think there there is a ton of interest in Haskell from the, ahem, > "real world" programmer types. In fact, it seems to me that's where > Haskell's recent growth has been. There are a lot of things showing > up on Hackage relating to networking, Unicode encoding, databases, web > apps, and the like. > > The nice thing about Haskell is that you get to put the theory in > front of a lot of people that would like to use it to solve immediate > programming problems. But they will only use it if you can explain it > in terms they understand. There are plenty of "real world" programmer types who are using these scarily named things, Monoid, Monad, Functor, Existential Quantification. Programmers such as you*. Despite poor documentation, which everyone agrees could be improved, they've somehow managed to understand these things anyway. My impression is that to most of them Monoids, Functors, and Monads are Just Another Interface and Existential Quantification is Just Another Language Feature. There are poorly documented interfaces in every language**. Any "real world" programmer has some (plenty...) of experience dealing with this issue. These programmers do what they need to do to get stuff done. Again, somehow they learn how to use these things without waiting for "us" to provide an "explanation" in "terms they can understand;" too busy trying to get stuff done. > > There are a number of efforts in that direction: various websites, > articles, books, libraries, etc. And I think the efforts are > succeeding. But that doesn't mean there is no room for improvement. No one doubts that there is room for improvement. However, the direction is better documentation, not different names. Better names is fine, but I have not heard any remotely convincing alternative for any of the above terms. * Or me for that matter. I'm not an academic now and certainly wasn't when I started learning Haskell. I didn't know what a monoid was, had never heard of category theory or monads or functors. I was using monads and functors and monoids in less than a month after I started using Haskell. ** Heck, papers and decades worth of mathematical texts at almost every level is a heck of a lot more documentation than most "poorly documented" interfaces have. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Thomas DuBuisson
On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote:
> > How does forcing them to learn proposed terminology such as `Appendable' > > help here? Learners of Haskell do still need to learn what the new word > > means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. In programming, -every- name requires looking up or some other way of checking meaning. Other than perhaps arithmetic operators (and I have had that bite me), I have -never- in any language written code using a name without having some assurance that it actually meant what I thought it meant. Usually you have to "look something up" to even know a name exists no matter how "intuitive" it turns out to be. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cale Gibbard
On Thu, 2009-01-15 at 18:21 -0500, Cale Gibbard wrote:
> While you're absolutely correct and I agree with you, to be fair, > essentially all mathematicians have a sense of "rigourisability" > (whether they recognise it or not), which is a peculiar standard that > they apply to everything they hear or read. The level of rigour at > which mathematicians communicate is designed not to bore the listener > with details that they could easily supply for themselves, being an > intelligent mathematician, and not a mechanical abstraction. Indeed. One way to describe "rigorizable" is that it is (ideally) just enough precision to be unambiguous. Programmers don't have that luxury and thus clarity and hence communication suffer, which was exactly my point. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
Manlio Perillo wrote:
> > I'm fine with current names. > > However I would like to see better documentation, and examples. > > You can't just have in the documentation: > this is xxx from yyy branch of mathematics, see this paper. > > You should explain how (and why) to use xxx. > Absolutely this! I would rather have to look up Monoid than see Appendable used for operations that don't fit my notion of appending. I don't care much what things are called as long as it's accurate. Even so, I typically find Haskell's documentation to be not very helpful, because it's aimed towards category theorists. That is, Haskell documentation often seems to take the approach "The reader is familiar with [branch of abstract mathematics], so knows all these concepts. The job of the documentation is to show how standard terminology from [branch of abstract math] is written in Haskell". The problem with this is that most people aren't familiar with general abstract nonsense, and this documentation is useless for those, i.e. most, people. In fact, most people don't care about how abstract nonsense is written in Haskell. They care about solving their particular problems, and are only interested in abstract nonsense to the sense that it can be useful in solving those problems. Overwhelmingly the documentation does not show how particular concepts apply to actual programming problems, or any concrete problems at all. Here is the current complete documentation for Data.Monoid 'mappend', which happens to be a good example of which I speak: An associative operation That could mean anything. There are lots of associative operations. Should I believe the name that somehow this operation is append-like? If so, and I'm using a list instance, where are items appended to? Is it an append onto the tail of the list, or is it really a cons? I would expect the documentation to cover this, but it doesn't. Far too often the documentation fails to provide this sort of useful, practical information. This is the problem faced by an abstract-nonsense unaware user: I want to accomplish [some task]. Some blogger wrote that [monoids, functors, arrows, etc.] provide a good solution. But when I look up [monoids, functors, etc.] in [some academic paper], it doesn't show how these concepts apply to the problem at hand, or indeed any programming problem at all. In fact, I can't even understand what the doc says without first learning about [even more abstract stuff]. So now the user needs to develop a strong background in [some abstract topic] he/she doesn't care about just to figure out *if* that abstract topic could possibly be useful. At this point most users will give up. If instead they had access to documentation that says "[Monoids] are useful programming abstractions because they can solve problems A, B, and C in these manners, and incidentally they can do all this other stuff too", the same users would not only stick with Haskell longer, they would increase their theoretical awareness at the same time. I think even the most elitist Haskell users would think this is a good outcome. Of course this better documentation would need to be written. Somebody upthread (Duncan?) suggested that suitable individuals may not exist, and I agree with that. Of people who understand the material well enough to document it, many are busy doing other work, and many have no interest or are ideologically opposed to writing documentation of this type. This situation reminds me very much of a particularly well-known article by Milton Babbitt, "Who Cares If You Listen." I expect that many Haskellers would find it interesting at the least. John Lato _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Derek Elkins
Derek Elkins wrote:
> No one doubts that there is room for improvement. However, the > direction is better documentation, not different names. Better names is > fine, but I have not heard any remotely convincing alternative for any > of the above terms. After thinking about it, I think you are right. But, there is a problem -- nobody is stepping up to write that documentation. If we can't get it, then perhaps we ought to fall back on better names. If we *can* get it, all the better, because these things need good docs, regardless of what they're called. I can see it now: a monoid by any other name would smell as sweet... -- John _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by John Goerzen-3
On Thu, Jan 15, 2009 at 9:15 AM, John Goerzen <[hidden email]> wrote:
If you're learning Haskell, which communicates the idea more clearly: But Appendable is wrong. merge :: Ord a => [a] -> [a] -> [a] merge [] ys = ys merge xs [] = xs merge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys) | otherwise = y : merge (x:xs) ys newtype MergeList a = MergeList [a] instance (Ord a) => Monoid (MergeList a) where mempty = MergeList [] mappend (MergeList xs) (MergeList ys) = MergeList (merge xs ys) This is a perfectly good monoid -- one I have used -- but in no sense would I call MergeList "appendable". Also, in what sense is mappend on Endo appending? I just realized that the name "mappend" sucks :-). (++) would be great! In any case, to me being a Monoid is about having an associative operator, not about "appending". The only fitting terms I can think of are equally scary ones such as "semigroup". Which is worse: naming things with scary category names, as in "monad" and "monoid", or naming things with approachable popular names that are wrong (wrt. to their popular usage), as in "class" and "instance". In the former case, the opinion becomes "Haskell is hard -- what the hell is a monad?"; in the latter it becomes "Haskell sucks -- it's class system is totally stupid" because we are violating people's intuitions, rather than providing them with none whatsoever. In a lot of cases there is a nice middle ground. Cases where (1) we can find an intuitive word that does not have a popular CS meaning, or (2) where the popular CS meaning is actually correct ("integer"?). But eg. programming with monads changes the way you think; we cannot rewire people's brains just-in-time with a word. I like the word Monad. It makes people know they have to work hard to understand them. Luke _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Dan Piponi-2
>Your talk of undergraduate courses to concat two lists isn't grounded
>in any kind of reality, muddies the waters, and probably scares people >away from Haskell by giving the impression that it's much harder than >it is. I've been studying Haskell a bit to understand and learn more about functional programming (I'm using F#). I have to say, the scariest thing I've faced was exactly what you say. Everything I read built "monads" up to be this ungraspable thing like quantum mechanics. Even after I actually understood it well enough, I kept thinking I must be missing something because there's so much fuss about it. -Michael _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo <[hidden email]> wrote:
Yeah, monad is on the same level as quantum mechanics. Both are equally simple and popularly construed as ungraspable. (However to grasp monads easily you need a background in FP; to grasp QM easily you need a background in linear algebra) Luke _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Richard Feinman once said: "if someone says he understands quantum
mechanics, he doesn't understand quantum mechanics". But what did he know... Luke Palmer wrote: > On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo <[hidden email] > <mailto:[hidden email]>> wrote: > > >Your talk of undergraduate courses to concat two lists isn't grounded > >in any kind of reality, muddies the waters, and probably scares people > >away from Haskell by giving the impression that it's much harder than > >it is. > > I've been studying Haskell a bit to understand and learn more about > functional programming (I'm using F#). I have to say, the scariest > thing I've faced was exactly what you say. Everything I read built > "monads" up to be this ungraspable thing like quantum mechanics. > > > Yeah, monad is on the same level as quantum mechanics. Both are equally > simple and popularly construed as ungraspable. > > (However to grasp monads easily you need a background in FP; to grasp QM > easily you need a background in linear algebra) > > Luke > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Wagner
Andrew Wagner wrote:
> I think perhaps the correct question here is not "how many instances of > Monoid are there?", but "how many functions are written that can use an > arbitrary Monoid". E.g., the fact that there are a lot of instances of Monad > doesn't make it useful. There are a lot of instances of Monad because it's > useful to have instances of Monad. Why? Because of > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! > Look at all the cool stuff you can automagically do with your type just > because it's an instance of Monad! I think that's the point. What can you do > with arbitrary Monoids? Not much, as evidenced by > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html One example where Monoids (in full generality) are useful is that of measurements in the Data.Sequence paper (which is sadly not implemented in the library, although it is used to maintain the length for efficient indexing), http://www.soi.city.ac.uk/~ross/papers/FingerTree.html The concept applies to any tree that represents an ordered list. The basic idea is that given a measurement for single elements, class Monoid v => Measured a v where measure :: a -> v we can annotate a tree with cached measurements of the corresponding sequences, data Tree a v = Empty | Leaf v a | Node v (Tree a v) (Tree a v) measureTree :: Measured a v => Tree a v -> v measureTree Empty = mzero measureTree (Leaf v _) = v measureTree (Node v _ _) = v which can be calculated easily by smart constructors: leaf :: Measured a v => a -> Tree a v leaf a = Leaf (measure a) a node :: Measured a v => Tree a v -> Tree a v -> Tree a v node l r = Node (measureTree l `mappend` measureTree r) l r Because v is a monoid, the construction satisfies the law measureTree = mconcat . map measure . toList where toList Empty = [] toList (Leaf _ a) = [a] toList (Node _ l r) = toList l ++ toList r All usually efficient tree operations, insertion, deletion, splitting, concatenation, and so on, will continue to work, if the cached values are ignored on pattern matching and the smart constructors are used for constructing the new trees. measure or `mappend` will be called for each smart constructor use - if they take constant time, the complexity of the tree operations doesn't change. Applications include: - finding and maintaining the sum of any substring of the sequence. - maintaining minimum and maximum of the list elements - maintaining the maximal sum of any substring of the sequence (this can be done by measuring four values for each subtree: 1. the sum of all elements of the sequence 2. the maximum sum of any prefix of the sequence 3. the maximum sum of any suffix of the sequence 4. the maximum sum of any substring of the sequence) I also found the idea useful for http://projecteuler.net/index.php?section=problems&id=220 starting out with -- L system basis class Monoid a => Step a where l :: a r :: a f :: a and then providing a few instances for Step, one of which was a binary tree with two measurements. Bertram _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cale Gibbard
+1 to that Regards, John On Jan 15, 2009, at 4:10 PM, Cale Gibbard wrote: > 2009/1/15 Sittampalam, Ganesh <[hidden email]>: >> Lennart Augustsson wrote: >>> I think the documentation should be reasonably newbie-friendly too. >>> But that doesn't mean we should call Monoid Appendable. >>> Appendable is just misleading, since Monoid is more general than >>> appending. >> >> Then why does it have a member named 'mappend'? :-) >> >> Ganesh > > Good question. The names of the methods of the Monoid class are > inappropriate. > > My personal preference would be: > > class Monoid m where > zero :: m > (++) :: m -> m -> m > > (in the Prelude of course) > > - Cale > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Perhaps as a math/CS major I'm a bit biased here, but as a haskell
neophyte, I think my opinion is at least somewhat relevant... The immediate problem is certainly documentation. No one would groan more than once after hearing a term from abstract math if there was sufficient Haskell-oriented language. I can say that a monad is an endo-functor (in this case on Hask) which is the composition of two natural transformations; the clever parrot I am, I can even understand most of this... but that doesn't mean anything to me in a Haskell context; until a new Haskell programmer can find a Hasktionary with relevant terms in a Haskell context, everything is meaningless-- even though I can understand (i.e. apply meaning to) the definition of a monad on Hask, I can't apply the sort of meaning required to program with a monad without either figuring it out through experience, or seeing it shown to me in a programmer-relevant way (Or rather, both need to happen.) On the other hand, I really, really like getting behind things and understanding the theory. In C, well, C is the theory-- if I want to go deeper, I need to learn as much as I can about the way a computer actually, physically works (why, why, then, even have higher level languages?) or I need to take a history lesson so I can figure out the math that helped out... With Haskell, the theory is right there, staring at me. If the documentation were better, I wouldn't *need* to learn it, but if my curiosity is piqued, it's right there. Naming monoid "appendable" kills that-- by trying to make things "warm and fuzzy", you've weakened one of my strongest motivators for programming (especially in Haskell), namely how much of a direct application of cool math it is. I know I'm not the only one. As far as I know, one of the draws of Haskell is the inherent mathematical nature of it-- in how many other languages do people write proofs of correctness because they don't want to write test-cases? The kind of people who are going to be drawn to a language which allows [(x,y)| x<-somelist, y<-someotherlist] are overall, a mathy set of people, and trying to make our terms fuzzy isn't going to change that. So why not embrace it? This leads to another point: monoids are probably called monoids for the same reason monads are monads: they came directly out of higher math. Someone did sit down trying to name this cool new Haskell idea he had and then say, "Oh, of course, it's just [insert "obscure" math word that's used in Haskell]! I'll keep that name." He sat down, and said, "Oh! Wait if I use [insert "obscure" math word that's used in Haskell] this problem is simpler." It's named for what it is: a monoid, a monad, a functor, existential quantification. But there's a deeper problem here, one that can't be resolved inside the Haskell community. The problem is that the "Math?! Scary! Gross!" attitude that's so pervasive in our society is hardly less pervasive in the computer subculture. I shouldn't be more able to discuss abstract math with a conservatory dropout theater student than with someone who plans, for a living, to put well-formed formulae onto a finite state machine. I am. I don't expect the average programmer to be able to give me a well-ordering of the reals (with choice, of course), or to prove that category C satisfying property P must also satisfy property Q; but for God's sake, they better have a good intuition for basic set theory, basic graph theory, and most importantly mathematical abstraction. What is "good coding style" if not making the exact same types of abstractions that mathematicians make? Again, I don't expect a CS major to write a good proof, to explain rings to a 13 year old, or actually "do" real math; but I expect one to be able to read "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. " and be able to get a basic intuitive idea for what a monad is; with some thought of course. I would go so far as to say that a programmer should be able to intuitively understand "a system of objects and associative arrows", even if they can't "do math" with that... Programmers shouldn't be allowed to get away with the absolute ignorance of math that at least 75% of the CS majors at my school pass with. This doesn't mean there isn't a serious problem with Haskell documentation; it also doesn't mean that everyone should have a minor in math to be a programmer, but isn't an introductory course in discrete math required for most CS programs? Then why are programmers so afraid of basic mathematical definitions? And why do so many wear their ignorance and fear of math as a badge of honor? Sorry that this came out as a bit of a rant, but I spend enough time trying to convince people that math isn't horrid and disgusting... Cory Knapp _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Steve Schafer
On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote:
> On Thu, 15 Jan 2009 13:21:57 -0800, you wrote: > > >Where, in the history of western civilization, has there ever been an > >engineering discipline whose adherents were permitted to remain ignorant > >of the basic mathematical terminology and methodology that their > >enterprise is founded on? > > Umm, all of them? Really. So the engineer who designed the apartment building I'm in at the moment didn't know any physics, thought `tensor' was a scary math term irrelevant to practical, real-world engineering, and will only read books on engineering that replace the other scary technical term `vector' with point-direction-value-thingy? I think I'm going to sleep under the stars tonight... > >No one may be a structural engineer, and remain ignorant of physics. No > >one may be a chemical engineer, and remain ignorant of chemistry. Why > >on earth should any one be permitted to be a software engineer, and > >remain ignorant of computing science? > > Do you know any actual working structural or chemical engineers? Um, no. I try to avoid people as much as possible; computers at least make sense. Also anything else to do with the real world :) > Most > engineering disciplines require a basic grasp of the underlying theory, > yes, but not much beyond that. Perhaps I should have said `completely ignorant'? Or do you think that join . join = join . fmap join is of the same level of theoretical depth as quantum orbital mechanics? > Pretty much everything else is covered by > rules (either rules of thumb or published standards). > Show me an electrical engineer who can explain the physics of a pn > junction and how it acts as a rectifier, or a civil engineer who can > explain why the stress/strain curve of a steel beam has the shape that > it does, Again, do engineers know *what* stress is? Do they understand terms like `tensor'? Those things are the rough equivalents of terms like `monoid'. jcc _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |