Interesting. It might make be fun to try and look for "process oriented" vs. "existence/properties" oriented people around, and will sure make for some entertaining lunchtime discussions...

Like the thing with algebra-oriented vs calculus-oriented people eating corn: http://bentilly.blogspot.ro/2010/08/analysis-vs-algebra-pred... :)

I tend to be process oriented by default I guess, even your sine example... The sine function only "clicked" for me after I saw it as the y projection of the radius of the trigonometric circle and imagined that if you attached a pen to this point moving on the y axis while a paper scrolled at constant speed behind it you'd get that ondulating line. Now, I understand that this way of thinking quite biased (I tend to get very good intuitions about "how to build things" but not very good at explaining why they work afterwards), and it can make me miss obvious shortcuts, like looking for what properties and relationships conserve etc. and this is why I make an effort do more "what is" type of thinking about stuff... but "how to" thinking just seems more natural to me. Maybe it's "scientists" vs. "engineers" thing and programming just happens to be a middle-ground where both kinds of people are frequent :)

By the way, I relate to the sine as y projection of a unit circle too, far more than the triangle ratio.

But I relate to it by thinking of the y coordinates of the points between x=-1..1 in a unit-circle, without any drawing utensils/pens/etc.

I don't see why it makes anything easier to consider the process here, rather than just the set of y points, I need to ask some people at work to see how others see it.

Can more people chime in here, perhaps?

Just to make something clear before going away from this discussion: by "process" I don't necessarily think in terms of the drawing utensils/paper etc., I see it more as a "process of generating pixels or data points in a time dependent fashion and visualizing the animation of of the production instructions' results in my head". Or even more abstractly as an abstract ordered sets of instructions that mutate some shared state, it doesn't have to be something visual.

Yeah, I guess less abstract-minded process-thinkers would be more fixated to physical tools and representations, as physical reality is where this way of thinking originated I guess. I imagine drawing something in the sand then erasing it and drawing something else as a story teller moved to illustrating some other stage of the story he was telling Or using an abbacus with beads on a string. Generalize and abstract from this and a von-neumann machine with a bunch of registers suddenly becomes a pretty intuitive way to think about computing things and writing programs... then generalize more and from registers you get to variables, even more and you can have pointers.

It's quite a simple conceptual route from the intuitions of cave men drawing in the sand to programming in C (a good one if you really want to sound condescending to C programmers....) Whereas the conceptual route to lambda calculus and category theory and type systems and monads... that's a long, alien and tortuous one, even if it seems to lead to a wonderful castle.

...ok, now back to banging more imperative oop code for work together with my fellow coding cavemen :)

I don't see how you can separate the two. A point on a unit circle describes a triangle formed by the horizontal step along the X axis, and then a vertical step to get to the circle. The sine is the vertical step, for a unit circle. For a non-unit circle, this has the wrong scale, which is normalized by dividing by the circle radius. And that radius happens to be the third side of the triangle, the hypotenuse. You can ignore the triangle aspect when you assume the unit circle, which makes the hypotenuse 1.