Re: ANN: Kickstarter for beginning work on a new open-source Compiler

[Shark8 <OneWingedShark@gmail.com>]

On 19-Mar-14 15:28, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:0d9343e9-6190-46b0-a313-bc33ed17f28d@googlegroups.com...
> ...
>> But storing it as unprocessed text means that you [well, your
>> computer/tools] have to repeat a lot of work (e.g. parsing) again and
>> again. "Moving that processing to the outer loop" can reduce that, and
>> given the advantages of working w/ meaningful-data vs. generalized-text
>> it seems like a reasonable thing to do.
>
> *Seems* reasonable, but actually is just premature optimization.
>
> Computers have gotten amazingly fast these days -- a lot of the design
> decisions that we made with Janus/Ada to reduce compilation time and storage
> requirements don't do much today.
>
> And remember that an IDE needs human-level response times. On a modern
> computer, one can do a heck of a lot in between keypresses or mouse
> movements. On top of that, parsing is relatively easy and cheap. Parsing is
> one of the cheaper phases of a compiler, and it's dubious that it would be
> worth a complex (and likely to be much more fragile) data structure in order
> to save that small amount of time. Especially with the other costs of going
> away from standard text representations.

Fair points; but it still seems wrongheaded to treat the program-source 
as mere text unless absolutely needed. As someone said, text is the 
lowest common denominator... which is an absolutely stupid restriction 
when it comes to talking about tools; if everybody stuck to that 
ideology we'd all have vi or Notepad as our "standard programming editor".

Freeing the tools from the concerns of text (and files/filesystems) so 
they can concentrate on the job they're supposed to be doing is also one 
of the points I mention... this applies to programmers, too. (If you 
hate the company's officially approved style, there should be no reason 
whatsoever that the editor couldn't automatically translate between your 
preferred and the company's official style; if you're storing the code 
as an AST [or similar] then you have to handle that transition 
(txt->AST, AST->txt) anyway.... and switching styles should have no 
impact as "changes" in the Version-control system.)