While you might miss and/or or not use apply/map/fold/unfold in C#, that may have more to do with idiom than Sapir-Whorf expressibility. There’s a simple translation in either direction from and/or/if chains to ?: chains. (In fact, in your example the two have the same number of tokens!) C#’s delegate system supports map fully and cleanly, e.g. this generalized implementation. Granted, there’s some ugliness, but it’s all local management. Outside of the function, you just have map.

I felt as you seem to: there was “something out there bothering me”, but I wasn’t sure what. After a few days of introspection, what bothered me was that I couldn’t come up with a real example of an important style difference. It was discomforting for me to discover that my opinions. based on ‘principles’ and ‘theory’, are really just that — my opinions.

This comes down to the language effecting the way you think. The Sapir-Whorf theory (not sure if this is the correct spelling) hypothesizes that the language you speak effects what ideas you are capable of expressing. Nowhere is this more evident than in programming languages. I specific example would be something like the use of “and-or” constructs as a ternary operator in Python (test and success or failure vs. test ? success : failure). Because “and” and “or” return the values of their sub-expressions instead of returning a boolean value their might be a mismatch between Python and C#. That’s the best example I can come up with off the top of my head. It does seem as though there is something out there bothering me, but I can’t put my finger on it.

Taking the CLR as a high-level machine, it has TCO and typing (that is, if you give types at a call node, you don’t have to worry about run-time checking). It’s more than sufficient as a compilation target for functional and other weird languages. The question I’d now ask — a question for us, not for Jim Miller — is: why do we want that free ride? While the CLR already gives so many guarantees (and optimizations), do they also need to write the hard parts of our compilers for us? A good Erlang implementation does its own optimizations to make lightweight processes work…why can’t we, on the CLR?

After the talk, I did do the wankerish thing and asked about data binding support in the CLR. He gave the exact answer you would expect: it is unneccessary, because it can be otherwise easily encoded with little overhead, so they didn’t bother. Several MS products have constraint based or dynamic properties, so this was an explicit decision with performance honestly factored in. The same exact approach taken by Macromedia in their data binding implementation.