> Why are you ignoring the fact that you have to type so much less for the same result?

Mostly because in your Python example you're really just _using_ an inbuilt filter function (comprehensions) where in Erlang you're implementing one. If you compare using, it's shorter in Erlang. More importantly, though, it's because I agree with /u/coldtea that one line of statically typed code (like the C# example) does more for you than the equivalent dynamically typed code. It's _not_ the same result.

> a matcher for some category

Well, a type is a category, which is why the study of them is called category theory. Having them helps you write predicates, and helps you avoid trying to match something of an unrecognised category. The type system does the job of 'ignore everything else'. If you're duck-typing and you actually want to handle that job (which most programs don't, they just accept they might get errors), you have to go

    filter(x => x.some_method && x.some_method(99), list).

Try stringing that together into (filter this? (filter that? list)). My point is, you can totally have that power and expressiveness without forgoing a static type system. LINQ does it, that's enough of an example on its own. Any language worth its salt these days can string together .map(f).filter(pred).reduce((a,b) => a + b) calls and still let you hover over 'b' in your IDE and tell you exactly what it is. You don't have to choose between these things. As for writing all this 'without even thinking about type signatures': I want to think about type signatures when working with complex data. Having the type system actually lets me be more productive, it is not a hindrance. IDEs are a part of that, but also expecting a huge block of code to work first time.

I replied because your comparison purported to demonstrate that only dynamic languages could be so expressive. It was a bad comparison, and also not a useful example of what code that begs for expressiveness looks like. In fact, most static languages allow you to be productive and expressive when you need it, and let you lock down the use of certain code to strict requirements when you want to.

I imagine there is not a thing in the world I could do to stop you from citing OnLisp.

> does more for you than the equivalent dynamically typed code. It's _not_ the same result.

Yes. It does more checking at the cost of imposing restrictions, such as forcing homogeneous containers and conditionals and having less generic, less cluttered code. This is not merely hand-waving, BTW. One just have to take a look at some decent Lisp code, such as arc.arc or some good parts of Common Lisp or Norvig's code from AIMA which is simply wonderful.

As for typing, an old-school ADTs are OK for me (that is constructors, selectors and predicates explicitly defined as procedures). This requires some discipline, because the type system does not do anything for you, but all this is trivial, including writing pattern-matching.

I could argue that strong typing via type-tagging of values (values has a type, not variables principle) is good-enough as long as it comes together with other Lisp's features, such as everything is an expression, everything is a first-class value, which gives one such beauties as the Numerical Tower, but this is quite another topic.

I am also OK with the SML-family languages, love Haskell for its clarity and conciseness and have nothing against them, but... I still think that there are prototyping languages and implementation languages, and I still prefer to prototype in a dynamic-typed language and would still use Common Lisp if I could have a choice or Clojure.

Well, typing less is not necessarily always the most important thing - though it certainly appears to be useful when writing small examples for pedagogical purposes.