Post #118,648
9/23/03 10:19:45 PM
|
Designers should ALWAYS look for pushback
As noted in [link|http://www.cato.org/pubs/pas/pa-335es.html|http://www.cato.org/...pas/pa-335es.html], people's actions are already in a dynamic equilibrium with their goals. Therefore any change you make to make it easier for those people to act in accord with your goals is likely to generate pushback as people adjust to try to meet the old set of goals.
The result is that technologies which attempt behaviour modification have a strong tendancy to generate compensating behaviours that undo what the technology intended to happen, and the benefit/loss from the technology shows up in unpredicted ways.
Tools like checked exceptions that make it easier for people to achieve a level of proof that they have accounted for all possibilities are very useful for the minority of developers who were trying to achieve that kind of goal, and who can now do so with much less work. However the attempted enforcement generates pushback from many other developers who just set out to circumvent the inconveniences caused.
Similar comments could be made about security procedures, safety technologies, and many other intersections between technology and actual human beings.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,654
9/23/03 10:35:08 PM
|
OT: I didn't picture you reading Cato stuff. :-)
Another excellent post. Carry on.
Cheers,
Scott.
|
Post #118,655
9/23/03 10:38:52 PM
|
I don't generally
I got there from [link|http://www.cl.cam.ac.uk/users/rja14/econsec.html|http://www.cl.cam.ac...ja14/econsec.html].
Are you saying that I should look for other worthwhile Cato stuff? I'll put the idea on my list. (Currently I am borrowing books from co-workers so that I can get some idea where they are coming from for their job roles.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,657
9/23/03 10:54:19 PM
|
I can't offer an opinion.
Like you, I've ended up there a few times after doing searches for particular information. I haven't read enough of their stuff to recommend it (or not).
[link|http://www.cato.org/about/about.html|About Cato] lists some things I can agree with, but it's pretty easy to write a moving policy statement that many will be enthusiastic about. It's how those policy statements are put into practice in the real world that matters though, IMO.
The list of people on the [link|http://www.cato.org/people/directors.html|board of directors] includes John Malone of Liberty Media (he may have a lot to do with the dreck on TV these days) and the president of "U.S. Term Limits". They don't give me a warm feeling, but perhaps they're just hands-off directors.
I haven't found a political or philosophical group that I can strongly identify with. I've got a bit of a libertarian outlook, but am not a hard-core Libertarian. I haven't voted for the winner in any presidential election since 1980. :-/
Cheers,
Scott.
|
Post #119,139
9/26/03 8:58:09 PM
|
Cato's been mucking around since the '60s at least
I have been disinterested in tracking their activities (and it was harder through the '70s - Everybody has an Ethics Clause and is Wonderful in all internal docs. Natch)
I recall that several pieces af artful dissembling in support of the Admin strategy of discrediting Viet-war protestors (with no distinction == alllumpedtogether; the simplisticism beloved of Muricans) emanated from this "think-ish tank". The specifics might come back, were I inclined to see how much old stuff is available on the web now.
I don't therefore presume that anyone who writes for them is similarly afflicted -- only that management has not, to my recollection, ever represented other than a Reactionary mindset, and a willingness to speak (however academic) bafflegab as will assist their political aims. Same old same old.
Ashton
|
Post #119,184
9/27/03 3:38:50 PM
|
Re: Cato's been mucking around since the '60s at least
Hi Ashton, Cato was founded in 1977, two years after the end of the Vietnam war.
Also, they're consistently libertarian, not reactionary. They support legalizing drugs, gay marriage, ending farm subsidies, and opposed the war in Iraq (mistakenly, I thought), the PATRIOT act, and so on.
|
Post #119,203
9/27/03 8:27:20 PM
|
Re: Cato's been mucking around since the '60s at least
I recall the mention by-name in "mid-70s" in connection with the Admin war on anti-Viet matters and presumed they were not a new creature. Now I wonder if 'Cato' was a re-use of a previous group's logo -not an- 'institute'..? So much for recollections and time-lines. If calling self 'libertarian' implicitly condones privatization of Soc Sec ... at any rate, this list, commenting on their 25 year anthology This book, published in conjunction with Cato's 25th Anniversary, is a must-have collection of the best articles published by Cato over the past 25 years. It includes such luminaries as Milton Friedman, Peter Bauer, William A. Niskanen, Julian Simon, Carolyn Weaver, George Gilder, Karl Popper, Justice Antonin Scalia, Richard Epstein, Vaclav Klaus, Alan Greenspan, Paul Craig Roberts, Charlotte Twight, Rep. Dick Armey, and P.J. O'Rourke.
These articles span a variety of important issues, including the fall of communism and apartheid, globalization, school choice, Social Security privatization, technology and the new economy, and personal freedom. They show the power of ideas to change the world around us -- especially the idea of liberty. More and more countries around the world are opting for free trade and free markets, and the Cato Institute has played an important part in popularizing those policies to a worldwide audience. This is definitely a collection to treasure by all those who love liberty. ..appears to reflect the spread: when you can find Karl Popper.. Scalia!! Dick Armey! and PJ O'Rourke [ Eat the Rich] courted by the Same Group -?- I must -continue-to- wonder, WTF DO They Mean? Ashton
|
Post #119,183
9/27/03 3:26:35 PM
|
Re: Designers should ALWAYS look for pushback
But checked exceptions don't actually let you get that level of proof! Java's exception language is too impoverished to say the sorts of exception conditions that you want to be able to say. (And the effect languages that do, are generally too complicated to be usable in practice.)
Personally, I don't think that checked exceptions are the problem: I think exceptions are the problem. Or more precisely, the semantics of exception handlers are the problem. Which handler catches an exception is something that can be known only at run-time (since it depends on the precise call chain), and as a result it's really, really hard to reason about who handles what. Exception handlers sneak dynamic scoping back into our programs through the backdoor.
I don't know how to fix that yet, though.
|
Post #119,729
10/1/03 2:11:30 PM
|
How do you do "meta" flow of control?
There is a natural conflict between the desire to create semantics for "exceptional" program flow, and the desire to keep program flow highly structured. Exceptions are a better compromise for this conflict than either returning error codes which the caller has to check and react to, or the solution of using goto for exception handling.
The problem isn't in my eyes that exceptions are reintroducing dynamic scoping - it is that they are providing something too close to a goto for some people's needs.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,731
10/1/03 2:38:21 PM
|
Another possible solution to exceptions...
...would fall along the lines of specifying a delegate or function to call in the event that an exception occurs within some scope. In Smalltalk, for example, you typically send a code block in the "Unwind" parameter that will execute in the case of a rollback.
In any case, exceptions come in many shapes and sizes. For the most part they are synchronous events that are usually handled in an asynchronous manner (at least asynchronous when compared to the context in which they are run). On a small scale, they mimic if-then-else or goto logic. On a larger scale, they can introduce havoc into the sequence of the program.
|
Post #119,846
10/2/03 1:53:57 PM
|
Not appropriate for the situation being discussed
The desire was for static verification of what exceptions would be called and how they would be handled. Dynamic runtime solutions don't address that desire.
Besides which, I am somewhat puzzled by how your proposal differs from what I am used to thinking of as the usual way you do exception handlers in a dynamic language. (Perhaps my confusion is due to the fact that I'm thinking about languages like Ruby which had Smalltalk as an inspiration.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,854
10/2/03 2:22:40 PM
|
Actually I'm mostly interested in what...
...Neel is tossing around as the alternatives for his implementation, so I'm just engaging in a little idle speculation. :-)
As far as I can tell exceptions involve two things: (1). a set of code to run when an exception occurs; and (2). a continuation point to jump to once that code is completed. I gathered from your assesment that you think these features have been reduced to a glorified goto construct (reversing the order i just gave). My point, if there was one, was that instead of being a label to which one branches to, the code to be executed can also be thought of as anonymous function which gets fired when an exception event us triggered. No comment was given on the effect in terms of continuation.
Anyhow, other than establishing whether an event is handled or whether it simply throws the exception up the continuation stack, the checked exception handling in Java doesn't give any other clues to the compiler (for static checking purposes). Might be valuable information, but it provides no information beyond the propagation.
|
Post #119,880
10/2/03 6:02:06 PM
|
What my thinking on this is...
In the original Go To Considered Harmful paper, a number of still valid uses for goto were listed. Exception handling was one of those.
AFAIK, exception systems were created to provide for an "exceptional program flow" mechanism which was still structured, attempting to eliminate a problem that goto was still used for.
So it isn't that exceptions come down to a glorified goto, it is that they are good enough at subverting the structured flow of control that they can share some of the problems that goto has.
See [link|http://c2.com/cgi/wiki?AvoidExceptionsWheneverPossible|http://c2.com/cgi/wi...sWheneverPossible] for an entry point into a similar discussion.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #119,921
10/2/03 10:34:48 PM
|
Re: Actually I'm mostly interested in what...
What I'd like is for exception handlers to be lexically scoped rather than dynamically scoped. For example, consider the pseudocode: \nfun make_foo() {\n try {\n lambda(){ raise Error; }\n } catch (Error) {\n print("Error caught in make_foo!");\n }\n}\n\nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n}\nIn a conventional exception system, running main() would result in foo() throwing an error that would be caught in main, and the message that main prints would be "Error caught in main!". This is dynamic scoping -- the exception handler chosen is the nearest enclosing handler live on the call stack. I'd like to try a lexically scoped exception system. In this version, the exception thrown in foo() would be caught by the lexically-enclosing exception handler -- that is, the one in make_foo(). So the printed message would be "Error caught in make_foo!" As it happens, a lexical discipline offers more powerful control flow than a dynamic one (you can write call/cc with it!!), but it is also easier to analyze in a modular way. But this isn't the whole story. To make such a system really useful to the programmer, you still need a type language that can express differing sets of exceptions concisely and precisely, and that's a hard problem: the two needs are at cross-purposes. But the lack of such is what makes Java's checked exceptions mostly useless.
|
Post #119,974
10/3/03 10:52:18 AM
|
Why not include the exception processing in the lambda?
Not sure I understand why the exception processing is not bundled as part of the anonymous function: \nfun make_foo() {\n lambda(){ \n try { \n raise Error; \n } catch (Error) {\n print("Error caught in make_foo!");\n }\n }\n}\nWould the catch not then be lexically scoped within the lambda function? I guess I don't understand what you are trying to. In the current languages, the exception within make_foo would only be trapped if the error were in the creation of the lambda function - not in the invocation. Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block? \nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n}\n
|
Post #120,007
10/3/03 3:21:13 PM
|
Re: Why not include the exception processing in the lambda?
The exception isn't part of the lambda, since I was trying to come up with the shortest example that illustrated the issue I was talking about. :)
Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block?
\nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n}
I'm not sure what you mean by "continuation point should be based on the point of invocation", but I do want execution to continue normally after the exception is handled (that's kind of the point of an exception, after all!). So your example should print \nError caught in make_foo!\nhere's where i end up when all is said and done?\n
|
