<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">Well this is where it gets bizarre to me.  Because, despite threading, the CPU still has to dispatch all processes and handle the data passing, ultimately.</span><div>

<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Yeah. It works automagically, though, really nicely. It means I don't need to mess around with a huge spaghetti of locks and mutexes and semaphores when i want to use multiple cores. Although the CPU has to handle all the processes and data passing, the programmer (almost) doesn't have to. That's a pretty big gain.</font></div>

<div><font face="arial, sans-serif"><br></font><div><span style="font-family:arial,sans-serif;font-size:13px">> Well, I argue that in the world of programming language evolution, all of these, except for the last, are premature optimizations.</span></div>

<div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I dunno, lots of people like event loops, not just the scala actors people: Go's goroutines, python's greenlets, ruby fibers, etc. are all doing this. They provide nice correctness (no pre-emption causing race conditions) and performance (OS threads are heavy!) characteristics. Looking at the "message passing" systems I know about:</span></div>

</div></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">- Erlang processes</span><span style="font-family:arial,sans-serif;font-size:13px"><br>

</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">- Go goroutines</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">- Scala actors</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">- Obj-C objects</span></div>

<div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">3 out of 4 are basically using it for concurrency, for isolating mutable state and providing the multi-thread-serializable-calling behavior you called "bizarre". This is just to back up my claim that the things Scala-actors (and the other message passing systems above) give you w.r.t. concurrency is actually <i>really nice</i>, and even if you don't see the benefits, they're there and people love them.</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">How can you use a list comprehension unless you know the length or depth of each sub-list?</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">The most common cases are non-recursive data structures, so I already know their depth, the less common case is recursive data structures, and I recurse on them; people do it all the time. I mean you could encapsulate the recursion in a method which calls itself on its children, or you could ask for its children in your function and recurse on them yourself. Neither is really better or worse, just different approaches with different tradeoffs.</font></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">Where that where the ClassName and the Class.__doc__ should get you half the way there.  There necessary component would be a universal/abstract data type.  I propose a FractalGraph which can handle and scale any level of complexity. As long as we have a universal data type, the class hierarchy that emerges will be simple and general to handle, rather than dealing with personal taxonomies.</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Isn't the idea of an "object" with "methods" and "fields" basically that universal data type? How is it yours will scale to any level of complexity and be simple and general to handle but the "object" universal data type doesn't?</span></div>

<div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34)">> No.  While you're technically correct as to the issue of isomorphism.  In practice, the usage you propose does not help whatsoever.  "(mgs, a, b)" is too complex.  Firstly, in the message-passing scheme I'm proposing, you never pass in more than one piece of data, unless it's a very structured, perhaps (a single XML-like tree?).</span> </div>

<div class="im" style="font-family:arial,sans-serif;font-size:13px"><font color="#000000"><br></font></div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><font color="#000000">Is the proposal basically to use shorter methods with fewer parameters? I mean, a list of arguments (which could be objects and contain other objects inside) sounds exactly like an XML-like tree to me.</font></div>

<div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px">

<font color="#000000">Here's an interesting question: Is there any existing language/system out there, that's built in the manner you describe (message passing etc.), which you can point at and say "see, they do it this way and it works much better"? That would help immensely in understanding what benefits you're envisioning, since I (and others?) apparently don't see them</font></div>

<div class="im" style="font-family:arial,sans-serif;font-size:13px"><font color="#000000"><br></font></div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px">

<br></div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 6:22 PM, Mark Janssen <span dir="ltr"><<a href="mailto:dreamingforward@gmail.com" target="_blank">dreamingforward@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">On Thu, Mar 21, 2013 at 11:08 AM, Haoyi Li <span dir="ltr"><<a href="mailto:haoyi.sg@gmail.com" target="_blank">haoyi.sg@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34);font-family:arial;font-size:small">There are basically two discussions happening here: ADTs (small objects with public contents) vs Encapsulation, and method calls vs message sends. A few responses:</span><br>




</div><div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div></div></blockquote></div><div>Thank you.  You've boiled the discussion down to the two main elements.  Abstract data type's (which I was calling "prototypes")  vs. Encapsulation is the important distinction.  It's not an easy distinction to see from the words alone.  The former, I'll say, is built from the ground (the bits) upwards, while the latter, while the latter from the top (the application-layer), downwards.  But, I wouldn't say that for ADTs that public contents were the important part.  In fact, I'd argue the opposite. </div>

