Something worth reading about programming

General Insights:
Programming languages worth learning
Why The New Guy Can’t Code
An open letter to those who want to start programming
The worst algorithm in the world?
Hacker Writing Style
A list of Cheating sheet
What's your most controversial programming opinion?
The first step is to start
Best of 2008 for developers: tips, tricks, scripts and sources!
List of freely available programming books
Why data structures matter 
General summary of  open source software licences
Some basic standard for programming design
"You've got to find what you love"
How to get a job as a programmer
Top 10 programming fonts
Rewrite your code
Functional thinking: thinking functionally. Part 1, Part 2, Part 3.
The Principles of Good Programming (Chinese Translation)
程序员技术练级攻略 
Learning Vim Progressively (简明Vim练级攻略  && Vim速查卡)
Letter to a Young developer (Chinese Translation)
How can you program if you're blind? (Chinese Translation)

Specific Languages:
Art of Assembly Language Programming
Coming home to Vim
Why C# Is Not My Favorite Programming Language
Java.next() - Clojure: The Return of the Lispers
Ruby or Python? Well, it depends...
If programming languages were religions...
Graph Visualization in Python
A skip list container class in Python 
Why PHP Was a Ghetto
Good Haskell source to read and learn from
Why is C++ still a very popular language in quantitative finance? 

Audio relevant:
The problem with HTML5 audio

Productivity:
Unmaintainable code
Productivity tips for the easily distracted

Github uploading

折磨死我了……

这应该是个很不错的版本控制，以及所谓社会化编码的网站工具。不过上手还真的是需要段时间的。可能以后经常维护，会熟能生巧吧。

两个不错的参考文献：
Git for beginner
Github Help links

great resources for C.prog.lang

Basic commands and references:
C Programming Language
C/C++ references
The Definitive C++ Book Guide and List
Google C++ Style Guide
Lessons on development of 64-bit C/C++ applications
MIT C/C++ Introductory course
Solution manual of "The C Programming Language" (Kernighan & Ritchie)
两个C++的library
Six free E-books on C and C++

Algorithms:
Complicated data structure and algorithms
“火柴棍式”程序员面试题
如何调试makefile变量
打印质数的各种算法

Suggestions && methodologies:
Small C projects
21 days vs. ten years
如何学好C语言
如何学好C++
C++程序员自信心曲线
语言的歧义
C语言下的错误处理的问题

In-depth discussions:
Primeval C: two very early compilers 
The context sensitivity of C’s grammar
C is a Wasteland
Why C++ is vastly superior to C
Which programming languages are fastest?
Top 6 List of Programming Top 10 Lists
 A Guide to Undefined Behavior in C and C++: Part1, Part2, Part3.
Go Programming Language, Or: Why all C-like Programming Languages Except One Suck
Experience porting 4k lines of C code 
Why do C++ folks make things so complicated?
Can a local variable's memory be accessed outside its scope?

Some of my thoughts:
Keep writing in C to solve the algorithm problems.
Transform to Clojure/C++/Python whenever the application scenario needs.
Read more about Perl/Python/Java.
Try to solve some puzzles or challenges everyday

Algorithm complexity

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan

Remark: If the code is complex enough to be at the limits of your skills, then debugging that code will exceed your skills. In other words, don't make code so complex that you can't maintain it. "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?", quoted from Kernighan (and Plauger, in "The Elements of Programming Style").

I've found that using weaker tools can help with complexity. It's hard to write a complicated C program because it can't do very much. C programs tend to use lots of arrays because that's all you get, but it turns out that arrays are great -- compact memory representation, O(1) access, good data locality. I'd never advocate intentionally using a weak tool, though. Instead, my lesson has been: write Python code like it was C.--"Complexity is the enemy" written by Evan Martin.

Programming craftsmanship

 The article below is a digest from "Programming is not a craft" (courtesy to the author Dan North.)

-----------------
Software Craftsmanship risks putting the software at the center rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

They understand software development is a skill, in fact a whole portfolio of skills: understanding and modeling a problem domain, understanding programming languages, libraries, paradigms and idioms, choosing which to apply in a given situation, learning and understanding algorithms, mastering the "path to production" (build, deployment, release), monitoring and availability, process automation, Lean theories of supply, production and product development, utility and cloud computing, concurrency and parallelism, and so on.

The oft-quoted figures of tenfold increase in productivity of expert versus novice programmers are wrong by orders of magnitude in my experience. A really great programmer (and I've been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.

It seems to me the most successful programmers I've encountered don't craft software; they write software in order to move information around, in order to get something done. Information is the real deal – the software just defines the space that it moves around in. For those programmers, success is about getting information from point A where it's currently languishing to point B where it's going to actually be useful, as quickly and effectively as they can. Success in a UI is about rendering or capturing exactly the information that will be useful – no less and certainly no more – in a succinct, obvious way. The software is incidental, a detail, hidden away in the wings, and it is ultimately entirely disposable.

starting point

B.E.    100*2+50=250        (two exam plus one course)
M.E.    300+300+50=650        (three years)
MSc    100+600+50+200=950    (lab and homework)
=1850hr

recent reflection

There is an essay talking about the LISP Curse , which is so much familiar with the development of Computer Vision/Machine Learning with signal processing. I have taken two consecutive courses of computer vision, and one paragraph of description in the essay above could summarize all of my feelings:

"Programs written by individual contributors tend to follow the scratch-an-itch model. These programs will solve the problem that the contributor, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone contributor's own setup, but may not be portable to other implementations with even similar scenarios, or to the same implementation on other platforms. Documentation may be lacking. Being essentially a project done in one's copious free time, or based on the only destination of making a proposal to apply grants, the program is liable to suffer should real-life responsibilities intrude on it. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem"...(at maximum).

Those two courses were just copying and trying hard to duplicate other works from some other professors. All of the works were self-contained. The instructor wished that some of the duplications would lead him any insight, and then let some of his own students to add some other specifications on it, to make the so-called "breakthrough", and to publish one or more papers. Yes, the papers are the ultimate destination, which could both make the students graduate and reveal the extraordinary achievements of the professor.

I should have somewhat lucky feeling not choosing this lab, although I might also learn a lot by choosing it and complete my doctoral degree... And in the latter scenario, the lucky feeling seems exactly like a useless self-consolation. But, anyway, collective intellectual is definitely the right way to improve one field of study. And more importantly, I should leave myself sufficient time to learn more and think about everything.