Why is C++...

...so bad? Why does it have such a bad reputation?

I'm an experienced C++ programmer and, while the language has warts, I can't understand the reason for the enormous amount of criticism against the language.

I'd like to hear the honest opinions of /prog/rammers in this regard.

The only thing I hate about C++ is how it makes it really easy to create huge thick lasagnas of abstraction and overcomplicate things a lot.

D is better that is all

>>110

Having already mentioned that I don't always expect people to be complete morasses of stupidity, I agree with everything else you've said, wholeheartedly. You have actually summarized what I've said (or intended to say anyway). It too makes my blood boil whenever people blindly refuse to receive new ideas, but what can we do? We ain't responsible for that, anyway. I strive to save my energy for people which are worth any cause.

The C++ fandom is incredibly filled with people who abuse wording power. And the C++ enemies (such as that guy in the mailing list) are no weaker with respect to this. Language wars are particularly funny (if they would not be rather sad) because people engage in them with such a passionate and zealous spirit that it really sounds like a religious argument. C++ battles are particularly epic.

>>117

I'm not special in any way, and I don't disregard the Blub sentiment. I just don't think it holds as an argument for inducing (or rather pushing) mentality changes, for the reasons I've written before. Ultimately, I think that applying the Blub argument is just a too easy way to win any debate, because it sounds like religion. Compare: "Of course you disagree with me, after all you have never been exposed to the X thinking paradigm and thus you're unable to think otherwise" with "Of course you disagree with me, after all you're not Christian and thus Satan's influence is on you." (This is just an example, please don't take it personally or even religiously :)

Once in a while one will have the Blub feeling. However, as I told you before, people will rather develop a degree of creativity in response to it, instead of being permanently locked inside a mental cage as Graham's argument will suggest. I'm absolutely sure even you have done it, too, specially if you're a self-taught programmer: haven't you ever "invented" things during your initial programming experiences? I'm sure you did, everyone else I know did that. Sure, there is a limit up to which this phenomena will go: seldom will a person reinvent lambda-calculus or abstract logic-programming through C syntax, but one is nevertheless well aware and well open to consume and understand these new ideas in the moment one's exposed to them.

The whole problem regarding the wordplay in your macro example could not be more true. Language is tricky in the sense that it is not guaranteed that one word or expression ("macro" in your example) will correlate to the same concept people are expecting them to. This is a very dangerous degree of communication noise, and the most important problem, in my sole opinion. I often think that many of the world's problems themselves are caused simply because people misunderstand each other -- and they do it often at the very basic language level. As it is expected, people concerned with this kind of problem will appeal to a more verbose and more carefully explained way of expressing themselves, in order to attempt to diminish this misunderstanding noise.

C "macros" and Lisp "macros" are not the same thing -- unfortunately, the same word suggest they are alike.

>>121

Yes, I agree with you. It is very easy, very easy indeed to write a problematic OO design. And C++ is no different from that, unfortunately. Just look: people in C++ can't even decide what damn source file extension to use in their projects: .cpp, .cxx, .c++, .cc, .C... how come they could ever agree on other, deeper aspects of their designs?

Are these language problems? Do people need barriers to help them decide (or rather impede them to choose) between possibilities -- including that one?

I'm well aware of the so-called "paradox of choice". It is very likely that C++ suffers from the "too many choices" disease indeed.

--

Also, thank you people for replying to my posts. I've been enjoying the discussion. I hope I have contributed to something.

>>123
I don't disagree too strongly with your take on the blub stuff. However, I'd argue that there's a professional responsibility to understand what your colleagues (and not just coworkers) are doing.

In fact, if you only have your blub then you probably don't even understand it. For years I wrote nothing but C and Perl (sysadmin+programmer at an ISP), but after learning other languages I felt I was blind about the very languages I was using. Sometimes, for example, there's a non-local but accessible minima within your blub, but just outside the perspective it presents. But it's also about understanding limits.

Re: inventiveness, I'm always amazed by this. I haven't seen lambda calculus re-invented, but I have seen fixed-point combinators reinvented in more than half the cases I've seen them used. (It's hard to solve until you actually need it.)

>>123
Listen, guy.

You seem different from the average /prog/ scum, so I'm going to try to enlighten you.

