[plt-scheme] Teaching Scheme

I just want to make sure students (and therefore my future software
developers) understand why languages like FORTRAN and C (as examples) have
the semantics that they have, why languages like LISP (or Scheme) and Python
(as examples) have the semantics they have, and why those semantics are
different. I think it is rather interesting that FORTRAN and LISP (in its
various flavors) as two of the earliest languages are still the two
exemplars of the extremes. [As an American, maybe I should call FORTRAN a
'conservative or republican' language and LISP as a 'liberal or democratic'
language. I can't help but notice that, in that case, the liberal languages
seem to be more factionalized than the conservative ones.] More 'modern'
languages seem to fill in between them.


On Mon, May 3, 2010 at 7:57 AM, Samuel Williams <
space.ship.traveller at gmail.com> wrote:

> Dear Doug,
>
> I appreciate your feedback.
>
> In a certain sense, I agree that having the appropriate terminology is
> useful. In any subject, we are stuck with words which have vague definitions
> at best.
>
> Compiled vs Interpreted is a very crude comparison - but I like the way you
> have summarized it.
>
> As an interesting (counter?) example, we have JRuby. Ruby is interpreted by
> Java implementation of Ruby. Then, for optimization, we compile the Ruby AST
> (abstract syntax tree) into Java bytecode which runs directly on top of the
> JVM (still an interpreter). Then we expect the JVM to compile bytecode into
> native code, if it is suitable. Is JRuby compiled or interpreted? Who knows!
> I don't know! Both!
>
> Well, after a bit of hand waving, its still useful to call JRuby an
> interpreted language, in my opinion. But it certainly isn't black or white
> :p
>
> However, I agree that the terminology is important, and the distinction is
> important. We have to agree on something otherwise it becomes difficult to
> discuss and communicate.
>
> Maybe Shriram, you can provide some insight into exactly what point of view
> you are taking, since we might be misinterpreting your response.
>
> Kind regards,
> Samuel
>
> On 4/05/2010, at 1:42 AM, Doug Williams wrote:
>
> As pointed out in your paper, the use of terms compiled versus interpreted
> is a long-standing, high-level generalization of programming languages.
> There are languages like FORTRAN and C that essentially go out of their way
> to bind things early specifically so they can be efficiently converted into
> machine language - i.e., compiled. Other languages like LISP (or Scheme) and
> Python go out of their way to delay binding for flexibility - which
> confounds efficient compilation to an extent. [And, yes the language
> designers often had exactly those distinctions in mind in designing specific
> languages - particularly those on the compiled side.] I personally find the
> distinction useful and definitely not nonsensical. I would say ignoring the
> conventional terminology is as bad as literally embracing them. Just my 2
> cents.
>
> On Mon, May 3, 2010 at 6:50 AM, Shriram Krishnamurthi <sk at cs.brown.edu>wrote:
>
>> Dear Mr. Williams,
>>
>> The phrase "interpreted", when applied to languages, is nonsensical.
>> Think about it for a minute and it should be clear to you.
>>
>> The notion of programming language paradigms is also, in my opinion,
>> largely nonsensical:
>>
>>
>> http://www.cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/<http://www.cs.brown.edu/%7Esk/Publications/Papers/Published/sk-teach-pl-post-linnaean/>
>>
>> I'm sure you have the best of intentions, but I have no idea what it
>> is you're actually trying to accomplish -- in particular, why are you
>> trying to reconstruct information that is already abundantly available
>> on the Web?
>>
>> Shriram
>> _________________________________________________
>>  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/e16d9a9f/attachment.html>