"Hackers & Painters" Excerpts [4]

1. Startups are like mosquitoes; they usually have only two outcomes: either win everything or disappear completely. You usually don't know which outcome you'll have until the very last moment.

2. The most basic principle you must always keep in mind is to create what people need, which is creating wealth. If you want to get rich by creating wealth, you must know what people need. Very few companies really care about how to make customers more satisfied. How many times have you harbored worry and fear in your heart? When you hear "Your opinion is important to us, please do not hang up," do you really feel that the matter will be resolved satisfactorily?

3. The consequence of working slowly is not just delaying technological innovation, but very likely killing it. Only under the incentive of quickly obtaining huge benefits will you challenge those difficult problems; otherwise, you wouldn't be willing to touch them at all. Developing new technology is a very painful experience. Engineers are willing to accept ordinary salaries to work on some attractive projects (such as fighter jets and moon rockets), while technological innovations more closely related to daily life (such as light bulbs and semiconductors) can only be invented by entrepreneurs.

4. Nowadays, getting rich by creating wealth has become a common model. Everyone who does this applies almost the same trick: measurement and leverage. The former comes from the cooperation of small teams, and the latter comes from developing new technologies.

5. If I could choose, would I live in a society that is very rich overall but I am relatively poor, or live in a society where I am very rich but the society is very poor overall? I would choose the first option. If I had children, it might be debatable which choice is better. But generally speaking, what you want to avoid is absolute poverty, not relative poverty in a society that is wealthier overall.

6. A society needs rich people, mainly not because you need the rich's spending to create jobs, but because of what they do in the process of getting rich. I am not talking about the trickle-down effect of wealth flowing from the rich to the poor, nor am I saying that if you let Henry Ford get rich, he will hire you as a waiter at the next banquet. I am saying that if you let him get rich, he will build a tractor, and you will no longer need to use horses to plow the fields.

7. Scrutinizing the kernel of a language and considering which parts can be discarded is at least a very useful exercise. In my long career, I have found that redundant code leads to more redundant code. Not only is this true for code, but for a lazy person like me, I find this proposition also holds true under the bed and in the corners of the room: one piece of trash generates more trash.

8. Only those programming languages with the smallest and cleanest kernels will exist on the main trunk of evolution. The smaller and cleaner a language's kernel is designed, the more tenacious its vitality.

9. You might think only arrogant people would predict technology a hundred years from now, but please don't forget that the history of software development has already passed 50 years. In these 50 years, the evolution of programming languages has actually been very slow, so looking forward to languages a hundred years from now is not an illusory idea.

10. The evolution speed of programming languages is more like the evolution speed of mathematical symbols, not like the evolution speed of real technology (such as transportation or communication technology). The evolution of mathematical symbols is a slow, gradual change, not the leapfrog development of real technology.

11. I think that in the next 50 years, a large part of the progress in programming languages will be related to libraries. Future libraries will be as carefully designed as the language kernel. The importance of excellent libraries will exceed the language itself. Whether a language is statically typed or dynamically typed, object-oriented or functional, is less important than the libraries. Language designers accustomed to thinking in terms of variable types might shudder at this trend. Doesn't this degrade language design to the level of application development? The use of libraries should fit the programmer's intuition, allowing him to guess which function can meet his needs.

12. As end users have already realized, the concept of running speed is changing. With the rise of Internet software, more and more programs are not limited by the computer's computing speed, but by I/O speed. Increasing I/O speed will be a very worthwhile thing to do. In this regard, programming languages can also play a role. Some measures are obvious, such as using concise, fast, formatted functions, while others require deep structural changes, such as using caching and persistent objects.

13. Let's try to describe the language hackers dream of to summarize the above. This language is clean and concise, has the highest level of abstraction and interactivity, is easy to equip, and can solve common problems with very little code. No matter what program it is, the code you really have to write is almost all related to your own specific settings; other general problems have ready-made libraries to call.

This language's syntax is suspiciously short, allowing you to quickly write a prototype of a program. Then when you start optimizing, it also provides a truly excellent profiler, telling you where to focus. You can make multiple loops incredibly fast, and embed bytecode directly where needed.

This language has a large number of excellent examples to learn from, and is very intuitive; you only need to spend a few minutes reading the examples to understand how to use this language. Only occasionally do you need to consult the manual.

This language's kernel is small but powerful. Each library is highly independent and carefully designed like the kernel, and they all work well together. Each part of the language fits perfectly like the various parts of a precision camera; don't give up or keep certain features for compatibility issues. The source code for all libraries is easily available. This language can easily talk to the operating system and applications developed in other languages.

This language is built in layers. Higher abstraction layers are transparently built on top of lower abstraction layers. If needed, you can use the lower abstraction layers directly.

Except for some things that absolutely must be hidden, all details of this language are transparent to the user. The abstraction capabilities it provides are only for your convenience in development, not to force you to act in its way. In fact, it encourages you to participate in its design, giving you equal rights with the language creator. You can change any part of it, even including its syntax. It makes the parts you define yourself as equal as possible to the parts it defines itself. This dream programming language not only opens its source code but also opens its own design.