看到 @
skinny 的说法，我重新审视了一下这楼的问题，觉得有必要澄清。
上面所有楼层的回复，除了最开始两个以及我说的，没体验直接信都有直球误导的风险。
因为这些观点不说是否正确，至少都是片面的。
比如说：
@
villivateur 从来没有靠几行代码把系统搞崩的体验照样可以掌握好 C 。
@
chuanqirenwu 从来不学 C++也可以学好 C 。（虽然我不反对学 C++作为长期性建议。）
@
ZXYF 学好 C 不保证能理解清楚大部分 Python 复杂一点的东西，反而可能养成依赖实现细节的坏习惯而学坏。
@
jones2000 这是个进阶学法； CPython 的 C 这样的互操作不是适合新手学习的，虽然程度整体比混用 C 和汇编来得容易（因为 CPython 对互操作的支持相对非标准 C 的“官方性”更强而更完善）。
@
ch2 不学 unistd 而使用 C 的价值仍然存在，比如制造和 unistd 并行的东西。Windows NT/ReactOS 执行体也是基本都用 C 写的，这也算操作系统，但和 unistd 无关，所以你说的还有点自相矛盾。注意嵌入式还有没操作系统的独立实现。当然，市场上讲非操作系统的东西用 C 来讲没多少收益。
而学会怎么写程序，说实话和是不是用 C 没什么关系。换别的看上去通用点的语言一样是这个建议，但一样不会让你特别地学会某种具体语言。
其它白开水观点不评价。
我强调的问题是，C 特别容易让人陷入表面上学会而实际上了解的另一套玩意儿的问题。极端点的就是谭浩强 C 。“C 没有对象”是另外一个常见的误解。这种错误通常不能通过你会不会写程序做对几个题目检验出来，直到参考文献推理一些具体的问题到底是谁做错的时候，才发现很容易被坑。
避免这种问题的简单方式就是阅读相关的文档。任意不足以区分具体语言和其它语言的区分的文献都不算是足够相关的。
务必摈除某些人认为的“装逼”思想。阅读文档理解意思这就是专业用户吃饭的本事。并且，这就是工程师这个职业的本职工作和区分于其它分工发挥价值的地方。
所谓“用”，反而是形而下的辅助手段。极端情况下一个用户可以化身人肉编译器在没有编译过一行程序的情况下“学会”某种语言（特别是在这种语言不存在实现时——这才是真正能算装逼沾点边的，但也就是专业人士的家常便饭）。
然而没有谁能虚空脑补出别人决定的设计。
自测具体语言的了解程度的简便方式同样直接阅读相关上下文的任意的文档，至少能有自信了解大多数是在讲什么，比如：
www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm毕竟，如果连 bug report 都看不大懂，这也水过头了。