tags:

views:

1576

answers:

8

The software base I am developing for uses a signficant amount of yacc which I don't need to deal with. Some times I think it would be helpful in understanding some problems I find but most of the time I can get away with my complete ignorance of yacc.

My question are there enough new projects out there that still use yacc to warrant the time I'll need to learn it?

Edit: Given the response is mostly in favour of learning Yacc, is there a similar language that you would recommend over yacc?

+21  A: 

Yes, these tools are worth learning if you ever need to create or modify code that parses a grammar.

For many years the de facto tool for generating code to parse a grammar was yacc, or its GNU cousin, bison.

Lately I've heard there are a couple of new kids on the block, but the principle is the same: you write a declarative grammar in a format that is more or less in Backus-Naur Form (BNF) and yacc/bison/whatever generates some code for you that would be extremely tedious to write by hand.

Also, the principles behind grammars can be very useful to learn even if you don't need to work on such code directly. I haven't worked with parsers much since taking a course on Compiler Design in college, but understanding runtime stacks, lookahead parsers, expression evaluation, and a lot of other related things has helped me immensely to write and debug my code effectively.

edit: Given your followup question about other tools, Yacc/Bison of course are best for C/C++ projects, since they generate C code. There are similar tools for other languages. Not all grammars are equivalent, and some parser generators can only grok grammars of a certain complexity. So you might need to find a tool that can parse your grammar. See http://en.wikipedia.org/wiki/Comparison_of_parser_generators

Bill Karwin
Totally agree with Bill - descending parsers are critical part of development heritage that seems to have been forgotten.
stephbu
+5  A: 

I don't know about new projects using it but I'm involved in seven different maintenance jobs that use lex and yacc for processing configuration files.

No XML for me, no-sir-ee :-).

Solutions using lex/yacc are a step up from the old configuration files of "key = val" lines since they allow better hierarchical structures like:

server = "mercury" {
    ip = "172.3.5.13"
    gateway = "172.3.5.1"
}
server = "venus" {
    ip = "172.3.5.21"
    gateway = "172.3.5.1"
}

And, yes, I know you can do that with XML, but these are primarily legacy applications written in C and, to be honest, I'd use lex/yacc for new (non-Java) jobs as well.

That's because I prefer delivering software on time and budget rather than delivering the greatest new whizz-bang technology - my clients won't pay for my education, they want results first and foremost and I'm already expert at lex/yacc and have all the template code for doing it quickly.

paxdiablo
I agree that grammars like above are better for config files, but not for the reason you claim. Not having time to learn is an awful reason. A better reason is that XML config files are in fact ugly, bloated and suitable for processing by programs rather than people.
Rafał Dowgird
It's nothing to do with not having time to learn. As with all business decisions, there's a cost-benefit analysis - why learn a new way of doing it slower (for me) when there's a perfectly good faster way? I run a business, not a educational institution. Free time is better spent with family.
paxdiablo
+1  A: 

I work on projects that use Yacc. Not new code - but were they new, they'd still use Yacc or a close relative (Bison, Byacc, ...).

Yes, I regard it as worth learning if you work in C.

Also consider learning ANTLR, or other more modern parser generators. But knowledge of Yacc will stand you in good stead - it will help you learn any other similar tools too, since a lot of the basic theory is similar.

Jonathan Leffler
A: 

A general rule of thumb: code lasts a long time, so the technologies used in that code last a long time, too. It would take an enormous amount of time to replace the codebase you mention (it took 15 years to build it...), which in turn implies that it will still be around in 5, 10, or more years. (There's even a chance that someone who reads this answer will end up working on it!)

Another rule of thumb: if a general-purpose technology is commonplace enough that you have encountered it already, it's probably commonplace enough that you should familiarize yourself with it, because you'll see it again one day. Who knows: by familiarizing yourself with it, maybe you added a useful tool to your toolbox...

Yacc is one of these technologies: you're probably going to run into it again, it's not that difficult, and the principles you'll learn apply to the whole family of parser constructors.

Rich
I understand the first two points you are making (regarding likelihood that the sw will still be around and bumping into yacc) but the company is throwing out the current product and starting from scratch so doesn't really apply to me :)
hhafez
+2  A: 

I don't know about yacc/bison specifically, but I have used antlr, cup, jlex and javacc. I thought they would only be of accademic importance, but as it turns out we needed a domain-specific language, and this gave us a much nicer solution than some "simpler" (regex based) parsers out there. Maintenance might be an issue in many environments, though - since most coders these days won't have any experience with parsing tools.

Draemon
since my next role will be Java role I'll have a look at jlex/javacc
hhafez
It's *well* worth the time invested to pick the tool best suited to the type of grammar you're using to describe the language.CUP is LALRAntlr is LL*JavaCC is LL(k)And some lexers and parsers work better or worse together. We went with CUP+JLex but it's all down to the language.
Draemon
+2  A: 

I haven't had the chance to compare it with other parsing systems but I can definitely recommend ANTLR based on my own experience and also with its large and active user base.

Another plus point for ANTLR is ANTLRWorks: The ANTLR GUI Development Environment which is a great help while developing and debugging your grammars. I've yet to see another parsing system which is supported by such an IDE.

utku_karatas
ANTLR has mostly the same syntax as YACC but it's also used in conjunction with java. The principles are the same.
boutta
+3  A: 

PEGs are the new hotness, but there are still a ton of projects that use yacc or tools more modern than yacc. I would frown on a new project that chose to use yacc, but for existing projects porting to a more modern tool may not make sense. This makes having rough familiarity with yacc a useful skill.

If you're totally unfamiliar with the topic of parser generators I'd encourage you to learn about one, any one. Many of the concepts are portable between them. Also, it's a useful tool to have in the belt: once you know one you'll understand how they can often be superior compared to regex heavy hand written parsers. If you're already comfortable with the topic of parsers, I wouldn't worry about it. You'll learn yacc if and when you need to in order to get something done.

Jason Watkins
A: 

We are writing new yacc code at my company for shipping products. Yes, this stuff is still used.

Mitch Haile