[plt-scheme] Teaching Scheme

Language comparisons and benchmarks are based on problems that are already solved.  Is the true value of programming, solving new ones?  In the comparison involving the 100 doors problem, the point should be the comparison of techniques that lead to the solution as if one does not exist.  Which of these 'languages' leads to a solution that recognizes the square-root property?  Can a language lead to such a solution?  Or is it the programming techniques that use the language?

My point of view stems from experience, which might not be typical: many projects are over budget and behind schedule because programs do not work.  They do not work because they are not designed sensibly, yet organizations insist to fuss over issues such as those covered in comparisons often shown in web pages: interpreted vs compiled, this language vs that one, this unrolled loop vs that embedded machine code, etc.

Computers are part of a fantastic technology that allows us to solve problems which are not even necessarily technical, but their technical implementation distracts us mercilessly.

rac

On May 3, 2010, at 6:35 AM, Samuel Williams wrote:

> Dear Shriram,
> 
> Thanks for your reply.
> 
> On 4/05/2010, at 2:31 AM, Shriram Krishnamurthi wrote:
> 
>> Let me caricature (a part of) this exchange:
>> 
>> Samuel: ... interpreted vs compiled ...
>> 
>> Shriram: nonsensical!
>> 
>> Samuel: well, most X's have interpreters, most Y's have compilers, so
>> it's reasonable to call X interpreted and Y compiled
>> 
>> Doug: convention is good, and anyway some languages are more static
>> and others are more dynamic, so we can use "interpreted" and
>> "compiled" as proxies
>> 
>> Samuel: yes, the term doesn't quite make sense (think about JITs), but
>> also, what Doug said!
>> 
>> To which I offer several responses:
>> 
>> 1. Notice how you (Samuel) subtly shifted your argument.
>> 
> 
> Thanks for your clarification. I feel that it is simply a matter of being aware that there are a vast range of terminologies and that not everyone agrees on the same meaning. I think its perfectly valid to be aware that terminology can be used in different ways with different meanings, and I appreciate your insights.
> 
> I don't think I've ever made an argument one way or another - I have simply done my best to use accepted conventions - but I appreciate that this might not be the best approach...
> 
> What is really important, as you have pointed out (point #3), is the general biases and assumptions made by the affiliation of a particular terminology to a particular language, and in a sense its implementation. I think this is actually a very important point which I haven't considered much.
> 
>> 2. If you want to use "interpreted" and "compiled" as aliases for
>> "dynamic" and "static", why not just use "dynamic" and "static"
>> instead, instead of abusing terminology?  Indeed, if you are trying to
>> create an EDUCATIONAL site, why not EDUCATE people that their
>> terminology is wrong, rater than propagate their mistakes?
> 
> This makes a lot of sense. So, do you separate it like this:
> 
>> 
>> 3. These terms are not value-neutral.  People hear "compiled" and
>> think "fast"; they hear "interpreted" and think "slow".  (Admit it, so
>> do you.)  Of course, this might have nothing to do with the reality of
>> implementations.  But it damns languages prematurely.
> 
> Well, in a sense, it depends on terminology and understanding. When I think compiled I think rigid and structured, and when I think interpreted I think potentially slow and somewhat more flexible.
> 
> I think generally this is a relatively well accepted understanding - but I'm not suggesting that it is correct. From your arguments I believe that it might not be a good way to portray languages.
> 
>> 
>> 4. Sometimes, these terms are references not to the implementation
>> strategy but to the interaction interface: "interpreted" means "offers
>> a REPL" while "compiled" means "works off a command-line".  But in
>> fact that is another bogus alias.  Furthermore, it does a great
>> disservice to compiler writers for languages like Scheme, who've taken
>> the trouble to write actual compilers while providing the *interface*
>> of an "interpreter".  Why don't you give them credit for their work?
>> 
> 
> Sure, this makes sense.
> 
>> Personally, I learned Scheme using a compiler and C using an
>> interpreter (really), so these terms have always struck me as bogus.
>> 
> 
> Understandably so.
> 
>> As for paradigms, I've made my point in my document.  Glad you enjoyed
>> reading it.  If you insist on using absurd terminology, I won't get in
>> your way.
> 
> Well, while I think your response is overly harsh, I think you make valid points and I'll certainly do my best to improve the standard of the material.
> 
> Can you give me some feedback about the categorization:
> 
> Statically Typed:
> 	C, C++, Haskell, Java, Pascal
> 
> Dynamically Typed:
> 	Ruby, Python, Scheme, Smalltalk, Perl, Basic, JavaScript, PHP
> 
> I personally still see issues with the terminology, but please suggest the way it can be improved for better education and awareness. I'll also discuss this with my professors.
> 
> Do you think its appropriate to mention that the main implementation is compiler or interpreter? Or is this pretty much a non-issue in your mind?
> 
>> 
>> As for the broader issues with your site, Neil and Jos have made the
>> relevant points admirably.
>> 
>> Shriram
> 
> Kind regards,
> Samuel
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100503/98fda972/attachment.html>