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

[Don Caton]

Michael:

Yes, I will certainly agree that compiling on various platforms can be a
headache.  I've seen cross-platform C++ headers that would make your eyes
bleed.  But OTOH, user contributions from ANTLR users on various platforms
could assist in that effort.  And to be honest, there's no "official"
support for Antlr on Windows platforms to speak of.  It took quite a bit of
trial and error to get Antlr to even run under Windows. 

> 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++. 

Well, with all due respect I'm not sure how you can make that assertion.
IMO, it depends to a large degree on the individual programmer.  If any
particular language was significantly easier to use, everyone would be using
it.  In any case, this is a philosophical issue on which we may simply
disagree.

>           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.

Yes, like parsers <g>.  In a debug build, it takes my antlr-generated (C++)
parser about 15 seconds to parse a 77k source file.  With full optimizations
enabled, the same code finishes in slightly under 2 seconds.  I'm not
kidding.  I was sweating bullets when got my parser to work and found it was
so slow.

Regards,
 
Don Caton
Shoreline Software, Inc.
 

> -----Original Message-----
> From: micheal_jor [mailto:open.zone at virgin.net] 
> Sent: Friday, October 22, 2004 11:47 AM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: build issues: bytecode assembly 
> generation
> 
> 
> 
> --- 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
> 
> 
> 
>  
> 
> 
> 
> 




 
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/