<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-family:arial,sans-serif;font-size:13px"></div><div style="font-family:arial,sans-serif;font-size:13px">


>> or ensuring messages are handled serially per-object,<br><br>

</div><span style="font-family:arial,sans-serif;font-size:13px">>This happens in either paradigm.</span><br><div class="gmail_extra"><br></div></div><div class="gmail_extra">I mean that messages sent <i>from multiple threads </i>are handled serially.</div>


</div></blockquote><div><br></div></div><div>Well this is where it gets bizarre to me.  Because, despite threading, the CPU still has to dispatch all processes and handle the data passing, ultimately.</div><div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"> If your entire program is single threaded (as many python programs are) or has a GIL which prevents multiple concurrent method calls, then i guess it isn't a big deal. But in a language that does have pre-emptive multithreading, this basically gives you a non-blocking, guaranteed (because there's no other way to interact with the object other than sending messages) "lock" around each object. Each object basically gets:</div>




<div class="gmail_extra"><br></div><div class="gmail_extra">- its own single-threaded event loop to run its methods</div><div class="gmail_extra">- without the performance hit of creating lots and lots of threads</div><div class="gmail_extra">




- without the overhead of running multiple processes and IPC betweeen the one-thread-per-process event loops (twisted, node.js, etc.) when you want to utilize multiple cores</div><div class="gmail_extra">- with minimal overhead over standard method calls (both syntactic and performance)</div>




<div class="gmail_extra">- for zero effort on the part of the programmer</div></div></blockquote><div><br></div></div><div>Well, I argue that in the world of programming language evolution, all of these, except for the last, are premature optimizations.</div>

<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div><span style="font-family:arial,sans-serif;font-size:13px">>Yes, and here is where something significant I think will happen.</span><br style="font-family:arial,sans-serif;font-size:13px">




<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">Complicated data structures just simply don't get re-used.  Python</span><br style="font-family:arial,sans-serif;font-size:13px">




<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">allows lists within lists within lists, but any program that uses that</span><br style="font-family:arial,sans-serif;font-size:13px">




</div><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">outside of n x n matrices won't ever get re-used ever.  Because there</span><div>


<span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">i</span><span style="font-family:arial,sans-serif;font-size:13px">s no unified data model.</span></div>


</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I disagree completely. Coming from Java, where every list-within-list has its own special class to represent it, my experience is that is a terrible idea:</div>




<div class="gmail_extra"> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">


- Want to convert from one list-within-list to another list-within-list? Use a list comprehension and be done with it. Want to convert a special InsnList to a special ParameterList? Much more annoying.</div></div></blockquote>


<div><br></div></div><div>How can you use a list comprehension unless you know the length or depth of each sub-list?</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra">It's not like encapsulating the whole thing makes the data struture any less complicated: it just makes it more annoying to do things with, because now I have to learn <i>your</i> way of doing things rather than the standard python-list way of doing things.</div>


</div></blockquote><div><br></div></div><div>Where that where the ClassName and the Class.__doc__ should get you half the way there.  There necessary component would be a universal/abstract data type.  I propose a FractalGraph which can handle and scale any level of complexity. As long as we have a universal data type, the class hierarchy that emerges will be simple and general to handle, rather than dealing with personal taxonomies.</div>

<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">In the end, message sends and method calls are basically isomorphic, so much so that in Scala you can <a href="http://doc.akka.io/docs/akka/2.1.0/scala/typed-actors.html" target="_blank">transparently convert method calls to message sends under the hood</a> if you prefer that syntax! Unless there's some significant advantage of doing it, it seems to me that the improvement would basically be forcing people to run a regex on their code to convert obj.method(a, b) to obj << (msg, a, b), and then life goes on exactly as it did before.</div>


</div></blockquote><div><br></div></div><div>No.  While you're technically correct as to the issue of isomorphism.  In practice, the usage you propose does not help whatsoever.  "(mgs, a, b)" is too complex.  Firstly, in the message-passing scheme I'm proposing, you never pass in more than one piece of data, unless it's a very structured, perhaps (a single XML-like tree?).</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>mark</div></font></span></div>
</blockquote></div><br></div>