<div dir="ltr"><div><div><div>I'm using the Altitude web framework. It is based on Xtreams. I've tied myself into knots and now I have had an epiphany about what the problem is. I don't think I have a working model in my head about what Xtreams is doing or why. I'm going to say a few things here for other people hopefully to have a comment on. <br></div><br></div>My conception of Streams comes from Ch. 10 of "Squeak By Example". This is a very friendly chapter (Thank you Stephane Ducasse), because the examples are short, complete and fit into a Workspace.<br><br></div><div>There are some examples on the Xtreams Google Code page that do fit into a Workspace, but I don't think they help understanding Xtreams, really. There is a bigger picture solution that Xtreams addresses. I can see where it's pointing, I just cannot see how to use it yet. <br><br></div><div>The problem is I keep wanting to see a whole stream at once, to put it into a Workspace. Xtreams does not let you see a whole stream coming over a socket at once. Ever. It's maddening. I want to see what I'm dealing with and then deal with it. All I see are classes piled on top of each other. <br><br></div><div>And then I remembered a conversation I had at an event where someone said," Xtreams are just like the infinite streams described in 'The Structure And Interpretation Of Computer Programs', isn't that cool. You can process an infinite stream."<br><br></div><div>Yes, I nodded. It sure is cool. I made a mental note to look up streams in SICP at a future date. <br><br>This is that date. And the SICP has some fascinating things to say about streams. From section 3.5: <br><br></div><div>"Stream processing lets us model systems that have state without ever using assignment or mutable data. This has important implications, both theoretical and practical, because we can build models that avoid drawbacks inherent in introducing assignment. On the other hand, the stream framework raises difficulties of its own, and the question of which modelling technique leads to more modular and easily maintained systems remains open." <br><br></div><div>"Unfortunately, if we represent sequences as lists, this elegance is bought at the price of sever inefficiency with respect to both time and space required by our computations. When we represent manipulations on sequences as transformations of lists, our programs must construct and copy data structures (which may be huge) at every step of the process." <br><br></div><div>Our current streams implementation is inefficient because it copies everything whole, which consumes masses of unnecessary memory. With Xtreams we can manage an infinitely long stream, saving resources. But it leads to the problem I've been complaining about which is I cannot see the stream I'm working on. That is something I'm going to have to adapt to. It sounds worth the effort. But as the first passage makes clear, it's modelling the data in a different, dare I say non-object oriented way (functional?). <br><br></div><div>Why do we want Xtreams? It saves resources and allows us to process infinitely. In comparison, our Streams classes are crude and inefficient. What price do we have to pay? We need to mentally conceptualize streams in a different -- perhaps, extremely different -- way. <br><br></div><div>I do not have a mental model for what Xtreams is doing yet. How do other people conceptualize using Xtreams in contrast to the existing Streams implementation? <br></div><div><br></div><div>Chris <br></div><div><br><br></div><div> <div class="" title="Page 231"><div class="">
<p><span style="font-size:10pt;font-family:"LMMathSymbols10";font-style:italic"><br></span></p><p><span style="font-size:8pt;font-family:"NimbusSanL""></span><span style="font-size:10pt;font-family:"LMMathSymbols10";font-style:italic"></span><span style="font-size:8pt;font-family:"NimbusSanL""></span><span style="font-size:10pt;font-family:"LMMathSymbols10";font-style:italic"></span><span style="font-size:8pt;font-family:"NimbusSanL"">
</span></p>
</div>
</div>
<br></div></div>