![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
... 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 21:15:02
Message: <49bef995@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 16 Mar 2009 21:18:30
Message: <49befa66@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |