Matz talks about FP and others

Ruby Creator Yukihiro "Matz" about Ruby,
Functional Programming and
Programming Languages Design

Quite interesting. It seems that Matz was
amazed by the power of Haskell, but thinking
it was a bit too hard to understand.
So I guess we could expect some features
in Ruby 2.0 would come from Haskell?
That would be quite appealing!

And he was interested with actor model too.
I guess Matz and I have some overlapped interests.
Akka seems very interesting too, though I don't
know how it differs from Scala's build-in actor.

some quotes below:

recent functional programming languages like
Haskell and OCaml has a lot of advanced functional
features. Some of them cannot be introduced
without changing the language like for example,
returning the lazy evaluation. We need to change
the language in a fundamental way.

Just like extreme programming, you need to
introduce almost all of the features/methods to
get benefits. Introducing one or few of them
won't help but makes troubles. We'll need to get
lazy evaluation, no side-effect, etc. at once,
or only get complexities without getting
real benefits.

The functional programming has many good attributes
in the programming, but still it's quite difficult
to understand to ordinary people like me.

Mmm...

To get all the good attributes of functional
programming, the language should be purely
functional, like Haskell.

Right...

I'm thinking about isolating the side effect into
a small part of the program, like an actor, so
they communicate with the channels without any
sharing data is the solution for that.

Mmm... how about command-query separation?
This would be easier to integrate since you
won't have to change the architecture.

Actor, as I said, is a quite interesting concept in these days,
since we had the buzzwords like "Clouds"

It's surely a buzzword... XDXD

it's quite difficult to integrate the STM into a
language like Ruby. I think I'd choose the Actors
if I were to do some kind of concurrency.

Sorry, I'm not familiar with STM.
Could someone elaborate why was STM
hard to integrate into Ruby?

Actors is part of the variation about object
oriented programming, in the historical sense.

Same as Reader said.

If there was any new paradigm in the future,
there should be there by now.

I cannot agree more...

If someone considers Ruby as a Smalltalk dialect,
I inherited so many concepts from Smalltalk, so
I'm proud of being part of the Smalltalk community.

I don't know Smalltalk, but feel quite the same.
I remember that someone said Smalltalk is revived
via Ruby. Perhaps I would say Ruby is superior too.

It's quite difficult to implement the small tools
like the scripting tool by Smalltalk by the
Smalltalk program that usually carries a huge
image with the software.

That's why I'd never tried Smalltalk...
It's quite difficult to give it a simple try!

Concurrency is very difficult to understand, so
making Ruby a concurrent language, makes Ruby
difficult to accept for many people.

Basically I agreed... but I guess someday we would
enter a world that you can't write a non-trivial
software with no concurrency. I'm just thinking loud...

Imagine the C++ templates: the basic concept is
very simple, but the C++ template, combined with
any other type systems and other features in the
language became very complex, it made the language
pretty complex.

Yet another I cannot agree more...

Q: You are not for functionalities that mix?
A: Yes, I try to avoid that kind of complexity.

Mmm... I don't know. Still trade-off I guess...

Let me put the PHP aside.

XD

Would post this (without my murmur) in 嵐達網 later.