[antlr-interest] Re: build issues: bytecode assembly generation

micheal_jor open.zone at virgin.net
Fri Oct 22 08:47:28 PDT 2004



--- In antlr-interest at yahoogroups.com, "Don Caton" <dcaton at s...> wrote:
> Michael:
> 
> > I suspect because developing in Java is more productive and, 
> 
> Ugh.  I've heard this argument raised many times, whether it's from
the VB
> crowd or the Delphi crowd or whoever.  Whether one language is "more
> productive" than any other has far more to do with the skills and
experience
> of the person using the language in question, rather than the language
> itself.

Given developers with the same level of proficiency and experience
with C++ and Java, most will be able to produce an application like
ANTLR much more quickly and easily with Java than C++. There are of
course some applications where the need to optimize memory usage
and/or speed aggressively suggest C++ (or perhaps C or assembly
language) might be a better choice.

> Whether the ANTLR development effort over the years would be been less
> productive if C++ was used is questionable.

Not at all. Ensuring it compiled correctly on a variety of C++
compilers across many OS platforms would have been a job in itself.

> True that it would be impractical to post binaries for all
platforms, but
> given the nature of ANTLR, I would assume that most people interested in
> such a tool would have access to a C++ compiler.  It's not uncommon
on most
> platforms to build your own tools from source code.

ANTLR users all have access to gcc I suppose but, that is far from
saying they are C++ developers and can fix any issues that arise while
attempting a build. Many are Java or C# developers and may be quite
unused to compiling C++ projects. Lex/Yacc certainly don't require
this level of familiarity.

> > Incidentally, the DFA-as-bytecode generation issue isn't a 
> > runtime limitation, it is a *language* limitation
> 
> Yes, and that's the reason I raised the issue.  Whenever you have to
resort
> to a hack in order to work around a fundamental language limitation,
that
> (IMO) calls into question whether the right language is being used
for the
> job.

Perhaps. In this case my understanding is that Ter can already
generate Java code for the generated DFAs. He is now trying to
optimize the DFA generation/representation for Java targets. IOW, this
isn't an issue about the ANTLR tool itself. DFA generation for C++, C#
and other targets aren't affected and would presumably use those
language's features (including any required hacks to make them
similarly efficient).

> It seems curious that Java has a goto in its runtime but no way to
> express that in the language.

I seem to remember it has something to do with Java's secure mobile
code aspirations.

Micheal






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the antlr-interest mailing list