"Turn" on the thinking of language

Before I wrote so many bad things about Haskell, but didn't mention its good place, I had to admit that I learned something very important from Haskell, which is thinking about "type". Although Haskell's type system is overly restrictive, it is "unnatural" from a "philosophical" point of view (not mathematically), but if a programmer has never learned Haskell, there is a lack of an important thing in his mind. This kind of thing is difficult to learn from other languages besides Haskell,ml,clean,coq,agda.

Haskell gave me the inspiration

One of the easiest mistakes a scheme programmer has not learned about Haskell is to take #f any value other than (scheme's logical "false") as #t (scheme logic "true"). Many people think this is a "feature" of scheme, but it is actually one of the few drawbacks of scheme. If you understand the history of Lisp, you will find that at the earliest time, Lisp used the value of the nil (empty list) as "false", while the nil other values were "true". This leads to the confusion of logical thinking.

Scheme has made some improvements to Lisp's chaotic approach, so in scheme, empty lists ‘() and logical "false" values #f are separated. This is a very obvious thing, one is a list, one is bool , how to confuse. This error in Lisp affects a lot of other languages, such as the C language. The C language takes 0 as "false", while the value of not 0 is all "true". So you see some smart C programmers writing this code:

int i = 0;......if (i++) { ...}

Scheme stops nil as "false", but still does not #f value all as "true". Scheme admirers generally tell you that the advantage of doing this is that you can use

(or x y z)

Such an expression, if one of them is not #f , then the expression returns its actual value directly, not just #t . Then you can write the code like this:

(cond [(or x y z)  => (lambda (found)       (do-something-with found))])

Instead of:

(let ([found (first-non-false x y z)])  (cond   [(not (eq? found #f))    (do-something-with found)]))

The first code uses a special "syntax" for Scheme, which takes the => (lambda (found) ...) (or x y z) returned value as its argument and found returns the result computed by the function. The second code does not assume that any value that is not #f is "true", so it does not put (or x y z) into cond the condition, but first binds the value it returns to found , and then puts the value in cond the condition.

This second piece of code more than the first piece of code a let, adding a layer of indentation, seemingly more complex, so many people think #f it is not the value of all as "true" the practice is reasonable. In fact, Scheme in order to achieve this goal, just committed the "one-sided pursuit of short" language design smart (see this blog post). In order to make this situation short and the loss type accurate, the cost is very unworthy.

Haskell's type system is a way to help you think closely about types of problems. If you've never learned Haskell, you won't find that there is a type error in this area. But Haskell did a bit too much, because of the blind worship of the theory of type derivation, first order logic and category theory, Haskell introduced a lot of unnecessary complexity.

Various types of derivation I have designed over 10, some of which are much more powerful than Haskell. Category theory is actually not something that is particularly useful. Many mathematicians call it "abstract nonsense", which means that it is too "generic" to be the equivalent of saying nothing. I used to read the whole category theory textbook in one night and found the content inside of me in fact through my own hands (implementation of compilers, design type system and static analysis, etc.), has long been understood. The theory does not bring about a simplification of the programming language. On the contrary, it complicates the programming language.

I'm tired of the "genius attitude" of Haskell programmers, so I don't want to use Haskell anymore, but my mind is left with something that "inspires" me. The understanding of Haskell has made me a better Scheme programmer, a better Java programmer, a better C + + programmer, and even a better shell scripting programmer. I can reproduce the essence of Haskell's programming in any language. But let me continue with Haskell, but it's like I'm going to jail. The simple thing is that in Haskell it becomes something new and confusing. I've seen most of Haskell's designers ' papers, and in a few minutes I know how their set of things has changed, and there are few new things in it. Most of this is because of the "new concepts" (such as Monad) introduced by Haskell that do not have problems. There are more intelligent people in the world than they are, simpler but more powerful theories. So don't assume that Haskell is the pinnacle of the world.

How to say, I think every programmer's life should be at least a few months in meditation to learn Haskell. Learning Haskell is like having a vegetarian diet for a few days. Eating a vegetarian diet every day is obviously a lack of overall nutrition, but every day you eat meat, you may never be aware of how serious the toxins in your body are.

The harm of specializing in a language

I once told people that there are some good things in C + +, but what I did not say is that there is too much bad stuff in C + +. C + + is a "toxin" a lot of language, like pork.

Some people have been writing C + + for a lifetime, writing C + +, like eating pork every day. The result is that they have a very solid grasp of the "pearls" in C + +, so that they have a "brain residue" phenomenon-they can't write a logically clear procedure. (Here the "Pearl" is a special term, it does not contain the meaning of praise.) Please refer to this blog post. ）

For example, many C + + programmers are proficient in functor writing, but in fact functor just because C + + does not first-class function and the "work." C + + functor can never be as useful as a Scheme lambda function. Because every time you need a functor you have to define a new class and then make the class object. If there are free variables in the function, then these free variables must be put into the functor field by the constructor, so that when the "Main method" inside the functor is called, it will know the value of the free variable. So, you have to define some field. After so much trouble, what you get is just a Scheme programmer that uses a lambda like breathing air.

Many C + + programmers who are proficient in functor think that they will use functor to demonstrate their high level. But functor this thing is not only a "flexible", but also from the functional language inside the "learning" come over. At the earliest, C + + programmers didn't really know what to functor. If you take a test, you will find that C + + was born in 1983, and Scheme was born in 1975, and Lisp was born in 1958. The birth of C + + was 8 years later than scheme, but scheme began with lexical scoping lambda. Functor is nothing more than a curved imitation of lambda. In fact, some of the things that C + + added later (including the Boost library) are basically parody.

Remember November 11, 2011, the creator of C + +, Bjarne Stroustrup, made a speech at Indiana University, on the theme of the new features of c++11. I was there at the time, and the host Andrew was one of the chief designers of the Boost library (he had been my mentor for a while). He even praised Stroustrup will choose the day, only regret speech time not set at 11 o ' Night.

Although I admire Stroustrup's sense of humor and modesty, I also see that c++11 is not really a "new thing" in a language like Scheme. Most of the time it is to get rid of some of their bad habits and then learn something from other languages and then cover up the traces of these studies. But in the end, it is still impossible to achieve the original effect of other languages. However, due to the high popularity of C + +, there are many existing code, its status and importance is still hard to shake. So these "sins of the Ancestors", we may have to work for several generations to compensate.

So what are the good things that C + + does not have in other languages? actually very little. I'll talk about it when I'm free.

Learn several languages more

What I want to say today is that no language is worth your life's energy to "master" it. "Mastery" actually stands for "brain residue"-you become an efficient machine, not a person with a mind. You have to have a certain skepticism about each language, rather than embracing it completely. Everyone should learn multiple languages, so as not to allow their own ideas to be bound by a single language, and can not accept new, more advanced ideas. It's like everyone should learn at least one foreign language, or you're stuck in your own nation's way of thinking. Sometimes this national tradition of thought will let you deep into the unnecessary pain but can not extricate themselves.

"Turn" on the thinking of language