Shared publicly  - 
Watching a talk by Temple Grandin, who's visiting Google today. She emphasizes that animals and people with autism are bottom up thinkers, whereas (some) other people are top down thinkers.

Thinking about this, I believe I am a bottom up thinker. I generalize from examples, I can't start with a concept in the abstract, I have to see examples first and then can develop the abstract concept.

Could this explain my difficulties with learning Haskell? Higher-order functions like Functors and Monads seem to be the ultimate abstract concepts.
Steve Han's profile photoKyle Lee's profile photoAKara Magic's profile photoAndres Cuartas's profile photo
I think I might have a similar style of thinking.
Nah, Guido, it's not you. I'm not just a top-down thinker, I'm a former mathematical logician who eats weird computer languages like candy - that's about as well prepared as any programmer could possibly be to grok Haskell, but I too find it hard going.
Funny, I always thought that was my special way of thinking ;-)
With you on this, bottom_up_thinkers += 1
i heard a program recently about autism and why some people are highly functional with autism and others not so, my sons and myself have a form of ADHD, in my day we got labeled lazy and stupid but schools today are much more aware and I am amazed at how well my boys do academically, you have achieved legend status in your field and come across humble and sane - IMHO we need more of your kind of thinking ;)
Monads are best understood by generalising from examples, IMO. But don't get too hung up on understanding monads, it takes a while for the idea to click for most people.
I don't think it's possible at all to "understand" abstract concepts (particularly monads) in the way you can understand concrete concepts. There is no one (real, concrete) thing that all monads are.
The designers of Haskell consider side effects to be bad, but real world programming languages need side effects. So they introduced monads so that they could add side effects to the language in a way that is on the one hand well defined and on the other hand so complex that most people won't use them. I think that once you grasp that basic fact it will start to make sense. But I am not a Haskell expert.
+Ian Lance Taylor That's almost completely wrong. Read Philip Wadler's paper "Comprehending Monads" for examples of pre-IO monads and their usefulness.

It's also inaccurate to say that monads add side effects to the language.
I always thought haskell was more difficult to get started with because it is so different. That said, time/patience seems to help getting past this.
Never stuck long to Haskell, however, I'd rather expected brains surviving in nature need to be pattern recognizer, i.e. buttom up. If you're thinking abstract it is rather how deep and precise the patterns are, you can grasp. Samples are simply abstractions which are too precise, and abstractions which are overly abstract have the tendeny to be worthless. Understanding happens between these extremes.
Hmm by learning from examples you are in danger of "extracting" the wrong conclusions or aspects. As you know examples can proof a thesis wrong but not show general characteristics of hypothesis/structures/whatever. For example (my favorite): when a newb ask for a way to write an image on a block device a lot of people answer: use dd if=imagefile of=/dev/disk
But without knowing the abstract concept of POSIX this newb will always using dd to write on disks, because with this example he doesn't learn the concept of block devices or posix or why cp imagefile /dev/disk works, too, or why cat <imagefile >/dev/disk is the third of 1000 ways to solve the problem...

I don't think you're a bottom-up-thinker, Guido. I think you're just very skilled in reading and understanding other people's solutions(!) for problems you know. (and that's a good thing!)
All science has always been build by observation and empiric method, and find a generalisation to explain/predict, and improve it when examples show it's wrong, trying the other way is just flawed.
+Sven Teresniak I have thought a lot about my ways of understanding things and I really am a bottom-up thinker. A very common thing I have to ask when people explain stuff to me is "can you give me an example of that idea?" Also I prefer to design software bottom up -- I won't generalize until I have at least 2, preferable 3 or more different examples. YAGNI ("You Ain't Gonna Need It") was invented for me. PS. In your example, "the abstract concept of POSIX" makes no sense to me. I'd much rather see the three ways of doing it and I'll come to my own conclusions, thank you.
+Gabriel Pettier That is a common myth actually; science is much more complicated than that. One of Temple Grandin's points is that it takes all kinds of minds.
Temple is amazing. I heard her speak when I was working at +OrganicValley as a web strategist. I'm definitely 'bottom-up' if that means learning from examples.
Yeah okay, I believe you! :)
With POSIX I meant the fact that dd as well as cp, cat, bash, you-name-it, all use open() read() write() close() without any "block device magic". But you cannot see this fact in examples.
I'll go google for some websites about top-down/bottom-up approaches now. Seems very interesting. And I'm not sure to which end of the spectrum I'm more attracted to. :)
I'm currently reading "a popular history of science" so maybe i'm influenced ^^. One of the point is that people going from concepts to reality will try to make reality fit the concepts, and completly ignore the facts proving the concepts wrongs.
+Gabriel Pettier In many cases, a generation later better facts are discovered that disprove those earlier "facts". Remember DDT? This pesticide was one of the big "scientific" discoveries of the 50s or 60s. It took a while to find out that it was also killing life all over the planet.
+Sven Teresniak lawyers I read seems to want current law applied and tested before new ones comes around. It's legislators that want new laws all the time, for the sake of mindless action.

