The best language when it comes to CPU and RAM usage is machine language. You cannot do better than machine language. At all. No way. The best compiler will only match the machine language implementation, and usually not even come close.
there's actually a lot of debate about this point. unless you're a really, really good assembly programmer, a mature compiler working with well written high-level code will most likely produce faster, more efficient assembly than you can. a good compiler benefits from the years of knowledge and experience of its authors. this means that it knows every trick that they know. it knows the chip inside and out and can make much more sophisticated counter-intuitive optimizations around obscure side-effects of infrequently used instructions. compilers have less of an advantage on RISC architectures than they do on more advanced chips with hundreds of instructions; many more than most humans can hope to fully understand.
of course, if you write bad high-level code, the compiler will happily produce bad assembly code.
and assembly still can't be beat for code size. that and its direct access to the hardware are the reasons people still do use it.
its fun though and will teach you a great deal about computers that you just won't learn from coding high-level languages. you haven't lived till you've spent over 24 hours straight debugging Z-80 assembly.
anyway, i agree with your message though. TIMTOWTDI applies outside perl too. sometimes one of the ways to do it is a different language.
In reply to Re: "Get the Job Done" (GeJDo)
by thraxil
in thread Too Many Ways To Do It
by George_Sherston
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |