Glad to hear the ANTLR vs Yacc holy way (a.k.a. LL vs LR) is still going strong. This one holy war may actually be older than emacs vs vi. Have the ANTLR guys dropped their Java credo or they're still thinking they are going to convince any C developer with a .jar?
Both ANTLR and Yacc are painful to work with. I ended up writing my own parser generator instead. So much better!
Why you should not use (f)lex, yacc and bison
51–59 of 59 posts
Re: Why you should not use (f)lex, yacc and bison
#52Antler doesn’t support C or C++. But they’ll use an obscure C##.
Lots of people have opinions on the language (or Microsoft themselves) and it may not be up there with C++, Java, and Javascript in terms of adoption.
However it's 20+ years old, massively used in enterprise, powers sites like StackOverflow, and is most definitely (by language rankings and surveys) a top tier ecosystem - often in the top 5.
Re: Why you should not use (f)lex, yacc and bison
#53Earlier quoted context omitted.
How easy is it to make quick changes to hand-written parsers. Imagine, for example, that the input being parsed is not under the authors control and it suddenly changes. The parser must be changed.
It is super easy to change. It is just normal code.
Re: Why you should not use (f)lex, yacc and bison
#54While I definitely agree that ANTLR is a great tool, I feel that many of the critics about Bison are somewhat unfair.
First of all, many people like to tie Flex and Bison together, and that's wrong. You don't have to use Flex to feed tokens to your Bison parser. And my personal opinion is that Flex is badly maintained. Releases are infrequent, and issues keep on stacking. So please, stop putting Flex and Bison in the same bucket: they _can_ be used together, but they are not maintained by the same people.
Second, many people seem to not know that Bison is way more than YACC. To name just a few features of Bison
- it goes way beyond LALR(1): IELR(1), canonical LR(1), and GLR are supported
- it generates parsers in C, C++, Java and D
- it supports push and pull parsing
- it supports customized error message generation
- it can generate explicit counterexamples about conflicts (see https://en.wikipedia.org/wiki/GNU_Bison#Counterexample_gener... to see examples)
- it perfectly supports reentrant parsers and it comes with several examples of such parsers (see https://github.com/akimd/bison/tree/master/examples/c)
- and way more.
The original article says:
> Flex and Bison are very much stable software. They are maintained, but development of new features is limited, if not absent.
Before emitting such strong statements about Bison, please at least look at its current state and to the NEWS file (https://git.savannah.gnu.org/cgit/bison.git/tree/NEWS). There were two major releases in 2018, three in 2019 and two in 2020. That's 29 releases in four years if you also count the bug fix releases. Therefore "development of new features is limited, if not absent" is pretty much false. Did the author actually studied Bison before writing all this?
Re: Why you should not use (f)lex, yacc and bison
#55Re: Why you should not use (f)lex, yacc and bison
#56Re: Why you should not use (f)lex, yacc and bison
#57Re: Why you should not use (f)lex, yacc and bison
#58Antler doesn’t support C or C++. But they’ll use an obscure C##.
Obscure? C#? Lots of people have opinions on the language (or Microsoft themselves) and it may not be up there with C++, Java, and Javascript in terms of adoption. However it's 20+ years old, massively used in enterprise, powers sites like StackOverflow, and is most definitely (by language rankings and surveys) a top tier ecosystem - often in the top 5.
Re: Why you should not use (f)lex, yacc and bison
#59Earlier quoted context omitted.
Obscure? C#? Lots of people have opinions on the language (or Microsoft themselves) and it may not be up there with C++, Java, and Javascript in terms of adoption. However it's 20+ years old, massively used in enterprise, powers sites like StackOverflow, and is most definitely (by language rankings and surveys) a top tier ecosystem - often in the top 5.
many embedded systems could not use C++ namely because of lack of real-time capability caused by too-long pauses made by C++ garbage memory collection overhead.
You're right about embedded systems. Most ecosystems that use a GC would struggle there, including DotNet.