| 00:05 | <Hixie> | man, this Nick guy i so verbose |
| 00:06 | <Hixie> | i don't think i've ever seen him write a comment on a bug report that actually fits on one page of my laptop's screen |
| 00:41 | <Philip`> | Hixie: You could try rotating the screen ninety degrees, assuming it's a widescreen laptop, and then it may be more likely to fit |
| 01:11 | <Hixie> | Philip`: even then... |
| 03:45 | <Hixie> | othermaciej: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7657#c8 |
| 03:45 | <Hixie> | othermaciej: any chance the official process will be made public soon? :-) |
| 03:46 | <othermaciej> | Hixie: Sam and I have a disagreement about some details - I'll try to get it settled soon (target is next week) |
| 03:46 | <Hixie> | k |
| 04:03 | <miketaylr> | i'm pleased to see that boolean attributes work as css selectors, i.e., [list] {background:#ff0;} |
| 04:03 | <miketaylr> | (in opera/chromium) |
| 04:04 | <miketaylr> | are there any opera devs in the house? |
| 04:07 | <TabAtkins> | They're either just waking up or starting work. Give 'em a few hours. |
| 04:08 | <TabAtkins> | Or, if you wait until American morning, they're just ending work, and hang out a lot. |
| 04:08 | <miketaylr> | TabAtkins: oh yeah, i suck at time zones. |
| 04:08 | <miketaylr> | thanks |
| 04:08 | <TabAtkins> | np |
| 04:46 | <inimino> | /b 19 |
| 04:46 | <inimino> | oops |
| 12:12 | <Hixie> | ok nn |
| 13:53 | <zcorpan> | hsivonen: should i make the pseudo-attributes processing of xml-stylesheet unattached to processing instructions so that they can be invoked for any string (e.g. comment data)? |
| 13:56 | <hsivonen> | zcorpan: do you mean for reuse in other specs? |
| 13:57 | <zcorpan> | hsivonen: yeah |
| 13:57 | <hsivonen> | zcorpan: If it's easy to have that kind of generality, I guess having it doesn't hurt |
| 13:57 | <zcorpan> | it would be easy |
| 13:58 | <hsivonen> | seems like a good idea in that case |
| 14:00 | annevk2 | wonders if we're turning into framework designers :p |
| 14:12 | <hsivonen> | annevk2: if you organize a program into methods, you aren't an astronaut just yet :-) |
| 14:17 | <TabAtkins> | Man, why does my optimism about humanity's inherent honesty have to be so sorely tested even on something where honesty should be so *simple* like a technical mailing list? |
| 14:18 | <Philip`> | What makes you imagine it's a technical mailing list? |
| 14:18 | <hsivonen> | TabAtkins: which mailing list is testing your optimism about honesty? |
| 14:19 | <TabAtkins> | hsivonen, htmlwg. ;_; |
| 14:19 | <hsivonen> | TabAtkins: anything in particular that doesn't appear inherently honest? |
| 14:19 | <TabAtkins> | Philip`, it's the technology that does it, I think. |
| 14:19 | <TabAtkins> | hsivonen: Shelley's attempts to reframe your arguments. |
| 14:20 | <hsivonen> | TabAtkins: I don't think there's dishonesty involved. |
| 14:21 | <hsivonen> | It is a bit annoying though that following up on the hypothetical offered previously is countered with additional requirements that don't seem to allow hypotheticals. |
| 14:21 | <TabAtkins> | I find it difficult to imagine that she's being honest in constantly turning your arguments over and poking at what she perceives is the weakest *social* point of it, while completely ignoring the technical discussion that is the point of your arguments. |
| 14:22 | <TabAtkins> | I think it's one of the most stark examples of incompatible worldviews I've ever personally witnessed. |
| 14:23 | <hsivonen> | TabAtkins: what was the weakest social point in my argument? |
| 14:24 | <TabAtkins> | Imo, the fact that you are purposely playing dumb to force the other side to elucidate their proposals more concretely. |
| 14:25 | <TabAtkins> | Shelley then twists that into implying that you are either ignoring them for dishonest reasons, or are just too stupid to realize that they've given answers (inadequate though they may be). |
| 14:26 | <hsivonen> | I'm not purposely playing dumb. I honestly don't know if the set of characteristics of "decentralized extensibility" is a proper subset of the characteristics of Namespaces. |
| 14:26 | <hsivonen> | but every time I try to understand what's essence and what's incidental to an implementation, people don't want to answer me |
| 14:27 | <TabAtkins> | I know, that's what you're trying to force them to answer. But they think the answer is obvious, and so assume that you're being dishonest. |
| 14:28 | <hsivonen> | frankly, if there's nothing you can change about Namespaces without it stopping being "decentralized extensibility", we should remove the fancy term and just talk about Namespaces |
| 14:29 | <TabAtkins> | Ah, but that removes the ability to trap people into agreeing on principle, so they can't reject Namespaces when the full proposal is put forth. |
| 14:29 | <hsivonen> | if there's a distinct principle to agree on, I think the principle should be explicitly formulated |
| 14:31 | <TabAtkins> | I agree 100%. Which brings us around to my optimism about humanity's honesty being tested. |
| 14:50 | <TabAtkins> | Anyone know how to get a Print Preview out of Chrome? Trying to debug a media=print stylesheet in it, and it's more difficult if I have to actually print every time (even if only to a pdf). |
| 14:53 | <Philip`> | Install Safari, select 'print preview' menu option? |
| 14:53 | <Philip`> | (I assume it has one...) |
| 14:54 | <TabAtkins> | I need to reinstall safari anyway, so sure. |
| 14:54 | <gavin> | on mac it uses the built-in platform print-preview, presumably |
| 14:54 | <gavin> | does it implement its own on windows? |
| 15:11 | <othermaciej> | Safari on Mac just generates a PDF for Print Preview - dunno what it does on Windows |
| 15:14 | <TabAtkins> | othermaciej: What would be the best way to complain about Webkit's rendering of broken images with alt-text? |
| 15:15 | <TabAtkins> | (The bug I was addressing wasn't about print stylesheets at all, but rather about the print button on the page, which doesn't currently have an image. I was relying on Firefox's treatment, where it's literally indistinguishable from just having the alt-text there instead.) |
| 15:15 | <TabAtkins> | (For small images, though, the "broken image" icon completely overlays the text.) |
| 15:16 | <TabAtkins> | (In webkit) |
| 15:16 | Philip` | suggests fixing the image so it's not broken |
| 15:16 | <TabAtkins> | Part of the reason I *add* alt-text, though, is so I can rely on the page still being usable when images *do* break for whatever reason. |
| 15:17 | <TabAtkins> | In this case I was just waiting for the actual image, so I slid in an <img> tag without a @src for now. |
| 15:17 | <Rik|work> | TabAtkins: https://bugs.webkit.org/show_bug.cgi?id=11200 and https://bugs.webkit.org/show_bug.cgi?id=5566 |
| 15:17 | <othermaciej> | TabAtkins: bugzilla |
| 15:17 | <Rik|work> | TabAtkins: shake those oooold bugs |
| 15:17 | <othermaciej> | TabAtkins: but I suspect your complaints are known issues, so commenting in the existing bugs would be best |
| 15:32 | <TabAtkins> | Thanks, you two. |
| 15:44 | <zcorpan> | hsivonen: btw, after having looked at http://philip.html5.org/data/script-open-in-escape.txt too, i found one site (www.jeuxactu.com) with 3 pages that breaks with proposal #3 |
| 15:45 | <zcorpan> | hsivonen: so it is on the order of 10 pages out of 425000 that break with proposal #3 |
| 15:47 | <zcorpan> | hsivonen: where there around 600-700 out of 425000 that break with what's in the spec now, afaict |
| 15:48 | <Philip`> | How many break with what browsers currently implement? |
| 15:49 | <zcorpan> | Philip`: 0 for the purposes of the numbers above |
| 15:51 | <zcorpan> | there might well be pages that do something like <script><!-- foo() </script> <script><!-- bar() //--></script> and expect both foo() and bar() to run |
| 15:51 | <zcorpan> | which they would with proposal #3 but don't in current browsers |
| 15:51 | <zcorpan> | i haven't looked for such pages |
| 15:53 | <zcorpan> | (or there might be pages with that pattern but expect none of them to run) |
| 15:56 | <zcorpan> | sorry, 600-1300 out of 425000 |
| 15:56 | <zcorpan> | since i don't know what the overlap is between the two sets of data |
| 16:02 | <zcorpan> | hmm, if i look at http://www.marchander.com/catalog-9500-gallery.html it has commented out the script element, so it is not relevant |
| 16:03 | <zcorpan> | so the breakage could be less than 600 |
| 16:03 | <annevk2> | the win being no reparsing? |
| 16:04 | <zcorpan> | yes |
| 16:04 | <zcorpan> | no reparsing means better performance, too |
| 16:04 | <zcorpan> | since we don't need to wait for the whole page to load before deciding where to close the script element |
| 16:05 | <zcorpan> | reparsing also means potentially reparsing several times |
| 16:06 | <zcorpan> | <script><!-- foo() </script> <script><!-- foo() </script> <script><!-- foo() </script> etc |
| 16:43 | <annevk2> | more anecdotal namespace fun: http://www.w3.org/mid/op.u1b23ela64w2qv@annevk-t60 |
| 16:45 | <Philip`> | div[xml|lang|="ar"] |
| 16:45 | <Philip`> | I like how the excellent unambiguous syntax makes it really easy to read |
| 17:01 | <zcorpan> | div:lang(ar) |
| 17:02 | <annevk2> | they're not the same |
| 17:02 | <annevk2> | people should not use a Selector such as [xml|lang] in general |
| 17:24 | <gsnedders> | Hixie: yt? |
| 17:26 | <jgraham> | gsnedders: He went to bed not very many hours ago |
| 17:27 | <TabAtkins> | What timezone is Hixie in? |
| 17:27 | <gsnedders> | TabAtkins: America/San_Franicso |
| 17:27 | <gsnedders> | jgraham: He's normally getting up around now, how am I to know? :P |
| 17:28 | <TabAtkins> | k. He acts like he lives in -12 or something. |
| 18:02 | <gsnedders> | Does IE throw when it comes across an undefined variable in JS? |
| 18:39 | <jgraham> | gsnedders: iirc then yes, for some definition of undefined |
| 18:39 | gsnedders | wonders what rev of html5lib he has installed at home, as he's getting diff. output from anolis :\ |
| 18:41 | gsnedders | notes anolis does not work with html5lib tip |
| 18:46 | jgraham | wonders if this is the namespace issue or something else |
| 18:50 | <gsnedders> | Dunno/ |
| 19:21 | <gsnedders> | Hmm, jgraham: you got any idea where I could get a couple of GB -> Euro power adapters here? |
| 19:26 | <TabAtkins> | A drug store? |
| 19:29 | <Dashiva> | gsnedders: Clas Ohlson probably |
| 19:29 | <gsnedders> | Dashiva: Ah, that sounds likely. |
| 19:34 | gsnedders | shudders at the thought of trying to find things in Clas Ohlson |
| 19:39 | <Dashiva> | That's what the catalogue and/or employees are for |
| 19:40 | TabAtkins | is having fun abusing a "functional programming is too inefficient!" weenie who thinks that functional programming is just what you get when you use recursion. |
| 19:42 | <TabAtkins> | /educating |
| 19:43 | <Philip`> | That seems backwards |
| 19:43 | <Philip`> | Recursion is what you get when you use functional programming |
| 19:43 | <TabAtkins> | Aw, Philip`, now I have to educate you too. |
| 19:43 | <Dashiva> | "I have only learned now that there is a "text/palin" option that I have never heard of" |
| 19:43 | <TabAtkins> | Recursion is a low-level operation that you should use as little as possible. |
| 19:44 | <TabAtkins> | Functional programming can probably be best defined as using maps and folds a lot. |
| 19:44 | <TabAtkins> | At least as a decent heuristic. |
| 19:44 | <Dashiva> | Functional programming can be described as the designer forgetting to include variables |
| 19:45 | <TabAtkins> | Iteration is perfectly fine in a functional language. It's just usually unnecessary, just as recursion is usually unnecessary. |
| 19:45 | <Philip`> | TabAtkins: Maps and folds are just abstractions of recursion |
| 19:45 | <TabAtkins> | Because you're almost always using much more powerful primitives. |
| 19:46 | <TabAtkins> | Philip`, um? Maps and folds *can* be thought of as recursive. They can also be thought of as iterative. The distinction is really unnecessary here. |
| 19:47 | <TabAtkins> | Because both iteration and recursion are low-level operations that are basically equivalent. You just choose one or the other based on how easy they make a particular problem. |
| 19:47 | <Philip`> | TabAtkins: The defining feature of functional languages is there's a simple core that just does (recursive) function calls and not much else, and everything else is built on top of that |
| 19:48 | <TabAtkins> | Perhaps of functional *languages*, yes. Not functional *programming*. |
| 19:48 | <Philip`> | and the underlying recursiveness is critical for issues like performance of folds |
| 19:48 | <TabAtkins> | All functional programming needs is the ability to define functions as first-class objects. |
| 19:49 | <TabAtkins> | ?_? You can get equal performance out of an iterative fold as you can with a recursive one. |
| 19:49 | <Philip`> | (and pure functional languages can't do iteration at all, because it doesn't make sense when there's no mutable state) |
| 19:50 | <Philip`> | TabAtkins: I'm talking about functional programming in terms of programming in functional programming languages, not in terms of writing stuff with functions in other languages ;-) |
| 19:50 | <TabAtkins> | I'm talking about functional programming in terms of writing Lisp code that passes functions around properly. I rarely iterate *or* recurse in my programs, because neither are necessary. |
| 19:51 | <TabAtkins> | And whether mapcar is implemented as a recursive function or an iterative is irrelevant to me, as long as it's performant. |
| 19:52 | <TabAtkins> | (The most natural implementation is a pretty trivial iterative one, actually, that builds a list by holding onto the tail as it constructs it.) |
| 19:52 | <Philip`> | TabAtkins: The performance issue is relevant because some folds might take O(n) stack space, due to their recursive nature |
| 19:53 | <Dashiva> | That's what kept nagging me about prolog |
| 19:54 | <Dashiva> | Sure, it works now. It works most of the time. But I can never be sure what crazy antics it will pull on me. |
| 19:54 | <TabAtkins> | Indeed, performance is important. But how it works underneath isn't. If your fold primitive is inefficient because it's implemented recursively, then you need a better compiler that can instead unfold it into an iteration. |
| 19:57 | <Philip`> | Dashiva: I expect that's partly why C (and C++ to a lesser extent) is nice for high-performance code, because you can know pretty much exactly what any line of code is going to do, and you can read it and profile it and optimise it and it makes sense |
| 19:57 | <Philip`> | whereas other languages might do all kinds of crazy black-box runtime stuff |
| 19:58 | <TabAtkins> | That's what profilers are for, and hooks that allow you to drop down the abstraction ladder when necessary. |
| 19:59 | <Philip`> | and even if other languages are theoretically more efficient (e.g. JITs can use dynamic profiling data), in practice it seems much harder to write efficient (because e.g. the JIT will magically stop working if you have too much bytecode and there's no good way to debug it and work out the problem) |
| 20:00 | <Philip`> | TabAtkins: Dropping down the abstraction ladder can be really hard |
| 20:00 | <TabAtkins> | So make sure you have a compiler that makes it unnecessary most of the time. ^_^ |
| 20:01 | <Philip`> | and working out what high-level modifications will result in desired low-level changes, several levels of abstraction away, can also be really hard |
| 20:01 | <Philip`> | TabAtkins: The ability for a compiler to make it unnecessary seems largely determined by the language |
| 20:02 | <TabAtkins> | Philip`, explain? |
| 20:02 | <Philip`> | hence C being good because it encourages compilers to have very little abstraction from the hardware |
| 20:02 | <Philip`> | and Prolog being less good because it takes a lot of effort to work out what the hardware's doing, regardless of how clever your tools are |
| 20:04 | <TabAtkins> | Okay, I see that. |
| 20:04 | <TabAtkins> | But many languages (especially multiparadigm functional languages) do make it relatively easy to do so. |
| 20:06 | <TabAtkins> | (I'm not convinced that logic programming is at all a good general paradigm, though, so my opinion of Prolog is fairly low to start with.) |
| 20:07 | Philip` | wonders what multiparadigm functional languages are |
| 20:07 | <TabAtkins> | Lisp, for one. |
| 20:07 | TabAtkins | is a Lisper, and so uses a lot of examples from it. |
| 20:07 | <Philip`> | (If it's not just syntactic sugar for lambda calculus then it doesn't sound like a functional programming language to me :-p ) |
| 20:08 | <TabAtkins> | It *can* be. Or you can do OO programming with CLOS. Or iteration with whatever the hell you want. Or aspect-oriented. Or logic programming. Whatever. |
| 20:09 | <TabAtkins> | Lisp doesn't go out of its way to be pure, shutting down useful avenues for making a program easier to write (this is basically why I haven't switched to Haskell yet). |
| 20:55 | jgraham | wonders if anyone else thought of Michael Palin rather than Sarah Palin |
| 21:12 | <Philip`> | jgraham: http://www.michaelpalinforpresident.com/ did |
| 21:43 | <jgraham> | TabAtkins: http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16 is rather suggestive of (at least one) functional language being non-trivial to optimize |
| 21:43 | <jgraham> | (although the author is trying to make quite the opposite point) |
| 21:44 | <jgraham> | However I guess C and similar is rather hard to optimize when you move from simple single thread/core to highly concurent problems |
| 21:44 | <jgraham> | (although obviously it can be done; see MPI and similar) |
| 21:47 | Philip` | saw a talk on automatic concurrency optimisation of Haskell programs |
| 21:47 | <Philip`> | and it didn't seem particularly awesome |
| 21:48 | <Philip`> | With an infinite number of cores and zero added overhead it was at most something like 50% faster on real programs |
| 21:48 | <Philip`> | which didn't really seem worth the effort |
| 21:48 | <Philip`> | (I've probably got the numbers entirely wrong) |
| 22:03 | <Dashiva> | Philip`: That might be amdahl's fault, though |
| 22:05 | <Philip`> | Dashiva: Indeed, and the result is that programmers still need to understand concurrency and data dependencies in order to optimise their code, and the language can't do it for you |
| 22:09 | <heycam> | sicking, http://dev.w3.org/2006/webapi/WebIDL/dom/ |
| 22:09 | <heycam> | that is dom core etc. with nullable annotations added (and some getters and things) |
| 22:12 | <sephr> | what codec do I put in a <source type> for MP3? I have a <source> for OGG vorbis that is audio/ogg;codecs=vorbis but I don't know what audio/mpeg;codecs= should be |
| 22:14 | <webben> | sephr: I'm thinking the answer is, it shouldn't: http://www.faqs.org/rfcs/rfc3003.html |
| 22:16 | <sephr> | webben: thanks, I thought there were differing codecs for audio/mpeg |
| 22:16 | <sephr> | (like the mp3 hd codec?) |
| 22:17 | <webben> | i dunno... there may be ... but there doesn't appear to be a codecs parameter in the media type registration |
| 22:20 | <weinig> | heycam: should [Callback=FunctionOnly] allow objects that implement Call (like a NodeList) in addition to function objects? |
| 22:20 | <heycam> | weinig, currently yes that's what webidl requires |
| 22:21 | <heycam> | it just tries to do the [[Call]] at the appropriate time, iirc |
| 22:25 | <heycam> | webben, oh sorry i'm wrong |
| 22:25 | <heycam> | it explicitly mentions Function objects |
| 22:25 | <heycam> | er, weinig ^ |
| 22:25 | weinig | nods |
| 22:25 | <heycam> | opinions welcome on what makes sense |
| 22:26 | <weinig> | I think we allow passing objects that implement Call in most cases |
| 22:26 | <jgraham> | heycam: Is this somthing that the ES people are likely to want changed? |
| 22:27 | <jgraham> | Since iirc ES5 says that only functions implement [[Call]] |
| 22:27 | <heycam> | jgraham, that's a good point, i'll bring it up |
| 22:28 | <weinig> | jgraham: really? Wouldn't the host object exception get around that? |
| 22:28 | <jgraham> | weinig: The ES people don't like the host object exception |
| 22:28 | <heycam> | weinig, sounds like the host object exception is something the ES folks don't want to be invoked |
| 22:28 | <heycam> | right |
| 22:28 | <weinig> | I see |
| 22:29 | <jgraham> | (They would like WebIDL APIs to be impementable in ECMAScript) |
| 22:29 | <jgraham> | *implementable |
| 22:31 | <weinig> | jgraham: ok, what is the use case for that |
| 22:32 | <jgraham> | weinig: I'm not really sure. There was a lot of discussion and I didn't take all of it in |
| 22:32 | weinig | nods |
| 22:32 | <jgraham> | One suggestion was implementing secure mock-DOM objects in ECMAScript, but I think that was shown to be impractical |
| 22:33 | <webben> | Do you recall where that was shown? |
| 22:33 | <jgraham> | weinig: It was in a post from othermaciej_ |
| 22:34 | <webben> | on public-html? |
| 22:34 | <jgraham> | On the es-discuss / webapps/ public-html lists |
| 22:34 | <webben> | too ... many ... lists ;) |
| 22:34 | weinig | saw that cross-posting awesomeness |
| 22:35 | weinig | will ask maciej on the way to coffee |
| 22:35 | <jgraham> | webben: Basically he pointed out that you would end up needing to reimplement a substantial fraction of the browser |
| 22:36 | <jgraham> | http://lists.w3.org/Archives/Public/public-html/2009Sep/1060.html |
| 22:36 | <webben> | ta |
| 22:36 | <webben> | it's worth noting that people are in practice trying to build DOM cages like that |
| 22:36 | <webben> | e.g. Caja |
| 22:54 | <TabAtkins> | jgraham: That link doesn't show a failure mode of Haskell as a functional language, but rather a failure mode from it being a *lazy* language. |
| 22:55 | <jgraham> | TabAtkins: Fair enough |
| 22:55 | jgraham | -> sleep |
| 22:55 | <TabAtkins> | jgraham is also a lazy language. |
| 22:55 | <TabAtkins> | Always sleeping... |
| 23:11 | <TabAtkins> | Also, jgraham: http://donsbot.wordpress.com/2008/06/ |
| 23:11 | <TabAtkins> | Same author, a month later, explaining how the issue *can* be optimized away by the compiler, but GHC's current compiler is biased in a particular way that makes it difficult. |
| 23:12 | <TabAtkins> | He then pulls out a library that augments the compiler (easy to do in GHC) that fixes the bias and optimizes it properly, while using very high-level concepts the whole time. |
| 23:33 | <Philip`> | TabAtkins: Libraries that augment GHC compiler optimisations are very high-level concepts? |
| 23:33 | <TabAtkins> | Philip`, huh? No, the library makes the compiler smarter. |
| 23:33 | <TabAtkins> | Anything to do with compilers is by necessity probably not high-level. |
| 23:34 | <TabAtkins> | The point, though, is that then he can continue using proper high-level primitives in his code, secure in the knowledge that the compiler is smart enough to optimize it properly. |
| 23:38 | <Dashiva> | TabAtkins: He wasn't secure before, and he isn't secure now. It's just a matter of time before he hits the next compiler weirdness. |
| 23:38 | <Philip`> | TabAtkins: He can only be secure in that knowledge because he's looked at compiler details and disassembly output to work out that the compiler will be smart enough in this particular case |
| 23:41 | <TabAtkins> | Dashiva, Philip`, well duh. There will always be places where the compiler fails. What was shown is that you *can* achieve that super-tight assembly in pure Haskell, which means the rest of your code (which is *not* performance-critical) can also be in Haskell. The person writing pure C has to do the entire thing in C, which is a punishment all by itself. |
| 23:42 | <TabAtkins> | And those compiler-failures are pretty much only relevant on tight inner loops, which you can find via profiling and spend the effort necessary to rewrite into a more efficient form. |
| 23:43 | <TabAtkins> | As opposed to writing in a low-level language, where you have to deal with that sort of thing *all the time*, because you simply don't *have* higher-level primitives to work with. |
| 23:44 | <Philip`> | At least the person writing C did the whole inner loop in a single line of pretty straightforward code, and got performance equivalent to a whole series of blog posts on writing the same thing in Haskell :-p |
| 23:44 | <Dashiva> | And it's amazing how something as simple as summing a list becomes a degenerate case :) |
| 23:45 | <TabAtkins> | Dashiva: Summing a list of 1e9 doubles is a degenerate case in *any* language. |
| 23:46 | <TabAtkins> | Philip`, the trivial transformation for Haskell (done in the first post linked by jgraham) is basically equivalent to the C code. |
| 23:47 | <TabAtkins> | Except that it still gets to use the wonderful abstraction of a list of 1e9 doubles elsewhere, while C can *never* do so - it has to manually implement laziness at the point of necessity. |
| 23:48 | Philip` | remembers reading a vaguely interesting thing about a game that was developed in a custom dialect of Lisp, including a whole sub-language for writing PS2 assembly code for performance-critical bits |
| 23:49 | <TabAtkins> | That'd be one of the Crash Bandicoot games. |
| 23:49 | <TabAtkins> | One of the things it did was optimize the placement of resources on the disk, allowing for data-streaming at a level that would have been impossible by hand. |
| 23:49 | <TabAtkins> | It was in GamaSutra originally. |
| 23:51 | <TabAtkins> | http://c2.com/cgi/wiki?LispInJakAndDaxter |
| 23:51 | <Philip`> | (But then they got bought by EA and had to standardise on C++) |
| 23:52 | <daedb> | Sony owns Naughty Dog |
| 23:52 | <Philip`> | Oh, okay, I guessed wrong :-) |
| 23:53 | Philip` | notes that he can count the number of times he's wished for a list of 1e9 doubles on the fingers of one elbow |
| 23:55 | <TabAtkins> | Philip`, so you won't have to worry about the compiler failing when you use a naive strategy in Haskell, will you? |
| 23:56 | <TabAtkins> | And yeah, part of the problem with ND was they overevolved their dialect, so that when enough engineers left they no longer had the knowledge necessary to maintain it. |