Thanks Shriram for the answers - please see inline. <br><br><div><span class="q"><span class="gmail_quote">On 5/2/07, <b class="gmail_sendername">Shriram Krishnamurthi</b> <<a href="mailto:sk@cs.brown.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
sk@cs.brown.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Why would you expect PLT to use CPS? Virtually no modern compiler
<br>> does.</blockquote></span><div><br>It's just me being ignorant of compilers internals in general - thanks for the tip. <br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Understood. I would say that the ilities are probably neither better<br>> nor worse than you would expect, but just different. We have, in<br>> effect, run a many-year experiment using Continue, a semi-commercial
<br>> Web application for conference paper management written entirely in<br>> PLT Scheme (<a href="http://continue.cs.brown.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">continue.cs.brown.edu
</a>). Over the years we have gradually<br>> refined our understanding of its performance, and some of Jay's work
<br>> on continuation replacement strategies (not written up anywhere, but<br>> I'm sure he can say more here if he feels inclined) stems from our<br>> observations of this system (and of its sibling, Resume, which handles
<br>> the faculty job ads for Brown CS and was also used at Northeastern CCS<br>> this past year).</blockquote></span><div><br>Thanks - hopefully Jay would be feeling inclined to share ;) </div><span class="q"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Yes. For now I'm focusing on client-side computation.<br><br>> Our view of the server has evolved. Initially we thought of it as just<br>> a dumb repository of data. But then when we saw that we had built a
<br>> fairly nice API for connecting to Web services, we realized that was<br>> our way out of the "how rich a server?" conundrum. I have written<br>> this up on the Flapjax blog, where this post also takes some cracks at
<br>> the so-called "tierless" languages:<br><br>> <a href="http://flapjax.blogspot.com/2007/02/tierless-tieranny.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://flapjax.blogspot.com/2007/02/tierless-tieranny.html
</a><br><br>> By the way, until now I knew of only one other person who understood
<br>> that the so-called three-tiered architecture is actually a two-tiered<br>> *architecture*. I was pleased to see from a throw-away aside earlier<br>> in this thread that Matthias is the second such person.
</blockquote>
</span><div><br>Thanks for the link - I didn't know the term is tierless - not sure if I like the name... ;)</div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> No, it's also a research question, but not one I care about. The<br>> tierless guys are interested in this. I think this is fundamentally a<br>> confused question, though. Putting things in different places
<br>> involves introducing a new (and significant!) locus of failure; you<br>> need to worry about communication, synchronization, policies, etc. I<br>> don't think we're anywhere near being able to do such things
<br>> seamlessly. *Furthermore*, whether you run on the client or on the<br>> server has a huge impact on the kind of UI you write (imagine a<br>> word-processor that ran purely on the server, and sent every keystroke
<br>> as a synchronous communication...). So I focus on assuming that<br>> people know what they want running where and will program to that.</blockquote></span><div><br>In a way I thought this is what your research topic #3 would be, given your interest in "competing" with RoR so to speak. Perhaps we are not thinking the same thing?
<br><br>Your description of tierless is basically a higher level compiler/translator that compiles code into the multiple tiers, and RoR or any other framework all do that to various extent (I wouldn't really classify any of these as languages though... maybe you are talking about other languages instead of RoR/equivalents) - or am I missing something?
<br><br>Agreed on whether the code runs on client or server makes a big difference, and to me that's part of the challenge in spec'ing design/tradeoffs. Definitely makes no sense to build a word processor running on a server, but on the other hand, building a word processor with both client & server components (without having to write the same logic more than once) to allow for better collaboration than wiki sure does. But this is just an observation cuz you know that more than I do already ;)
<br><br>Thanks for your time, Shriram! ;)<br><br>yinso <br><br></div></div>