POV-Ray : Newsgroups : povray.off-topic : This is the sort of brokenness... Server Time
6 Sep 2024 09:17:09 EDT (-0400)
  This is the sort of brokenness... (Message 1 to 10 of 164)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Darren New
Subject: This is the sort of brokenness...
Date: 16 Mar 2009 14:42:03
Message: <49be9d7b$1@news.povray.org>
... that I hate seeing in a popular language. Backwards compatibility for a 
language already rushed out the door is really a killer, IMO.

http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."


Post a reply to this message

From: Warp
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 15:14:58
Message: <49bea532@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> ... that I hate seeing in a popular language. Backwards compatibility for a 
> language already rushed out the door is really a killer, IMO.

> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/

  In my little experience, trying to use a programming paradigm (eg. OOP)
with a language which has no specific support for that paradigm (eg.
traditional lisp or scheme, or C) only creates a ton of kludges.

  Also this:

"The argument is that, using a very small number of rules for forming
expressions and with a minimal syntax it is possible to support all
possible programming paradigms. For instance, if the language has
support for higher-order functions, closures and dynamic typing, we
can implement object oriented programming without special language
level syntactic support. Tail-call optimization elude the need for
special looping constructs."

sounds like you could argue in favor of languages like brainfuck which
have a minimal set of instructions, yet are still Turing-complete.

  Eg. just because tail recursion is enough to perform any kind of
looping construct doesn't necessarily mean that special looping constructs
wouldn't be a useful tool.

-- 
                                                          - Warp


Post a reply to this message

From: Darren New
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 16:30:37
Message: <49beb6ed@news.povray.org>
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> ... that I hate seeing in a popular language. Backwards compatibility for a 
>> language already rushed out the door is really a killer, IMO.
> 
>> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/
> 
>   In my little experience, trying to use a programming paradigm (eg. OOP)
> with a language which has no specific support for that paradigm (eg.
> traditional lisp or scheme, or C) only creates a ton of kludges.

Yeah, except these kludges are in the class files, because nobody wants to 
break the JVM to get new features. Alternately, you get things like .NET 
with a bunch of new features that are only available on Windows because 
people doing Mono need time (and motivation) to reimplement. Hard to say 
which mechanism is best.

> "The argument is that, using a very small number of rules for forming
> expressions and with a minimal syntax it is possible to support all
> possible programming paradigms. For instance, if the language has
> support for higher-order functions, closures and dynamic typing, we
> can implement object oriented programming without special language
> level syntactic support. Tail-call optimization elude the need for
> special looping constructs."
> 
> sounds like you could argue in favor of languages like brainfuck which
> have a minimal set of instructions, yet are still Turing-complete.

If it's fast enough and you have sufficiently flexible macros, sure. Kind of 
like the way C++ can use general purpose constructor and destructor 
semantics to implement resource management.

>   Eg. just because tail recursion is enough to perform any kind of
> looping construct doesn't necessarily mean that special looping constructs
> wouldn't be a useful tool.

I think if you look at the level he's speaking about here, i.e., the JVM 
level, that objection goes away.  Think about something like .NET only 
supporting tail recursion in the CIL - all the *languages* would translate 
looping stuff into tail recursion, just like right now C# translates 
closures into nested class declarations invisibly.

And if you're familiar with LISP, and the power of its macro system, you can 
see where he's coming from - LISP has a powerful looping construct (called 
LOOP :-) that expands internally into the definition of a tail-recursive 
function.

Something where you can't rewrite the source code at compile time to fit 
your needs? No, doesn't work out to make a bunch of minimal things. It also 
pushes the burden for figuring out optimizations back onto the runtime. For 
example, in a C-style for loop, you can tell by looking at the source code 
if there's an index variable that can be stored in a register and not pushed 
to memory on each loop. (In Pascal, it's trivial, for example, due to "for" 
being much simpler.) If you have a macro that turns every loop into tail 
recursion, then the runtime/JIT/whatever now has to analyze the variables 
coming in and the variables being passed in *all* the possible 
tail-recursive calls to see if there's one that might be serving as a loop 
index. On the other hand, you might also wind up with more opportunities to 
optimize something that would be harder to express in something like C, so 
the compiler needs to do as much work, but doesn't because the compiler 
authors spent more time on other types of optimization. Sort of the 
difference between generating optimal bytecodes from Java vs generating 
optimal machine code from bytecodes, given the entire context of the program.


-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."


Post a reply to this message

