[racket] Question

Rüdiger Asche wrote at 09/05/2012 04:53 PM:
> Regardless, for the sake of the excercise, it's kind of enlightening 
> that your solution actually reduces to the naive approach - when I was 
> in school (before the last ice age if I recall correctly) , we'd 
> probably be asked to come up with an elegant *algorithmic* solution 
> (which means, for example, something like a tower of Hanoi type 
> circular swap which naturally beats the naive approach in the general 
> case) -

> if the choice now is between two approaches that actually do the same 
> thing only on two different abstraction levels - does that imply that 
> the student is already so familiar with the syntactic expansion 
> mechanism that he or she "looks behind the macro" at first glance and 
> is able to identify both as based on the same procedure and only takes 
> the macro approach for better readability -

CS undergrads are still taught algorithms and algorithmic efficiency, 
and some of them also learn a bit about lower-level stuff in an OS or 
compilers class.  But I wouldn't expect the average CS undergrad using 
Racket to have much idea how the "match" form is implemented, nor its 
performance characteristics.

Overall, I'd say that a smaller percentage of developers nowadays have 
awareness of how to write efficient code, than did a couple decades 
ago.  There's less need for it.  The computers are faster, the typical 
languages are higher level, and the barrier of effort required to do 
satisfactory software seems lower.  (A lot more stuff, such as in Web 
development, can be done at the skill level of what used to be MIS 
clerical workers, although the nature of the work is a little different.)

Learning efficiency is also harder now, when your program is fast 
regardless of how you write it, and you can't just count machine code 
instructions or use simple rules like "function calls and malloc are 
expensive".

The people who can do work in which efficiency still matters -- OS 
internals, embedded systems, large scalable systems, scientific 
computing, etc. -- still exist, just like they used to.  Some of them 
are even developing Racket or using Racket.

Neil V.