现在的位置: 首页 > 综合 > 正文

Failing To See the Big Picture – Mistakes we make when learning programming

2013年12月14日 ⁄ 综合 ⁄ 共 7180字 ⁄ 字号 评论关闭

Failing To See the BigPicture

Mistakes we make whenlearning programming

 

By pongba (http://blog.csdn.net/pongba)

 

Let’s start with anobvious fact:

The Inconvenient HumanNature, #1
People are inherently more easilyattracted by “interesting” (as opposed to “mundane”) things. (We will define“interesting” in the later parts)

What can we derive fromthis simple axiom?

A lot of things. Butsince we’re talking about learning programming, we shall focus mainly on theimplications it has for how we learn programming.

Programming, theinteresting and the mundane

The Interesting

What was the firstthing that struck you when you first learned how to program? Wasn’t it thesimple fact that you could order a computer to do stuff by simply typing abunch of characters (thinking of the “hello
world” program that we all havewritten)? But what happened then? You (hopefully) would learn the things thathappened under the hood and drove your programs, which leads us to the firstpoint:

If it’s something underthe hood, it’s interesting (therefore attracts people).

People are alwayscurious about the forces behind the phenomenons in nature since the dawn ofhuman civilization. There’s a need for people to seek the reason why somethinghappened. We call it the desire to understand.

After you’ve learnedhow to hack up a program, and the reason why your program works all the waydown to the bit level. What, then, would be the next thing you do? You writeprograms, and in so doing discover more
and more features of your programminglanguage, which means you get more and more familiar with your language and youstart to notice the sorts of things it can do conveniently and those it can’t.That when language tricks step into the picture. Language tricks
areinteresting in that they enable you to do something you usually can’t do. Humanbeings are born problem solvers, we like solving problems just as much as welike seek out the deep reasons why stuff works. But sadly we’re also adeptproblem creators.

In program languagesense, the problems of which we seek for solutions are also the ones created byus. For example, there has recently been a remarked theory suggesting thatdesign patterns are missing language
features. First we create a language that -of course - has some drawbacks which we then use language tricks (such asdesign patterns) to overcome, but as time goes by, we would get to a pointwhere all those kinds of patterns aren’t wealth anymore but instead
turn intopure burdens, which is when we build them into the language. However, bysolving the problems created by the previous language, we often create our ownnew problems. For example, there’s always this “DSL & GPL” (where GPL meansgeneral-purpose language)
debate. On the one hand, building domain specificfeatures into a language has the obvious advantage that it would be a lot moreconvenient for programmers to use when faced with domain-specific programmingtasks, but on the other hand it would also limit the
usage of the language, thusmaking the whole set of runtime system only accessable by itself (yeah, ofcourse I know there’s inter-language operation, but that’s still anotheradditional step don’t you think?). As to GPLs, the main advantage of them is touse
a single runtime system to serve theoretically unlimited application areas.This isn’t without compromises, either. The main compromise is that when facedwith domain-specific problems, a GPL only makes for a second-class language.That’s why Microsoft “invented”
the CLR system; that’s also why Martin Fowlerstarted advocating the so-called 
Language-OrientedProgramming.

So, to sum up, wecreated all kinds of language abstractions to make programming easier. But, asit always has been, by solving one problem (programming convenience) we createother ones. Our language will no doubt
have many drawbacks, that is, ones thatmake certain programming tasks harder to do. That’s where language tricks stepin and 
steal
our focuses
 (I guess you allhave a huge stack of language “techniques” books, right?). If you don’tunderstand what I’m saying, please take a look at any suggested “classic C++books” list.

However, why on earthdo we have to learn those tricks? We don’t, actually. But we tend to. Because:

We’re born problemsolvers, we like solving problems; problems are interesting, even if they’recreated by ourselves.

So, what happens afterthat? We learn new “techniques”. By “techniques”, I mean literally dozens oflibraries, frameworks, APIs, and several new languages dubbed “the next bigthing” (whether or not they say that
explicitly). Again, why do we have tolearn these? We don’t, really. We can learn them on an as-needed basis. One ofthe main reasons we’re attracted to them is because:

We like new stuff. Ifit’s new, it’s interesting.

Another reason is thatwe like to jump on the bandwagon.

The Inconvenient HumanNature, #2
Jumping-on-the-bandwagon
: If everyone is doingit, so should I.

Not only docorporations use this strategy to induce us, we do it ourselves, that is, wecreate our own bandwagon. When some new language or technique comes out, weoften get so excited that we blind ourselves
to the problems it has; we’reblinded by the halo created by its featured features. We often, as a result,regard it as a panacea. We start eagerly to learn it. Programmers are smartanimals, probably too smart. They always yearn for new stuff (check out what’sbeen
discussed on the major programming forums and you will know what I’msaying), just like beasts hungering for blood. You walk around on theprogramming forums, you see thousands and thousands of technical details; it’san endless job learning all those, but programmers
love that.

The Mundane

On the other hand, whatdo (most) programmers not love? Principles, be it coding principles in thesmall (e.g. “always give variables meaningful names”) or development principlesin the large (e.g. “write  tests
before you write the actual code”).They’re just dull. They’re not tricky; they’re not weird; they’re notchallenging. We can’t show the world how smart we are by complying with somesilly rules. What we do love is writing some insanely tricky code or
using
some dazzlingpatterns that nobody else has a clue what we’re doing (or everybody knows whatwe’re doing).

Right?

The Self-handicappedProgrammers

On the one hand,programmers are learning too fast, and learning too much (see above). On theother hand, there’re always times when we need to learn new things.

There actually areseveral kinds of human natures that can hinder one from learning new things.The  one related to what we’re getting at is:

The Inconvenient HumanNature, #3 
Self-serving bias
: We love what we’redoing, or who we’re; we dislike all the things that counter it.

Admit it or not, we’veall been through this. After we get familiar enough with some language or platform,
theself-serving bias will start to affect what we like (and learn) and what wedislike (and won’t learn). Language debates are all too common in programmingcommunity. By blinding ourselves to the disadvantages of our languages orplatforms and to the advantages
of other languages or platforms, we limit ouraccess to new techniques and ideas. In a sense, we limit our potentials.

Conclusion

Most of the times,we’re learning just a little too much. We’re attracted to interesting stufflike a moth
to a flame. Oroftentimes we just learn what everybody else around us is learning or whatwe’re told to learn, not knowing why we should learn it. Fact is, however,after we’ve grasped the essential knowledge, other stuff can just be learned onan as-needed basis.
Don’t fall into technical details unless they’re essentialor needed right away. There’s just unlimited number of details to follow inthis area; you can put your time to something more useful (learning theessentials, learning the ideas, or even just another
language).

On the other hand,however, we’re learning too little. We blind ourselves to the reallyimportant subjects
just becausethey look dull. Tests? That’s like wearing condoms before having sex!Refactoring? Why do we have to do something that’s not going to generate newfunctionalities and not shinny at all? Defensive Programming? No thanks, Iknow what I’m doing here.
API Design? Oh-Man, it’s just too darn hard toconsider how somebody else would be using my code when I’m writingthe SPLENDID implementation. New languages? What… R U saying that mine isnot good enough? Did U NOT see how I can bend the language to do whatever
theheck I want it to do?

 

抱歉!评论已关闭.