The only purpose of a practical programming language is to allow writing of useful programs. The only measure of usefulness of a programming language is the usefulness of the programs written in it. Everything else, how helpful the language really was, how much did it boost the programmers' productivity, which features of it were most useful, are secondary details encompassed and relying on that one and only measure.

The purpose of a practical programming language is most definitely not to inspire flames on anonymous textboards, mailing lists, usenet groups, etc.

The usefulness of a programming language most definitely can't be appraised by discussing its merits, in the abstract. How many times have you designed a moderately complex system that seemed absolutely perfect in every respect, only to discover that it absolutely sucks in practice, that all problems that it purported to solve are either irrelevant or not really solved at all? Myself, one too many, so I simply don't trust abstract reasoning any more.

So. The only valid kind of discussions about programming languages begins with a demonstration of a useful program, or, better, several useful programs, written in some language or in some dialect, or using some new approach, which, supposedly, made writing that program somewhat easier. Then you get people who want to write useful programs with less effort, asking you: OK, can you tell us more about your experience and explain the thinking behind it working in that exact way?

You see, the fundamental hurdle is overcome by definition this way: they aren't, like, "I think that your thing sucks, prove me wrong", they are already convinced that your thing might be useful and now only politely request clarifications.

The discussion no longer looks like: "why do I think this thing must be useful", but "this thing is useful, here's how, exactly". The latter kind of discussions can be useful, the former -- can't, ever.

My point is, go do some motherfucking programming, motherfucker: http://programming-motherfucker.com/, instead of wasting your intelligence on pointless discussions.

>>125

Slow day at Burger King?

>>125
I don't know what all that follows from, but if you have to demonstrate everything from the ground up every time you want to discuss a topic you're probably not talking to the right people. For example, it's more productive to have a discussion about programming with experienced programmers than with goldfish.

If you're introducing something new or even a new combination of features in a PL, then sure, by all means you'd better demonstrate it. But if there's an established language or technique which improves quality and productivity for certain types of problems then demanding a personal demonstration is just willful ignorance. Besides, if I write the code, you will not learn much at all. The blub argument isn't merely about ones ability to judge a language or technique, it's about ones inability to assess it due to ignorance, having failed to fully understand the demonstration.

Blub isn't really a serious problem, except that it keeps people writing terrible PHP, Ruby and Java code. I see a lot of this and think "if they'd only try something that made them think differently they'd come back and write the best blub of their lives!" Getting back to the demonstration, it usually looks like more work even if just conceptually. The hill is a little steep but not as high as it seems, and the valley on the other side is quite deep. But you may never know. I can show you pictures, but you need to travel there yourself to understand its relationship with your side of the hill.

>>123
I think that Lisp and C macros have some important similarities that warrant the same term. They're both systems for transforming code before it is evaluated. The only major difference really is that C's macro language is a non-Turing-equivalent text copy-paster, and Lisp's macro language is Lisp.

And as for inventiveness, it is often a matter of standing on the shoulders of giants. If it's hard to reinvent lambda calculus in C, try monads and state-less programming, which builds very heavily on lambda. People don't do these things in C because C doesn't make it worth it. That's what I keep saying. People certainly CAN make complex data structures in asm, but they don't. Not typically. People CAN write an immutable array-mapped hash tri in COBOL, but COBOL does not make it worth it.

And that's what language features are to me. It's when a language makes it worth it to use a particular strategy. And I really think it takes a language. In C++ and old-style (pre-closure) Java you always see the big systems: a) make an 'architecture' which implement half of a higher level language and b) lots of XML, which makes up the syntax of that language. It seems downright unavoidable.

Blub programmers don't stumble in the middle of coding and say "i need some high-level functions to simplify this or Lisp macros to generate this". They code. They produce software. They write pages of docs. Blub is very useful and easy in what it does. Blub would lose some abstract fights, but Blub uses abstraction in a limited way that is enough for most programmers.
And thus Blub is "worse is better" personified since it does not pay for any abstraction it does not use.

>>127
You don't understand. It's not about demonstration for the purpose of explanation, it's about demonstration for the purpose of proof.

