 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Warp wrote:
> > I'll try to be less paranoid next time.
>
> Thank you. I appreciate it. In return, feel free to say something early on
> if it sounds like I'm not making the effort. :-)
whoa! A lot of kicks, punches and bruises later and you almost feel in love...
:P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> whoa! A lot of kicks, punches and bruises later and you almost feel in love...
I'm not offended by anything Warp has said. He's a smart and insightful guy
with lots of knowledge. I learn enough from him I want to stay on his good
side. Occasionally his conversations style is annoying, but I'm pretty sure
mine is moreso. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/
Why write
(define (addn n) (lambda (k) (+ n k)))
when you can just say
addn n = (+n)
? ;-)
Seriously though, adding completely new features to a system not
designed to support them is not an easy thing to do. This is not news. I
do, however, agree that a simple design that is widely powerful is
better than a huge raft of special-purpose rules for specific situations.
(This is one of the reasons why Haskell's ever-expanding set of features
worries me. If people need all these extra features, doesn't that kind
of indicate that the language is broken?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> "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.
If a language is "powerful enough", you can create the abstractions you
need from within the language and use that. If the language is not
powerful enough, the things you need must be hard-coded into the
language, which is less flexible.
On the other hand, a compiler can take advantage of the specific
features of a specific language, but can't easily take advantage of the
properties of some custom abstraction that you designed yourself.
(Although some languages allow the programmer to specify compile-time
transformations that go some of the way.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>
>> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/
>
> Why write
>
> (define (addn n) (lambda (k) (+ n k)))
>
> when you can just say
>
> addn n = (+n)
Shouldn't that be addn n = (n+) ?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> Why write
>>
>> (define (addn n) (lambda (k) (+ n k)))
>>
>> when you can just say
>>
>> addn n = (+n)
>
> Shouldn't that be addn n = (n+) ?
It doesn't matter. Addition is usually a commutative operation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I see you're back! :D
Invisible escreveu:
> Darren New wrote:
>
>> http://vijaymathew.wordpress.com/2009/03/13/dangerous-designs/
>
> Why write
>
> (define (addn n) (lambda (k) (+ n k)))
>
> when you can just say
>
> addn n = (+n)
>
> ? ;-)
Because in plain Scheme you can't?
> (This is one of the reasons why Haskell's ever-expanding set of features
> worries me. If people need all these extra features, doesn't that kind
> of indicate that the language is broken?)
If I'm not wrong, core Haskell is about as clean and simple as plain
Scheme, both based on lambda calculus. Building upon solid, flexible
and simple infrastructure is not a bad idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > Shouldn't that be addn n = (n+) ?
> It doesn't matter. Addition is usually a commutative operation.
Unless you are using the + operator to, for example, concatenate strings...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Shouldn't that be addn n = (n+) ?
>
>> It doesn't matter. Addition is usually a commutative operation.
>
> Unless you are using the + operator to, for example, concatenate strings...
Sure. In that case, it makes a difference - and so you'd better decide
which one you actually meant. But remember, Haskell's string concat
operator is (++), not (+).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> I see you're back! :D
You can't see my back. It's invisible. ;-)
>> Why write
>>
>> (define (addn n) (lambda (k) (+ n k)))
>>
>> when you can just say
>>
>> addn n = (+n)
>>
>> ? ;-)
>
> Because in plain Scheme you can't?
I know that. ;-) I'm just being a Haskell whore, as usual.
>> (This is one of the reasons why Haskell's ever-expanding set of
>> features worries me. If people need all these extra features, doesn't
>> that kind of indicate that the language is broken?)
>
> If I'm not wrong, core Haskell is about as clean and simple as plain
> Scheme, both based on lambda calculus. Building upon solid, flexible
> and simple infrastructure is not a bad idea.
Sure. But taking a solid, flexible and simple infrastructure and making
it complex and convoluted isn't such a hot idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
