I'm interested in your critique but it seems to me you've misrepresented two of his points.
#2 compares Lisp's minimalism to any language with more complicated syntax, not just C/C++. So I don't think this insight is "common to almost all high-level languages". (The idiosyncracies he mentions are from Ruby and Python.)
#3 isn't about Visual Studio's memory usage, it's about it being slow [1]. When I work in C#, many times a day VS is unresponsive enough to break my flow, so much so that I go off and check a website like this one (it's better than sitting there feeling angry). This is disastrous in a programming tool, so I don't think the author is being precious.
(There's also a deeper point to be made here, which is that the ultra-interactiveness of Lisp and Smalltalk environments is so different from what one experiences in the likes of Visual Studio that it makes a qualitative difference in one's programming.)
There may even be a little more to #1 than you give him. "In Lisp it feels like types are a tool I can employ when I need it" refers not just to static-vs-dynamic typing but also to the fact that one can easily write functions without having to make up types to hang them on (i.e. programs don't have to be organized into object models). That's not true of all high-level languges.
I share your desire to read more knowledgeable and useful writing on this topic. But I did like the post because it's clearly coming from real experience.
[1] Admittedly, much of this slowness is due to the add-in bizarrely known as Resharper. But that's Visual Studio's fault too - for being so backward and provincial that it needs a humongous third-party workaround to achieve bare tolerability even compared to Java.
#3 may be true for C# development; I read a lot of C#, but don't write it. But I did spend 4 years writing a significant amount of systems C++ code in VC++, and --- at least 8 years ago --- VC++ was significantly better than any comparable C environment.
We can get into a tit-for-tat on it versus, e.g. GCC, but I feel like one way to lose a programming environment shoot-out is to imply that Microsoft half-asses that part of the business.
Regarding #2, you seem to be sticking up for the author's implication that Ruby has "complex" syntax compared to Lisp. Clearly, most languages have more "idiosyncracies" (here defined as: "notation of any sort") than Lisp. That doesn't make Lisp's austerity an interesting lesson to take to other languages; it is, in fact, the major failure of Lisp.
There is a notion, unaddressed in the original post but far more important than any of that post's insights, that obsessively regular syntax is crucial to metaprogramming. Even defined down to "true macros", this is simply folk wisdom: you can get "Lisp-style macros" out of any language that gives you access to an abstract syntax tree.
Finally, call the two "mainstream" high level languages Ruby and Python (relegating Perl and PHP to uh, different, uh, categories). Both share the type system the author appreciates in Lisp.
Re #3: you're right to distinguish between the MS environments for C++ and C#. Your comment on VC++ matches my experience from about the same time. But when I say that VS.NET is backward and provincial, believe me I mean it as an understatement. There are very clear points of comparison (Eclipse and IntelliJ) and compared to either of them VS is a bad joke. It only survives because the MS development world is largely a parochial backwater in which most programmers eat the porridge they're given and don't care to look at anything else, like medieval peasants who never leave their village.
Apologies for ranting. I've never been a big MS-hater (though I seem to be getting there), and I hardly think the Java IDE is the last word in programming environments (having an editor generate my duplicate code for me is not my idea of a good time; as you may have noticed, I like Lisp!) But like most hackers here, I care deeply about my tools, and it pains me to work in ways that feel suboptimal or ugly.
Your other points were, as usual, pretty interesting, but I burned myself out on this one. :)
I like s-expressions too, but --- and I'm asserting this without a shred of evidence, appealing to the better angels of your common sense --- most developers, Peter Norvig notably included, believe other languages benefit from having more notation. For one thing, to a point, increasing the level of notational "richness" of a language improves comprehensibility of code.
I don't see much there to suggest Norvig is a big fan of adding syntax to Lisp. In fact you could read "This seemed to satisfy the infix advocates" as an expression of the opposite viewpoint.
Reasonable people could disagree, unless/until Norvig clarifies, but I'm going to take his apparent conversion to Python as evidence that Norvig is not a sexpr fanatic.
Frankly, I don't think you "get" Lisp at all. Lisp's lack of syntax is its greatest strength. Beginning or inexperienced programmers in general seem to have great difficulty with this concept.
> Even defined down to "true macros", this is simply folk wisdom: you can get "Lisp-style macros" out of any language that gives you access to an abstract syntax tree.
Here's what Norvig says about a particular language that has access to the AST (he's not a "convert" to Python - he just decided to use it for examples in his AI book because he feels beginning programmers can pick it up easier):
Python does not have macros. Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this:
This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use.
#2 compares Lisp's minimalism to any language with more complicated syntax, not just C/C++. So I don't think this insight is "common to almost all high-level languages". (The idiosyncracies he mentions are from Ruby and Python.)
#3 isn't about Visual Studio's memory usage, it's about it being slow [1]. When I work in C#, many times a day VS is unresponsive enough to break my flow, so much so that I go off and check a website like this one (it's better than sitting there feeling angry). This is disastrous in a programming tool, so I don't think the author is being precious.
(There's also a deeper point to be made here, which is that the ultra-interactiveness of Lisp and Smalltalk environments is so different from what one experiences in the likes of Visual Studio that it makes a qualitative difference in one's programming.)
There may even be a little more to #1 than you give him. "In Lisp it feels like types are a tool I can employ when I need it" refers not just to static-vs-dynamic typing but also to the fact that one can easily write functions without having to make up types to hang them on (i.e. programs don't have to be organized into object models). That's not true of all high-level languges.
I share your desire to read more knowledgeable and useful writing on this topic. But I did like the post because it's clearly coming from real experience.
[1] Admittedly, much of this slowness is due to the add-in bizarrely known as Resharper. But that's Visual Studio's fault too - for being so backward and provincial that it needs a humongous third-party workaround to achieve bare tolerability even compared to Java.