

Functional Languages Discussion by Joe, Odersky & Don Syme  - thebootstrapper
http://www.infoq.com/interviews/functional-langs

======
lsd5you
I feel a bit for Martin as a non-native English speaker. It can be very easy
for the native speakers to dominate a discussion unintentionally (and even
when trying not to).

The impression Erlang gives me is one of being almost an anti-language,
emphasising the system at large and discouraging over sophistication in the
details. I think the point Joe Armstrong makes about hardware interoperability
is telling. His vision of software is one much closer to hardware and the
networking. Though I think the fact that there is an awful lot of unnecessary
complexity in software it does not mean that sophistication and complexity is
not sometimes necessary. Not that he ever voiced that, just sometimes in the
process of advocating something pluralism can get left out.

------
jhrobert
I am amazed that there would still be discussions about what OOP is or is not.

The only agreement seems to be around "polymorphing" -- the ability to define
a behaviour that works consistently over many "things" that share some
similarities. Good.

But the root of evil comes back to very initial definition of what an object
is:

An "object" is something very concrete, it is not a mere "thing", it has: \-
an identity \- a state \- a behaviour

Is a "hello" an object? No, no more than 9 or any number is an object, because
these beasts are "values".

However, the way a string is implemented is probably an object at some level
(this is not true of a number, CPUs can deal with them directly). But this is
an implementation detail.

Unfortunately the essential difference between what is a Value and what is an
Object is poorly promoted/teached. But this is improving thanks to functional
languages.

In a perfect world there would be "things", that are either "values" or
"objects". In the imperfect world of us we have "objects", that are more or
less mutable.

~~~
shadowfox
> An "object" is something very concrete, it is not a mere "thing", it has: -
> an identity - a state - a behaviour. Is a "hello" an object? No, no more
> than 9 or any number is an object, because these beasts are "values".

This seems to be strongly debated (still). Languages like Ruby (and Smalltalk)
treat numbers as objects. You can argue that numbers are really objects with
immutable state for example.

This is not to say that I disagree with what you are saying. But the topic
itself is still debated (as is a lot of stuff about the theory and basics of
object systems)

~~~
silentbicycle
Indeed. The meaning of "object" has always been pretty fuzzy in CS. When you
compile C code, you get .o ("object") files. It's like "thingamajig".

~~~
jhrobert
That's because the source is the plan to build a table, whereas the .o file is
the table itself. Tables are objects, plans to build tables are ideas.

~~~
silentbicycle
Sure, but the connection between that and "object" in the OOP sense is
tenuous. For all it matters, the .o file could contain "chunks".

------
davidw
Very interesting and wide ranging discussion. Lots of ideas in there too:

> Joe Armstrong: What I’d like to see and we don’t do is integrate the
> language within the revision control system because if you rename a
> variable, and you submit it to the revision control system and say "This is
> a completely different version of a completely different program but you
> just rely on the variable because there is no semantics at all just to make
> it a little bit more readable if you correct a spelling mistake in a
> comment." The revision control system is a sort of generic and applied to
> any programming language and that’s really stupid. They need to be much more
> smart to check what really happening, not this superficial stuff.

> Don Syme: So we’ll have Erlang RCS, Erlang specialized?

Early on, Joe Armstrong talks about Erlang being "object oriented". I don't
really agree though, because by the time you actually get processes and things
put together - especially with OTP - you have a lot of other stuff running
underneath, so you're not just operating at a 'pure' level of sending messages
back and forth. And there's lots of boilerplate too. However, it's still a
good way of thinking about Erlang from an architectural point of view.