Imagine someone claiming that he considered various possibilities and concluded that spherical cars (which he calls "cudders") are in every possible way superior to traditional car-shaped cars. They have better structural integrity, dissipate less heat, etc. The logic is irrefutable. So you ask, where's your prototype, dude? Are you an engineer or a fucking philosopher? You don't logically prove that your design is superior, you build a prototype and prove by demonstration, that's the only kind of proof acceptable in engineering.

The blub argument isn't merely about ones ability to judge a language or technique, it's about ones inability to assess it due to ignorance, having failed to fully understand the demonstration.
The Blub argument is horribly misguided, because it assumes that people are supposed to judge a language by learning it, but then they are too lazy and remain ignorant, blah blah blah. People judge a language by observing the programs written in the language. Not even reading them, just noticing that they exist, are developed at such and such pace, have such and such defect incidence, etc.

You don't hear Blub programmers saying that yes, from seeing various useful Lisp programs they can infer that Lisp is clearly superior to Blub, but, sadly, they are too stupid to understand why. What you hear instead is them saying "proofcode or get the fuck out", and rightfully so.

>>128
What is the saying? If it is easy to use, but hard to do right, it should be part of the language.

The whole "Blub is bad" spouted by Paul Graham is more of "Blub is primitive and does not have X built-in"
Notice he doesn't mention speed, memory use, any real world characteristics but only abstracted out "power" since obvious this "power" is free(in performance) and does not require any "mental resources" unlike Blub.
    "Our hypothetical Blub programmer wouldn't use either [Cobol or assembly]. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

    As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

    When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

    By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs."

>>130
Don't be retarded. Lisps have been used to excellent effect for good and evil for years.

>How can you get anything done in Blub? It doesn't even have y.
because you don't do y, you do Z. Thats is the Blub way, its not as generic or complete, but its in Blub.
You want some Lisp? You have to add it yourself. Thats the Blub way.
Blub isn't better or worse, its just a niche thats wide enough for most tasks.
C++, Cobol, C, Fortran all been a form of Blub dominating the niche, and they all feel deficient, but every step in that niche in another Blub improving the former Blub. In the end Lisp will be a part of Generic Blub, and the reason for using Lisp at all will disappear.
Another worse-is-better victory.

C++ is seriously the most bloated motherfucking pile of shit ever created. When I think about all the brainpower wasted on C++, I cry a little bit.

>>133
Now it's not, at least not visibly, and that's all anyone needs to know about it.

And please don't start with the entire "you need to be popular to become popular" bullshit, languages and platforms get routinely bootstrapped based on their merit.

In 2005, people were choosing Ruby not because there was a lot of Ruby vacancies. And not because somebody convinced them to learn it on a dare, and they managed to understand the superiority of monkey patching.

In 2005, people were choosing Ruby because they saw DHH in a $1000 shirt and could smell easy money (also, Axe).

In 1970s, people were choosing C because they saw Unix and how it was ported on new hardware in the matter of days.

Contrary to the popular amongst lisp weenies belief, software industry is not "fashion-driven", Blub programmers actually have rather sensitive bullshit detectors.

>>136
I think lisp is about as popular as it can be with programmers as retarded as they are. I don't mean that as a snob, right now we need a metric fucktload of retarded programmers. I'd go so far as to say the reason we have so many retarded programmers is because we've gone about creating them because we need them.

Those who need lisp's power often find a way to use one. The naughty dog dude is still using lisps, I think actually he went from hand-rolling a lisp to hacking with mzscheme last I checked. I use Racket at work, but I'm not going to start a blog about it.

I don't really care if lisp-like languages are popular. If I cared about popularity I'd use C++.

>132

http://c2.com/cgi/wiki?PrematureOptimization

>>136

I'm not sure what you're trying to say.

Very little selects against unproductivity in the computing ecosystem. I don't think "it's what people are doing" is necessarily a good argument because of this. In the professional/enterprise world, which dominates the culture of the open source world (in the sense that the open source world is mostly professional programmers in their spare time, not full-time open source writers), productivity is essentially selected against. Your job security is improved by writing inflexible crap that takes a long time to develop. Secretly and subconsciously, few of us care if we can be more productive.

