> That doesn't say much in itself though. Such infrastructure for "earthquake notification" could just be a few thousand lines or even mostly "glue" code. In t

> That doesn't say much in itself though. Such infrastructure for "earthquake notification" could just be a few thousand lines or even mostly "glue" code. In total Openstack encompasses around +4M SLOC written in Python. How much is deployed in a given cloud depends on the configuration. However the community must still shepherd and manage all of that code and make regular, stable releases on a six-month cadence. It's not "just" glue code. > As you say "It does rely on systems written in static languages and is itself written in one" which kind of refutes the whole argument, doesn't it? Not necessarily. Awk was necessarily written because querying unstructured input is a huge pain in plain C. Kernighan gave a recent example of this in one of his recent talks on programming language design. The caveat is there is a limit at which adding more lines to an awk program becomes counter-productive. It's essentially a good DSL but a terrible language. I think Python defies that -- with the millions of lines of code managed by the community of thousands of developers a large system written in a dynamic language isn't impossible or necessarily hindered by its lack of static type analysis. > For those cases couldn't one just use a DSL or at worse an sandboxed isolated dynamic language from inside a STL talking care for the rest of the system? In some sense this is how I view Python and languages of its kind... but I think in practice it's more of a philosophical viewpoint. In practice dynamic languages are general purpose and much suited to certain kinds of programming that static languages are not. Common Lisp and Smalltalk are great examples of dynamic languages kicking butt. Starting in the debugger and developing self-introspecting systems has a peculiar effect on the programmer. One tends to develop a domain language for solving a class of problems in order to make them tractable. One thing I dislike however is how divorced it can be from the machine. Some Common Lisp compilers can produce really awesome code but it does take a little more burden from the programmer to gain such efficiency from the compiler (compared to the tactical omissions of defined behavior from languages like C which allow almost trivial optimizations... with the trade off that certain errors are quite likely on my part if I'm not careful). I think there is room for both in the world. I really enjoy OCaml, C, Python, and Common Lisp... and I would seriously consider the problem before the language. Our job after all is to transform data and not spend time writing pretty, elegant, or clever code for the code's sake. update: grammar.