6 ms·

I see a lot of people do stupid shit because they don't seem to think it will make a big difference. One mistake isn't a big deal, is it? The problem is that

I see a lot of people do stupid shit because they don't seem to think it will make a big difference. One mistake isn't a big deal, is it? The problem is that it becomes habit, and then you're making plenty of these, and you think it's okay, but in reality a lot of these mistakes have become normal. I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau. Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better. For example, you can start using more anonymous functions in your code because all the cool kids are doing it, but unless you really understand how to deal with high-order functions and what a map and fold are, you are just going to be doing stupid shit that doesn't really help your code at all.

watmough 15y ago
|Sometimes you need _directed_ learning to push you past that plateau. That and practice. My chess improved noticeable with timed play. Putting a time limit on a game forces you to do 'something', if only to stop losing. In my case, this forced me to eventually develop a strategy and focus my game on actually attacking particular areas of the board. This really improved my game.
doctoboggan 15y ago
On a side note, I just watched Crockford on Javascript and he said lambda functions are the greatest innovation in computer science. Could you point me toward a resource that will explain why?
- shadowfox 15y ago
  I am sure there are better reads. But I found this one a decent back when I read it: http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf A lot of what that particular paper talks about is applicable to other languages that have lambda expressions in them. Some of the examples in it does rely on lazy evaluation though. Laziness is usually encodable in most languages with lambdas. But most aren't lazy by default. Keep that in mind.
- jemfinch 15y ago
  Search for (several) "Lambda the ultimate" papers.
  - djm 15y ago
    Here's a list of them: http://library.readscheme.org/page1.html http://library.readscheme.org/page1.html
- nandemo 15y ago
  Does he really call it an "innovation"? It would be more precise to say that the lambda function is a essential concept in computer science. Lambda functions -- which is just another name for anonymous functions -- are a basic element of lambda calculus, which is one of the foundations of computer science (predating electronic computers). In more practical terms, you need lambdas to have closures, currying and higher-order functions in general. Without that you don't have Lisp, ML, Haskell, etc. http://en.wikipedia.org/wiki/Anonymous_function http://en.wikipedia.org/wiki/Anonymous_function
joe_the_user 15y ago
Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better. I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple". The problem of overcoming bad habits is a really tough one. In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming. I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors. If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.
- andrewflnr 15y ago
  Regarding performance tests: maybe just try to write code that works the first time, see how big a chunk of code you can write at once and still have it work the first time. And when it doesn't work, don't just fix it, analyze what happened and learn from it specifically to avoid making similar mistakes in the future. You'll acquire (I'm guessing) a list of things to avoid that eventually become good habits, enabling you to get stuff done faster and concentrate on more important things. I guess it's mainly a matter of avoiding the avoidable mistakes. Not that I've done this. I should.
  - jacques_chester 15y ago
    You've described, very roughly, the basis of the SEI's "Personal Software Process". Keep records of your errors, study what you do wrong, change your personal process to drive them out, repeat.
- joelhooks 15y ago
  The concept of code katas approaches this to some extent. http://en.m.wikipedia.org/wiki/Kata_(programming) http://en.m.wikipedia.org/wiki/Kata_(programming)
gwern 15y ago
> I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau. This is exactly right. Ericsson and the related expertise psychology literature calls your directed learning 'deliberate practice'. Have you read the _Cambridge Handbook_ or his 1993 paper http://www.gwern.net/docs/1993-ericsson-deliberatepractice.pdf http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ?
nostrademons 15y ago
Simply using map and folds instead of for-loops is just more stupid shit that doesn't really help your code at all. It's not really any shorter or less bug-prone, and it makes your code harder to follow for people who don't understand map & fold. The real benefit comes from when you understand the concepts behind map and fold. If you realize that fold is nothing but replacing each n-ary constructor of an algebraic data type with an n-ary function, then you recognize that you can do the same thing for data structures besides sequences, like binary trees, graphs, and ASTs. There you're getting some benefit, because there's no built-in language syntax for iterating over those. data List a = a : [a] | [] [1, 2, 3, 4] = (1 : (2 : (3 : (4 : [])))) foldr :: (a -> b -> b) -> b -> [a] -> b foldr (+) 0 [1, 2, 3, 4] = (1 + (2 + (3 + (4 + 0)))) foldr (*) 1 [1, 2, 3, 4] = (1 * (2 * (3 * (4 * 1)))) ...by extension ... data Tree a = Leaf a | Branch (Tree a) (Tree a) foldTree :: (a -> b) -> (b -> b -> b) -> Tree a -> b foldTree f g (Leaf x) = f x foldTree f g (Branch x y) = g (foldTree f g x) (foldTree (f g y) Then you recognize that the GoF calls this the Visitor pattern, because certain stupid languages don't have higher-order functions or algebraic data types, and so you need to make the equivalencies between concrete subclass => ADT constructor, Visitor => function, and object state => return value. Suddenly a lot of modularized compiler libraries (eg. LLVM) make a lot more sense. Then you realize that a map is nothing but a list-fold where the binary operation is constrained to be the composition of some arbitrary function of the element together with a cons operator: map :: (a -> b) -> [a] -> [b] map f = foldr ((:) . f) [] The cool thing about this formalism is that it makes it explicit that f depends only upon the single element of the sequence, and that the ordering of the resulting list is independent of the actions of f. In other words, map can be parallelized. And that lays the groundwork for MapReduce, which lays the groundwork for massive-scale parallel data processing.
- Radim 15y ago
  What lays the groundwork any massive-scale parallel data processing is a lot of good engineering, being aware of the common execution scenarios and relations to the environment (incl. HW). Plus tinkering with little devilish "details". Pretty much the opposite of the (true but trivial) concept that ordering of the result is independent of the map function. TL;DR What you wrote at the end sounded a bit analogous to saying startups succeed because of their idea, while they succeed for a number of things -- mostly the execution and how much other people like the idea in the real world.