There are occasionally miracles, like Rails. But it's no surprise that it was born out of web startups and otherwise people who had a vested interest in the success of their company and not its failure. (And, again, having an interest in your company's failure is the norm.) But claiming that Ruby isn't a product of fashion is pretty... stupid. It's like the poster child for fashion in computing. "rockstars" anyone? Come on.

And, qualitatively, a lot of what Rails offers would really be better in a language with macros. But the thing is, a Lisp just doesn't superficially look as nice/familiar as Ruby. It's like getting programmers to use high level language is a matter of giving them a "spoonful of sugar" to help the medicine go down.

The problem with Blub programmers' "bullshit detectors" is that the practical effect is "everything new (to me or otherwise) is bullshit." Which is mostly true. The problem is that they don't see how bullshit their day to day work really is. If their bullshit detectors were half as 'sensitive' as you say, they'd see that spending all day debugging incidental problems caused by C++ is complete bullshit.

Because Linus and Theo say so

>>137
I think lisp is about as popular as it can be with programmers as retarded as they are.
Yeah. I want to point out one thing. Read some PG's essays back from early 2000s. He also says that all this stuff with lambdas and higher-order functions is waaaay over the head of an average (read: retarded) programmer. And that's why Lisp is unpopular. That's basically your argument, right?

Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data. And the code monkeys learn that shit. And Lisp is still unpopular, and you still blame the fact on it being waaay to complex for an average programmer, now in some other ways, like macros, I guess. Funny, isn't it?

>>138
Yeah, this totally makes sense. Average FOSS programmers produce crappy, buggy, slow, bloated code at a snail's pace, such is the pervasive Enterprise culture. At the same time the Lisp master race churns out perfect code a couple of hundred times faster. But every evening they delete all the code they wrote during the day, because the world just isn't ready for it yet.

>>140
That's basically your argument, right?
No. It has nothing to do with it. I don't doubt most coders could understand anonymous functions, closures, continuations, and so forth. But the thing is that they don't understand them, they don't usually gravitate to languages which exploit them, and they continually reinvent poor solutions to problems which are aided by them. Furthermore, they continue to insist on syntax which makes much of it very difficult.

Now, before you shit your pants over a lisper blathering on about syntax, I have no problem with syntax. I quite like nice syntax, actually. But because I like nice syntax, I want the syntax to be flexible, so I can bend it to my needs, when I need it---but not before. If I do it before, then the syntax could get in the way of something nice. (Metaprogramming, for example.)

Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data.
2011!!!! TWO THOUSAND FUCKING ELEVEN. This is DECADES too late. C++11 finally got anonymous functions. Are you fucking kidding me?

2011. This is a point against you, my friend.

Lisp is not complex, its just too different from normal ALGOL-type languages and the syntax is making it cryptic.
Average programmer would not choose Lisp even if Lisp was faster. The features average programmers needs are already there in Blub and Blub is fast enough.

>>140
At the same time the Lisp master race churns out perfect code a couple of hundred times faster. But every evening they delete all the code they wrote during the day, because the world just isn't ready for it yet.

Well if you were as well read of PG as you say, you'd know that is almost the case. Viaweb made Yahoo Stores in Common Lisp with 2 guys in a couple of years, and then they sold to Yahoo. Turns out, they couldn't find CL programmers to work on it, so they decided to have a couple dozen C++ programmers reimplement it in twice the time. The rumor is that they actually resorted to implementing Lisp for some of it, consciously confirming Greenspun's Tenth Rule.

The model of "high level stuff isn't used because programmers are uneducated about them and lack ambition." explains a lot more of what I see and personally experience than "high level stuff isn't used because it isn't actually valuable."

The problems with Lisp are cultural, both within and without, and solved in both cases by Clojure. Within - just needed a reboot.  Without - just need a stepping stone, like Java. Java programmers are finally seeing the value of lexical scope and immutability, but their language treats this stuff as special cases. I think Clojure will look more and more attractive to Java programmers.

>high level stuff isn't used because it isn't actually valuable.
The problem such stuff is not valuable outside of the language.
If you could port features to Blub they become valuable,thus making Blub more important and useful.

>>143
The rumor is that they actually resorted to implementing Lisp for some of it
I thought that was just PG's guess because he couldn't imagine how they'd do some of what he did without dark macrology. I know nothing of his coding skills, and I usually don't write macros because they aren't needed often, and since he agrees they aren't needed often and still felt the need to use them, I'd guess that his guess is probably correct. Sometimes you just need a fucking macro and C++ metaprogramming is a fucking joke.

