Subject: Re: Maybe Erlang is OO after all? - msg#00211

Previous Message by Date: click to view message preview

Re: Maybe Erlang is OO after all?

Joe Armstrong wrote: I have been reliably informed that maybe Erlang *is* OO after all. Isolation is needed to implement true objects - they *must* be isolated processes are a very good approximation to true objects (in as much as two Erlang processes are fairly well isolated) [...] - Erlang *is* OO and - Erlang is *more* OO than any of the other so called OO languages [...] Put that in your pipe and smoke it! Cheers It seems to me that there is a big difference between processes and objects in that objects, or OO, don't take account of time. So Objects are discrete, whereas Processes are continuous. If you don't ever take time into account the isolation of private methods/members work very well - the object discretely changes from one state to the next and it doesn't exist between states. Which is why the old example of : /* start */ create Object { var x = 0; } Object.function(y){ set x = y; } output of Object { set result = 100/x; //but what is the value of x here? } /* end */ is seen as right by OO people: -Object doesn't exist -> step 1 : object created -> step 2 : object exists in state x=0 -> step 3 : object set to state x=y -> step 4 : output object and wrong by non-OO people -Object doesn't exist -> step 1 : object created -> step 2 : object exists in state x=0 -> step 3 : object exists in state x=y who fear one of the paths : in parallel: -> step 3 : output Object {Bang! Error : divide by 0} or sequentially: -> step 4 : object set by "someone else" to state x=0 -> step 5 : output Object {Bang! Error : divide by 0} This, ISTM, is also why in OO (admittedly Object Pascal, Java and guessing at C++) threads are so difficult to manage, as they are implicitly time-based, so the thread object can only _simulate_ being in a distinct state (either by polling or blocking) when it is actually in a different state during any time interval - and in no particular state at a given point in time. Processes, by handling the time component of state can basically emulate an object, as they can quite naturally enforce the isolation, polymorphism and the inheritance, which is why : claiming OO for Erlang is a bit like claiming functionalness for C - yes you *can* do it, but it's not practical although rather than "practical" I'd say "native". Alternatively, I'd suggest that items in a database would be more easily represented by an OO language as the states are very explicit and very distinct - due to having an enforced commit or rollback, the database items also don't exist between states. Anyway : dutifully smoked. (Or dutifully me.pipe.smoke.earlier() ;) Cheers, Kurt. ps: Never noticed before how OO has stolen a whole lot of usefully descriptive words. Try describing the time component without using the word "component", or database `items` without using the word "object".

Next Message by Date: click to view message preview

Strange mnesia behaviour

Hmm flush_downs cleans the msg queue, with alot msgs in it, it takes some time.. Can you email me the test program? /Dan Anders Nygren writes: > Hi > I have found a strange thing in mnesia. I was trying > to do some throughput measurement on a process. > > My process does the following: > 1, receive one message > 2, make one mnesia:select > 3, send one message > > My test was to send N identicat messages to my process > and measure the time it took to process all messages. > To my suprise the times grew non-linearly with N. > eprof shows that > N = 10 - > mnesia:flush_downs/0 is called 55 times > N = 100 -> mnesia:flush_downs/0 is called 5000 times > N = 4000 -> a whopping 4 million times. > > Also if I run the test twice with 50 messages I get > 2500 mnesia:flush_downs, but when I run one test with > 100 messages there are 5000. > > I the mnesia table has one record. > I am using a single node -> no distribution. > The table is type bag, disc_copy. > I am using R9C on Suse 8.2. > > Is there something wrong with mnesia or is there > something I dont understand? > > /Anders > > Yahoo! Mail - Gratis: 6 MB lagringsutrymme, spamfilter och virusscan. Se mer > på http://se.mail.yahoo.com

Previous Message by Thread: click to view message preview

Re: Maybe Erlang is OO after all?

----- Original Message ----- From: "Joachim Durchholz" <joachim.durchholz@xxxxxx> To: <erlang-questions@xxxxxxxxxx> Sent: Monday, August 25, 2003 10:22 AM Subject: Re: Maybe Erlang is OO after all? > I think this is more a problem of the way that OO is typically implemented. > C++ is particularly bad here: during construction, all calls are > "nonvirtual", i.e. you can't use virtual functions to "do the right > thing" during object initialization. Since there's a very common need > for that, you end up using two-phase object construction: first > construct the object, then initialize it. And made much worse by the workings of initialising reference and const data. (And have you ever noticed how poorly const works the iostream library? They just don't fit together at all.) > If a language > makes it easy to package out-of-band data such as error diagnostics into > results, and where it's likewise easy to disassemble that data on the > caller side, then it's not necessary to have this. In other words: > traditional programming languages are missing both tuples that can be > defined and constructed with minimal syntactic overhead, and they are > missing pattern matching on tuples. Very, very true! Other than the lack of closures (and you could only ever have a restricted version of them in a non-GC language) I find the combined absence of pattern matching and tuples the greatest lack in C++ (which is the language I work in 90% of the time, and really does have many advantages for an important if restricted set of real world programming tasks.) Thought: you can add restricted closure support to C++ using the Open C++ toolkit - I wonder if it will support pattern matching? It's other big problem is that the language needs a refactoring browser as much or more than Java or Smalltalk, but is so hard to parse that no one seems capable of writing one. - Jonathan

Next Message by Thread: click to view message preview

Problem with 64 bit FP under ARM

Hello all, I have a problem with 64 bit floating point numbers on an embedded SA1110 based machine running under Linux. A summary of the problem: (Running under Linux on x86): 1> <<1.0:64/float>>. <<63,240,0,0,0,0,0,0>> (Pretty much as expected for a little endian machine) (Running under Linux on ARM): 1> <<1.0:64/float>>. <<0,0,0,0,63,240,0,0>> (Looks a bit like little endian, only the quads are swapped) This essentially means that any code compiled with floating point constants in it will not run on the other machine. It might also mean other issues as well, but this is where I first discovered the problem. I'm not an ARM expert, so I can only assume that the correct representation for a double on ARM is with the quads swapped with respect to "normal" LE ordering. Does anyone here know if this is the case? I'm thinking it maybe could be a problem with the FP emulator? (There is no FPU on this board). In the mean time, I've included some hacks in erl_bits.c to modify erts_bs_put_float() and erts_bs_get_float() to swap the quad order when reading or writing 64 bit floats on ARM. This seems to fix the cross compilation problem. Are there any other areas that I should be looking at? Martin