Produce 15y ago
In regard to what you said about determined and directed practice, it's essentially a case of it being more about the quality, not quantity of time spent on something. I realised this a number of years ago and have been utilising it ever since. Most people tend to keep going down one particular route when they're trying to achieve something and, when they hit a roadblock, they keep pushing forward. This is working harder. The alternative is to go in a completely different direction where, rather counter-intuitively, we have a chance of picking up information/experience which will get rid of the previously encountered road block. This is working smarter. If something seems too difficult, it probably is, and the reason for that is that one is missing key pieces. Doing the same thing will not find these pieces but looking in non-obvious places will (since if it was obvious, it wouldn't be difficult in the first place). I think that the mechanics behind this consist of what is basically, to borrow a term from comp sci, an impedance mismatch between our internal maps of the world and the shared maps we call physics or math or piano technique. We tend to organise things in a particular way so that we can communicate about them with each other but this shared set of symbols is never the same as an individuals' internal representation. I think that the reason all internal maps are different is because the subject (the human) is an integral part of them. In other words, one's understanding of gravity will have shared symbolism with completely subjective experiences that have nothing to do with gravity. The process of learning is essentially a mapping of one set of symbols to another. More accurately, there seem to be three levels, the experience itself, the internal symbols relating to the experience and the external shared symbols we use to communicate with each other. Based on this, I think that the categorisations in the shared map rarely make sense internally and that, as a layman, following the lines drawn by the categorisations doesn't make sense, hence the roadblocks that people encounter. To put it another way, the categorisations we have in our shared knowledge are primarily for communication purposes and are, objectively speaking, irrational. Separating math from physics from music does not make sense in real terms since they are different perspectives on the same system. Or, to put it yet another way, the map is not the territory and those who understand that are much more adept at navigating with maps.
lepacheco 15y ago
People do stupid shit because most of the time they don't know "what" is the stupid shit in whatever they are doing. It is hard and only looks easy on hindsight. This is the part were a mentor or good teacher can make a HUGE difference.

watmough 15y ago

|Sometimes you need _directed_ learning to push you past that plateau. That and practice. My chess improved noticeable with timed play. Putting a time limit on a game forces you to do 'something', if only to stop losing. In my case, this forced me to eventually develop a strategy and focus my game on actually attacking particular areas of the board. This really improved my game.

doctoboggan 15y ago

On a side note, I just watched Crockford on Javascript and he said lambda functions are the greatest innovation in computer science. Could you point me toward a resource that will explain why?

shadowfox 15y ago
I am sure there are better reads. But I found this one a decent back when I read it: http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf A lot of what that particular paper talks about is applicable to other languages that have lambda expressions in them. Some of the examples in it does rely on lazy evaluation though. Laziness is usually encodable in most languages with lambdas. But most aren't lazy by default. Keep that in mind.
jemfinch 15y ago
Search for (several) "Lambda the ultimate" papers.
- djm 15y ago
  Here's a list of them: http://library.readscheme.org/page1.html http://library.readscheme.org/page1.html
nandemo 15y ago
Does he really call it an "innovation"? It would be more precise to say that the lambda function is a essential concept in computer science. Lambda functions -- which is just another name for anonymous functions -- are a basic element of lambda calculus, which is one of the foundations of computer science (predating electronic computers). In more practical terms, you need lambdas to have closures, currying and higher-order functions in general. Without that you don't have Lisp, ML, Haskell, etc. http://en.wikipedia.org/wiki/Anonymous_function http://en.wikipedia.org/wiki/Anonymous_function

joe_the_user 15y ago

Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better. I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple". The problem of overcoming bad habits is a really tough one. In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming. I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors. If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.

andrewflnr 15y ago
Regarding performance tests: maybe just try to write code that works the first time, see how big a chunk of code you can write at once and still have it work the first time. And when it doesn't work, don't just fix it, analyze what happened and learn from it specifically to avoid making similar mistakes in the future. You'll acquire (I'm guessing) a list of things to avoid that eventually become good habits, enabling you to get stuff done faster and concentrate on more important things. I guess it's mainly a matter of avoiding the avoidable mistakes. Not that I've done this. I should.
- jacques_chester 15y ago
  You've described, very roughly, the basis of the SEI's "Personal Software Process". Keep records of your errors, study what you do wrong, change your personal process to drive them out, repeat.
