Zero C

[Joe Armstrong]

On Mon, 9 Aug 2004, Michael Williams wrote:

> In article <cf7akn$ncs$1@REDACTED>,
> mike@REDACTED (Michael Williams) writes:
> |> In article <BD38FDD7.F22%enewhuis@REDACTED>,
> |>  enewhuis@REDACTED (Eric Newhuis) writes:
> |> |> http://zeroc.com/
> |> |>
> |> |> Comments?
> |> |>
> |>
> |> Site is not reachable?
> |>
> |> /m
>
> I had a quick look at the Ice.
>
> If you want to program Erlang type applications in Java or C++, this might
> be a good framework to use. I.e. distributed concurrent systems.
>
> But it would help you to avoid a lot of the inherent
> problems in C++ such as pointer errors, memory leaks etc. As well as that
> as Ice threads are in no way memory protected from each other, the Erlang/OTP
> style to make distributed fault tolerant systems is not applicable.
> But if you are sourcing a lot of ready made C++ or Java software,
> Ice could well be the way to go.
>

I think not.

>
> Ice is probably what Corba would have been if it hadn't been designed by
> a comittee....
>

Yes indeed.

   The problem with Ice is that it appears to be just "a better version
of CORBA"

   << the  word "just" here is not  meant to be derogatory  - since Ice
represents a *massive* amount of work >>

   I think that both Corba and Ice (and for that matter virtually *all*
the  IDL based  systems  make  the *same*  fundamental  error) -  they
abstract  away  from  the  actual  messages  which  are  seen  on  the
communications channels  and replace these by function  calls and APIs
which essentially hide RPCs.

   Q: Why is this bad?
   A: Because it turns a simple problem into a horribly difficult problem.

  Let me give a simple example.

  Lets suppose I want to make an "FTP like service" - here is a *simple*
way to do this.

  First we specify a the protocol.

 	list            => [string()]
 	{get, string()} => {yes, bin()} | {error,NoSuchFile}

  The notation A => B means "If you send me a message A I promise to return
a B" - X | Y means X or Y.

  What is string()? (its a string silly) guess - the filename - right!
      and bin() -- the content of the file

  So here's an imaginary telnet session to my imaginary FTP server

 	telnet some_server 1244
 	Connected to jenny.sics.se.
         Escape character is '^]'.
 	list.
         ["/home/joe/abc", "/home/joe/dir/a1", ....]
 	{get, "/home/joe/dir/a1"}.
         {yes, <<23,45,12,34..   >>}

That was easy wasn't it?

   If we  *expose*the underlying protocol  (ie tell people what  it is)
then  it become  *really easy*  to  write clients/servers  in any  old
language that you feel like (even in Java :-) - but if you *hide* the
details  of the  protocol and  provide a  stub-compiler and  loads of
tools then things can quickly become a nightmare of complexity.

   The  Ice hello  world example  is needs  16 pages  of dense  text to
describe it.

   This is a server which sends  you a "hello world" message. In my way
of thinking the example needs a *one line* specification.

   ping => "Hello world"


   (You send me a ping atom, I'll sent you back a constant "Hello world" string)

   Implementing this in any language (apart from Intercal) is easy.

   << aside - In my FTP example I said

 	list => [string()]

      In UBF I would have said.

 	list => files()

      and

 	files() = [file()]
 	file() = string()

      The idea being to name types in an intuitive manner, for details
read
        http://www.sics.se/~joe/ubf/site/quick.html
>>

/cheers

Joe


> /mike
>