3 ms·
Thinking on "Why calculating is better than scheming" vs SICP I realize that there is an axis where most programmer's ways of thinking can be placed, with 2 ext
by nnq 14y ago
Thinking on "Why calculating is better than scheming" vs SICP I realize that there is an axis where most programmer's ways of thinking can be placed, with 2 extremes:
- the mathematician-programmers: the thinking in terms of "what is" extreme, or mathematical thinking inspired programming: people closer to this like to think in terms of types and usually dislike dynamic languages, they also like to be able to properly reason about all aspects of a program, to have defined "states" they can think about. These people tend to like MLs, Haskell, OCaml, F#. The "mathematical beauty of perfect code" is their ideal and favorite metaphor. And I think they are right that teaching a Lisp to a beginner pushes ones mind away from "what is" oriented programming.
- the Schemers: the thinking in terms of "what transformations to apply to something (it doesn't matter what "something" actually "is") to get something else or somewhere else" programmer: these people like to be able to transform everything, including code itself, they like homoiconicity or macros in general, they prefer thinking in terms of "how to compose/cahin transofrmations" instead of types, they tend either no know or not value category theory too much and they are ok with seeing code as an "organic entity" that can't always be reasoned about. These people tend to like Lisps, Smalltalk and dynamic languages. The "programming as magick", in the sense of "controlling the spirits (processes) inside computers" is their favorite metaphor. They also like to maintain a playful mood and their "it's ok that paying customers get shafted every now and then" may have had a reason for businesses' dislike for "schemer" types and "schemer" realted technologies. As an offside paradox, some "schemers" tend to also like OOP, though they understand it should not be overused (I consider Alan Kay, usually mentiones as the father of OOP to be a "schemer"). I think that exposing a young learner to Lisp pushes one mind towards this direction, and this is why I love SICP. If you are a competent engineer you surely have a serious amount of math knowledge, so you can easily switch your mind to what-is/math mode and see the mathematical beauty when there is one to be seen, but most "mathematician-programmers" never seem to be able to love this "ruleless organic beauty" of the "schemer way".
I consider myself a "schemer" and I am biased to this side, but I understand and appreciate the value and arguments of the other - I'd rather fly in a plane with the control systems coded by a "mathematician-programmer" than by a "schemer" like me :)
- qu4z-2 14y agoInteresting. I prefer the "programming as magick" metaphor, and would say I have a playful mood regarding programming, but I still like static typing. Having said that, I love higher-order functions and macros as well. Defining it as a continuum feels like I should be either on one end, or somewhere inbetween on the various traits, but I have rather strong attachment to some traits from each side. I think you're right that a lot of the traits you mention tend to be clustered together in programmers though.
- nnq 14y ago...anyone grows to love static typing sooner or later, after endless debugging sessions in dynamic language codebases :) But I think that higher-order functions don't belong to one extreme or the other - anyone uses them, even weekend-coders that do javascript or have been exposed to php 5.4's new features end up using them - they are something so basic that any language has it in one form or another, even C has function pointers. Macros, otoh are a very different creature: they may seem similar to higher order functions in Haskell where you can use hof for what you'd use macros in Lisp, but they are a whole different ball game because you can't reason (formally, or informally but within the "what is" mindview) about code that transforms/generates code (or you can, but it's just TOO HARD), and I guess this is why so many developers are afraid of them and language-designers omitted them or added them as an extra feature and not as core language defining features from day 0 (for example Scala - I bet the language would've been very different if macros would've been there since version 0.1, been more "usable", and used to build more core language features on top of them...).