<div class="gmail_quote">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 class="im"><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div></div></blockquote><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><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>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> </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>Well, I argue that in the world of programming language evolution, all of these, except for the last, are premature optimizations.</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"><br></div><div class="gmail_extra"><div class="im"><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 class="im">
<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>How can you use a list comprehension unless you know the length or depth of each sub-list?</div><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>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> </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>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>
<div><br></div><div>mark</div></div>