![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 16 Jan 2009 13:30:11 -0600, Mike Raiford wrote:
> Jim Henderson wrote:
>
>> simulated, the math and physics are the same for the airfoil. But for
>> the person doing simulation, there's this thing called a library that
>> we can link into to figure out the fancy math for us - so we don't need
>> to memorise arcane formulae. We just need to know the inputs to a
>> function and the outputs from a function.
>
> I'm playing devil's advocate a bit, but ... what if there is no such
> library that would give you the values you need regarding lift, etc.
> What if part of what you need to do in the simulation is to create these
> calculations? Then you must certainly know these arcane formulae.
>
> Granted, if something is needed enough, you won't be the first person to
> do it and a solution will be available...
When it comes to formulae for airfoil calculations, that's all pretty
well established now.
But even if you needed to create the library, how many people do you know
who would rely solely on their memory when creating a library that
hundreds or thousands of people might end up using? I know *I'd* be
referring to my books to make sure I implemented the formula correctly.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> You don't need to know algebra to know how to write a program? You don't
> need to know how "and" and "or" works to write a program?
>
> You can't understand what a compiler does without knowing any abstract
> algebra. Heck, you can't even know the difference between a literal and
> an expression without knowing abstract algebra. You realize that "pass
> by value" is abstract algebra, right?
OK, now I actually *know* abstract algebra, and your statements still
make no sense to me.
> How do you know if your while loop terminates if you don't know how
> predicate calculus works?
You don't need to know the formal theory to understand how a simple loop
works. Basic intuition will tell you that.
> Actually, I think the answer is more that you know these things, and you
> just don't know the terminology the academics use for much of the stuff.
The discussion seems to be gradually anealing towards the idea that it's
not the *names* that are the problem, but the near-total lack of any
semblance of documentation about them that doesn't assume you already
hold a PhD in advanced mathematics.
For example, the documentation for the Monoid class states
"The monoid class. A minimal complete definition must supply mempty
and mappend, and these should satisfy the monoid laws.
Methods:
- mempty: Identity of mappend.
- mappend: An associative operation.
- mconcat: Fold a list using the monoid. For most types, the default
definition for mconcat will be used, but the function is included in the
class definition so that an optimized version can be provided for
specific types."
Assuming you already know what a monoid is, this is quite transparent.
If you've never heard of a monoid in your life, none of this makes the
slightest semblance of sense. And looking it up on Wikipedia still
doesn't tell you what this has to do with writing useful programs in
Haskell. (Or any other language.)
(The same library features Endo, "the monoid of endomorphisms under
composition". Even I have no clue what in the name of God that actually
means.)
The concensus seems to be that
- Haskell is inherantly mathematical, with a strong emphasis on deep
abstractions.
- Deep abstractions can be hard to learn, so we should document them better.
However - and this is what makes me so angry - there is a strong element
in the community who claim that Haskell should *only* be used by maths
experts. I find that to be arrogant and elitist.
The reasoning behind this seems to be "if you don't study category
theory, you cannot write computer programs, so it's OK for Haskell to
demand that everybody learns category theory before using it". This is
of course easily falsifiable.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> OK, now I actually *know* abstract algebra, and your statements still
> make no sense to me.
I suspect you just never really thought it thru. You know that a compiler is
just a bunch of rewrite rules, for example, right?
Basically, everything a computer program does is mapping strings of bits to
abstract algebras. The I/O of a Turing machine is a mapping from strings of
whatever-symbols-can-be-on-the-tape to abstract algebras.
>> How do you know if your while loop terminates if you don't know how
>> predicate calculus works?
>
> You don't need to know the formal theory to understand how a simple loop
> works. Basic intuition will tell you that.
That's because the basics of predicate calculus are easy to learn. So easy,
you probably already knew them before you knew what it was called.
I have a box with some balls in it. I pull out one ball. It's black. I can
conclude that not all the balls that were in the box were white, right? That
means if I want to check if all the balls are white in a box, I can stop the
loop once I find the first black ball.
>> Actually, I think the answer is more that you know these things, and
>> you just don't know the terminology the academics use for much of the
>> stuff.
>
> The discussion seems to be gradually anealing towards the idea that it's
> not the *names* that are the problem, but the near-total lack of any
> semblance of documentation about them that doesn't assume you already
> hold a PhD in advanced mathematics.
In Haskell, yes, that could be the case. For example, "mempty is the
identity of mappend" makes perfect sense, if you know what "is an identity
of" means.
> Assuming you already know what a monoid is, this is quite transparent.
> If you've never heard of a monoid in your life, none of this makes the
> slightest semblance of sense.
Sounds like someone needs to write a textbook about what the terms in
Haskell means.
> However - and this is what makes me so angry - there is a strong element
> in the community who claim that Haskell should *only* be used by maths
> experts. I find that to be arrogant and elitist.
I suppose that is. I guess it depends on their goals. Telling someone else
what they should or should not use seems arrogant.
> The reasoning behind this seems to be "if you don't study category
> theory, you cannot write computer programs, so it's OK for Haskell to
> demand that everybody learns category theory before using it". This is
> of course easily falsifiable.
Haskell doesn't demand anything. :-) If you write the documentation for
people who don't study category theory, I'm sure Haskell won't object.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> OK, now I actually *know* abstract algebra, and your statements still
>> make no sense to me.
>
> I suspect you just never really thought it thru. You know that a
> compiler is just a bunch of rewrite rules, for example, right?
What do rewrite rules have to do with abstract algebra?
> Basically, everything a computer program does is mapping strings of bits
> to abstract algebras. The I/O of a Turing machine is a mapping from
> strings of whatever-symbols-can-be-on-the-tape to abstract algebras.
Still not making any sense...
>> You don't need to know the formal theory to understand how a simple
>> loop works. Basic intuition will tell you that.
>
> That's because the basics of predicate calculus are easy to learn. So
> easy, you probably already knew them before you knew what it was called.
Well fair enough. But certain people seem to think that "if you haven't
even bothered to do an undergraduate course in advanced mathematics, you
shouldn't be allowed near a computer". Which just seems absurd to me...
>> The discussion seems to be gradually anealing towards the idea that
>> it's not the *names* that are the problem, but the near-total lack of
>> any semblance of documentation about them that doesn't assume you
>> already hold a PhD in advanced mathematics.
>
> In Haskell, yes, that could be the case. For example, "mempty is the
> identity of mappend" makes perfect sense, if you know what "is an
> identity of" means.
...which *I* do, but your typical programmer has *no clue*.
This is really why the whole discussion started. Some blogger tried to
switch from Python to Haskell, and was looking for a class called
"appendable" or something. But no, it's called Monoid. Notice how this
sounds almost exactly like Monad, yet does something wildly different.
(Somebody was even kind enough to point out that a Monad *is* a Monoid.
Yay, that's really going to help...)
>> Assuming you already know what a monoid is, this is quite transparent.
>> If you've never heard of a monoid in your life, none of this makes the
>> slightest semblance of sense.
>
> Sounds like someone needs to write a textbook about what the terms in
> Haskell means.
My favourit is the documentation for the Writer monad. The documentation
basically says "This module is inspired by [some random paper]". The
paper in question is an essay on how to do polymorphic programming. It
mentions a writer monad as a brief 6-line example program in passing,
with no suggestion as to how you use it. Yay for documentation!
We need propper documentation here! The docs for existantial
quantification are similarly vague. (But hey, it's a compiler manual,
not a language tutorial... *sigh*)
>> However - and this is what makes me so angry - there is a strong
>> element in the community who claim that Haskell should *only* be used
>> by maths experts. I find that to be arrogant and elitist.
>
> I suppose that is. I guess it depends on their goals. Telling someone
> else what they should or should not use seems arrogant.
Yeah, what *are* Haskell's goals? An often-quoted one is "avoid success
at all costs". They seem to be doing a good job!
Thing is, I really love Haskell. But I'm not a mathematician, so I can't
understand lots of stuff. And the attitude seems to be "well if you're
not clever like us, you should go back to Python" or similar.
>> The reasoning behind this seems to be "if you don't study category
>> theory, you cannot write computer programs, so it's OK for Haskell to
>> demand that everybody learns category theory before using it". This is
>> of course easily falsifiable.
>
> Haskell doesn't demand anything. :-) If you write the documentation for
> people who don't study category theory, I'm sure Haskell won't object.
Hmm... Do you have *any idea* how many monad tutorials there are?
Not that monads are complicated. They're just very abstract, so it's
kinda hard to explain what they "are".
Imagine trying to explain what a number "is" to somebody who doesn't
already know. Well, I mean sure, the integers are easy enough. But what
about negative numbers? Fractions? Irrationals? Transcendentals?
Imaginary numbers? Hmm... actually, this is pretty hard!
And yet, most people wouldn't think twice about using "numbers". So it
can't be that hard...
I think perhaps that's Haskell's problem. It's a language which excells
at abstracting things, with the result that the standard libraries are
chock-full of constructs so abstract that they can only be named after
terms from mathematics. And even if they weren't, it would *still* be
stupidly hard to explain what they're for...
I guess Haskell will never be popular. :-(
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> What do rewrite rules have to do with abstract algebra?
Algebra *is* rewrite rules.
> Well fair enough. But certain people seem to think that "if you haven't
> even bothered to do an undergraduate course in advanced mathematics, you
> shouldn't be allowed near a computer". Which just seems absurd to me...
Agreed.
> ...which *I* do, but your typical programmer has *no clue*.
I think learning what an identity value is should be pretty easy. :)
> We need propper documentation here! The docs for existantial
> quantification are similarly vague. (But hey, it's a compiler manual,
> not a language tutorial... *sigh*)
So write them.
> Yeah, what *are* Haskell's goals? An often-quoted one is "avoid success
> at all costs". They seem to be doing a good job!
Haskell doesn't have goals. He's dead. The programming language doesn't have
goals. It was never alive.
> Imagine trying to explain what a number "is" to somebody who doesn't
> already know. Well, I mean sure, the integers are easy enough. But what
> about negative numbers? Fractions? Irrationals? Transcendentals?
> Imaginary numbers? Hmm... actually, this is pretty hard!
I don't know. That was like third and fourth grade, here.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Invisible wrote:
>> What do rewrite rules have to do with abstract algebra?
>
> Algebra *is* rewrite rules.
AFAIK, abstract algebra is about the study of anything that has certain
mathematical properties, and what that gives rise to. You don't actually
rewrite anything.
>> ...which *I* do, but your typical programmer has *no clue*.
>
> I think learning what an identity value is should be pretty easy. :)
Yes - if it was documented! (In language relevant to computer
programming...)
>> We need propper documentation here!
>
> So write them.
Gotta understand something before you can explain it.
>> Imagine trying to explain what a number "is" to somebody who doesn't
>> already know. Well, I mean sure, the integers are easy enough. But
>> what about negative numbers? Fractions? Irrationals? Transcendentals?
>> Imaginary numbers? Hmm... actually, this is pretty hard!
>
> I don't know. That was like third and fourth grade, here.
Yeah. But you try summing all that up in a short expression. Quite hard,
isn't it?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Darren New wrote:
>> Invisible wrote:
>>> What do rewrite rules have to do with abstract algebra?
>>
>> Algebra *is* rewrite rules.
>
> AFAIK, abstract algebra is about the study of anything that has certain
> mathematical properties, and what that gives rise to. You don't actually
> rewrite anything.
The rewrite rules specify what the properties are. List some properties for
me, and I'll show you what the rewrite rules are. :-)
"Zero is the identity for addition"
A+0 = A
0+A = A
>>> ...which *I* do, but your typical programmer has *no clue*.
>>
>> I think learning what an identity value is should be pretty easy. :)
>
> Yes - if it was documented! (In language relevant to computer
> programming...)
I dunno. I don't think I could have gotten out of third grade without
knowing the identity value for addition and multiplication.
--
Darren New, San Diego CA, USA (PST)
Why is there a chainsaw in DOOM?
There aren't any trees on Mars.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |