I'm a little late here, but TFA contains a very good suggestion that I've used: job queues. That guarantees that you don't have physics resources idling while graphics jobs are waiting to be done, and vice-versa. A perk of the jobs and job queues model is that it's simple to understand (as multithreaded models go), and there tends to be a much simpler relationship between the software design and the dependency/deadlock analysis than with other models. In general, job queues give you more rigor with less thinking.
You're completely wrong about blame. A responsible boss will treat errors and slowdowns with a heavy dose of lecturing, rambling, and war stories. Remember, whatever the shortcoming is, the cure is for the implementers to study at the knee of the manager and become more like him.
John Carmack is, among other things, a performance expert, and the most interesting thing he says in this article is this:
"The difference between theoretical performance and real-world performance on the CPU level is growing fast. On, say, a regular Xbox, you can get very large fractions of theoretical performance with not a whole lot of effort. The PlayStation 2 was always a mess with the multiple processors on there, but the new generations, with Cell or the Xbox 360, make it much, much worse. They can quote these incredibly high numbers of giga-flops or tera-flops or whatever, but in reality, when you do a straightforward development process on them, they're significantly slower than a modern high-end PC."
He's putting programmers on notice that the days of writing single threaded code for a simple virtual von Neumann machine are over. The hardware designers bent over backward for years to support that programming model, and they've given up. They've hit the wall and moved on to other things. The smart programmers (like John Carmack) are figuring out how to follow them.
Wow, I never thought of using my math skills as a social chastity belt. I find that waving my arms and yelling "booga booga!" works pretty well, but it sometimes attracts unwanted attention. Next time I'll try functional analysis instead. Thanks for the idea!
In their world "god-like software developer" is an oxymoron, because the software developers are peons too. They math whizzes are known to make comments like, "I don't know how you guys have room in your heads for trivial luxuries like XML and multiple inheritance. I don't even have room for basic stuff -- just yesterday I had to pull out one of my old textbooks to refresh myself on simulated annealing."
But they're right. Developers, including myself, have a tendency to spend time learning admin skills, while ignoring powerful stuff that would actually make us better programmers:-(
It's possible to be a good developer yet not be competent to admin one's own machine. In the most obvious case, the code you write is targeted to a different platform. Less obvious, but no less real, are the guys with physics, math, or other non-CS backgrounds who handle algorithms and performance issues on many software projects. Much of that work is platform-neutral, and you can even know a hell of a lot about your target OS (paging algorithms, scheduling algorithms, etc.) and your target physical platform (disk performance, cache sizes, etc.) without having a clue about package management or security.
When you pin your company's profits on over estimating contracts and "finishing early", all you're doing is lying to your clients and screwing them out of their money.
What's wrong with charging what the market can bear? If no one else can offer a lower estimate, then he is the best choice for the contract and the client is happy to do business with him. If I win an Ebay auction with a bid of $100, but I could have afforded to pay $150, have I stolen $50 from the seller?
If you dont have a job for more than a month, while activly submitting resumes, you arent trying hard enough or aiming low enough.
Being unemployed for months isn't necessarily a sign that you're doing something wrong. I'm a software developer, and last time I was looking, I was unemployed for a little over a year. I did everything right. I sent out resumes for every job listing I could find that I was qualified for, customized for each listing, and in my spare time I picked up a couple of Java certs. I wasn't picky. After a few months I started applying all over the country, and I took the first job I was offered, at $15k less than my previous job. Also, I must be pretty decent at what I do, because I worked my way back up to the original salary in less than eighteen months.
In the year that I was unemployed, I started to develop some weird suspicions about whether I was really any good, or just a drone. When I started the job and realized that the work was well within my capability, I was a little bit surprised. That's what being unemployed will do to you.
Thanks very much for coming to Slashdot to talk about this. If you don't mind speculating, I would love to hear an expert's anser to the following questions:
If you were in charge of permanently shutting off Manhattan to human-controlled vehicles and switching to a system of autonomous vehicles, what infrastructure would you install to make it easy for autonomous vehicles to operate*? How much easier is that task than the task of integrating a small number of autonomous vehicles into a normal American city? How far are we from the technical ability to accomplish it?
* For example, I imagine static sensors would do a much better job of identifying and tracking human foot traffic than vehicle-mounted sensors.
The article presents the history of Stanley is presented as a series of intellectual breakthroughs that I can understand, just like a lot of the pop science I read when I was a kid (and continue to read). I'm pretty sure each of these breakthroughs (such as learning from humans and assessing sensor data critically) are ideas that have been around in AI for a long time. The true story of Stanley is no doubt just as dramatic but much harder for a layperson to appreciate.
I think the first practical non-military application of autonomous cars will involve a ton of infrastructure. It won't be achieved solely by making the cars as advanced as possible, but by providing a lot of supplemental data from an array of stationary sensors (and processors) installed by a city or theme park that wants to be the first to have autonomous cars.
Eventually human drivers will be banned, and the cars will communicate and cooperate with each other (much better than human drivers!). Traffic engineers will maneuver cars manually in rare instances, and computer-controlled cars will give them a wide berth. Safety will be improved, but so will traffic efficiency. Cars will become less personal, hence smaller and more efficient; crashes will become rarer and safer, hence cars will be smaller; computers will be better drivers, so cars will run faster and closer together. We can look forward to a period of ten to thirty years in which freeways don't get any wider.
Continuing my utopian fantasy, if cars become autonomous and have less personal significance, many city dwellers will choose to use taxi services instead of owning their own cars. That means that most of the cars on the road at a given time can have a sensible capacity, rather than the maximum capacity the owner imagines that he or she might need. Per-capita energy use for personal transportation in the U.S. will drop to a fraction of the current level.
It will happen someday, but maybe not in the next hundred years, depending on how stubborn we are. It would certainly be easier and more rewarding to start with helpful, high-infrastructure environments, but the military has such a massive capacity for funding research that we will probably solve the harder problem of hostile environments first. I.e., we'll have autonomous robot sharks with frickin' laser beams on their heads long before we have Johnny Cab.
Re:Loving complexity for complexity's sake
on
Ruby Off the Rails
·
· Score: 1
Exceptions in C++ are a last ditch holy shit maneuver to save the information when the moon crashes into the data center. Exceptions in C++ are for ghastly aberrant situations
Bjarne Stroustrup (whom you seem to accept as an authority, since you cite the ARM) says, "In C++, exceptions are used to signal errors that cannot be handled locally, such as the failure to acquire a resource in a constructor." (That's a bit different from Things that aren't supposed to happen, ever.) He also acknowledges that there are cases "where it is not entirely clear what should be considered an error and what should not."
Furthermore, he is willing to consider using exceptions for non-error conditions: "Using exceptions as alternate returns can be an elegant technique for terminating search functions." However, he almost immediately follows that with, "Whenever reasonable, one should stick to the 'exception handling is error handling' view," tempered with, "Unfortunately, the real world isn't so clear cut. Program organization will (and to some extent should) reflect that."
The lesson? If you want to spout puritanical dogma, don't cite an avowed pragmatist as your only authority. Come to think of it, if you want to spout puritanical dogma, you're better off not be talking about C++ at all, since it's about as impure and accomodating as anything you can buy on the streets late at night, partly by design.
(All quotes are from TC++PL, except the first, which is from the technical FAQ on Stroustrup's web site.)
Setting authority aside, I don't think any distinction related to domain semantics or "expectedness" (much less Does not ever happen, ever-ness) is a reliable guide to what should and should not be an exception. Such distinctions lead to gunk like this (please pardon the formatting; I haven't really figured out how to post code on Slashdot yet):
File open_file(string filename, bool user_provided_filename=false): ____if(file doesn't exist): ________if(user_provided_filename): ____ ________// it's "expected" for user-provided filenames to be bad ____________return File::invalid() ________else: ____________// it's "exceptional" for non-user-provided filenames to be bad ____________throw FileNotFoundException(filename) ____....
This example is based on real code that was written by an inexperienced programmer who knew the "rules" too well for his own good. I have also heard a programmer seriously propose that we fork a mature source code module to replace exceptions with return codes for a certain class of errors, so that it could be used in a setting where the errors were "expected" rather than "exceptional." That's clearly absurd, but it's a logical consequence of allowing domain semantics to determine what should and should not be an exception.
Consistency, understandability, elegance, and performance are important; an abstract idea of what constitutes an "error" can be a helpful heuristic, but it disintegrates if pressed too hard. One of the nice things about C++ programmers is that they have fewer preconceptions than programmers in other languages, so using exceptions consistently within a module is not a stylistic mistake no matter how they're used, as long as understandability and performance aren't compromised.
I agree that Python's elimination of brackets for code blocks does reduce the number of symbols. However, I look at it the exact opposite way: their removal doesn't make the code more readable because excess has been trimmed; instead, their removal makes it less readable because useful visual cues have been taken away.
The trick with Python is to trust the indentation, which is very, very hard when you have 10+ years of experience telling you that indentation lies.
At first my mind kept looking for the curly braces in Python code. Now, when I'm editing C++ code, I'm annoyed because I realize I'm looking twice at every block: using the indentation to guide me because it's easy and I can't help myself, while subconciously (and sloppily) checking the curly braces because I know that indentation means nothing to the compiler.
Personally, I think this depends on the situation. There are some languages like Perl and C++ that can only be used to their full potential by people who put a serious amount of effort into learning them. This is a disadvantage, but there tends to be a trade-off between language complexity and design complexity: language features sometimes enable simpler designs. If you can ensure that your coders are all fluent in the target language, it's advantageous to go with the language that gives you a simpler design. In other situtations, you might accept a slightly more complex design to make it possible for a wider pool of programmers to contribute.
Wow! You and I must have minds that work in very different ways. I can do that with every language I've programmed a bunch in except Perl. That's why I gave up on it and settle on Python instead, in spite of a serious case of conciseness envy.
I'm not in IS, but I've been in the same quandary you are -- running myself ragged running a one-man show that I shouldn't have been handling by myself. The problem is that the "correction" of the problem is to replace one superhero (you) with several normal (less hardworking) people who will collectively cost several times what they pay you. The company pays more and gets the same result. You'll never be able to sell them on that. Instead, you have to promise them something they don't already get.
Incidentally, this is why you should never do anything in superhero mode -- wait until they let you do it sustainably, or you'll be stuck doing it alone forever.
It's not pointless at all. Somebody is going to have to fix the code, and it helps to see code out of sync with comments - it means something is fishy and needs to be examined closely. If I see
// get a random prime number
p = 2 * random_int() + 1;
then I immediately see a bug: the guy who wrote his code thought all odd numbers were prime. He's an idiot, but he helped me debug his code. If he carried on thinking p was prime but never documented that mistaken assumption, figuring out the bug would have been ten times harder.
I see comments EXACTLY like this:
i=i+1;/* Add one to i */
ALL THE TIME. It is incredibly annoying, and trains your eye to ignore all comments, so you miss the occasional useful one. If you don't see comments like that in real life, then you are without a doubt the luckiest programmer alive.
Wow.... I've never seen anything that clearly idiotic, and I've read the code of perhaps a dozen coworkers in my career, as well as a certain amount of open-source code. Perhaps what you see is the result of refactoring unclear code to be more clear, making the comments superfluous?
You know, you inherit code with repeated use of an expression like this:
You create a function named firstPossibleCheckupDate and use a wildcard search-and-replace to replace those expressions. You confirm that each replacement is valid, you recompile, the unit tests pass, but you accidentally leave a few comments in the code that look like this:
// first possible checkup date
date1 = firstPossibleCheckupDate(date2);
I don't think that's so bad in the big scheme of things.
it is hard to figure out what parts of what do which
... and what parts are meant to do which.
Sometimes important organizational insight never gets transferred from a programmer's mind to the code. What's missing are comments like:
// This is the proper place to check Records for consistency, as it // is the only place that ALL records pass through before being // committed. Do NOT create a way for Records to bypass this code!
This prevents maintenance programmers from accidentally adding consistency checks that don't always run, scattering duplicated consistency checks throughout the code to ensure that they always run, or splitting the control flow up so that future consistency checks *have* to be duplicated.
Because of a lack of comments like this, frequently you find that the original programmer can make a change in a few minutes by adding a few lines of code, while a maintenance programmer takes longer, uses more code, and gets it subtly wrong.
By "dynamic compiler" I mean a just-in-time compiler or any other compiler that has the opportunity to optimize code as it runs. What I had in mind is that some optimizations can't be performed unless the optimizer is able to examine code that is called from the code being optimized. A link-time optimizer would also be able to perform such optimizations, so a dynamic compiler isn't really necessary.
One interpretation of a type declaration is that it is a compile-time assertion that must be proven by the compiler. I imagine that making compile-time assertions about a function's impact on memory management would be very useful in some systems. This is a natural application for typing.
Another idea: One of the qualifiers (perhaps the default) should specify that the compiler can choose whatever type it predicts will be most efficient, of the types it can prove valid. A dynamic compiler might make very good use of that freedom.
I'm familiar with unwind-protect; it has essentially the same form as a try/finally clause in Java. It's an improvement over simple try/catch, and you only have to remember to release your resources in one place, but you still have to explicitly release your resources, which makes it different from RAII and easier to get wrong.
You can actively undermine the RAII idiom in some cases by performing dangerous operations on the resource object, but you can't simply forget to release the resource, since one line of code specifies when to acquire the resource and when to release it. unwind-protect requires two lines and allows you to leak the resource by forgetting the second line.
I think the problem is that live objects managed by the garbage collector may hold references to an object that is scheduled for immediate destruction. Then the language has to choose between aborting, leaving the object alive, or leaving the referring objects in an invalid state.
I just proposed a solution to this problem, in which safety is enforced by a scope-aware type system, in another comment:
Slashdot Mirror
I'm a little late here, but TFA contains a very good suggestion that I've used: job queues. That guarantees that you don't have physics resources idling while graphics jobs are waiting to be done, and vice-versa. A perk of the jobs and job queues model is that it's simple to understand (as multithreaded models go), and there tends to be a much simpler relationship between the software design and the dependency/deadlock analysis than with other models. In general, job queues give you more rigor with less thinking.
You're completely wrong about blame. A responsible boss will treat errors and slowdowns with a heavy dose of lecturing, rambling, and war stories. Remember, whatever the shortcoming is, the cure is for the implementers to study at the knee of the manager and become more like him.
John Carmack is, among other things, a performance expert, and the most interesting thing he says in this article is this:
"The difference between theoretical performance and real-world performance on the CPU level is growing fast. On, say, a regular Xbox, you can get very large fractions of theoretical performance with not a whole lot of effort. The PlayStation 2 was always a mess with the multiple processors on there, but the new generations, with Cell or the Xbox 360, make it much, much worse. They can quote these incredibly high numbers of giga-flops or tera-flops or whatever, but in reality, when you do a straightforward development process on them, they're significantly slower than a modern high-end PC."
He's putting programmers on notice that the days of writing single threaded code for a simple virtual von Neumann machine are over. The hardware designers bent over backward for years to support that programming model, and they've given up. They've hit the wall and moved on to other things. The smart programmers (like John Carmack) are figuring out how to follow them.
Wow, I never thought of using my math skills as a social chastity belt. I find that waving my arms and yelling "booga booga!" works pretty well, but it sometimes attracts unwanted attention. Next time I'll try functional analysis instead. Thanks for the idea!
In their world "god-like software developer" is an oxymoron, because the software developers are peons too. They math whizzes are known to make comments like, "I don't know how you guys have room in your heads for trivial luxuries like XML and multiple inheritance. I don't even have room for basic stuff -- just yesterday I had to pull out one of my old textbooks to refresh myself on simulated annealing."
:-(
But they're right. Developers, including myself, have a tendency to spend time learning admin skills, while ignoring powerful stuff that would actually make us better programmers
It's possible to be a good developer yet not be competent to admin one's own machine. In the most obvious case, the code you write is targeted to a different platform. Less obvious, but no less real, are the guys with physics, math, or other non-CS backgrounds who handle algorithms and performance issues on many software projects. Much of that work is platform-neutral, and you can even know a hell of a lot about your target OS (paging algorithms, scheduling algorithms, etc.) and your target physical platform (disk performance, cache sizes, etc.) without having a clue about package management or security.
What's wrong with charging what the market can bear? If no one else can offer a lower estimate, then he is the best choice for the contract and the client is happy to do business with him. If I win an Ebay auction with a bid of $100, but I could have afforded to pay $150, have I stolen $50 from the seller?
Being unemployed for months isn't necessarily a sign that you're doing something wrong. I'm a software developer, and last time I was looking, I was unemployed for a little over a year. I did everything right. I sent out resumes for every job listing I could find that I was qualified for, customized for each listing, and in my spare time I picked up a couple of Java certs. I wasn't picky. After a few months I started applying all over the country, and I took the first job I was offered, at $15k less than my previous job. Also, I must be pretty decent at what I do, because I worked my way back up to the original salary in less than eighteen months.
In the year that I was unemployed, I started to develop some weird suspicions about whether I was really any good, or just a drone. When I started the job and realized that the work was well within my capability, I was a little bit surprised. That's what being unemployed will do to you.
Is it just me, or was the second "article" just a marketing pitch?
Thanks very much for coming to Slashdot to talk about this. If you don't mind speculating, I would love to hear an expert's anser to the following questions:
If you were in charge of permanently shutting off Manhattan to human-controlled vehicles and switching to a system of autonomous vehicles, what infrastructure would you install to make it easy for autonomous vehicles to operate*? How much easier is that task than the task of integrating a small number of autonomous vehicles into a normal American city? How far are we from the technical ability to accomplish it?
* For example, I imagine static sensors would do a much better job of identifying and tracking human foot traffic than vehicle-mounted sensors.
The article presents the history of Stanley is presented as a series of intellectual breakthroughs that I can understand, just like a lot of the pop science I read when I was a kid (and continue to read). I'm pretty sure each of these breakthroughs (such as learning from humans and assessing sensor data critically) are ideas that have been around in AI for a long time. The true story of Stanley is no doubt just as dramatic but much harder for a layperson to appreciate.
I think the first practical non-military application of autonomous cars will involve a ton of infrastructure. It won't be achieved solely by making the cars as advanced as possible, but by providing a lot of supplemental data from an array of stationary sensors (and processors) installed by a city or theme park that wants to be the first to have autonomous cars.
Eventually human drivers will be banned, and the cars will communicate and cooperate with each other (much better than human drivers!). Traffic engineers will maneuver cars manually in rare instances, and computer-controlled cars will give them a wide berth. Safety will be improved, but so will traffic efficiency. Cars will become less personal, hence smaller and more efficient; crashes will become rarer and safer, hence cars will be smaller; computers will be better drivers, so cars will run faster and closer together. We can look forward to a period of ten to thirty years in which freeways don't get any wider.
Continuing my utopian fantasy, if cars become autonomous and have less personal significance, many city dwellers will choose to use taxi services instead of owning their own cars. That means that most of the cars on the road at a given time can have a sensible capacity, rather than the maximum capacity the owner imagines that he or she might need. Per-capita energy use for personal transportation in the U.S. will drop to a fraction of the current level.
It will happen someday, but maybe not in the next hundred years, depending on how stubborn we are. It would certainly be easier and more rewarding to start with helpful, high-infrastructure environments, but the military has such a massive capacity for funding research that we will probably solve the harder problem of hostile environments first. I.e., we'll have autonomous robot sharks with frickin' laser beams on their heads long before we have Johnny Cab.
Bjarne Stroustrup (whom you seem to accept as an authority, since you cite the ARM) says, "In C++, exceptions are used to signal errors that cannot be handled locally, such as the failure to acquire a resource in a constructor." (That's a bit different from Things that aren't supposed to happen, ever.) He also acknowledges that there are cases "where it is not entirely clear what should be considered an error and what should not."
Furthermore, he is willing to consider using exceptions for non-error conditions: "Using exceptions as alternate returns can be an elegant technique for terminating search functions." However, he almost immediately follows that with, "Whenever reasonable, one should stick to the 'exception handling is error handling' view," tempered with, "Unfortunately, the real world isn't so clear cut. Program organization will (and to some extent should) reflect that."
The lesson? If you want to spout puritanical dogma, don't cite an avowed pragmatist as your only authority. Come to think of it, if you want to spout puritanical dogma, you're better off not be talking about C++ at all, since it's about as impure and accomodating as anything you can buy on the streets late at night, partly by design.
(All quotes are from TC++PL, except the first, which is from the technical FAQ on Stroustrup's web site.)
Setting authority aside, I don't think any distinction related to domain semantics or "expectedness" (much less Does not ever happen, ever-ness) is a reliable guide to what should and should not be an exception. Such distinctions lead to gunk like this (please pardon the formatting; I haven't really figured out how to post code on Slashdot yet):
This example is based on real code that was written by an inexperienced programmer who knew the "rules" too well for his own good. I have also heard a programmer seriously propose that we fork a mature source code module to replace exceptions with return codes for a certain class of errors, so that it could be used in a setting where the errors were "expected" rather than "exceptional." That's clearly absurd, but it's a logical consequence of allowing domain semantics to determine what should and should not be an exception.Consistency, understandability, elegance, and performance are important; an abstract idea of what constitutes an "error" can be a helpful heuristic, but it disintegrates if pressed too hard. One of the nice things about C++ programmers is that they have fewer preconceptions than programmers in other languages, so using exceptions consistently within a module is not a stylistic mistake no matter how they're used, as long as understandability and performance aren't compromised.
The trick with Python is to trust the indentation, which is very, very hard when you have 10+ years of experience telling you that indentation lies.
At first my mind kept looking for the curly braces in Python code. Now, when I'm editing C++ code, I'm annoyed because I realize I'm looking twice at every block: using the indentation to guide me because it's easy and I can't help myself, while subconciously (and sloppily) checking the curly braces because I know that indentation means nothing to the compiler.
I guess the word "counterintuitive" is an oxymoron in your universe ;-)
Seriously, give it a try! I find it's a great relief when I can trust that the indentation and the program structure always match.
Personally, I think this depends on the situation. There are some languages like Perl and C++ that can only be used to their full potential by people who put a serious amount of effort into learning them. This is a disadvantage, but there tends to be a trade-off between language complexity and design complexity: language features sometimes enable simpler designs. If you can ensure that your coders are all fluent in the target language, it's advantageous to go with the language that gives you a simpler design. In other situtations, you might accept a slightly more complex design to make it possible for a wider pool of programmers to contribute.
Wow! You and I must have minds that work in very different ways. I can do that with every language I've programmed a bunch in except Perl. That's why I gave up on it and settle on Python instead, in spite of a serious case of conciseness envy.
I'm not in IS, but I've been in the same quandary you are -- running myself ragged running a one-man show that I shouldn't have been handling by myself. The problem is that the "correction" of the problem is to replace one superhero (you) with several normal (less hardworking) people who will collectively cost several times what they pay you. The company pays more and gets the same result. You'll never be able to sell them on that. Instead, you have to promise them something they don't already get.
Incidentally, this is why you should never do anything in superhero mode -- wait until they let you do it sustainably, or you'll be stuck doing it alone forever.
p = 2 * random_int() + 1;
then I immediately see a bug: the guy who wrote his code thought all odd numbers were prime. He's an idiot, but he helped me debug his code. If he carried on thinking p was prime but never documented that mistaken assumption, figuring out the bug would have been ten times harder.
i=i+1;
ALL THE TIME. It is incredibly annoying, and trains your eye to ignore all comments, so you miss the occasional useful one. If you don't see comments like that in real life, then you are without a doubt the luckiest programmer alive.
Wow.... I've never seen anything that clearly idiotic, and I've read the code of perhaps a dozen coworkers in my career, as well as a certain amount of open-source code. Perhaps what you see is the result of refactoring unclear code to be more clear, making the comments superfluous?
You know, you inherit code with repeated use of an expression like this:
date1 = nextWorkday(date2.nextWeek().nextWeek().nextWeek() .nextWeek().setDay(Date::monday()));
You create a function named firstPossibleCheckupDate and use a wildcard search-and-replace to replace those expressions. You confirm that each replacement is valid, you recompile, the unit tests pass, but you accidentally leave a few comments in the code that look like this:
date1 = firstPossibleCheckupDate(date2);
I don't think that's so bad in the big scheme of things.
Sometimes important organizational insight never gets transferred from a programmer's mind to the code. What's missing are comments like:
This prevents maintenance programmers from accidentally adding consistency checks that don't always run, scattering duplicated consistency checks throughout the code to ensure that they always run, or splitting the control flow up so that future consistency checks *have* to be duplicated.
Because of a lack of comments like this, frequently you find that the original programmer can make a change in a few minutes by adding a few lines of code, while a maintenance programmer takes longer, uses more code, and gets it subtly wrong.
By "dynamic compiler" I mean a just-in-time compiler or any other compiler that has the opportunity to optimize code as it runs. What I had in mind is that some optimizations can't be performed unless the optimizer is able to examine code that is called from the code being optimized. A link-time optimizer would also be able to perform such optimizations, so a dynamic compiler isn't really necessary.
One interpretation of a type declaration is that it is a compile-time assertion that must be proven by the compiler. I imagine that making compile-time assertions about a function's impact on memory management would be very useful in some systems. This is a natural application for typing.
Another idea: One of the qualifiers (perhaps the default) should specify that the compiler can choose whatever type it predicts will be most efficient, of the types it can prove valid. A dynamic compiler might make very good use of that freedom.
Ah, I see. A Lisp programmer is never stuck with redundancy - I should have remembered that!
I'm familiar with unwind-protect; it has essentially the same form as a try/finally clause in Java. It's an improvement over simple try/catch, and you only have to remember to release your resources in one place, but you still have to explicitly release your resources, which makes it different from RAII and easier to get wrong.
You can actively undermine the RAII idiom in some cases by performing dangerous operations on the resource object, but you can't simply forget to release the resource, since one line of code specifies when to acquire the resource and when to release it. unwind-protect requires two lines and allows you to leak the resource by forgetting the second line.
I think the problem is that live objects managed by the garbage collector may hold references to an object that is scheduled for immediate destruction. Then the language has to choose between aborting, leaving the object alive, or leaving the referring objects in an invalid state.
1 37054
I just proposed a solution to this problem, in which safety is enforced by a scope-aware type system, in another comment:
http://slashdot.org/comments.pl?sid=169616&cid=14
I don't know if any language already supports this or not.