joelhooks 15y ago
The concept of code katas approaches this to some extent. http://en.m.wikipedia.org/wiki/Kata_(programming) http://en.m.wikipedia.org/wiki/Kata_(programming)

gwern 15y ago

> I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau. This is exactly right. Ericsson and the related expertise psychology literature calls your directed learning 'deliberate practice'. Have you read the _Cambridge Handbook_ or his 1993 paper http://www.gwern.net/docs/1993-ericsson-deliberatepractice.pdf http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ?

nostrademons 15y ago

Simply using map and folds instead of for-loops is just more stupid shit that doesn't really help your code at all. It's not really any shorter or less bug-prone, and it makes your code harder to follow for people who don't understand map & fold. The real benefit comes from when you understand the concepts behind map and fold. If you realize that fold is nothing but replacing each n-ary constructor of an algebraic data type with an n-ary function, then you recognize that you can do the same thing for data structures besides sequences, like binary trees, graphs, and ASTs. There you're getting some benefit, because there's no built-in language syntax for iterating over those. data List a = a : [a] | [] [1, 2, 3, 4] = (1 : (2 : (3 : (4 : [])))) foldr :: (a -> b -> b) -> b -> [a] -> b foldr (+) 0 [1, 2, 3, 4] = (1 + (2 + (3 + (4 + 0)))) foldr (*) 1 [1, 2, 3, 4] = (1 * (2 * (3 * (4 * 1)))) ...by extension ... data Tree a = Leaf a | Branch (Tree a) (Tree a) foldTree :: (a -> b) -> (b -> b -> b) -> Tree a -> b foldTree f g (Leaf x) = f x foldTree f g (Branch x y) = g (foldTree f g x) (foldTree (f g y) Then you recognize that the GoF calls this the Visitor pattern, because certain stupid languages don't have higher-order functions or algebraic data types, and so you need to make the equivalencies between concrete subclass => ADT constructor, Visitor => function, and object state => return value. Suddenly a lot of modularized compiler libraries (eg. LLVM) make a lot more sense. Then you realize that a map is nothing but a list-fold where the binary operation is constrained to be the composition of some arbitrary function of the element together with a cons operator: map :: (a -> b) -> [a] -> [b] map f = foldr ((:) . f) [] The cool thing about this formalism is that it makes it explicit that f depends only upon the single element of the sequence, and that the ordering of the resulting list is independent of the actions of f. In other words, map can be parallelized. And that lays the groundwork for MapReduce, which lays the groundwork for massive-scale parallel data processing.

Radim 15y ago
What lays the groundwork any massive-scale parallel data processing is a lot of good engineering, being aware of the common execution scenarios and relations to the environment (incl. HW). Plus tinkering with little devilish "details". Pretty much the opposite of the (true but trivial) concept that ordering of the result is independent of the map function. TL;DR What you wrote at the end sounded a bit analogous to saying startups succeed because of their idea, while they succeed for a number of things -- mostly the execution and how much other people like the idea in the real world.

Produce 15y ago

In regard to what you said about determined and directed practice, it's essentially a case of it being more about the quality, not quantity of time spent on something. I realised this a number of years ago and have been utilising it ever since. Most people tend to keep going down one particular route when they're trying to achieve something and, when they hit a roadblock, they keep pushing forward. This is working harder. The alternative is to go in a completely different direction where, rather counter-intuitively, we have a chance of picking up information/experience which will get rid of the previously encountered road block. This is working smarter. If something seems too difficult, it probably is, and the reason for that is that one is missing key pieces. Doing the same thing will not find these pieces but looking in non-obvious places will (since if it was obvious, it wouldn't be difficult in the first place). I think that the mechanics behind this consist of what is basically, to borrow a term from comp sci, an impedance mismatch between our internal maps of the world and the shared maps we call physics or math or piano technique. We tend to organise things in a particular way so that we can communicate about them with each other but this shared set of symbols is never the same as an individuals' internal representation. I think that the reason all internal maps are different is because the subject (the human) is an integral part of them. In other words, one's understanding of gravity will have shared symbolism with completely subjective experiences that have nothing to do with gravity. The process of learning is essentially a mapping of one set of symbols to another. More accurately, there seem to be three levels, the experience itself, the internal symbols relating to the experience and the external shared symbols we use to communicate with each other. Based on this, I think that the categorisations in the shared map rarely make sense internally and that, as a layman, following the lines drawn by the categorisations doesn't make sense, hence the roadblocks that people encounter. To put it another way, the categorisations we have in our shared knowledge are primarily for communication purposes and are, objectively speaking, irrational. Separating math from physics from music does not make sense in real terms since they are different perspectives on the same system. Or, to put it yet another way, the map is not the territory and those who understand that are much more adept at navigating with maps.

lepacheco 15y ago

People do stupid shit because most of the time they don't know "what" is the stupid shit in whatever they are doing. It is hard and only looks easy on hindsight. This is the part were a mentor or good teacher can make a HUGE difference.