+Guido van Rossum Yes, it takes a lot of time to build science, and we seems to be worse at it than were our ancestors, who trusted more trials and errors and at least failed on a far lower scale. Most scientific "discoveries" of the XIXth and XXth century where just extraction of knowledge from "simple" people that used the stuff and didn't conceptualised on why it would work.

But i'm not sure to see how that contradict what i said.

Anyway, good night, and thanks for python that rocks my world, i don't want to waste your precious time in arguments :).
The way I understood it, Monads are only the best idea they could come up with to make the beautiful world of no-side-effects functional relationships work with the real, non-deterministic world.

+Sven Teresniak, contrary to popular belief bash is not POSIX ;).
+Tom Spanjaard See +Jonathan Cast 's comment on this thread to find a paper by Wadler about monads. Monads are not the only idea to implement functional IO either... See "Uniqueness Typing". Monads are just a general abstraction for a pipeline of functions. They can be used for just about anything, such as introducing the potential for failure in a pipeline (the Maybe monad), adding state in a pipeline (the State monad), or providing a framework for creating a pipeline of functions operating on a list (the List monad). But you're right, Haskell's only current method of IO (save for the horrors of unsafePerformIO) is through the IO monad.
Aww, I miss all the good talks. Will look for the video later. :)
+Guido van Rossum i have several friends who usualy says "can you give me an example of that idea?" right after i've started to explain my abstract idea. they cannot just listen to me for five minutes until i full fill them with a number of examples. i'm getting mad when hear this phrase:)
+Alexander Grabanski, unsafePerformIO is actually how I do Poor Man's Debugging in Haskell, for lack of a decent widely-available debugger with intuitive interface (ha! you say, no such thing exists for any language, and you'd be right ;)).
+Tom Spanjaard unsafePerformIO is pretty good for debugging IO actions. [I guess the "horrors" part was about the violation of referential transparency, and all of the issues (such as memoizing functions that use unsafePerformIO) associated with it]

Although I may appear to be a Haskell programmer from this thread (Which I'm not much of, I'm kinda a beginner), I have to say that I really like gdb for use with C/C++. I can almost always track down exactly what the error is (except when the code is extremely confusing... But that's just bad code. [Which reminds me... I need to rewrite my interpreter])
I like to think more top-down, but I don't think it helps for understanding Haskell. Building from the bottom-up gives you better ideas of where you might encounter partial functions or other error conditions. It also helps prevent unnecessary abstractions from creeping in. YAGNI is a good policy; no need for the generic function until you find yourself writing the same code twice or right before you hit paste.

Using unsafePerformIO for "printf" debugging is a simple cheat that I use myself. unsafePerformIO can even be used safely in production code. The "unsafe" part is that it allows the programmer to write code that is not referentially transparent. If you use usafePerformIO it is "on your head" to make the code referentially transparent, or at least make is only opaque/translucent in ways that are ignorable. (So, debugging with it is fine. But, logging with it is probably not good.)
+Alexander Grabanski, gdb is indeed pretty decent, but a debugger like that only really works for stack-based languages, and you have to make sure your binaries have debugging symbols or it becomes pretty useless. But there's no debugger which visually represents the serial flow of the entire program's execution, where you can go back and forward intuitively at will.
+Tom Spanjaard True... A visual debugger sounds interesting... It would probably be most effective for functional languages. Well, you've identified a need that hasn't been filled... Maybe a good side-project?
+Tom Spanjaard, gdb does actually support running the program backwards. Your binaries don't have to have debugging symbols either, gdb can load those from separate files. (You compile with debugging information and then strip to a separate file.)

There are some visual front-ends to gdb that (e.g.) show the updates to the backtrace and local variables "live", but they tend to be a bit flakey, IME.
+Boyd Smith, are you talking about moving up and down in the call stack? Also, I know about separating the symbols (though there's no reason not to keep them in the ELF binary imo), but lots of open source software seems to default to not building debug symbols and stripping binaries. And yeah, I once tried a graphical front-end to GDB, but I remember it only worked on a limited subset of OSes (read: Linux-only).
+Tom Spanjaard, no not moving up and down the stack (although it does support that) but actually running a program in reverse:

I play with two (graphical front-ends to gdb), one was a KDevelop plug-in, I think, and the other was something simpler, maybe xgdb? I thought both of them would work in kFreeBSD as well as Linux.
Thanks for that link, Prateek! The first example in that blog post already lifted some of the mist I had around bind.
Add a comment...