A few reasons to master the CL, even if you don't plan to write on it in the future

Perhaps this article is worth posting before the previous two, in that my cycle is about Common Lisp, but better late than never.

Once upon a time, when I read the article, Paul Graham, and was just starting to learn CL, I'm pretty skeptical of the assertion that Lisp allows you to understand other languages better, and in General, a programmer who knows CL will learn any other language, the most for a couple of weeks and will to write it even better than it says most people who know the language for a couple of years.

But now I came to the conclusion that this statement is still true.

Trust me.
New ideas in programming language not seen since the mid-90s, since the standardization of Common Lisp.

If you take up one of the modern CL implementations, such as SBCL, more or less will understand with a standard ANSI CL and its extensions provided by the implementation, then you will know and understand and from such programming paradigm, such as:
the

the
• of the Imperative and its variations (in CL even has goto! and other means of control flow it taxied counterparts from all other languages)
the
• Structure (no comments)
the
• Object-oriented and its variations (From fault to CLOS)
the
• Functional(CL encourages to localize side effects, and to write without them)
the
• Event-driven (which is kolvekar, i.e. function objects)
the
• Generalized (see end of article about polymorphism)
the
• Metaprogramming (it's Lisp! The program itself is the object language)
the
• To a certain extent, parallel programming
the
• And so on and so forth — using language features that directly implement the previous paradigm, and bonding all macros, CLOS, and condition system, you will be able to make the language anything from a logical paradigm and the built-in Prolog, and ending with visual programming.

I'm just saying that all mainstream languages, and in particular, object-oriented, are subsets of the CL, just with your syntax and some constraints in typing(the type system of the CL very simple, but at the same time, infinitely powerful and intractable in full even in the dynamics).

In principle, this is true even for si, since I've learned that working with FFI and inline Assembly helps to understand si and conventional assemblers more than even working with them.

A functional, including esoteric, languages, after meeting with CL will not look quite so esoteric, and will, in principle, at a glance.

To a certain extent, the modern implementation of CL will help to deal with common to all languages the techniques of code optimization, with many low-level concepts(see above about C) with multithreaded programming and concurrency(all know where Google got the idea for MapReduce?), and even with the construction of complex systems(although this is, of course, more comes with experience).

I'm talking only about languages and General programming concepts, not talking about specific frameworks and libraries, and any things that actually are orthogonal to language concepts, but you may also be more productive to learn them, noticing patterns, you are familiar with Lisp and therefore structuring information faster. Personally, once I have some experience with CL helped them to better understand the nature and purpose of XML, and something else — helped to understand the organization and General principles of graphical user interfaces and GUI-frameworks.

There's still Haskell, Yes, that, they say, is also "enlightens". But personally, I think Haskell some syntactic sugar over a few basic concepts which are actually available and in Lisp, only in a more General, and from that, less visible, and of course, less binding. These concepts are:
the

Pattern-matching(well, ADTYes, but ADT is essentially needed only for pattern-matching), which is a kind of dynamic multiple dispatch.

the

Lazy evaluation, which is reduced to the flows(streams) and closures.

the

Polymorphism(which, in fact, is the reason for the presence in Haskell the whole husk types). Parametric polymorphism is, conceptually, a subset of dynamic typing, and ad-hoc dispatch on types(which in Lisp can be achieved as banal if+typep and more powerful mechanisms, such as CLOS). Someone will say — but in Haskell it at compile-time! Yes, but I don't think it's something so special — if pripret, and macros to write, and transfer operations on the types in compile-time and in Lisp(and no, this will not have to invent a new language on top of CL, just have to work with objects "lexical environments", which, though the specific format in the standard stated, in all major implementations of the present information about the types of grant), though then have to deal with only a subset of the type system CL since in General it is intractable even in the dynamics, as I already mentioned above.

Article based on information from habrahabr.ru