From: Darren New
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 18:07:45
Message: <49becdb1$1@news.povray.org>
Warp wrote:
>   In my little experience, trying to use a programming paradigm (eg. OOP)
> with a language which has no specific support for that paradigm (eg.
> traditional lisp or scheme, or C) only creates a ton of kludges.

Actually, LISP has excellent support for OO. It has closures (which are 
objects without the types, not unlike javascript objects) and it has macros 
that let you Do The Right Thing with the syntax and integrate it cleanly 
into the language. It's not going to look like Java/C++/C#/etc classes, but 
I'd disagree it's a kludge.

I don't remember scheme enough to know how clean it is, and I'll agree with 
you on the C part. :-)  And that's not to say there aren't things that would 
be very difficult to do in LISP without native support built into the 
language (like some forms of control flow, for example).

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."


Post a reply to this message

From: nemesis
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 18:42:30
Message: <49bed5d6$1@news.povray.org>
Darren New escreveu:
> Warp wrote:
>>   In my little experience, trying to use a programming paradigm (eg. OOP)
>> with a language which has no specific support for that paradigm (eg.
>> traditional lisp or scheme, or C) only creates a ton of kludges.
> 
> Actually, LISP has excellent support for OO. It has closures (which are 
> objects without the types, not unlike javascript objects) and it has 
> macros that let you Do The Right Thing with the syntax and integrate it 
> cleanly into the language. It's not going to look like Java/C++/C#/etc 
> classes, but I'd disagree it's a kludge.

More than that, Common Lisp has CLOS:
http://en.wikipedia.org/wiki/Common_Lisp_Object_System

> I don't remember scheme enough to know how clean it is, and I'll agree 
> with you on the C part. :-)  And that's not to say there aren't things 
> that would be very difficult to do in LISP without native support built 
> into the language (like some forms of control flow, for example).

Are you kidding?  One of the main strenghts of Lisp is its macro system. 
  Not dumb C preprocessing, a metaprogramming features which allows you 
to create nice new syntax for any control flow you want.

See:
http://www.paulgraham.com/onlisp.html

Scheme itself lives up to its original goal as a minimalist and 
incredibly flexible and powerful language.  See for instance an 
implementation of a full-fledged, purely functional object-system:
http://okmij.org/ftp/Scheme/index.html#pure-oo

This is done purely with functions and will look awkward for Warp in the 
way they are called, but thing is:  one layer of macros later and it 
looks just as integrated into the language as if OO was always there.


Post a reply to this message

From: Darren New
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 19:12:58
Message: <49bedcfa$1@news.povray.org>
nemesis wrote:
> More than that, Common Lisp has CLOS:
> http://en.wikipedia.org/wiki/Common_Lisp_Object_System

Yes. I was trying to describe that it doesn't have to be built in, tho. :-) 
I like CLOS.

(I don't know if CLOS counts as "built in" or not.)

>> I don't remember scheme enough to know how clean it is, and I'll agree 
>> with you on the C part. :-)  And that's not to say there aren't things 
>> that would be very difficult to do in LISP without native support 
>> built into the language (like some forms of control flow, for example).
> 
> Are you kidding?  One of the main strenghts of Lisp is its macro system.

Didn't I say that? :-)

> http://okmij.org/ftp/Scheme/index.html#pure-oo

Cool. Thanks for that.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."


Post a reply to this message

From: nemesis
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 20:35:01
Message: <web.49beefea11b2c188b5d35d190@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> (I don't know if CLOS counts as "built in" or not.)

It is.

> > http://okmij.org/ftp/Scheme/index.html#pure-oo
>
> Cool. Thanks for that.

That guy has all sorts of cool stuff, either in Scheme, Haskell or C++.

The "On Lisp" book by Paul Graham is very good too.  It's available in PDF and
explores Lisp macros as no other.


Post a reply to this message

From: Darren New
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 20:39:15
Message: <49bef133@news.povray.org>
nemesis wrote:
> The "On Lisp" book by Paul Graham is very good too.  It's available in PDF and
> explores Lisp macros as no other.

Yep. Got it, read it. :-) I wish I had a use for it. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 21:15:02
Message: <49bef995@news.povray.org>
Warp wrote:
>   In my little experience, trying to use a programming paradigm (eg. OOP)
> with a language which has no specific support for that paradigm (eg.
> traditional lisp or scheme, or C) only creates a ton of kludges.

Heh, did you see the GObject framework?


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 21:18:30
Message: <49befa66@news.povray.org>
Darren New wrote:
> ... that I hate seeing in a popular language. Backwards compatibility for
> a language already rushed out the door is really a killer, IMO.
> 
> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/

OMG, *that* is how they implemented it?!


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.