On Tuesday, March 11, 2003, at 12:27 pm, Shevek wrote:
[snip]
The tradeoff for moving things to compile time is coder speed. The extra
syntax, typing and complexity of source code structures makes it take
longer to write code. As we all know, machine time is MUCH cheaper than
programmer time.
I agree with your last sentence completely ;-) However, I don't think that moving stuff to compile time necessarily makes the source code more complex. All of the perl6 stuff that excites me is doing what I do already in perl5 - but doing it in a far more elegant and direct manner. It's going to save me keystrokes, not add more.
The fact that this makes it easier to introspect the code for optimisation is a happy side effect. The speed of perl has hardly ever been an issue for me... most of my code spends all its time waiting for databases and net connections :-)
There is also the fact that all of the new stuff is optional. You can still do:
sub double { map { $_ * 2} @_ };
if you want. You don't have to use the new stuff unless you need it.
(maybe there should be a new perl6 acronym - YDHTUYWT - You Don't Have To Unless You Want To ;-)
[snip]
[snip]Languages like ADA95 (I think), C++ (somewhat) [more examples?] are designed as very rich source languages to pass a lot of semantic information to the compiler. They are tedious to write. Frequently, however, the compiler throws away a lot of the semantic information too early in the compile phase). Traditional binary has no information to optimise.
Personally I think that's more an issue of language design rather than being directly related to the information sent to the compiler. C++ in particular has had its syntax and semantics warped considerably by its C roots and a fetish for execution efficiency above all other considerations.
On the other hand Eiffel, to pick another of my favourite minority languages, can take tons of semantic info to its compile stage, but (IMHO) has been designed well and is not at all tedious to write.
Yes, the compiler does need more info to do compile time optimisations - but writing this can be an advantage since you describe what your code does more precisely. In a well designed language this produces self-documenting code that is far easier to write, read and maintain. The programmer gains as much as the compiler does by the higher level of abstraction described in the code.
Not that I think there is anything wrong with runtime optimisations of course :-)
Cheers,
Adrian
