Erlang hints from an CO junkie

[Vlad Balin]

> I'm getting a bit tired of seeing Alan Kay's name spelled with an "e".
> It's KAY, not KEY.
I'm not native speaker, as you could notice. And have read this name in
Russian.
Thank you for correction. Btw, it's more polite just to spell it properly.
It's not particularry interesting to know have you been tired or not.

> For what it's worth, Smalltalk, including the Squeak and Croquet systems
> on which Alan Kay has most recently worked, does *not* really handle
> concurrency via OO.  Processes are objects, and
>     pid := [.....block of code....] fork.
[ skipped ]
We discussing an approach for conceptual desing, not the way *how* it's
implemented in Smalltalk. Details of Smalltalk implementation are not
interesting, what is interesting is the _semantic_ (!) of message processing
operation, if you can understand the difference, of cause.

Here you just switched the topic. Previously it was about KAY's (thank you
again) definition of an object system, not about
Smalltalk implementation. Read mail carefully, please.

> Another important point is that if you combine
>  - processes which do computations using
>  - a pure functional programming language
>  - and message sends to other processes
> then the potential for things that look like mutable variables is
> inescapable.  This happens in CCS, CSP, and the (few) related formalisms
> that I am familiar with:  once you can do
>
>     var := receive <store,X> then var(X)
>
>     var(X) := receive <store,Y> then var(Y)
>            or receive <fetch,Pid> then send <value,X> to Pid then var(X)
>
> then you have something practically indistinguishable from an imperative
> variable.  If you want a solution that doesn't involve something that
> looks like mutable state encapsulated in processes (even though it isn't
> technically mutable), then you have to ban processes.
>
> This *DOESN'T* look like OO.  It looks like CCS or CSP or mu calculus
> or FCP or GHC or whatever.
So many clever words, and no any arguments why and in which sense it
*DOESN'T* look like OO. Looks like capitalization is is used instead of
arguments. Moreover, you have not even referred to definition OO
which it *DOESN'T* look like. Who knows, what is happening in your head?
Noone, until you explain. Now I feel only that you are a bit tired.

> That doesn't mean you can't implement OO in such a scheme.
> I once had an MSc student who designed a highly concurrent OO language
> and implemented it by mapping it onto a version of ML with CSP-ish
> extensions.  (Was the name of that ML version LCS?  Something like that.)
> But OO certainly doesn't feel *natural* in this model.
 [ skipped ]
> My point here is that if you
>
> 	Just look at it from another side.
>
> then a whole lot of things which are easy to do in Erlang become
> practically impossible to think of.
Really? :) Are you sure you understand the mail you're replying on?
You mean, that if I will think of processes as of objects (without classes)
at the stage of *high*level*design* (in order to simplify "concurrency
patterns"
identification), then I magically will not be able to take Erlang process
nuances into account in further design and development? :))) IMHO,
people are not idiots.

[ skipped ]

> 	>From the other hand, string object from STL (C++) is an
> 	excellent example of OO practice.
>
> (a) While C++ strings _are_ part of the C++ standard, they are _not_
>     part of the STL.  I have a copy of the 1998 STL Programmer's Guide
>     from SGI online, and I can assure readers that 'string' is not there.
I have several STL libraries installed on my computer, and as
working C++ developer with 5+ year expertience I can assure you that string
is a part of these libraries. And STL library is the part of C++ standard,
JFYI.
http://www.sgi.com/tech/stl/table_of_contents.html
Strings are defined as one of STL container types. I will not assure
"readers"
in anything like you, just give them the possibility to check it online.

Anyway, if string even would not be a part of STL, it's completely STL
compatible,
and designed in a spirit of STL.

It's funny to see how you're step by step trying to proof that I'm an idiot
:)).
It even look like the main goal of you "publication". One problem, I'm sure
that
I'm not one. And I (like the most people) don't like such attempts.

> (b) C++ strings are widely regarded as a disastrously bad design.
>     They have so many problems that I don't know where to begin, but
>     you will find plenty of discussion of the topic on the web.
:)) I see, they have so many problems that you choose not bother yourself
giving
example of even one. Likely, it could be found in internet, because it's
known that almost everything can be found there. :))

> (c) The funny thing about the Standard Template Library is that
>     IT IS NOT OBJECT-ORIENTED.  It's all about *templates*, as the name
>     says, not about *objects*.  What it depends on is NOT OO in any
>     way shape or form but higher-order functions and overloading.
>     You can, and Stepanov in fact *did*, produce something very similar
>     for Ada 83, which was the last version of Ada not to support OO.
The funny thing is that OBJECT-ORIENTED term has a number of different
definitions, and OBJECT term has been often defined separately from OBJECT-
ORIENTATION.

The more funny thing is that you have to read my mail again
in order understand which definition of OBJECT I'm operating with. I do
not make a secret out of it.

And the funniest thing is that I'm not going to discuss with you which
definition
of an OBJECT term is better. Leave it to the college students.

> 	Suppose you want to capitalize letters in the string.  If you
> 	going to find (sic.) corresponding method in std::string, you are
> 	wrong.  You will not find it.  Because string expose only an
> 	iterator interface, like generic container, which doesn't depend
> 	on string implementation.  _This_ is the right way to represent
> 	the string object.
>
> C++ strings do _not_ "expose only an iterator interface".  A quick check
> with an AWK script looking at /opt/SUNWspro/WS6U2/include/CC/Cstd/string
> found over 100 public types and methods.  Some of those are the iterator
> interface, but the majority of them are not.  There's assignment,
> comparison, concatenation, in-place appending, searching, all sorts of
> stuff done directly by basic_string<> and _not_ via the STL at all.
Not all sorts of stuff. I meant that it'm mainly STL container (not only an
iterator, of cause) interface, with a few string specific functions. In
contract to CString model, you don't have to "attach" everything to the
class to perform string manipulation, that was counter-argument to Joe.

That's all about design, not about running AWK scripts. So YOU could just
ignore it, if you're not interested in topic.

>
> 	What you have to do, is to apply _generic_ algorithm
> "transform" (working on
> 	all container types!) and use scalar function toupper( char ).
> 	Beutiful. Natural. Clever. And string is still an object.
>
> I have The Talking Moose on my MacOS X box.  Only a few minutes
> ago it popped
> up and said 'for every problem there is a solution which is
> simple, neat, and
> wrong'.
Even if I'm working with ASCII strings?
Have you asked me which strings I'm working with?
No? :) So calm down, please.