Human Factors in Programming Languages

Take a look at Quicksort implementations in Erlang

qsort1([]) ->
[];
qsort1([H | T]) ->
qsort1([ X || X <- T, X < H ]) ++ [H] ++ qsort1([ X || X <- T, X >= H ]).

and in Haskell


qsort1 [] = []
qsort1 (p:xs) = qsort1 lesser ++ [p] ++ qsort1 greater
where
lesser = [ y | y <- xs, y < p ]
greater = [ y | y <- xs, y >= p ]

Haskell syntax is much nicer to look at – a important quality of a good language. Many programming languages didn’t pay enough attention to human factors issues. In other words, we need more social scientists involved in designing the next big thing.

erlang

Erlang is a concurrent, functional language for distributed, fault-tolerant, real-time systems. I have played around with Erlang lately, and noticed that it is really a specialized language. I have tried all sorts of functional programming languages before, hence I was not surprised about the syntax and the functional paradigm of Erlang – strict evaluation, single assignment. However, the current implementation of the language make it too specialized for anything else but the domain it was created for – telephony systems. For example, the language does not have the String type built-in. That alone makes it very unpleasant in many situations; we have to deal with texts all the time in this Internet era.

Besides, it has many “warts”:http://damienkatz.net/2008/03/what_sucks_abou.html to make it a mainstream language.

Design Principles

From “Design Principles Behind Smalltalk”:http://users.ipa.net/%7Edwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

* Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
* Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.
* Purpose of Language: To provide a framework for communication.
* Scope: The design of a language for using computers must deal with internal models, external media, and the interaction between these in both the human and the computer.
* Objects: A computer language should support the concept of “object” and provide a uniform means for referring to the objects in its universe.
* Storage Management: To be truly “object-oriented”, a computer system must provide automatic storage management.
* Messages: Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages.
* Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
* Modularity: No component in a complex system should depend on the internal details of any other component.
* Classification: A language must provide a means for classifying similar objects, and for adding new classes of objects on equal footing with the kernel classes of the system.
* Polymorphism: A program should specify only the behavior of objects, not their representation.
* Factoring: Each independent component in a system would appear in only one place.
* Leverage: When a system is well factored, great leverage is available to users and implementers alike.
* Virtual Machine: A virtual machine specification establishes a framework for the application of technology.
* Reactive Principle: Every component accessible to the user should be able to present itself in a meaningful way for observation and manipulation.
* Operating System: An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.
* Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.

Reading List: Design Patterns

“Design Patterns by GoF”:http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

It is definitely an important book. I helped to popularize the concept of design patterns, good solutions for certain frequent-seen problems. And really, it is all about design patterns. I cannot help but thinking the book make the concept much more academic than it is. The authors presented patterns in a elaborate way of a scientific paper; and again design patterns are no science. Recently, I think many design patterns are the direct result of language weaknesses. For example, the book used C++ to illustrate examples, however many patterns will be redundant if you use Python. The reason of many patterns is due to the weakness of current programming languages, particularly C++.

10 Minute Email

“http://10minutemail.com/10MinuteMail/index.html”:http://10minutemail.com/10MinuteMail/index.html

This service solves a pressing problem, we all have for a long time.