>>145
macros ... aren't needed often...
...when one works on a toy problem, that has no need for it's own language.

>>146
Yeah, thats sad. All Lisp programs which don't integrate a toy language are deficient and need to be refactored.

>>146
Do you actually write programs or read about other people writing them? Even if you're going to implement a DSL, you're still not writing macros often. What the fucking fuck.

>>147
Well, I've a bunch of code, that looks like following:

(let ((var (expr)))
  (if (eq var :fail)
      (fail-expr var)
      (progn ...)))
I'll define a macro `try`:

(try (expr) (fail-expr it)
  ...)


How would you solve that?

>>130
You don't logically prove that your design is superior, you build a prototype and prove by demonstration, that's the only kind of proof acceptable in engineering.
lolwut? Anyway, software is intangible, thus it can't be engineered as it is application of the natural sciences.

The Blub argument is horribly misguided
It is not, Blub is easy to observe, if someone is exposed to BASICs (as I have when I was young), they'll write in the confines of most of BASICs paradigm.
The BASICs (incl. "structured BASICs" like QuickBASIC) were notorious for having a set of general case simple stuff intended to be BASIC, with a small bunch of cryptic shit for those who just happened to already know machine architecture and assembler like PEEK, POKE, VARPTR, VARSEG, which of course none of the BASIC manuals ever cover.
BASIC runtimes basically often had a lot of limitations like a bounded string space, limited number of string concatenations in some contexts (70 in QB45), and absolutely no advanced abstraction devices which all require a reference model to be part of the language. Despite the language, people managed to write fairly advanced things like games in it.
Exposure to C requires significant mental realignment after that as that language provides for raw references. What many attribute as object oriented being a significant improvement is mainly only having a referencing mechanism over record types, which was in assembler in raw manner and then Lisp in safe manner but with the first argument syntactically moved to the left side of the function call.

>>137
I think lisp is about as popular as it can be with programmers as retarded as they are. I don't mean that as a snob, right now we need a metric fucktload of retarded programmers. I'd go so far as to say the reason we have so many retarded programmers is because we've gone about creating them because we need them.
Indeed, Blub is used because common programmer livestock only need to write CRUD for their masters and that can be written in any language.
Most likely companies actually do use these other languages with advanced features despite speed tradeoffs because the experts the companies rely on require it but its always company secret.
Remember the russian dude that is going to prison for leaking Erlang code of Goldman Sachs.

>>140
Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data
Is there a job posting with this requirement as proof? VB.NET cevolved a lot since VB6 but it still allows stuff like ON ERROR RESUME NEXT, proficiency in anon funs would seem like a outlier skill.

>>141
No. It has nothing to do with it. I don't doubt most coders could understand anonymous functions, closures, continuations, and so forth. But the thing is that they don't understand them [...]
They do understand them now, when they are in Visual Basic. The fact that Visual Basic only got them about five years ago is completely irrelevant to your argument, unless you want to argue that the average programmer's IQ jumped up forty points since then (and then you'll have to explain why Lisp still isn't popular). Which means that the "Lisp paradox" can't be explained by the stupidity of the average programmer. No matter how much the argument flatters you.

>>143
Well if you were as well read of PG as you say, you'd know that is almost the case.
You missed the point. Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least. It doesn't matter how many morons are churning retarded code out there, all it should take is ten or twenty good programmers equipped with the superior tool to make all the difference. Fucking Reddit was implemented in Lisp by three or so guys, who then rewrote it in Python, ha ha.

You don't need to understand Lisp to be attracted to quality software. The premise of the Blub paradox doesn't work here. So if it is not happening, then there must be something wrong with theoretical justifications of Lisp superiority, seeing that Lisp programmers totally fail to produce superior software.

Also, I find it hilarious how you get in your rut and claim that the problem is with the incompetence of the majority of FOSS programmers, because the more incompetent they are, the easier it should be for hypothetical competent Lisp programmers to leave them in the dust. You are literally arguing for my point.

