How to make wealth

How to Make Wealth is a great and enlightening essay. Paul Graham is great writer and thinker.

Here I highlight 3 excerpts (or paragraphs) from the above essay.

I can remember believing, as a child, that if a few rich people had all the money, it left less for everyone else. Many people seem to continue to believe something like this well into adulthood. This fallacy is usually there in the background when you hear someone talking about how x percent of the population have y percent of the wealth. If you plan to start a startup, then whether you realize it or not, you're planning to disprove the Pie Fallacy.

A programmer can sit down in front of a computer and create wealth. A good piece of software is, in itself, a valuable thing. There is no manufacturing to confuse the issue. Those characters you type are a complete, finished product. If someone sat down and wrote a web browser that didn't suck (a fine idea, by the way), the world would be that much richer.

Understanding this may help to answer an important question: why Europe grew so powerful. Was it something about the geography of Europe? Was it that Europeans are somehow racially superior? Was it their religion? The answer (or at least the proximate cause) may be that the Europeans rode on the crest of a powerful new idea: allowing those who made a lot of money to keep it.

Hackers & Painters was a great read and it's one of my all-time favorite books. If you don't want to buy the book you can read the essays at http://www.paulgraham.com/articles.html


By the way, there is a bug in the last index page, of Hacker & Painters. Can you spot it?

Leverage work that has already been done

Anders Hejlsberg: Leverage is everything today. Your computer is, from a programming perspective, basically a bottomless pit. You could write code from now until the day you die and you would never fill it up. There's so much capacity, and end user expectations keep going up and up and up. The only way you really succeed is by finding smart ways to leverage work that has already been done. That wasn't the case if you go back 25, 30 years ago. You had 64k of memory, well, gee, that would fill up in a month or two.
[Masterminds of Programming]

Received vs Perceived information

This is a powerful concept to keep in our minds.

What Scott McCloud is saying is that the way our brain works, we receive/understand concrete and realistic visuals faster than more abstract entities. In the latter case, the brain must first compose things together, transform them into more concrete entities, and finally convert them into thoughts or images.

Simple example:

• line 1
• line 2
• line 3

<li>line 1</li>
<li>line 2</li>
<li>line 3</li>

I am quite sure that the first bullet list can be seeing (percepted) by anyone (fast); the second only by those who are familiar with the HTML syntax.

It's not an accident that sophisticated programming editors support (at least) a syntax highlighting feature.
Syntax highlighting helps us to receive information hidden in the code quickly.

I'm really looking forward the day in which the current model of software writing will not require nested function calls or if-else chains, thus behavior diffusion across the code, but rather a way of expressing data relations and behaviors among object entities, in a totally different manner. Let's say fast-receive-perceive (?) techniques for modeling our programs.

Understanding Comics: The Invisible Art is a 215-page non-fiction comic book, written and drawn by Scott McCloud and originally published in 1993. It explores the definition of comics, the historical development of the medium, its fundamental vocabulary, and various ways in which these elements have been used. It discusses theoretical work on comics (or sequential art) as an artform and a communications medium. It also uses the comic medium for non-storytelling purposes.

Knuth, emphasis on function as well as form is basic to design problems

The Art of Computer Programming, Volume 1
2.2 LINEAR LISTS
2.2.1 Stacks, Queues, and Deques, pg. 238

[...]

We must decide in each case how much structure to represent in our tables, and how accessible to make each piece of information.  To make such decisions, we need to know what operations are to be performed on the data.  For each problem considered in this chapter, therefore, we consider not only the data structure but also the class of operations to be done on the data; the design of computer representations depends on the desired function of the data as well as on its intrinsic  properties.  Indeed, an emphasis on function as well as form is basic to design problems in general.

Elements of Programming, Notes

Here I'll post notes from Elements of Programming (Alexander Stepanov, Paul McJones) that are interesting and insightful, IMO. That takes (will take) a lot of time because I do it in my free time.

here we go,

• As with other areas of science and engineering, the appropriate foundation of programming is the deductive method. (pg ix)
• Discovering the architectural principles of the book should be the reader's goal. (pg ix)
• Starting with a brief taxonomy of ideas, we introduce notions of value, object, type, procedure, and concept that represent different categories of ideas in the computer. (pg 1)
• A central notion of the book, regularity, is introduced and elaborated. When applied to procedures, regularity means that procedures return equal results for equal arguments. When applied to types, regularity means that types possess the equality operator and equality-preserving copy construction and assignment. (pg 1)
• Categories of Ideas: Entity, Species, Genus.
• An abstract entity is an individual thing that is eternal and unchangeable, while a concrete entity is an individual thing that comes into and out of existence in space and time. (pg 1)
• A function is a rule that associates one or more abstract entities, called arguments, from corresponding species with an abstract entity, called the result, from another species. (pg 2)
• A datum corresponding to a particular entity is called a representation of the entity; the entity is called the interpretation of the datum. We refer to a datum together with its interpretation as a value. (pg 2)
• A datum is well formed with respect to a value type if and only if that datum represents an abstract entity. (pg 2)
• An object is a representation of a concrete entity as a value in memory. An object has a state that is a value of some value type. (pg 4)
• Values and objects play complementary roles. Values are unchanging and are independent of any particular implementation in the computer. Objects are changeable and have computer-specific implementations. (pg 4)
• Functional programming deals with values; imperative programming deals with objects. (pg 5)

What is the role of math in computer science and programming in particular?

In the book Masterminds of Programming, Peter Weinberger gave an answer which,  in my opinion, is a good one.

Peter: My degree is in math, so I'd like to believe that math is fundamental. But there are many parts of computer science, and many kinds of programming, where one can be quite successful without any mathematics at all.
The use (or usefulness) of mathematics comes in layers. People with no feeling for statistics or randomness will be misled over and over again by real-world data. There's mathematics in graphics, there's lots of mathematics in machine learning (which I think statisticians think of as a form of regression), and there's all sorts of number theory in cryptography. Without some mathematics, people are just cut off from understanding large parts of computer science.

Never heard of  Peter Weinberger?
How about the AWK programming language?
Al Aho, Peter Weinberger, Brian Kernighan