'make' year for Perl

while I agree that writing less code tends to generate fewer bugs, I adamantly disagree with the statement that the only way to write code with fewer bugs is to write less code.

even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.

using the language that best matches the abstraction of your code both decreases the lines of code needed, and decreases the errors. but the big win is in the fit, not in the lines of code.

>>As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it.
Whoever said that lied to you. A dynamic language has just as many paths through it. Just some of them are generated by the compiler/interpreter. The downside is since you give it less constraints it can do less optimisation and more importantly less error checking.
>>Ultimately - even truistically - the only way to write code with fewer bugs is to write less code.
Yes but that means less functionality.

>>The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation;

The languages which separate compilation and execution (which btw isn't a restriction of the language but rather of the tools we choose to write , we could write an interpreter for c++ if we wanted).

The power that some languages have is they can create code on the fly. Ironically this was something that assembly had but when it came to write 'c' it was stripped out. It's a feature that's rarely needed or desirable. It's far more often misused than it used correctly.

If one wished , one could add an 'eval' to compiled languages by seperately compiling the extra code as needed and having a few constraints on optimisations for the original code. One particular optimisation that we would need to be very careful with is where instead of having two variables 'foo' and 'bar' we instead alias 'bar' to 'foo' since our analysis shows that 'foo' and 'bar' always have the same value.

>>I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
I honestly don't understand why people like 'untyped' languages. It's no hassle to compile and run the code , and you could get the same speed as an untyped language out of a compiled language if you wanted to sacrifice optimisation and error checking to the same extent as an untyped one.

Consider the wasted time spent reanalysing a program every time you run it? and consider that you need to run it anyway to test it. Why not trade some of that reanalysis time for better optimisation? or time you could spend doing other things?

IMHO that was one of the things that scripting has historically got wrong but that's due to the fact that historically they didn't create an intermediate format but rather put the code into an 'abstract syntax tree' and interpreted it from that. That has changed though since a lot of them convert the AST into an intermediate form that is more linear and then interpret that.

Unfortunately it's one of the things that history has landed in our laps and it's not something we'll rid ourselves of soon.