Take a look at Quicksort implementations in Erlang
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
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 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.
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.
“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++.
A good writeup by EV: “Link”:http://evhead.com/2007/12/how-to-evaluate-new-product-idea.asp
This service solves a pressing problem, we all have for a long time.