Believe it or not, there are people out there who find a controlled amount of madness in their lives to be a very amusing diversion from the alternative. I am one of those people.
I think it's worth noting that the concepts of "game" and "real life" have different boundaries to different people. To me, playing a game is part of my real life. It takes up my real time and requires my real mind to work. What separates it is context. Games are "safe". Games have certain components behind them so that they happen in a social context that is generally understood by participants (and, often, outsiders), that the actions taking place aren't to be taken seriously.
In a game like Steve Jackson Games' "Killer", it's when someone pulls out a nerf dart gun. While the game does not necessarily have its own set-aside time and place in the traditional sense, the game actions themselves still happen "on game time".
So, I'd say there's a difference. The problem isn't when "game time" isn't a specific, set aside block of time. The problem is when the emotions and reactions you have in a gaming context leech out of that context. I've heard before of "Killer" players developing some serious paranioa when they didn't manage their emotions well enough. That's where the problems begin.
It is the case. I double-checked for my own sanity (though I suspected I was correct), and the moon is moving further away from Earth, though I misreported the rate- its orbit lengthens by 3.8 centimeters a year, not a foot.
What if a big enough asteroid or piece of space junk plowed into it, driving it lower into it's orbit or even into the atmosphere?
This would depend highly on the trajectory of the asteroid or meteroid prior to impact, its mass and velocity, etc. Possible results could include...
...destruction of the LEO end of the elevator, causing the Earth's rotation to whip the cable about, which I suspect would burn the ribbon up.
...smashing laterally into the LEO end of the elevator, which would, IMHO, either cause cable breakage or a shearing effect similar to what I previously described.
...impacting directly on top of the LEO end of the elevator, pushing it straight into the atmosphere at a reasonable velocity, probably sufficient to generate entry heat and burn up the end of the elevator ALA Columbia.
Then again, these are just guesses. I'm not a physicist. I'm also not an astronomer, but I seem to recall hearing that most meteroids skid across the atmosphere rather than plunging straight down, which would make the first two cases the bigger likelihoods in my opinion.
Also, when you talk about something "sufficiently large", you could be talking about something REALLY big, too...something we'd have time to look out for. The LEO end of the elevator would have a pretty good "bird's eye view" of the larger objects flying on an intersect course. If things got bad, but we saw them coming, we could save "collapse" of the elevator by just letting go of the ribbon on Earth's end, shooting the LEO end off into space.
Eh, maybe this is some old rumor that I'm parrotting, but I recall hearing that the moon's distance from Earth increases at the rate of one foot every year.
This is a difference that can only be determined by going in and looking at the code that *actually controls your application*. Wherever it may reside.
In the case of AOP, the "control" of the application is distributed among several different concerns. When a pointcut is reached, many different "interceptors" or "advisors" get a shot at the context of this pointcut and may perform various operations on it. Depending on how AOP is implemented in this case, the advisors may or may not be able to actually alter the data flowing in and out of the pointcut. It's relative to the way your AOP is being done. In the case of AspectJ, if you want to know how your code behaves, you read your source code. In a more dynamic environment...say...the Interceptor stack in JBoss, you look in a config file and find out what's wrapping your application logic. If you're so inclined, you can then look up the source code of your interceptors. To be completely honest, you have about as much ability to know what's going on as you do anywhere else- things are just organized differently.
Does this also imply that in certain situations it is not possible to have reliable behaviour?
Sure. Here's one situation- a member on your team writes an interceptor that intercepts some other method call and scrambles the data entering the pointcut, then applies this interceptor to points of execution in the program. Even then, though, the behavior is reliable. Why? Because it's doing exactly what it's supposed to do- it's applying someone's destructive interceptor before executing a bit of code. In my opinion, someone who would actually do this to a project is also the same someone who probably would undocumentedly scramble a struct passed by pointer into a function or overload operators so that his code could look more like a game of Yahtzee.
I guess I'm just a cynic when it comes to *good* practices...
To me, it's not a simple matter of good practice. Your basic business/application logic developer isn't going to be writing and applying aspects. Instead, s/he just writes application logic, and your security expert writes a security subsystem, then applies it over the top of everyone's business logic.
This isn't some everyday programming trick. It's designed for managing complexity and separation of concerns in large projects. To use the example of JBoss again, which is on a big AOP kick, the point is that an EJB developer just writes and EJB...the JBoss server then applies interceptors over it so that it has transaction support, caching, can be replicated across nodes of a cluster, etc.
So, your average programmer isn't going to just pointcut everyone else willy-nilly. In fact, your average programmer is never even supposed to know s/he's being pointcut.
Which will inavoidably lead to very bad code. Remember operator overloading in C++, where a similiar overuling of semantics was possible? Because of its abusive potential it was one of features that became considered bad practice if used at all later.
I can see what you mean, but I do see this as different from operator overloading. Aspect weaving does not change the semantic definition of a language's mathematical operators. Depending on your AOP use, too, AOP advice may not have full access to the whole of the program to abuse it. I have seen some interceptor implementations that only let the advice have access to the context of the method call. Yes, this could mean that you could write advice that scrambles the parameters before a function call, leading to unsuspected results in the function call, and I would definitely call that abusive.
Honestly, though, that's the breaks. Being able to pass pointers into a function gives the author of a function the opportunity to wreck whatever's on the end of said pointers, and that allows for abuse, but I consider it worthwhile to do. There are great ways to abuse everything.
In many ways, you're right. The current solution for dynamic run-time AOP in Java is...Bytecode Engineering!
Dynamic Proxies are good, but require that you have some sort of basal interface for objects the proxy conceals. The result, really, is that you can only apply advice on methods of the interface and nothing more. True dynamic AOP will allow virtually anything to be advised, though. LISP is in a solid position to do this...the more I learn about other languages, the more I want to start doing my regular coding in LISP.
Any language requiring you to re-engineer your compiler's output format to implement dynamic behaviour is too static for its own good.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.
Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.
Really, the biggest use for AOP is, as far as I know, still not available in AspectJ. AspectJ was, as of the last time I looked at it, just an additional compiler for a language extension to Java. As a result, I can't say that I find AspectJ all that amazing.
AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.
The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.
This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.
Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.
It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.
Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.
Then again...I could be talking arse. Here come the flames!
Actually I was making a joke (that the benchmarking task itself was what the act of anticipating things, which this tool would obviously have a one up on... ). But someone modded me up insightful, so maybe I'm on to something.
Believe it or not, you are sorta on to things. One of the "competitor" scheduler implementations to the anticipatory scheduler is the CFQ scheduler, which is written with very different intents as far as latency and bandwidth of service go. The CFQ implementor has protested that the benchmarks cast a poor light on the CFQ scheduler because they focus on tasks it isn't designed to optimize for and that the CFQ scheduler is preferable for normal desktop use (whereas the anticipatory scheduler is preferable for server use).
So, like with most humor, there was a kernel (no pun intended) of truth in there.;)
In this case, they're talking about an I/O Scheduler, which is in charge of planning I/O through some resource so that activities on that resource correctly complete as quickly as possible. To be specific, this scheduler is for the hard disk I/O Scheduler, which plans reads and writes from/to your hard disks.
The Anticipatory Scheduler is designed to optimize your disk I/O based on the assumption that reads of related material tend to happen in short succession, while writes tend to be singular and larger. As a result, when the scheduler encounters a read, it anticipates that there will be other reads in short succession, so it waits and then checks for them and, if they're there, they move to the front of the line. The name comes from the tiny waiting period when it anticipates future reads.
This is, of course, a condensed version of what I think I've learned from reading KernelTrap for the last few months. Someone's bound to tell you I'm talking arse.
"Ignore everything your math teachers tell you for the next four years. They will destroy your love for math, and you'll spend your early twenties making up for it on your own. Especially ignore your high school calculus teacher, Ms. Albritton, who will tell you you will never make it anywhere in computer science."
Terrence McKenna and others have postulated that the consumption of psychedelic mushrooms during the period around 50,000 years catalyzed the great leap from being near animal to accquiring language, technology and culture that we associate with humanity today.
Let me first start by saying that I myself am a psychonaut, and that psilocybin has been the most influential substance I've used. Now that I've said that, let me say this: McKenna is full of it on this topic. McKenna's attribution that psychedelics is a necessary "reverse logic" used to validate pre-existing suppositions and it's very little more.
What do I mean by "reverse logic"? Well, it works like this- McKenna loved psychedelics and believed that they created revolutions in thought, awareness, understanding, etc. This notion is personal belief and supposition, but by grafting some veneer of logic over it, it can be made to look "really deep." How do you do this? Well, you do it by suggesting that not only will psychedelics bring about "the revolution" but that they already have. This is incredibly convenient. Ancient human civilization is the dumping ground of otherness. Noble savage romantics, feminists, psychonauts, UFOlogists, etc...all of these people paint into the practices of primitive humans what it is they want to see. McKenna's postulations hang around now because they sound deep to stoners, fit stoner logic, and satisfy a need in stoners to feel enlightened. In the end, I find the entire matter a bit on the intellectually dishonest side.
The same goes for the idea espoused by McKenna et al that psychedelic plants and fungi produce the chemicals they do as an evolutionary response- by producing euphoria-inducing chemicals, they encourage people to care for them and cultivate them, ensuring survival. I can't even begin to explain everything that I find wrong with that line of thought. At least, not in a venue like Slashdot.
One of the reasons LimeWire may seem slow is because of Java's traditional handling of sockets, though, which was heavily synchronized. NIO changes that.
Also, don't rule out people ranting about slowness because they know a program is in Java and believe Java is slow. I once fell victim to this misperception until some performance numbers set me straight.;)
Not to split hairs, but can't Huffman compression convers fixed length character code into a variable length code consisting of symbols from pretty much any set? Granted, I'm not overly knowledgable here, but most Huffman compression examples I see convert ASCII characters into variable length bit strings, so the symbols wouldn't be "character code" but a code made from bits.
I'm asking because I don't want to have this matter confused, so there's no need to jump on me if I'm wrong. A polite correction is all it takes.;)
"HEROES" you must be kidding. This people are not heroes, I have seen this reference far to many times in the last few days. Does it stink for the people who died? Yes, also for their families and friends. But just because you happen to catch a bad break in a very public location is not an automatic ticket to the exulted status of hero.
Yes, people who cappen to catch a bad break in the public eye are not heroes. It takes self-sacrifice, dedication, and a willingness to serve a perceived "greater good" to fall into what I'd call a hero. Every Red Cross member who works in a warzone or a place of active disaster (like a fire), every firefighter, every Peace Corps worker around the world, every astronaut...I could make a long list. They're all heroes. Most of them sacrifices something or puts something of great value (life and limb, etc) on the line because they feel the need to fill an important role that demands that sacrifice. People who rise to the occassion of extraordinary circumstances, like the rebellious passengers of the "fourth flight" on 9/11, are also heroes. Heroics, for me, is defined in the decision that there are more important things on the line than your own self-interests.
The United States of America has collected its fair share of those who have justifiable earned the title of hero, without the need to inflate the ranks with random people every time a tragedy has occurred. Think for a moment of the Marines who fought in the Pacific Theater during WWII. Those that landed on Iwo Jima and Okinawa. Most of these men did not want to be there, they knew going in that their odds stank and many got to see bodies stack up all around them yet most still charged forward to what must have seemed certain deaths. That earns you the right to be called a hero. In countless battles by many different forces, there are examples of those who have exposed themselves to heavy fire in effort to save a someone else, they have earned the rights to be called a hero.
No offense, but the people who stormed Iwo Jima were ordered to. Their options were either death on the battlefield or severe punishment for going AWOL. Many WWII soldiers were conscripted, too, meaning that they did not choose to fight (and, in many cases, die) in WWII. Was there self-sacrifice? Not in those cases. There was just a form of forced labor we call the draft. Out of that group, the soliders who became heroes are the ones who eventually chose self-sacrifice by, say, putting themselves in the line of danger to protect others.
I know there were a lot of good men on Iwo Jima who were genuinely fighting for the future of the free world, and I raise my Toast of the Revolution to them several times a year. What I'm saying is that fighting because you're forced to doesn't make you a hero in my eyes any more than random tragedy.
Now those two snipers who rescued the pilot of that crashed helicopter in Somalia? Those were a pair of heroes. According to their medal of honor report, they repeatedly demanded to be inserted after their COs told them it was too risky, and both defended the copper with their lives just to rescue the pilot.
The person who catches a bad break and has their office building fall down upon them, their car crushed by a tractor trailer, or their bus explode on them are indeed people who have faced tragedy, but that in itself does not a hero make.
In my book, you're automatically a hero if you volunteer for repeatedly putting yourself in a high-powered rocket based on a 1970s design model knowing full-well that you're going to break the sound barrier by an order of magnitude on the way up and are going to be protected by 30,000F heat on the way down by a brittle skin of synthetic materials. Especially after Challenger showed us all how truly fragile that vehicle is.
Then again, in my book, you're a hero if you sign up to fight fires. Every firefighter I've known has told me the same thing- if you fight structure fires, it's only a matter of time before you have a structure collapse on you. It happened to my former boss, who fought fires as an unpaid volunteer. Knowing the risks, and accepting them anyway, passes my "self-sacrifice" test.
Again, DS9 had the opportunity, but the ball was dropped in favor of a huge war that left me thinking 'eh'.
On the contrary, I thought the war was an excellent piece of writing. ST: TNG had, to me, sterilized the entire existence of life in the Federation. The entire value space of the characters seemed to me to be filled with this "my shit doesn't stink" air of utopian hypocrisy. It made me really look at the Federation as being full of complacency. The Dominion War was downright promethian, and it was full of the dirt, sweat, and blood not only of life, but of life in a military body.
In addition to that, I found DS9 to be very personal. The characters were filled with their own issues...Dax's murderous past...Sisko's reluctance to accept his destiny as the Emissary...Bashir's hidden tale of genetic tampering...and don't even get started with Garak. Really, these characters were far more accesible to me than those from TNG or even TOS.
On top of that, the characters' personal crosses to bear were being repeatedly manifest throughout the war. War is, in some ways, an easy plot device. It gives you a chance to expose the passions and flaws of your characters...war brings out extreme circumstances which can polarize people in their thoughts and actions. That's right where the Dominion War took the story, and I applaud the writers for their handling of it.
My only gripe was the rather abrupt ending to the series. The struggle between Sisko and the possessed Gul Dukat should have been more prolonged, IMHO.
Runtimes and Multiple Languages
on
The Future of Java?
·
· Score: 2, Insightful
Microsoft jumped on a rather interesting point in their new CLR environment- if the API is universal at the bytecode level, then you can build up many languages utilizing the API and compile them down into one common bytecode. This does offer many forms of interoperability between the languages, but the question of whether or not you really want to do that comes into play. This may just be my own myopic opinion, but it seems to me that that the multi-language promise of.NET has the same promise as that of the Tower of Babel...you're going to be able to get started just fine and build things beautifully for a while, until your effort is crushed by a confusing mess of different languages.
This might have not been a really big deal if it were just VB, C#, and ASP, since they all share so many similarities, but add in "managed C++" and COBOL, and give all of these languages roughly equal footing to what they're capable of, and your development team is going to be in a position of coding anything they like in whatever language they want, and that's going to become a confusing mess to maintain.
Now, before I say anything further- YES, I am a Java programmer. I also program in C, C++, and Perl, though...I just don't get paid to do those. I like Java, but I don't think it's the messiah of languages. I will say, however, that I like it because I find it easy to code in and that, in my personal experience, fewer people have wrecked my day with bad Java programming than with C or C++ programming, and that makes it a pleasant "headache free" language for me. Since it's so "headache free", and because I can do so much with it, I often default to using Java unless there's a reason to do otherwise.
Now, since I've given what is probably my ignorant and unsolicited opinion on.NET and on multi-language runtimes, let me throw out another ignorant and unsolicited opinion. To put it shortly, I think that bytecode interpreting runtimes are really going to take over in the future of programming.
If there's one thing I've forever loved in Java that I wished I had in native code languages, it was the ability to, without care of the implementation details of some remote system, load and bootstrap executable code from that system. C and C++ have dynamic resource loading capabilities, but I just don't find them as flexible as dynamic class loading in Java. I've looked at LAM and MPI and I've programmed in CORBA...all of these different technologies seem to have one thing in common to me- they struggle to put a common veneer over different machines so that they can be used together.
I like MPI quite a bit, actually, but when I look at the ease with which I can create distributed services in JINI, the distributed options for native code languages just don't seem that great. The bytecode interpreting runtime (the JVM or the.NET CLR) is its own veneer over a machine's actual native operations, and so chunks of programs can be more easily exchanged, bootstrapped, and executed on disparite machines. From the heterogenity comes the power of very flexible dynamic loading of runnable code, and such a feature seems to me to be extremely important in creating distributed systems.
Again, I'm not saying Java or.NET is going to take all or be all. Honestly, I'd like to see these two bow out in a few more years and make room for a runtime that picks up where they leave off, because they both leave things to be desired. Also, rock solid native code languages are still incredibly important...not only are they necessary when you need more raw machine access, but how else will everything that bytecode languages depend on be implemented? And, of course, scripting languages that allow for fast and effective programming will be perennial.
But I think that the future of quite a bit of programming, especially a lot of business applications programming (which, at least in my experience, relies increasingly on distributed systems), is going to start going to virtual machines interpreting bytecodes.
I'm sure I'll get flamed for this, so please have at it.;)
Naturalists basically say "Spiritual people believe in their myths because they don't understand science."
Well, that just seems silly to me, anyway. Given the way that people re-fit their myths and idologies around science and scientific discovery (such as the changing role and impressions of God), it would seem almost axiomatic to me that people believe in their myths for reasons other than science. Ignorance of science does facilitate some myths, and even helps create a mythology I call "scientism", which is a worship of scientific authority or the trappings thereof, but I don't know anyone who would take that overly-broad generalization seriously.
Here's the main point: Since naturalists imply that they would have a more favorable opinion of theism if naturalists were aware of famous theist scientists (however fallacious this logic may be), it's in the interest of theists to give them the requested information.
I don't know who these "naturalists" are, but I guess I'm not one of them, because I've never said that it would give me a more favorable opinion of theism. I really don't know where you've gotten this from in general, honestly. Anyone who would think better of theism because it included their fellows is falling prey to a herd mentality and isn't personally judging the idea based on their perceptions of its merits.
Do you consider both rational and historical inquiry to be outside the realm of empiricism?
Shermer gives an excellent example of empiricist historical study in Why People Believe Weird Things, and I do buy his arguments. So, some forms of historical inquiry are empirical, while others may not be. As for rational inquiry, my definition of rationality keeps it well apart from empricism.
Slashdot Mirror
I think it's worth noting that the concepts of "game" and "real life" have different boundaries to different people. To me, playing a game is part of my real life. It takes up my real time and requires my real mind to work. What separates it is context. Games are "safe". Games have certain components behind them so that they happen in a social context that is generally understood by participants (and, often, outsiders), that the actions taking place aren't to be taken seriously.
In a game like Steve Jackson Games' "Killer", it's when someone pulls out a nerf dart gun. While the game does not necessarily have its own set-aside time and place in the traditional sense, the game actions themselves still happen "on game time".
So, I'd say there's a difference. The problem isn't when "game time" isn't a specific, set aside block of time. The problem is when the emotions and reactions you have in a gaming context leech out of that context. I've heard before of "Killer" players developing some serious paranioa when they didn't manage their emotions well enough. That's where the problems begin.
Point well taken. ;)
It is the case. I double-checked for my own sanity (though I suspected I was correct), and the moon is moving further away from Earth, though I misreported the rate- its orbit lengthens by 3.8 centimeters a year, not a foot.
What if a big enough asteroid or piece of space junk plowed into it, driving it lower into it's orbit or even into the atmosphere?
This would depend highly on the trajectory of the asteroid or meteroid prior to impact, its mass and velocity, etc. Possible results could include...
Then again, these are just guesses. I'm not a physicist. I'm also not an astronomer, but I seem to recall hearing that most meteroids skid across the atmosphere rather than plunging straight down, which would make the first two cases the bigger likelihoods in my opinion.
Also, when you talk about something "sufficiently large", you could be talking about something REALLY big, too...something we'd have time to look out for. The LEO end of the elevator would have a pretty good "bird's eye view" of the larger objects flying on an intersect course. If things got bad, but we saw them coming, we could save "collapse" of the elevator by just letting go of the ribbon on Earth's end, shooting the LEO end off into space.
Those are just a few crackpot possibilities.
Eh, maybe this is some old rumor that I'm parrotting, but I recall hearing that the moon's distance from Earth increases at the rate of one foot every year.
In the case of AOP, the "control" of the application is distributed among several different concerns. When a pointcut is reached, many different "interceptors" or "advisors" get a shot at the context of this pointcut and may perform various operations on it. Depending on how AOP is implemented in this case, the advisors may or may not be able to actually alter the data flowing in and out of the pointcut. It's relative to the way your AOP is being done. In the case of AspectJ, if you want to know how your code behaves, you read your source code. In a more dynamic environment...say...the Interceptor stack in JBoss, you look in a config file and find out what's wrapping your application logic. If you're so inclined, you can then look up the source code of your interceptors. To be completely honest, you have about as much ability to know what's going on as you do anywhere else- things are just organized differently.
Does this also imply that in certain situations it is not possible to have reliable behaviour?
Sure. Here's one situation- a member on your team writes an interceptor that intercepts some other method call and scrambles the data entering the pointcut, then applies this interceptor to points of execution in the program. Even then, though, the behavior is reliable. Why? Because it's doing exactly what it's supposed to do- it's applying someone's destructive interceptor before executing a bit of code. In my opinion, someone who would actually do this to a project is also the same someone who probably would undocumentedly scramble a struct passed by pointer into a function or overload operators so that his code could look more like a game of Yahtzee.
I guess I'm just a cynic when it comes to *good* practices...
To me, it's not a simple matter of good practice. Your basic business/application logic developer isn't going to be writing and applying aspects. Instead, s/he just writes application logic, and your security expert writes a security subsystem, then applies it over the top of everyone's business logic.
This isn't some everyday programming trick. It's designed for managing complexity and separation of concerns in large projects. To use the example of JBoss again, which is on a big AOP kick, the point is that an EJB developer just writes and EJB...the JBoss server then applies interceptors over it so that it has transaction support, caching, can be replicated across nodes of a cluster, etc.
So, your average programmer isn't going to just pointcut everyone else willy-nilly. In fact, your average programmer is never even supposed to know s/he's being pointcut.
I can see what you mean, but I do see this as different from operator overloading. Aspect weaving does not change the semantic definition of a language's mathematical operators. Depending on your AOP use, too, AOP advice may not have full access to the whole of the program to abuse it. I have seen some interceptor implementations that only let the advice have access to the context of the method call. Yes, this could mean that you could write advice that scrambles the parameters before a function call, leading to unsuspected results in the function call, and I would definitely call that abusive.
Honestly, though, that's the breaks. Being able to pass pointers into a function gives the author of a function the opportunity to wreck whatever's on the end of said pointers, and that allows for abuse, but I consider it worthwhile to do. There are great ways to abuse everything.
That was a "rhetorical you". I didn't meant to target it specifically at you. I do beg your pardon.
Time to get new glasses. ;)
Dynamic Proxies are good, but require that you have some sort of basal interface for objects the proxy conceals. The result, really, is that you can only apply advice on methods of the interface and nothing more. True dynamic AOP will allow virtually anything to be advised, though. LISP is in a solid position to do this...the more I learn about other languages, the more I want to start doing my regular coding in LISP.
Any language requiring you to re-engineer your compiler's output format to implement dynamic behaviour is too static for its own good.
AOP is a very useful perspective to take, though, and I've seen it used to some incredibly good ends. Rhetoric it cheap.
It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.
Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.
AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.
The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.
This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.
Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.
It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.
Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.
Then again...I could be talking arse. Here come the flames!
Believe it or not, you are sorta on to things. One of the "competitor" scheduler implementations to the anticipatory scheduler is the CFQ scheduler, which is written with very different intents as far as latency and bandwidth of service go. The CFQ implementor has protested that the benchmarks cast a poor light on the CFQ scheduler because they focus on tasks it isn't designed to optimize for and that the CFQ scheduler is preferable for normal desktop use (whereas the anticipatory scheduler is preferable for server use).
So, like with most humor, there was a kernel (no pun intended) of truth in there. ;)
While I have seen some voices of dissent that the test isn't fair, I'm afriad I don't understand what you mean here. Could you please explain further?
The Anticipatory Scheduler is designed to optimize your disk I/O based on the assumption that reads of related material tend to happen in short succession, while writes tend to be singular and larger. As a result, when the scheduler encounters a read, it anticipates that there will be other reads in short succession, so it waits and then checks for them and, if they're there, they move to the front of the line. The name comes from the tiny waiting period when it anticipates future reads.
This is, of course, a condensed version of what I think I've learned from reading KernelTrap for the last few months. Someone's bound to tell you I'm talking arse.
"Ignore everything your math teachers tell you for the next four years. They will destroy your love for math, and you'll spend your early twenties making up for it on your own. Especially ignore your high school calculus teacher, Ms. Albritton, who will tell you you will never make it anywhere in computer science."
Let me first start by saying that I myself am a psychonaut, and that psilocybin has been the most influential substance I've used. Now that I've said that, let me say this: McKenna is full of it on this topic. McKenna's attribution that psychedelics is a necessary "reverse logic" used to validate pre-existing suppositions and it's very little more.
What do I mean by "reverse logic"? Well, it works like this- McKenna loved psychedelics and believed that they created revolutions in thought, awareness, understanding, etc. This notion is personal belief and supposition, but by grafting some veneer of logic over it, it can be made to look "really deep." How do you do this? Well, you do it by suggesting that not only will psychedelics bring about "the revolution" but that they already have. This is incredibly convenient. Ancient human civilization is the dumping ground of otherness. Noble savage romantics, feminists, psychonauts, UFOlogists, etc...all of these people paint into the practices of primitive humans what it is they want to see. McKenna's postulations hang around now because they sound deep to stoners, fit stoner logic, and satisfy a need in stoners to feel enlightened. In the end, I find the entire matter a bit on the intellectually dishonest side.
The same goes for the idea espoused by McKenna et al that psychedelic plants and fungi produce the chemicals they do as an evolutionary response- by producing euphoria-inducing chemicals, they encourage people to care for them and cultivate them, ensuring survival. I can't even begin to explain everything that I find wrong with that line of thought. At least, not in a venue like Slashdot.
Also, don't rule out people ranting about slowness because they know a program is in Java and believe Java is slow. I once fell victim to this misperception until some performance numbers set me straight. ;)
It doesn't require you to disagree. I asked "Does CLI already achieve this?" for a reason. ;)
Not to split hairs, but can't Huffman compression convers fixed length character code into a variable length code consisting of symbols from pretty much any set? Granted, I'm not overly knowledgable here, but most Huffman compression examples I see convert ASCII characters into variable length bit strings, so the symbols wouldn't be "character code" but a code made from bits. I'm asking because I don't want to have this matter confused, so there's no need to jump on me if I'm wrong. A polite correction is all it takes. ;)
Yes, people who cappen to catch a bad break in the public eye are not heroes. It takes self-sacrifice, dedication, and a willingness to serve a perceived "greater good" to fall into what I'd call a hero. Every Red Cross member who works in a warzone or a place of active disaster (like a fire), every firefighter, every Peace Corps worker around the world, every astronaut...I could make a long list. They're all heroes. Most of them sacrifices something or puts something of great value (life and limb, etc) on the line because they feel the need to fill an important role that demands that sacrifice. People who rise to the occassion of extraordinary circumstances, like the rebellious passengers of the "fourth flight" on 9/11, are also heroes. Heroics, for me, is defined in the decision that there are more important things on the line than your own self-interests.
The United States of America has collected its fair share of those who have justifiable earned the title of hero, without the need to inflate the ranks with random people every time a tragedy has occurred. Think for a moment of the Marines who fought in the Pacific Theater during WWII. Those that landed on Iwo Jima and Okinawa. Most of these men did not want to be there, they knew going in that their odds stank and many got to see bodies stack up all around them yet most still charged forward to what must have seemed certain deaths. That earns you the right to be called a hero. In countless battles by many different forces, there are examples of those who have exposed themselves to heavy fire in effort to save a someone else, they have earned the rights to be called a hero.
No offense, but the people who stormed Iwo Jima were ordered to. Their options were either death on the battlefield or severe punishment for going AWOL. Many WWII soldiers were conscripted, too, meaning that they did not choose to fight (and, in many cases, die) in WWII. Was there self-sacrifice? Not in those cases. There was just a form of forced labor we call the draft. Out of that group, the soliders who became heroes are the ones who eventually chose self-sacrifice by, say, putting themselves in the line of danger to protect others.
I know there were a lot of good men on Iwo Jima who were genuinely fighting for the future of the free world, and I raise my Toast of the Revolution to them several times a year. What I'm saying is that fighting because you're forced to doesn't make you a hero in my eyes any more than random tragedy.
Now those two snipers who rescued the pilot of that crashed helicopter in Somalia? Those were a pair of heroes. According to their medal of honor report, they repeatedly demanded to be inserted after their COs told them it was too risky, and both defended the copper with their lives just to rescue the pilot.
The person who catches a bad break and has their office building fall down upon them, their car crushed by a tractor trailer, or their bus explode on them are indeed people who have faced tragedy, but that in itself does not a hero make.
In my book, you're automatically a hero if you volunteer for repeatedly putting yourself in a high-powered rocket based on a 1970s design model knowing full-well that you're going to break the sound barrier by an order of magnitude on the way up and are going to be protected by 30,000F heat on the way down by a brittle skin of synthetic materials. Especially after Challenger showed us all how truly fragile that vehicle is.
Then again, in my book, you're a hero if you sign up to fight fires. Every firefighter I've known has told me the same thing- if you fight structure fires, it's only a matter of time before you have a structure collapse on you. It happened to my former boss, who fought fires as an unpaid volunteer. Knowing the risks, and accepting them anyway, passes my "self-sacrifice" test.
On the contrary, I thought the war was an excellent piece of writing. ST: TNG had, to me, sterilized the entire existence of life in the Federation. The entire value space of the characters seemed to me to be filled with this "my shit doesn't stink" air of utopian hypocrisy. It made me really look at the Federation as being full of complacency. The Dominion War was downright promethian, and it was full of the dirt, sweat, and blood not only of life, but of life in a military body.
In addition to that, I found DS9 to be very personal. The characters were filled with their own issues...Dax's murderous past...Sisko's reluctance to accept his destiny as the Emissary...Bashir's hidden tale of genetic tampering...and don't even get started with Garak. Really, these characters were far more accesible to me than those from TNG or even TOS.
On top of that, the characters' personal crosses to bear were being repeatedly manifest throughout the war. War is, in some ways, an easy plot device. It gives you a chance to expose the passions and flaws of your characters...war brings out extreme circumstances which can polarize people in their thoughts and actions. That's right where the Dominion War took the story, and I applaud the writers for their handling of it.
My only gripe was the rather abrupt ending to the series. The struggle between Sisko and the possessed Gul Dukat should have been more prolonged, IMHO.
Microsoft jumped on a rather interesting point in their new CLR environment- if the API is universal at the bytecode level, then you can build up many languages utilizing the API and compile them down into one common bytecode. This does offer many forms of interoperability between the languages, but the question of whether or not you really want to do that comes into play. This may just be my own myopic opinion, but it seems to me that that the multi-language promise of .NET has the same promise as that of the Tower of Babel...you're going to be able to get started just fine and build things beautifully for a while, until your effort is crushed by a confusing mess of different languages.
This might have not been a really big deal if it were just VB, C#, and ASP, since they all share so many similarities, but add in "managed C++" and COBOL, and give all of these languages roughly equal footing to what they're capable of, and your development team is going to be in a position of coding anything they like in whatever language they want, and that's going to become a confusing mess to maintain.
Now, before I say anything further- YES, I am a Java programmer. I also program in C, C++, and Perl, though...I just don't get paid to do those. I like Java, but I don't think it's the messiah of languages. I will say, however, that I like it because I find it easy to code in and that, in my personal experience, fewer people have wrecked my day with bad Java programming than with C or C++ programming, and that makes it a pleasant "headache free" language for me. Since it's so "headache free", and because I can do so much with it, I often default to using Java unless there's a reason to do otherwise.
Now, since I've given what is probably my ignorant and unsolicited opinion on .NET and on multi-language runtimes, let me throw out another ignorant and unsolicited opinion. To put it shortly, I think that bytecode interpreting runtimes are really going to take over in the future of programming.
If there's one thing I've forever loved in Java that I wished I had in native code languages, it was the ability to, without care of the implementation details of some remote system, load and bootstrap executable code from that system. C and C++ have dynamic resource loading capabilities, but I just don't find them as flexible as dynamic class loading in Java. I've looked at LAM and MPI and I've programmed in CORBA...all of these different technologies seem to have one thing in common to me- they struggle to put a common veneer over different machines so that they can be used together. I like MPI quite a bit, actually, but when I look at the ease with which I can create distributed services in JINI, the distributed options for native code languages just don't seem that great. The bytecode interpreting runtime (the JVM or the .NET CLR) is its own veneer over a machine's actual native operations, and so chunks of programs can be more easily exchanged, bootstrapped, and executed on disparite machines. From the heterogenity comes the power of very flexible dynamic loading of runnable code, and such a feature seems to me to be extremely important in creating distributed systems.
Again, I'm not saying Java or .NET is going to take all or be all. Honestly, I'd like to see these two bow out in a few more years and make room for a runtime that picks up where they leave off, because they both leave things to be desired. Also, rock solid native code languages are still incredibly important...not only are they necessary when you need more raw machine access, but how else will everything that bytecode languages depend on be implemented? And, of course, scripting languages that allow for fast and effective programming will be perennial.
But I think that the future of quite a bit of programming, especially a lot of business applications programming (which, at least in my experience, relies increasingly on distributed systems), is going to start going to virtual machines interpreting bytecodes.
I'm sure I'll get flamed for this, so please have at it. ;)
Well, that just seems silly to me, anyway. Given the way that people re-fit their myths and idologies around science and scientific discovery (such as the changing role and impressions of God), it would seem almost axiomatic to me that people believe in their myths for reasons other than science. Ignorance of science does facilitate some myths, and even helps create a mythology I call "scientism", which is a worship of scientific authority or the trappings thereof, but I don't know anyone who would take that overly-broad generalization seriously.
Here's the main point: Since naturalists imply that they would have a more favorable opinion of theism if naturalists were aware of famous theist scientists (however fallacious this logic may be), it's in the interest of theists to give them the requested information.
I don't know who these "naturalists" are, but I guess I'm not one of them, because I've never said that it would give me a more favorable opinion of theism. I really don't know where you've gotten this from in general, honestly. Anyone who would think better of theism because it included their fellows is falling prey to a herd mentality and isn't personally judging the idea based on their perceptions of its merits.
Shermer gives an excellent example of empiricist historical study in Why People Believe Weird Things, and I do buy his arguments. So, some forms of historical inquiry are empirical, while others may not be. As for rational inquiry, my definition of rationality keeps it well apart from empricism.