Empirical evidence is nearly impossible in this area.
On the other hand, we have a solid theory, not some "beliefs". If you want to dismiss the entire PL theory, you have to try really hard to justify such a stupid move first. The problem is, most of the dynamic proponents know next to nothing about the PL theory anyway.
> Empirical evidence is nearly impossible in this area.
Then stop arguing as if you have evidence. It's really that simple.
Present something that is not derived from opinion and speculation and make this an argument that is not subjective.
For what it's worth, I prefer static, strong type systems and I was recently dreaming out loud about strong, static typing in erlang with a colleague. I don't confuse my opinion and speculation in what's good and not with fact, though, which is the big difference.
> If you want to dismiss the entire PL theory, you have to try really hard to justify such a stupid move first.
It's a fact that there exists no definite proof of the objective superiority of static, strong typing. I don't need to "dismiss the entire PL theory" (what a silly thing to even say; not all PL theory is concerned with types).
You've come exactly 0.0% closer to showing any kind of evidence, empirical or not, and have only speculated more (on the value of static, strong type systems and of the skill and knowledge of people who disagree with you).
> Please, do present the solid theory that is not simply derived from speculation and opinion.
What theory shows is enough to claim superiority:
1) Dynamic typing is a subset of a static typing. This thing alone is enough.
2) Static typing provides more semantic options in both compile and run time, meaning that you can do more diverse things. Also quite a strong claim for superiority.
My friend, I am one of the biggest proponents of static typing that you will find, and let me say you are talking absolute nonsense. Your argument is very poor indeed and your attitude is setting back the social cause of promoting statically typed languages.
> 1) Dynamic typing is a subset of a static typing. This thing alone is enough.
This is like saying that more syntax is better. No, cutting away from something can make it better. This argument is not at all enough to claim superiority.
(C can be considered a subset of C++. Which is better?)
> 2) Static typing provides more semantic options in both compile and run time, meaning that you can do more diverse things. Also quite a strong claim for superiority.
"More diverse things" is ill defined. Which are they and why are they a net win? This is not at all a strong claim for anything, except "There is more".
> No, cutting away from something can make it better
What?!?
You can build a dynamic type system on top of a static one. The opposite is impossible. What else is there to even talk about?
> "More diverse things" is ill defined.
It is very well defined. Static (i.e., compile time) metadata allows to infer constraints in compile time. Dynamic metadata is useless for deriving constraints. A very obvious consequence of this observation is that there will always be far more boilerplate with dynamic typing than with static.
> You can build a dynamic type system on top of a static one. The opposite is impossible. What else is there to even talk about?
We are talking about the value of different kinds of type systems and using them. Being able to build a dynamic one on top of a static one says very little about whether or not dynamic or static typing is better for actual usage. On top of this lots of languages have added gradual typing, so this idea that you cannot take a language that is not statically typed and add a type system seems misguided.
> A very obvious consequence of this observation is that there will always be far more boilerplate with dynamic typing than with static.
I hope you realize that this is not at all what reality looks like.
> We are talking about the value of different kinds of type systems and using them.
Exactly. And you're apparently suggesting that there may not be a single case where you may want static constraints. Kinda very strong position, needs very strong proofs indeed.
> gradual typing
Gradual typing IS a static typing, period.
> you cannot take a language that is not statically typed and add a type system seems misguided.
What?!?
You cannot build a gradual typing system on top of a dynamic one.
> this is not at all what reality looks like.
I can only conclude that you do not know much about the reality if you think so.
> Exactly. And you're apparently suggesting that there may not be a single case where you may want static constraints.
No, I have consistently asked for objective proof that static typing is a net win over dynamic typing, something you have yet to even address. I don't know if you're intentionally misrepresenting my argument or if you're simply misunderstanding it, but I think you should re-read this whole thread.
As I've said previously, I prefer static strong typing, but I'm also in touch with reality and to present my opinion and speculation as some kind of fact isn't something I'm interested in.
> I can only conclude that you do not know much about the reality if you think so.
If we're jumping to conclusions I'd like to conclude that you think all PL theory is type theory and that you're ignorant of every other bit of it (and also that you're the type of person to think your every opinion is fact. I think both of these have been on display in this thread, so I actually think that's a stronger conclusion than the one you've drawn).
Sorry, cannot reply down the thread, so I'll put my answer here:
> This is not necessarily true: Static typing quite often requires you to satisfy the type system
We're talking about static typing in general, not some particular implementation of it.
Any static type system with an "anything" type (think of the System.Object in .NET, for example) allows a transparent fallback to dynamic at any time.
So, claiming that "there is a cost" is an outright lie.
> I haven't stated that dynamic typing is better, but I have stated that people claiming one or the other need to have proof.
You know, there is a little funny thingy called "logic". And one of the most common tricks in logic is a proof by contradiction. When you're asking for a proof that static typing is superior, the simplest way is to start with "let's assume dynamic typing is superior". This is exactly what I did. Unfortunately, you could not follow.
> If your programs are as airtight as the "proof" you've given here, I'm not sure I ever want to use them.
It's understandable that a person who do not know much about type systems in particular and PL theory in general also apparently does not know much about proofs and logic in general. After all, type theory and proof theory are indistinguishable.
> You know, there is a little funny thingy called "logic". And one of the most common tricks in logic is a proof by contradiction. When you're asking for a proof that static typing is superior, the simplest way is to start with "let's assume dynamic typing is superior". This is exactly what I did. Unfortunately, you could not follow.
Condescending, but not to be confused with correct. I'll try as well:
Given your obviously limited knowledge and familiarity with English I can understand that you seem to have issues understanding my basic argument, but I'll restate it for you:
If you are trying to claim something as superior, you need to provide actual reasons for it, not just speculation.
I hope you followed that.
> It's understandable that a person who do not know much about type systems in particular and PL theory in general also apparently does not know much about proofs and logic in general. After all, type theory and proof theory are indistinguishable.
It's actually not understandable that someone who claims to have a lot of knowledge in type systems and type theory, as well as logic, to provide "proof" that in no way proves what was asked for. It's also surprising that someone who claims to be so well versed in PLT essentially says it's all type theory.
It's understandable if a person with reading comprehension issues would have problems reading this post, so if you have any questions regarding it (or the previous posts), feel free to ask.
It is very childish and stupid to respond to a proof with a shit like "no, this is not a proof".
> The idea that static type systems are better to use (in general) because you can make dynamic type systems on top of them is simply not something you can just say and then have taken as fact.
Oh, did not realise you're so incompetent (although I should have guessed after your epic fail with the gradual typing). Do I have to prove that 2+2=4 too?
Once again: dynamic typing is a subset of static typing and therefore it is less powerful. Period. You cannot do anything with this fact.
Also, funny that you did not respond to my accusation that you believe that type systems are only for "validity checking". Which suggests that I was right.
We bent over backwards not to ban you, gave you lots of warnings and cut you tons more slack than we usually do. You're aware of how unacceptable it is to post comments like this to HN, and still you did it repeatedly in this thread, turning a large section of it into a toxic waste dump.
Obviously, your account is now banned. If you don't want it to be banned, you can email us at hn@ycombinator.com, but please don't do that until you're sincerely committed to never spoiling HN like this again.
Please stop editing your posts 40 minutes after you initially post them in order to muddle the post history. You're literally removing entire posts and adding completely new things, even as responses to responses. Work on your netiquette.
> Also, funny that you did not respond to my accusation that you believe that type systems are only for "validity checking". Which suggests that I was right.
No, not responding to something does not mean "you were right". I think strong static type systems are useful in many ways and I've already told you repeatedly that I prefer them. I have literally no care in the world what you assume about me.
Can you confidently say that you've given even one clear reason why it's better to use static typing over dynamic typing in this thread? You've gone on one rant about the fact that you can build a dynamic type system on top of a static one, but haven't actually presented even one fact about why it's better to use static typing over dynamic typing.
No one, in their next project, is going to build a dynamic type system in their static one, and then jerk off over that fact, when they could just start working on their ACTUAL project. Would you recommend to someone choosing between static and dynamic typing to start with a static one and then build their dynamic one on top of that?
Your posts are full of bullshit, stupid assumptions and personal attacks. I only wish you'll realize what a disservice it does to acceptance of your opinion and how hard it is to agree with you even while holding much of the same opinion, because you're so insufferable.
Do you feel like you should be able to make any nonsensical argument you want and people should take that as fact/proof? The idea that static type systems are better to use (in general) because you can make dynamic type systems on top of them is simply not something you can just say and then have taken as fact.
Also, I should add, I think you lost the "this is childish call" when, two posts into this thread, you made assumptions about everyone saying dynamic typing was useful (they obviously are not on your level, amirite?).
You started this thread off by saying empirical evidence of which is better for practical use is almost impossible to get. You then proceeded to argue your position as fact, knowing that you had no evidence to support it. If you want to present your opinion as fact, then feel free to find actual facts to support it.
You and sklogic took this thread into an inner circle of flamewar hell. This is a poster child for the kind of discussion we don't want here, which pollutes HN for everyone else. Please don't do this again.
If you feel provoked, catch it before it drives you into an angry back-and-forth. That's not easy, but it's something we all have to work on in order not to destroy this site.
> Please stop editing your posts 40 minutes after you initially post them in order to muddle the post history.
HN does not allow to continue a thread below a certain threshold.
> I think strong static type systems are useful in many ways and I've already told you repeatedly that I prefer them.
This is not what I was talking about. Learn to read.
My point is that you do not understand what does it mean that a bigger type system is providing new semantics for the language. You still fail to understand it, obviously, because this is a central point of my proof, which you failed to comprehend.
> No one, in their next project, is going to build a dynamic type system in their static one, and then jerk off over that fact, when they could just start working on their ACTUAL project.
Take a look at pretty much any code in static languages - it is almost always doing exactly this: various degrees of dynamic typing on top of static. Sometimes it is ugly, sometimes it is done the right way (LLVM is a good example of this approach).
> Would you recommend to someone choosing between static and dynamic typing to start with a static one and then build their dynamic one on top of that?
Even you somehow heard something about the gradual typing - which is exactly an example of this.
> Your posts are full of bullshit, stupid assumptions and personal attacks.
Omg. I'm only responding to your attacks. You're an uninformed and incompetent side in this argument, not me.
> HN does not allow to continue a thread below a certain threshold.
Click on the time (for example "2 minutes ago") to open the post and reply there.
> My point is that you do not understand what does it mean that a bigger type system is providing new semantics for the language. You still fail to understand it, because this is a central point of my proof.
And my point is that you haven't answered why using a static type system over a dynamic one is a net win for people, which is the entire point. If there is no empiric evidence, don't argue as if there were. You yourself admitted that there is no evidence for it, so why are you arguing from a contradictory position?
> Even you somehow heard something about the gradual typing - which is exactly an example of this.
No, the practical flow of doing that is exactly the opposite: Starting from dynamic typing and imposing types when they are needed, likely after an exploratory phase. You seem to be arguing from a much more disconnected view point where you take the position that the platforms underlying representation is what matters, and I am arguing from a practical perspective (What should the programmer choose for his next project?).
> Click on the time (for example "2 minutes ago") to open the post and reply there.
Shit. Is it a new feature? I do not remember this working before.
> And my point is that you haven't answered why using a static type system over a dynamic one is a net win for people
I am not interested in diverting the discussion from the topic. The topic was that static typing is superior to dynamic typing - i.e., more powerful and more flexible.
How does it translate to a "net win"? I do not care, honestly. There are fare to many factors other than the language features.
> I am not interested in diverting the discussion from the topic. The topic was that static typing is superior to dynamic typing - i.e., more powerful and more flexible.
> How does it translate to a "net win"? I do not care, honestly. There are fare to many factors other than the language features.
I'm glad we established that you don't care about the net win of this, so that we can agree that we're not at all talking about the same thing.
The net win is the entire point. I don't care how something is done if it's not a net win for me and my projects. It's irrelevant to say something is better in theory if there is absolutely no proof of it actually being better.
I can love macros, but would I go ahead and assert that a language with macros is absolutely better than a language without? No, they have a cost associated with them and their misuse makes things worse. Hence, they're not objectively superior to anything else. This goes for almost any feature, until you can prove a net win.
(Edit: The same goes for my point about C++ earlier. There are more things in C++ than there are in C, but most people would argue that C++ has too many things and that many of them actually make things worse. Hence, having more things in C++ could be considered a net loss.)
If your assessment was that I prefer being pragmatic and that I believe most things have a cost, then yes. I think macros can be done right (in Scheme, etc.), but even then they have a potential cost.
> Of course they are.
And this is obviously where we definitely diverge. I think macros are great, but I acknowledge that you can't make that statement without big disclaimers. You don't seem to care about being pragmatic, so for you it's more clear cut.
I provided you with a proof. Cannot you follow such a trivial logic?
Let me repeat it again, slowly:
1) Dynamic typing is a subset of static typing. With static typing you can do everything that is possible with a dynamic typing, at no additional cost, while the opposite is not true.
2) Static typing is far more than a mere "validity checking", as you apparently seem to believe. These advanced semantic properties cannot be added on top of a dynamic type system, so, even suggesting that a dynamic type system may be somehow superior is automatically declaring that under no circumstances you will ever need any of these properties.
> With static typing you can do everything that is possible with a dynamic typing, at no additional cost [...]
This is not necessarily true: Static typing quite often requires you to satisfy the type system and quite often is an exercise in what essentially amounts to paperwork. There is a cost.
> 2) Static typing is far more than a mere "validity checking", as you apparently seem to believe. These advanced semantic properties cannot be added on top of a dynamic type system, so, even suggesting that a dynamic type system may be somehow superior is automatically declaring that under no circumstances you will ever need any of these properties.
I haven't stated that dynamic typing is better, but I have stated that people claiming one or the other need to have proof. Dynamic typing is very rarely stated as better, whereas static typing is quite often cited as better subjectively, even if it's only opinion.
If your programs are as airtight as the "proof" you've given here, I'm not sure I ever want to use them.
Have your opinion and know that I share it (mostly), but also know that it's an opinion and that you'd do well in not confusing it with fact. Strong, static type systems are nice, but to say they're superior to dynamic type systems is an opinion and to present it as anything else is a lie.
> The problem is, most of the dynamic proponents know next to nothing about the PL theory anyway.
This is either a "triumph" of theory over reality, or an insult of a whole group of people.
In short: A lot of people like dynamic typing, and can be productive in it. If the "theory" you cite says static typing is better, the "theory" needs to be changed to reflect reality. If, on the other hand, you're wrong about the theory and/or about dynamic typing enthusiasts knowing it, you should apologize.
> A lot of people like dynamic typing, and can be productive in it.
"A lot of people can be productive in it" does not establish that nothing else could be better. I can be productive in bash, but I think we all agree "stringly typed" is not as good as most other approaches to programming language design.
Even "a lot of people find themselves to be most productive in it" doesn't tell us much, as other factors could very well dominate (most significantly familiarity of language and/or paradigm, but I'm sure we can both think of plenty of other candidates).
That honestly surprises me. When text is central, that sounds like when you most need to be able to organize your data without worrying about whether a delimiter might occur in some content...
Note that I'm not saying that a stringly typed language mightn't, in some cases, be the best choice. Just that it will be the best choice for reasons other than being stringly typed, and a language that allowed better organization of your data while offering similar affordances would be an improvement.
This is exactly the fallacy that dynamic proponents are constantly running into. Do not help them by reinforcing such claims.
Static typing bears important semantics far beyond a mere "validity checking" and compile time optimisations. And this fact is overlooked far too often.
In a static type system, all of the expressions and expression-like constructs of your language may have a constraint attached to them, which guarantees that a value this expression yields have certain properties; In a static type system there is a well defined set of rules, describing how such constraints are transformed when expressions are combined in a certain way.
In a dynamic type system, no such constraints exist (besides for the constant literals, of course) and there are no rules for combining the constraints.
This gets close but I think it doesn't yield a conclusion that Java is statically typed, and I think most people want a definition that concludes Java is statically typed.
(unless you allow only fairly trivial "constraints" in which case you're no longer distinguishing between categories of languages, since essentially any language can satisfy a trivial-enough constraint on its expressions)
I think it's reasonable to draw the line somewhere between Java and, say, Python in the kind of constraints that a type system can enforce. Java does not have a particularly sophisticated type system, but I wouldn't be surprised if I could get some reasonable help from it (I haven't written any Java in years, much Java in longer...).
Just remember that one of the reasons why the JVM does all sorts of fancy/mind-boggling runtime heuristics and optimizations is precisely because it's not possible, at compile time, to always determine a usefully-specific type.
(and to really go off the deep end, in Java it's not possible to determine even what the universe of possible types is at compile time, which is why I like it as a counterexample to people who think they can meaningfully define "statically typed" and have it manage to include Java)
> it's not possible, at compile time, to always determine a usefully-specific type.
You seem to be using "type" here to mean "runtime representation", which is a common use but is only one specific case of what is being discussed above. As I understand it (and remember that my Java is rusty), it is entirely possible to statically guarantee that whatever a given expression evaluates to, it satisfies a particular interface (moreover, it was deliberately labeled as doing so). That may not be "usefully-specific" for an optimizer (or more carefully, it may leave some vague that will be more usefully specified at runtime; we haven't established that the level of specification is of no use), but it certainly seems to be a constraint of the sort that sklogic was talking about above, and it seems like something that could be useful to me as a programmer.
I actually think that "representational types" - constraints that tell us explicitly about how the data is represented in memory - is the place where the dynamic typing languages got it right. As long as it's internally consistent, I don't care exactly how the data is laid out, and automatic systems can do a plenty good enough job figuring that out (except at system boundaries where I need to worry about interchange, or if I care an unusual amount about performance). If representation is not something I care about, I should not be wasting time/attention talking about it. Where, IMO, this goes wrong is overgeneralizing to say, "... and since that's all types are good for, types are not useful." That's not all types are good for.
> (and to really go off the deep end, in Java it's not possible to determine even what the universe of possible types is at compile time, which is why I like it as a counterexample to people who think they can meaningfully define "statically typed" and have it manage to include Java)
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types. This isn't a problem for the theory - we've still internally verified the constraints we're checking in each module, and potentially also at the interface (depending a bit on ABI).
it certainly seems to be a constraint of the sort that sklogic was talking about above
Well, this is the thing. sklogic and others seem to think there's some sort of clear bright line dividing, say, Python from Java, where in Python they'll claim you can only deduce a constraint like "is of type object" ahead of time but in Java you can deduce something more specific.
And setting aside the falsity of that (even on Python 2, which doesn't have the annotation syntax or library support to do type hinting, you can still deduce a lot of specific information AOT), I'd argue with the concept of a clear dividing line and say instead that there's a spectrum. And I say this precisely because in languages like Java you can end up only able to deduce something will be of, say, type "Entity", which while better than "Object" still feels less like a qualitatively different thing to me and less useful for expressing the kind of rich constraints hardcore static-type folks talk about. Yet people seem to accept it as a statically typed language.
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types.
It can happen in other languages, but Java specifically does a lot of heavy lifting to work around this kind of issue, and some of that is specific to the features and quirks of Java. There's a reason, after all, why people non-jokingly refer to the JVM as the best dynamically-typed language runtime ever developed.
But again what we end up talking about is less a clear binary of "this language is dynamic, that language is static" and more of a spectrum of different combinations of features and design choices which sort of gradually blend into each other as you look at them side-by-side. Which is why I like to argue with the idea that we can meaningfully define "static" or "dynamic" typing.
I can't even process what you're saying. What culture doesn't acknowledge self respect, and one's place in society relative to others?
Certainly there are small communities everywhere (even in America -- after all, they were prolific in America's infancy) that sought the creation of a hyper-communal and idyllic towns... but... those never scale because, well, people are selfish. But still. I just can't process what you're saying. Maybe I'm blinded by offense.
But we're talking about self-esteem, which everyone is supposed to get for free. Self-respect, like the respect of others, must be earned. Equating the two is a quintessentially modern-American mistake (I'm a modern American, and I made this mistake myself for years), and I think that's what 'sklogic calls out above.
> What culture doesn't acknowledge self respect, and one's place in society relative to others?
What culture (besides the Northern Americans) would so blindly equate self respect to self esteem? The others understand better that you can respect yourself even without the overblown, unrealistic views on your own abilities and virtues.
>>Do not forget that this very "self esteem" thingy is almost exclusively American. The other nations do not even think in such terms.
This over inflated sense of importance or "self esteem thingy" may be exclusively American but not anywhere close to all Americans subscribe to it. There are 330+ million people of various ages and backgrounds living in the US. I don't see how painting with such a broad brush like you have been does anything but inflame debate.
My question is this though, as much as people like bandying DK around, has it not been replicated? Specific to you, has the effect not been tested anywhere outside North America?
You're saying Americans are the only people in the world who care about themselves? Other countries are full of purely rational actors who attach no emotional value to their own abilities? Have you ever met a real person outside of America?
Ok, only Americans have over-inflated self esteem, that's a different statement. Still wrong, but at least it's a common stereotype.
And I don't think that study supports your comment at all.
> Supporting this contention, our Chinese participants reported liking themselves every bit as much as our European American participants.
> This finding supports our claim that cultural differences in self-esteem arise from cultural differences in self-evaluations, with people from East Asian countries evaluating themselves less positively than people from Western countries.
> Thus, even though cognitive self-evaluations are lower in China than in America, they are not less predictive of global self-esteem. This finding suggests that global self-esteem is experienced similarly across dissimilar cultures
This study finds that self esteem is equally prevalent across the two cultures, and as far as I can see says nothing about how much the participants value their self esteem.
Fine, I would be interested to see evidence of that if you have any. The study you linked was not related, and that doesn't match up with my own experiences with non-American.
Do you have a quote that describes that, because that's not what I saw at all. The basic summary is that while Chinese people tend to evaluate their skills more modestly than Americans, their emotional self esteem is just as high. I didn't see anything analyzing how they value their self esteem, or how it affects their behavior.
Because the author has an agenda, he's a dynamic typing and unit testing proponent. Do not expect anything even distantly resembling any kind of an objective science from someone who clearly is not interested in facts.
This is pretty much a personal attack and those are not allowed here.
Also, what you're saying doesn't match my recollection of luu's writings on this topic, which is that he's mildly in favor of static typing but changed his mind somewhat after looking at the dismal state of the evidence.
Who is not interested in facts? Did you even read the linked article? If you read nothing else, at least read the summary. He makes very very clear that he is a static typing proponent.
If that one is not, are there any scientific studies then?
Strongly typed languages require of me to do more work upfront, to satisfy their type checker. They must necessarily reject programs that would work correctly. In this process a lot of mistakes are eliminated, and this gives me more confidence that the result will work. I like that way of working. But does it produce more robust code? Is it more productive? It feels like it, but that doesn't mean it's true.
"Strongly typed" is not the same thing as "statically typed". Most dynamically typed languages are strongly typed, too. The distinction between static and dynamic type systems comes from whether type errors are caught at compilation time or run time.
Which basically settles the question for me as a programmer, anyway. Eliminating the possibility of a class of run time failures -- how can that not be a good thing?
The question to me is not whether type checkers are useful tools, but at what point they become a hindrance. If I may rephrase your question: The programs rejected by the type checker, how can they not be bad programs?
TL.DR. Looks like FP reduces bugs, and static typed FP reduces them a bit more, but there isn't enough data for the more interesting fine-granied conclusions.
Anecdotes are case studies. In social sciences, for example, it's often the only thing you have. Do not dismiss this kind of evidence when you do not have any other options.
And it's a natural match for Packrat, they work together really well.
> writing a hand-written parser is straightforward (although laborious)
Not that much more laborious than writing a BNF. You can still use a parser generator, just add some annotations for the error recovery, error reporting, pretty printing and indentation.
> It's not straightforward to combine two parsers for two sublanguages
With PEG or another lexerless parsing it's totally trivial. You can mix any languages you like.
> Writing reusable parsers.
Again, trivial with PEG, where parsers can be extensible and generic, and can be inherited in full or partially by the consequent parsers.
> Try writing a parser that allows you to reformat your source code, with whitespace and comments preserved.
And again, trivial with the lexerless PEG-based parsers.
> Try writing a parser with the hooks necessary to supports code completion and auto-correct.
You're getting this for free when using PEG.
> The line between the lexer and parser is not clear
Just forget about the lexers, once and for all. It's 21st century already. Burn your Dragon Book.
> With PEG or another lexerless parsing it's totally trivial. You can mix any languages you like.
Not strictly true; combining PEG parsers will always work, but it might not give you the answers you want. If you have some outer layer that has 'value=' and you want to follow it by an expression in various sub-languages, you have to try each language in turn - if language A has some weird corner-case where it happens to accept something that's an important and common case in language B, language A will always win unless you swap the two languages around, in which case B might recognise and mask some important syntax from A.
Worse, your combined language parser cannot tell you that the combination of A and B cause a problem, because PEG parsers don't really support that kind of consistency-checking. It's just a bug that'll crop up at run-time.
You can get around this by manipulating the outer syntax to have special "language A" and "language B" prefixes to mark what syntax to expect, or by manually merging them to create "language AB" which has the syntax priorities you want. But in both cases, that's (potentially delicate and thoughtful) human intervention, not "straightforward combining of two parsers".
> because PEG parsers don't really support that kind of consistency-checking
Not true at all. You can easily check if a new parser is breaking anything in the old one.
And in practice you never mix languages at the same level. A more typical example of such a mixing would be, say, regexp syntax in javascript.
EDIT: if you want more details on a theory of this static PEG verification, they will be available some time later when I polish my next bunch of commits.
I like PEGs a lot and even wrote my own PEG-like parsing language. The main problem I found was that, in practice, mixing lexing and parsing is a bad idea, so I have separate lexing in my system. It depends on the language, but I would say it's true for all programming languages.
It's just obvious that programming languages have separate lexical and grammatical structure. If you want to disprove that, show me some languages like C, Java, Python, etc. expressed as PEGs.
PEGs have been around for 12 years now; I don't see them being deployed widely. There are probably multiple reasons for that, but I believe usability in terms of expressing real languages is a big one. (People always harp on ordered choice; I don't think it's that big a deal because when you write a recursive descent parser, you're mostly using ordered choice too.)
You want to do as much work in the less powerful computational paradigm as possible -- that is, lex with regular languages. And then use the more powerful paradigm (PEGs or CFG algorithms) on top of that token stream.
I believe that lexing and parsing were combined in PEGs for reasons of academic presentation and bootstrapping, not for usability or practicality for recognizing real languages.
Several of your other points are wrong, but I'll leave it at that.
This is not because of a parsing complexity, it is only because C++ is an awful language for writing ASTs and parsers. Without all the boilerplate, an AST can be much smaller.
Why would you parse C++ on a low memory device anyway? What are you going to do with it? Anything that follows the parsing would require far more memory.
On the other hand, we have a solid theory, not some "beliefs". If you want to dismiss the entire PL theory, you have to try really hard to justify such a stupid move first. The problem is, most of the dynamic proponents know next to nothing about the PL theory anyway.