>>151
They do understand them now, when they are in Visual Basic. The fact that Visual Basic only got them about five years ago is completely irrelevant to your argument, unless you want to argue that the average programmer's IQ jumped up forty points since then
Whatever, you can continue to willfully misinterpret what I say ad infinitum so there's no point in trying to correct you.

But for those following along at home, the point is that these programmers easily handle and adopt solutions to problems already yielded decades ago by lisps. Only when a lisper points out, "Hey lisp does this," the first response is always, "When would I ever need to do that?" Then some pet language full of syntactical blunders throws in a lambda or something and there's a million blog posts about how cool language X is for doing this.

They are retarded because the solution has been there the whole time, they've been told about it, and they choose to remain willfully ignorant. Like >>151 actually.

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
Non sequitur. You must be the most naive motherfucker on the entire planet.

>>151
They do understand them now, when they are in Visual Basic. [...] programmer's IQ jumped up forty points since then (and then you'll have to explain why Lisp still isn't popular).
Visual Basic has a lot of stuff, it always had lots of stuff, that doesn't mean anybody is using it. It will also be avoided because the language has persisted for decades without it, all the blogspam tutorials won't cover it because they just in for the Adsense monies, and books just want you "proficient" in X hours, etc. Also, whenever anything is added to Visual Basic its because it is also in C#, VB.NET is just C# without braces, and things are added to C# to band-aid over limitations of the primary paradigm, those languages can do without the lambda, whereas lambda are central to the actual functioning of all functional languages. OTOH for Lisp's actual killer feature (protip: it is not lambda) does VB.NET have macros?

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
I don't know about others, but by the time I've been writing in Racket I just don't care about releasing anything, I do use it to analyze stuff like patterns in Wikipedia's dumps. Conversely, you'll find metric tons of stuff (mainly games) written in noob friendly languages because these people just want an EXE out, and have motivation to impress or some other similar desire.

>>153
these people just want an EXE out, and have motivation to impress or some other similar desire.
Sergey Brin just wanted a search engine out, he used noob friendly Python. Where is Brin with Python now and where is you with your Lisp? Q.E.D.

Just kill all lispers. Problem solved.

>>154
noob friendly Python.
I was actually thinking more along the lines of the various game optimized BASICs.
Where is Brin with Python now and where is you with your Lisp? Q.E.D.
（　≖‿≖）
(ﾉಥ益ಥ）ﾉ 彡┻━┻

>>155
Killing lispers won't kill Lisp.

>>157
Of course not. It's already dead.

>>158
doesn't look any deader than usual to me

>>152
They are retarded because the solution has been there the whole time, they've been told about it, and they choose to remain willfully ignorant.
Yes, but why have they choose to remain wilfully ignorant, this is the question! Not because they are too stupid to understand lambdas and higher-order functions (as PG argued), VB proves this. Why then? "Retards' ways are inscrutable", is that what your argument boils down, to wilful rejection of any attempts at explaining the phenomenon?

Here's an idea: maybe the immediate reason is that on one hand there are useful programs written in VB with lambdas, which makes VB codemonkeys to recognize the superiority of using lambdas, on the other hand there are no useful programs written in Lisp, which makes everyone with a grain of common sense to ignore Lisp?

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
Non sequitur. You must be the most naive motherfucker on the entire planet.
Nope. I see RoR mounting the webdev world precisely because it boosts productivity that much, and there are countless examples of that. There were no corporate backing, no aspie-flattering propaganda compared to PG's, just DHH in his $1000 shirt with a clear and loud message: I'm rich and famous because I developed such and such websites in a fraction of time it would take you with your PHP or whatever. You can be like me.

Similarly, C took the world by storm purely by virtue of demonstrating UNIX, how useful it is and how easy it is to port it on any platform.

This approach works. You show the virtue of your language by demonstrating useful programs written in it, and you get the snowball rolling, with more and more people contributing useful libraries, programs, examples, books.

Naturally, this approach doesn't work for Lisp, because Lispers don't practice it. Instead of writing useful programs and showing them to the world they produce innumerable arguments about Lisp superiority on purely theoretical basis. That doesn't work, no shit, Sherlock!

I repeat: programming is a branch of fucking engineering, it's not maths, it's not philosophy, your "logical arguments" are not worth half a shit. Like in physics, the experiment is what proves the theory, and nothing else.