Re: compile-time taint checking and the halting problem
David L. Nicol writes: : Steve Fink wrote (and I edited slightly): : : groan I can't figure out why so many people misinterpret my RFC12 : as requiring a solution to the halting problem. : : a large class of incompletely expressed : suggestions appear to get grouped into : : "This requires solving the halting problem!" : : without providing further explanation. Well, in my case, I wasn't actually meaning it strictly. Sorry for the imprecision--it's hard to squeeze everything into a talk. To me the saying is just shorthand for "potentially sufficiently computationally expensive that I don't want to worry about it for the default case". In other words, I was lumping polynomial in with exponential, and RFC12 feels polynomial to me. And it's not that I'm against the availability of polynomial algorithms in the parser, or the use of polynomial algorithms in general--I just think the default compile-and-run parser should avoid them. I'm not even sure that O(n * log(n)) is practical in the parser unless it's something essential. Warnings don't fall into the essential category, in my estimation. On the other hand, if, after we cover the essentials, the warning turns out to be O(n) in additional cost, we could certainly look at it again. But if that's the case, it will be easy to add without having designed it in first, especially if we've designed in the proper hooks for the optimizers. Note that I'm discussing RFC12 here. Taint checking at compile time provides a different set of issues. Larry
Re: compile-time taint checking and the halting problem
At 09:44 AM 10/23/00 -0700, Larry Wall wrote: David L. Nicol writes: : Steve Fink wrote (and I edited slightly): : : groan I can't figure out why so many people misinterpret my RFC12 : as requiring a solution to the halting problem. : : a large class of incompletely expressed : suggestions appear to get grouped into : : "This requires solving the halting problem!" : : without providing further explanation. Well, in my case, I wasn't actually meaning it strictly. Sorry for the imprecision--it's hard to squeeze everything into a talk. To me the saying is just shorthand for "potentially sufficiently computationally expensive that I don't want to worry about it for the default case". In other words, I was lumping polynomial in with exponential, and RFC12 feels polynomial to me. And it's not that I'm against the availability of polynomial algorithms in the parser, or the use of polynomial algorithms in general--I just think the default compile-and-run parser should avoid them. I'm really hoping to make allowances for a variety of optional optimizations. We can save the nastier things (and with perl's active data, a lot of stuff could reasonably be classed as difficult--good optimization's going to need fairly complex flow analysis, I think) for explicit requests, possibly with different default optimization levels for parse-and-go perl and compile-to-bytecode perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: compile-time taint checking and the halting problem
Larry Wall wrote: David L. Nicol writes: : Steve Fink wrote (and I edited slightly): : : groan I can't figure out why so many people misinterpret my RFC12 : as requiring a solution to the halting problem. : : a large class of incompletely expressed : suggestions appear to get grouped into : : "This requires solving the halting problem!" : : without providing further explanation. Well, in my case, I wasn't actually meaning it strictly. Sorry for the imprecision--it's hard to squeeze everything into a talk. To me the saying is just shorthand for "potentially sufficiently computationally expensive that I don't want to worry about it for the default case". In other words, I was lumping polynomial in with exponential, and RFC12 feels polynomial to me. And it's not that I'm against the availability Um (rereading it again) er... (and yet again)... so you're saying you know how to solve the halting problem in exponential time? Cool! Hang on a sec -- I'm going to head over to the other side of this Moebius strip and shoot my grandpa. Perhaps you might want to find another shorthand for "takes a long time"? ;-) Solving the halting problem is not computationally expensive. No program that does it takes longer than 42 femtoseconds per nybble of compiler input (43 if it needs to translate from pig latin). of polynomial algorithms in the parser, or the use of polynomial algorithms in general--I just think the default compile-and-run parser should avoid them. I'm not even sure that O(n * log(n)) is practical in the parser unless it's something essential. Warnings don't fall into the essential category, in my estimation. On the other hand, if, after we cover the essentials, the warning turns out to be O(n) in additional cost, we could certainly look at it again. Ah, yes. I understand the objection then, and agree. I'm not so sure about ignoring everything that's not default, though. gcc would be a much worse tool without the optional -Wall and -g flags. But certainly that's past the point where language design ends and environment begins. I'm not sure that measuring the hit in O() notation is meaningful here, either. If it takes nlog(n) time, that's a good hint that it'll slow things down too much to have it on by default. But that n is slippery -- it's a lot smaller than the fundamental n of the number of bytes the tokenizer sees. Even having O(n) additional cost doesn't say much -- if it runs twice as slowly, we still definitely don't want it. If it adds 10%, then maybe. Big-O notation is a good description of how a problem grows, but a bad description of user annoyance. But if that's the case, it will be easy to add without having designed it in first, especially if we've designed in the proper hooks for the optimizers. Yes, RFC12 changes nothing fundamental in the language, so can be ignored pretty much completely for now. But I wanted to point it out as an advantage of not going too crazy with perl's semantics: if a computer can read your code and extract some meaning without having to actually run it, then that computer will be able to catch more of your mistakes earlier. The usual perl trend is to make things as easy as possible for the programmer and screw the computer, which is a large part of why I like perl so much. But there's something to be said for making things easier for the computer, especially since something that's hard for the computer is often the same thing that screws the users when they start programming big stuff.
My reading list
(my apologies for the delay in sending this) Software Project Survival Guide by Steve McConnell Published by Microsoft Press. Takes you step by step through the project, and each chapter ends with a checklist of things that should be happening and things that shouldn't. Quite detailed, and with good concrete suggestions for things like team structure and code control. Effective Project Management (2ed) by Wysocki, Beck Jr, and Crane Published by Wiley Not specifically software projects, and big on the diagrams and paperwork methodology. Some useful information on how corporate structure and project team design can work together or conflict. Good information on what should be in the paperwork, so long as you can stomach the corporate bullshit. Debugging the Development Process by Steve Maguire Published by Microsoft Press Really good book with war stories from Microsoft about taking on failing projects and fixing them. Maguire seems to really know his stuff, and his advocacy of as few meetings as possible got him off on the right foot with me. Dynamics of Software Development by Jim McCarthy Published by Microsoft Press I read this in a 2 hour bus ride home from the airport, it's that skinny. But it's still quite interesting. He smacks a little of shallow pop psychology in his emphasis on people and what keeps people happy, but there is still good information in here. The Deadline: A Novel About Project Management by Tom Demarco Published by Dorset House This is a funny book in parts, entertaining, and yet informative. At points I felt like he was tending a little too much towards a Utopian view of things (monitoring progress is good, but I'd like to talk to people using the automated tools he describes before I buy it wholesale). Nonetheless, lots of good ideas and strong fundamental concepts can be learned painlessly from this book. And it's the only book on this list that uses the word "herpes". Nat
Re: My reading list
At 12:49 AM 10/24/00 +0100, Simon Cozens wrote: On Mon, Oct 23, 2000 at 04:11:34PM -0600, Nathan Torkington wrote: I'd just like to stoke the latent paranoia. Latent? What, there's some that *hasn't* come out yet? Damn, I bet it's too late to be afraid... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: My reading list
On Tue, 24 Oct 2000, Simon Cozens wrote: On Mon, Oct 23, 2000 at 04:11:34PM -0600, Nathan Torkington wrote: I'd just like to stoke the latent paranoia. :-) For those who haven't read them the Steve Maguire books are really really good. Hallo, no matter what you think of the software they shrinkwrap and sell they must (as a huge software company) have thought quite a bit about how to get it there. - ask Published by Microsoft Press Published by Microsoft Press Published by Microsoft Press Published by Wiley Published by Dorset House -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
