That's because ID is a skeleton created to pass for a scientific theory to teach a very particular point. Any powerful arguments have been neutered by pretending it is something it is not, and discarding what would most obviously weaken that point, or its acceptance as a curriculum topic.
There is a long tradition of philosophical ideas and theories based on Creationism in its diverse forms. This was a very mature debate (thousand-years old) in philosophy before it became a topic of science, and there is certainly enough substance to both present a debate to the fundamental assumptions of science, and influence the development of science itself in very profound ways.
Heck, I would argue that in order to understand why we accept science, this is a vital topic of study. Then again, I would argue that if we are to have critical thinking in high-school graduates, philosophy-training is vital, so I may be biased.
All of the interesting questions I have seen triggered by ID debate were old, interesting questions in biology that were already in intense study by scientists working in evolution.
I very much doubt ID has forced more self-analysis in these sciences than the gradualist-vs-saltationist or gene-vs-species selection debates, for example, which have been going on publicly strong (at least to untrained lay eyes) for decades.
On the contrary, I've often seen ID debates distort or silence the interesting debates in science and force researchers to play politics and present a unified front that plays to the caricature of evolution research presented by ID: the idea of darwinism as converntional wisdom that suffers no criticism or scientific analysis.
The positive change introduced by ID, I hope, is in the teaching of science, and by extension in correcting a fundamental misconception of science in the general public.
I think a significant source of the support for ID, and the accusations of hypocrisy against science, are due to a widening gap of communication and understanding on the most basic concepts between the average citizen and the people who do research. The scary thing is that this is not due to advanced concepts beyond the reach of a non-specialist, but on the very basic ideas of logic, science, objectivity, etc. The general population has a very post-modernist view of science in general, which is a concern considering current civilizations are so dependant on science, and said populations are not particularly post-modernist per se.
Based on the results, schools seem to be in the business of producing citizens trained in 'scientific facts' rathan than science as a discipline. From college and general interactions with people, I have gotten the impression that ID proponents are often quite correct complaining about evolution being taught as a 'final and complete truth' in US high-schools... the same, unfortunately, applies to practically everything else taught as science at that level too. I don't know if this would be a problem of curriculum, methodology, or just the lack of engagements of students in the inquisitive process.
There is no fundamental difference between the way most people understand evolution vs ID. This does not mean ID is science, it means evolution is being understood as religion.
Rather than correcting a deficiency in the understanding of science by students, however, ID proponents just ask that their 'final and complete truth' be taught as well. That they do not see the fundamental difference between the two 'theories' speaks of their misunderstanding of science, but more important is that from the POV of a large and diverse demographic, they are objectively right.
From the blurb, I was expecting Zambonini to be mostly wrong, but it seems he's just putting the blame in the wrong place (mostly).
This sort of courses may not be useful to get a job, but they can be vital to doing your job well. And therefore, keeping it. The information from courses like TOC and Algorithms, for example, are used regularly on the job: pretty much every time you code.
That does not mean you go and provide correctness-proofs and a full analysis of every code-path you write. That is too costly in most industries. What comes 'for free' from someone who has this background is the ability when they look at the problem to discard many bad solutions before attempting them, identify costly/intractable problems that need better specification, and solving concrete problems with very general (proven) solutions.
He's right that there are other less-academic skills you can use to land a job, but I'd disagree that this is the responsability of a CS program. For many of the issues he brings up, it wouldn't even be the responsability of an Engineering program.
The career-path is the choice of the students, and their responsability. Although keeping the academic courses relevant is important, I wonder if there are as many complaints about Math majors learning too much Math and not enough business/management.
Assumption: The role of a science university degree is NOT to provide all the information you will conceivably need in the industry (which is too broad and changes month). Its role is to provide the student with the fundamental background and the skills for the student to identify what is specifically important from all that knowledge, be able to learn it by themselves, and then make new contributions to that knowledge.
Considering that:
- If students cannot educate themselves on technical specifics (a programming language, xml, etc) outside of the college curriculum, they will face difficulties in the real-world regardless of whatever courses they took. - From the courses listed, one cannot say for sure, but it sounds you are in the right CS program.
Just make sure to complement your academic education with practical skills if your goal is to get an industry job. - He's right about databases. They're vital in and out of the industry, and they put to use some skills otherwise often neglected.
A good CS curriculum will include at least 1 course in database fundamentals, with at least a non-trivial practical project. - Taking a course because it mentions XML is total non-sense. There is no new deep theory behind XML, only minor technical decisions that certainly do not take a university course to learn.
While XML makes sense as a case study for a number of related areas (parsers, SE, databases, etc), there is nothing unique a student can't learn in a few hours.
If a new CS college hire cannot tell when to use DOM vs SAX after a 5 min. explanation on what the acronyms mean, then the problem is less with ignorance about XML and more with lack of those 'useless' CS fundamentals. - He's right about students not going into SE, but that is as much the student's fault as the university. In my experience, SE courses are not very popular with undergraduates where they are offered. If your aim is to be a Software Engineer, use the options available in your school. Take them if that is what you want to do with your degree.
I don't know if this is just more common in the US, or my 'sample' was less random: but from what I have seen many universities provide either an SE program/sub-program or corresponding electives
If they're not available, learn on your own and do projects that use that knowledge. The main benefit of the SE courses I've seen is identifying the big problems and pointing out old solutions. The interesting stuff you have to learn by yourself anyway. - Get real-world experience: internships, co-ops, part-time jobs. The most important
If you're talking about relatively small programs to solve very specific problems, I'd agree with you: having to apply 5 patterns likely means you chose the wrong ones. But for a big application there are plenty of problems that may or may not benefit from different patterns.
As a Patterns zealot, a book I'd recommend to most Pattern fanatics, as well as to any Pattern skeptic, is "Refactoring to Patterns", by Joshua Kerievsky.
It's a pretty good book on moving towards and (gasp!) away from design patterns based on application requirements and their actual usefulness, and warns frequently against the common bad habits of the Design Patterns zealot (everything needs a singleton, and a visitor, and...)
I doubt men are that repelled by advertisements...
I'd think men want anything that has sex in them, and are generally receptive to scenes that promote tribal behavior, if pop-culture is any indication.
Hence the popularity of memes originating in beer commercials.
I'd like to think people in general are receptive to clever amusement, advertising included; although that is a bit less substantiated, people do share such advertisements as interesting memes in spite of their corporate message. E.g.: I'm currently not looking for a backup solution, but If I ever do, a company that hires John Cleese is more likely to get my money.
It's interesting how much agreement there was a few decades ago on future technology predictions.
Before that, they were all over the place: alien invasions, giant mutant plants and insects, space pirates flying in rockets to other planets.
But then most people started agreeing on the basics: flying cars, nuclear power in every home, giant monolithic computers controlling the government, with potential interruptions by nuclear winters from WWIII.
The details were fuzzy, but with this consensus clearly we were onto something.
I have to disagree, at least with the random part.
At the time I saw Evangelion, I found it disturbingly interesting because of its Gnostic themes and their attention to detail.
They can look like random mishmash to people unfamiliar with the themes and mythos of early christianity, but so would real early christian mythology, particularly the neo-platonist cults that would be most pertinent to this.
It takes a bit of research to realize the for how long these had an effect on both mainstream christian and non-christian theology (influences in kabbalah and sufi mysticism, for example), and how much effort and time it took to homogeinize christianity to the non-random mishmash understood by Westerners today.
This is not to say the intention of Evangelion was to provide a faithful or even deep treatment of gnostic or medieval kabbalistic themes. The series took its own deviations and developed its own mythos for dramatic purposes (something that was commonly accepted in these circles anyway), and was guilty of some symbol squandering (crosses galore).
But I don't doubt that at the very least the director did his homework, which is more than I would say of most entertainment productions.
It seems to me that often when people complain about the randomness of the Christian themes in this or other works they miss the point by applying a very 18th-20th century impression of the Christian mythos and its malleability.
Yes, that explains why there is a massive exodus from Cuba to most countries you mention, in spite of the immigration restriction many have put in place precisely to stop the cuban influx... and the obvious restrictions Cuba itself to stop people from leaving.
How many people from Mexico, Nicaragua, Panama, etc. are desperately trying to get into Cuba?
For those who want to move, how many restrictions do they have to face to actually leave? Include that when putting the numbers in perspective, it does not favor Cuba.
I doubt you have been in any of the countries you mentioned. I'm not sure you even grasp the geography. (Hint: Neither Haiti nor Colombia are central american countries)
The reactions of the people both inside and outside of Cuba who have seen land on both sides of the sea are a better judgement of quality of life than statistics. Cuba, like many communist countries, has a history of playing with the numbers when measuring its social and economic successes.
Thanks for the links to the papers. I was vaguely aware of this as a known problem but I haven't been following the research as closely as I would like the last couple of years.
I still avoid thinking of the problem as "lack of structure" because the structure is there... it's just documented in an unexpected location in the source code. But I'm very wary of the IDE dependency as the solution to that problem, partly because it is a very heavy dependency to take, and partly because it does not 'click' in my mind as the most elegant solution.
IDE support is also only a solution for the static weaving problem, as in AspectJ. Dynamic weaving has some very tempting advantages for a good set of problems, such as services provided by hosting environments.
I understand the reluctancy to limit the "aspect obliviousness" because it limits the power and flexibility of the construct; but I find it interesting that in other methodologies obliviousness is something we have often moved away from as we develop richer security and correctness models. Your own work on ArchJava was a removal of participant obliviousness in component interaction, if I remember correctly from my grad school days.
It seems to me that a limitation in power will be very difficult to avoid if we want to solve the problem. Forfeiting dynamic weaving and taking the IDE dependency may be the solution, or maybe it will be adopting an explicit Advice/Advisee contract and a richer security model. I'm just glad research is active on the problem.
Well, except that AOP can only modify code in a structured way.. You can replace a method (no more obscure than method over-loading), you can wrap a method, turning it's body into a nested scope (again similar to a method which calls super). Yes they have before and after methods, but these are mere conviniences to the wrapping of a method.
I think you are missing my point: Lack of structure is the cause, not the problem. The problem is that from "just reading the source code" you cannot build a coordinate system to represent the state of your running process.
Invisibility creates the same problem, regardless of how structured is your invisible change. And that IS different.
Method overrides are both visible risk-points (you are the one calling the virtual method) and a well-known problem. That's part of the push for design-by-contract language features in research.
Even GOTO is a visible risk-point... they can make your coordinate system unmanageable by complexity or growth, but you are aware of the problem and can potentially grow your coordinate system to cover those cases on demand.
On typical AOP, the binding is defined by the advise, not by the pointcut. Your only hope of expanding you coordinates to know that you cover your code behavior is to include ALL aspects in your code as globals code snippets that can be injected in your code. With static weaving hopefully your aspect population, per project, is limited enough. With dynamic weaving, there is not even that hope.
One of the linked papers makes a very good point of comparing AOP not to GOTO, but to the declarative COME FROM which changes a piece of code after the fact.
If you don't have the proper tools to warn you that a method is over-loaded (IntelliJ's Idea, or I believe eclipse), then you aren't privy to the details of execution.
No, but you are aware of the call to a virtual method, so by the semantics of the programming language you should always assume it can be overloaded and code to the documented contract (preconditions, postconditions, invariants and errors).
Depending on the language, parts of the contract may or may not be enforced, but you are aware of the risks in that line of code.
Moreoever, there ARE AOP analysis tools which can warn you that an aspect has wrapped this method. Thus, provided sufficiently intelligent tools v.s. sufficiently obscure inheretance points of basic OOP, the whole readibility point is moot.
That was part of the point in the previous post:
Without doing the weaving explicitly so you can see this change, analyzing the code is hard or impossible. The problem is not readability, it is visibility. As you mention before AOP is well structured, and once the weaving is visible it is typically not that complex to read.
The problem is that you need special tools to SEE in the first place, and these tools have to take the whole project as a whole. This is is a break from previous methodologies where the IDE was a convenience... now it's an essential CASE tool that is part of your language: without it the code does not make sense.
And with dynamic weaving, your tool still cannot speculate on who may wrap your methods at runtime in the future.
As I've said in other posts, I prefer aspects which do not directly affect the ability of a code block to do as it conceptually is designed to do. They must have side-effects which are useful to the aspect, and nothing else.
Most or all of the problems would be moot if we restricted the flexibility of AOP as a general programming language methodology, but that requires a conscious change in direction in AOP, and more research on what limitations could we take without sacrificing the usefulness of AOP...
- Aspects which keep the method return invariant are safe, but they are a very limited us
As I pointed out previously, yes there are similar known issues in OOP, but they have been studied quite a bit and there are existing solutions.
Also, the points of code injection in OOP are far more evident because of their visibility in the calling source code as method invocations, so they can be part of your coordinate system. In AOP they are just not visible from the analyzed source code, so your coordinate system breaks.
AOP papers in general seemed to ignore the issue and present only the examples that benefit the most from AOP, and many practitioners end up seeing it as a panacea... it's good to see a change in that trend.
I'm not someone to dismiss AOP for this issue; this is a methodology I have been interested for a while now and had some direct research interest in it at some point. But before AOP can be embraced as part of mainstream development, we need to address the problems that arise when it is used in a suboptimal way, as it will when large teams use it for large projects.
I'm sure some solutions will arise, whether that translates into language-feature modifications or just best practice documentation, but we need to be looking at the problem.
As I mentioned in another post, I think this is a sign of maturity, more than weakness, in AOP. It means that it is taken seriously enough for non-toy projects for its compromises to become evident.
Funny, this is not the first time I heard of this complaint and, for example, I wouldn't think Anders Hejlsberg was afraid of learning a new language feature considering his career... (the question on AOP is asked within the first two mins if you don't want to watch the whole thing).
The concern predates the report for quite a bit, and from some reliable sources. This is not a surprise, as I would think the role of companies like forrester is to communicate trends like these, not to create them out of the blue.
You are right, programmers should choose the best tool for the task. But an issue with AOP as commonly proposed is that you can use the wrong tool and do the wrong task whether you choose it or not, because the weaving is not happening on your request (pointcut), but on the aspect's (advice).
Depending on the approach of the AOP framework this could be a risk at the team level (static weaving), or at the user level (dynamic weaving) because keeping track of all the aspects introduced by other people in your code is hard/impossible.
AOP based on declarative annotations could help a lot, but for dynamic weaving (which still can be extremely useful) the main problem doesn't go away.
Maybe providing limitations to the semantics of an aspect (in terms of invariants it must keep) would be a solution, but that would limit AOP to a non-general programming model, and for that we would have to define the classes of problems where it may be 'useful' or 'harmful', or provide a general way to define these limitations by the application (since we assume they are domain-specific).
In any case, this does not seem to me like the kind of criticism coming from people afraid of a "new thing".
Rather, it seems the kind of criticism a new technology faces when applied to 'real world' problems and projects, which is a good sign that AOP is taken seriously enough by mainstream development teams, and that there will be people working on solutions to these problems.
No, the problem with GOTO is that, as a consequence of being an unstructured flow control change, it makes it impossible to trust your reasoning about code because it destroys your ability to scope it.
To quote: "... it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress..."
I think Dijkstra's point was that any construct that does this is harmful.
Structured constructs are typically less liable to do this, but only because they are visible and the structure is known.
AOP does have the ability to inject arbitrary code in your function that can change its semantics and you cannot see this when reading the affected code.
No matter how structured that change is, its invisibility makes it impossible to fully understand your code from the source code without 'weaving in' all the aspects explicitly. Like GOTO, it destroys your ability to scope your reasoning of the code to the local view.
As much as I love AOP for a class of problems, this is a very valid concern that needs to be addressed.
It's certainly not the first language featureset that faces this problem; OOP can deal with its own issues with design by contract, either through documented best practices or by enforcing it in the language. I haven't seen much in AOP there, beyond the absence of problematic examples (which would typically come from real-world use).
Well, the papers linked in the psot describe the basic problem well enough and they're not charging 250 bucks for the pdfs... not sure what other research results are included in the forrester report, but I doubt there's much you wouldn't find in published academic material if your time is worth less than that... or if you just enjoy reading the research itself.
I) Not everyone stresses out on tests, standarized or not.
Particularly in aptitude tests, many people do better because they don't care too much. II) Some people are conditioned to 'high-stress test' situations, so that the situation becomes routine and they don't stress out.
If this is true, the second factor would suggest the standarized test culture is selective towards:
A)Individuals that train themselves specifically to take tests (with all those 'beat the SAT/GRE/GMAT' courses and books).
It is arguable if it is a good idea to favor this group, as the positive non-test-specific skills represented by this should be (normally) better represented by schoolwork.
B) Alumni from schools with methodologies centered on low-count, heavy-weight tests.
Once more it is arguable if this is the best educational methodology to select for.
Personally, most criticism I have seen against standarized tests has been very sophistic, but from what little information was in the article this does not seem to be the case.
From the point of view of an admissions board, I don't think it will ever be a reason to ignore the tests, just another thing to consider their weight when evaluating a candidate. Unfortunately, there are a lot of graduate programs that do not use personal interviews as part of the admission process.
Also, since we're talking of a standarized test, I don't think it even makes sense to worry about extreme outliers: they're likely to be considered differently anyway.
This is more likely to affect the larger population that does consistently better in less stressful circumstances but show 'normal' performance under pressure. If anything is affected, it would be the minimum bar for test scores, or the interpretation of a CV-vs-TestScore disparity.
You are correct, I should say that C# fully support static inner classes.
"Nested type" and "inner class" are, as far as I know, equivalent terms and the latter has been a common term used in both languages. However, this is the first time I know of someone who differentiates the two terms in practical use.
What makes the implicit "this.Outer" the essential feature of an "inner class" in your terminology? I'm also curious as to why you consider it such an important feature.
Once more this seems to be a matter of designer taste, but unlike anonymous inner classes, I do not see how this is particularly useful.
I have seen 2 broad categories where the reference to the outer class is useful: - Inner classes for logic encapsulation in a complex class: passing the reference explicitly is no pain here, though. - Anonymous inner classes: most useful because the class declaration itself is overkill, doing the constructor plumbing even more so.
I always saw the non-static inner class as a nice element of syntactic sugar that quickly gets out of control because it solves a non-problem if you ignore anonymous inner classes. In the process they complicate the language with special semantics and syntax for little need. Of course, once you bring this in to support anonymous inner classes it pays for itself. But the problem is that anonymous inner classes have almost always been a crufty solution themselves... 99% of the times I used them effectively they were functors and what I wanted was a method, not a full class.
Ignoring anonymous inner classes for a sec:
In Java, I do not have to pass an instance of my object to the inner class, so I get 'for free' the ability to write this (horrible) syntax:
int x= this.ExtremelyLongNameBecauseWeKnowClassesGetLongN amesTheseDays.privateMember.foo();
If the class has a non-trivial size (which for non-anonymous classes can easily happen) or the reader of the code is not familiar with the special semantics of Java's non-static inner classes, it's not immediately obvious where this reference came from.
As a programmer I have to make an explicit decision to NOT keep an extra reference in my object. if I forget to put the static modifier, I get this dancing implicit this.Outer 'for free' too, when normally I just don't need and pollutes the contents of the object.
In C#, you have to explicitly decide you'll need a reference to your outer type, and then use it:
public MyFooInnerClass(MyBarOuterClass bar) { myBar = bar; }...
int x = this.myBar.privateMember.foo();
The latter code seems to me more straightforward and readable, not depending on special semantics to know where myBar came from.
Sure, I have to pass the 'outer' object to the constructor myself instead of letting the compiler do it, but in exchange I don't have to worry about a different instantiation or reference syntax. Anyone who has never seen this done before will not be too surprised this works, and will have little trouble understanding what is going on.
In order to keep things clean in Java in my code I always made inner classes static until I actually NEEDED the outer reference. That is not different than explicitly passing the reference to the outer object in the constructor when you find you need to, only the latter is always an explicit decision on the programmer.
That seems to me a good thing, but once more it's a matter of taste.
What are you talking about? Inner classes are fully supported in C#...
Unless you're talking about anonymous inner classes (a different animal, typically with a different purpose altogether when it comes to design motivation).
This seems to have been a matter of designer taste on the part of Hejlsberg. 2.0 should bring anonymous methods, which aims to solve the same type of problems anonymous classes did, in a neater way.
Hmm... you did say it is 'unlike any other Japanese animation', therefore implying 'any other Japanese animation' == Anime == crap.
Like the parent poster, without your clarification I would interpret this as ignorance on the fact that 'anime' != Dragonball & co, and that Miyazaki's work are not unique in being 'films' rather than cartoons.
Maybe they're not as amazing to your taste as Miyazaki's, but I would not classify the works of any of the following as fundamentally different: Grave of the Fireflies, Metropolis, Perfect Blue, Millenium Actress, Tokyo Godfathers, Voices of a Distant Star, etc. etc. (If you are not familiar with one of these films, I heartily recommend grabbing a copy, you will not regret it).
There's lot of material that can challenge the 'uniqueness' of Miyazaki's work.
Borrowing the parent's argument, It's just like live movies in the US: 90% is crap, and given a native market of crap, whatever is exported decreases the proportion of non-crap by an order of magnitude. US cinema to the rest of the world is not Citizen Kane, it's Lethal Weapon 7.
I happen to agree with you that in the west, Anime is a movement more than anything else, and I also agree the direction of that movement is not something I'd link Miyazaki's (or other's) works more than incidentally.
This is disappointing, because once upon a time I was introduced to anime with the argument that animation != cartoons+toys, and there is plenty of material to confirm this. I guess it just proved more lucrative and popular to import the cartoons+toys frenzy.
Unfortunately, treating Miyazaki's films as a 1-person exception keeps other outstanding work in obscurity.
Like the parent poster, I have always been flabbergasted at the horrible inefficiency of US public transportation (I also hail from more civilized lands where an automobile is not a living requirement).
Most of the industrialized, and not-so-industrialized world has had decent bus systems for decades that are not 'inherently slow', and sharing the road with cars has little to do with it except in cities with chronic traffic problems.
It's a matter of logistics: US cities just don't put the resources to have frequent or extensive routes because every citizen is assumed to need a car. Every working citizen sees the car as a necessity because no resources have been put into public transportation.
My paranoid side would imagine this was a way to boost consumer spending for the long decades that the automobile industry was the economic driver, but my rational side is says it's just plain dumb-ness.
Considering the interception in both cases still happens before reaching the network, I would agree with the parent poster that it is just not a Federal case.
Arguing about the functional equivalence does not nullify the point: if I put a voice recorder in your office to record your phone conversations, it is not wiretapping. Whether this recorder is in your phone or in the trash can, or if it's a lip-reading AI program analyzing your security cameara videos, the fact it's the same data shouldn't make a difference.
In any decent local legislation, however, it would be illegal under state law.
You mean that bit about electrometallurgical reprocessing? Did you miss the "specific current developments" part?
All they said about it was it was not being taken seriously, and maybe someone in the future will, and maybe that will work.
For that matter, genetically engineered bacteria that can thrive in radioactive materials and process waste into gold is not being taken seriously either. Damn the skeptics, hopefully in 100 years science will prove them wrong.
Sorry, that's really not more specific than the vague references to advances in reprocessing in the future and the hope that fuel will be in demand.
These are all potential avenues we know about, and have known about for some time, to no effect. Yes, this is due to the political and economical climate.
But they didn't make a good case for change in the political climate. No good reason to think the public will be more nuclear-friendly to support this research, when for half a century it has consistently become nuclear-unfriendly.
We have been expecting oil to run out for a long time, and people have been trying to sell nuclear as a safer, cleaner option to coal since the nuclear reactor was invented. True as it may be, people don't buy it.
If you're going to depend on the magical fairies of the future to fix your nuclear waste problem, it's funny to assume they will not do anything about the energy crisis problem, except to go back to nuclear in spite of the social pressures to use that as a last solution.
This type of speculation has no more substance than the hope that by the time we run out of oil, we'll come up with fusion, or whatever.
It's ignoring a current problem because we hope the future will take a shape that we like, 100 years from now. I'll take it seriously when I get my personal spaceship to the moon, or they release Duke Nuke'em Forever.
Also, a minor nitpick, but what IS a "Brain Scientist"?
Is that like an Eye Doctor? Or a Budget Man?
If you're going to bother to invent technical words (erototoxins) to replace real, existing, technical words (hormones, neurotransmitters et al), or to go ahead and talk about psychopharmacological implants... it would be sensible to name the specialty whose findings you're quoting (neurologists, psychiatrists, cognitive scientists, whatever).
Particularly if you're making the case that memory is brain-damaging sexual abuse (the informed consent bit).
By that logic, to avoid leaving traces in the brain of highly excitatory stimuli, all minors should be stored in sensorial deprivation tanks to be fed approved stimuli by their parents.
After reading the article, I found it sorely lacking in the "New Vision" part, but filled with a pletorah of maybes, could bes, perhaps, and hopefullys.
It's great that they're suggesting a decent Plan B if Yucca fails, but to state that failure of Plan A is the best outcome because some hypothetical future invention will make it obsolete is not very scientific.
To those with boundless faith in the progress of technology: it's not whether science advances at the same rate in the future, it's whether its direction can be predictable.
As of now, by early 20th century speculation, we were supposed to have safe nuclear reactors powering our flying cars, and spaceships moving tourists to the moon.
This article does not even substantiate the speculation with specific current developments in an avenue of research or two. It just makes the assumption someone will come up with something new, soon, that may have something to do with the problem.
Slashdot Mirror
That's because ID is a skeleton created to pass for a scientific theory to teach a very particular point.
Any powerful arguments have been neutered by pretending it is something it is not, and discarding what would most obviously weaken that point, or its acceptance as a curriculum topic.
There is a long tradition of philosophical ideas and theories based on Creationism in its diverse forms. This was a very mature debate (thousand-years old) in philosophy before it became a topic of science, and there is certainly enough substance to both present a debate to the fundamental assumptions of science, and influence the development of science itself in very profound ways.
Heck, I would argue that in order to understand why we accept science, this is a vital topic of study. Then again, I would argue that if we are to have critical thinking in high-school graduates, philosophy-training is vital, so I may be biased.
All of the interesting questions I have seen triggered by ID debate were old, interesting questions in biology that were already in intense study by scientists working in evolution.
I very much doubt ID has forced more self-analysis in these sciences than the gradualist-vs-saltationist or gene-vs-species selection debates, for example, which have been going on publicly strong (at least to untrained lay eyes) for decades.
On the contrary, I've often seen ID debates distort or silence the interesting debates in science and force researchers to play politics and present a unified front that plays to the caricature of evolution research presented by ID: the idea of darwinism as converntional wisdom that suffers no criticism or scientific analysis.
The positive change introduced by ID, I hope, is in the teaching of science, and by extension in correcting a fundamental misconception of science in the general public.
I think a significant source of the support for ID, and the accusations of hypocrisy against science, are due to a widening gap of communication and understanding on the most basic concepts between the average citizen and the people who do research. The scary thing is that this is not due to advanced concepts beyond the reach of a non-specialist, but on the very basic ideas of logic, science, objectivity, etc. The general population has a very post-modernist view of science in general, which is a concern considering current civilizations are so dependant on science, and said populations are not particularly post-modernist per se.
Based on the results, schools seem to be in the business of producing citizens trained in 'scientific facts' rathan than science as a discipline. From college and general interactions with people, I have gotten the impression that ID proponents are often quite correct complaining about evolution being taught as a 'final and complete truth' in US high-schools... the same, unfortunately, applies to practically everything else taught as science at that level too.
I don't know if this would be a problem of curriculum, methodology, or just the lack of engagements of students in the inquisitive process.
There is no fundamental difference between the way most people understand evolution vs ID. This does not mean ID is science, it means evolution is being understood as religion.
Rather than correcting a deficiency in the understanding of science by students, however, ID proponents just ask that their 'final and complete truth' be taught as well. That they do not see the fundamental difference between the two 'theories' speaks of their misunderstanding of science, but more important is that from the POV of a large and diverse demographic, they are objectively right.
From the blurb, I was expecting Zambonini to be mostly wrong, but it seems he's just putting the blame in the wrong place (mostly).
This sort of courses may not be useful to get a job, but they can be vital to doing your job well. And therefore, keeping it.
The information from courses like TOC and Algorithms, for example, are used regularly on the job: pretty much every time you code.
That does not mean you go and provide correctness-proofs and a full analysis of every code-path you write. That is too costly in most industries.
What comes 'for free' from someone who has this background is the ability when they look at the problem to discard many bad solutions before attempting them, identify costly/intractable problems that need better specification, and solving concrete problems with very general (proven) solutions.
He's right that there are other less-academic skills you can use to land a job, but I'd disagree that this is the responsability of a CS program. For many of the issues he brings up, it wouldn't even be the responsability of an Engineering program.
The career-path is the choice of the students, and their responsability. Although keeping the academic courses relevant is important, I wonder if there are as many complaints about Math majors learning too much Math and not enough business/management.
Assumption:
The role of a science university degree is NOT to provide all the information you will conceivably need in the industry (which is too broad and changes month).
Its role is to provide the student with the fundamental background and the skills for the student to identify what is specifically important from all that knowledge, be able to learn it by themselves, and then make new contributions to that knowledge.
Considering that:
- If students cannot educate themselves on technical specifics (a programming language, xml, etc) outside of the college curriculum, they will face difficulties in the real-world regardless of whatever courses they took.
- From the courses listed, one cannot say for sure, but it sounds you are in the right CS program.
Just make sure to complement your academic education with practical skills if your goal is to get an industry job.
- He's right about databases. They're vital in and out of the industry, and they put to use some skills otherwise often neglected.
A good CS curriculum will include at least 1 course in database fundamentals, with at least a non-trivial practical project.
- Taking a course because it mentions XML is total non-sense. There is no new deep theory behind XML, only minor technical decisions that certainly do not take a university course to learn.
While XML makes sense as a case study for a number of related areas (parsers, SE, databases, etc), there is nothing unique a student can't learn in a few hours.
If a new CS college hire cannot tell when to use DOM vs SAX after a 5 min. explanation on what the acronyms mean, then the problem is less with ignorance about XML and more with lack of those 'useless' CS fundamentals.
- He's right about students not going into SE, but that is as much the student's fault as the university. In my experience, SE courses are not very popular with undergraduates where they are offered. If your aim is to be a Software Engineer, use the options available in your school. Take them if that is what you want to do with your degree.
I don't know if this is just more common in the US, or my 'sample' was less random: but from what I have seen many universities provide either an SE program/sub-program or corresponding electives
If they're not available, learn on your own and do projects that use that knowledge. The main benefit of the SE courses I've seen is identifying the big problems and pointing out old solutions. The interesting stuff you have to learn by yourself anyway.
- Get real-world experience: internships, co-ops, part-time jobs. The most important
If you're talking about relatively small programs to solve very specific problems, I'd agree with you: having to apply 5 patterns likely means you chose the wrong ones. But for a big application there are plenty of problems that may or may not benefit from different patterns.
As a Patterns zealot, a book I'd recommend to most Pattern fanatics, as well as to any Pattern skeptic, is "Refactoring to Patterns", by Joshua Kerievsky.
It's a pretty good book on moving towards and (gasp!) away from design patterns based on application requirements and their actual usefulness, and warns frequently against the common bad habits of the Design Patterns zealot (everything needs a singleton, and a visitor, and...)
You keep using that word, I don't think you know what it means...
I doubt men are that repelled by advertisements...
I'd think men want anything that has sex in them, and are generally receptive to scenes that promote tribal behavior, if pop-culture is any indication.
Hence the popularity of memes originating in beer commercials.
I'd like to think people in general are receptive to clever amusement, advertising included; although that is a bit less substantiated, people do share such advertisements as interesting memes in spite of their corporate message.
E.g.: I'm currently not looking for a backup solution, but If I ever do, a company that hires John Cleese is more likely to get my money.
It's interesting how much agreement there was a few decades ago on future technology predictions.
Before that, they were all over the place: alien invasions, giant mutant plants and insects, space pirates flying in rockets to other planets.
But then most people started agreeing on the basics: flying cars, nuclear power in every home, giant monolithic computers controlling the government, with potential interruptions by nuclear winters from WWIII.
The details were fuzzy, but with this consensus clearly we were onto something.
I have to disagree, at least with the random part.
At the time I saw Evangelion, I found it disturbingly interesting because of its Gnostic themes and their attention to detail.
They can look like random mishmash to people unfamiliar with the themes and mythos of early christianity, but so would real early christian mythology, particularly the neo-platonist cults that would be most pertinent to this.
It takes a bit of research to realize the for how long these had an effect on both mainstream christian and non-christian theology (influences in kabbalah and sufi mysticism, for example), and how much effort and time it took to homogeinize christianity to the non-random mishmash understood by Westerners today.
This is not to say the intention of Evangelion was to provide a faithful or even deep treatment of gnostic or medieval kabbalistic themes. The series took its own deviations and developed its own mythos for dramatic purposes (something that was commonly accepted in these circles anyway), and was guilty of some symbol squandering (crosses galore).
But I don't doubt that at the very least the director did his homework, which is more than I would say of most entertainment productions.
It seems to me that often when people complain about the randomness of the Christian themes in this or other works they miss the point by applying a very 18th-20th century impression of the Christian mythos and its malleability.
Yes, that explains why there is a massive exodus from Cuba to most countries you mention, in spite of the immigration restriction many have put in place precisely to stop the cuban influx... and the obvious restrictions Cuba itself to stop people from leaving.
How many people from Mexico, Nicaragua, Panama, etc. are desperately trying to get into Cuba?
For those who want to move, how many restrictions do they have to face to actually leave? Include that when putting the numbers in perspective, it does not favor Cuba.
I doubt you have been in any of the countries you mentioned.
I'm not sure you even grasp the geography.
(Hint: Neither Haiti nor Colombia are central american countries)
The reactions of the people both inside and outside of Cuba who have seen land on both sides of the sea are a better judgement of quality of life than statistics. Cuba, like many communist countries, has a history of playing with the numbers when measuring its social and economic successes.
Thanks for the links to the papers. I was vaguely aware of this as a known problem but I haven't been following the research as closely as I would like the last couple of years.
I still avoid thinking of the problem as "lack of structure" because the structure is there... it's just documented in an unexpected location in the source code. But I'm very wary of the IDE dependency as the solution to that problem, partly because it is a very heavy dependency to take, and partly because it does not 'click' in my mind as the most elegant solution.
IDE support is also only a solution for the static weaving problem, as in AspectJ. Dynamic weaving has some very tempting advantages for a good set of problems, such as services provided by hosting environments.
I understand the reluctancy to limit the "aspect obliviousness" because it limits the power and flexibility of the construct; but I find it interesting that in other methodologies obliviousness is something we have often moved away from as we develop richer security and correctness models. Your own work on ArchJava was a removal of participant obliviousness in component interaction, if I remember correctly from my grad school days.
It seems to me that a limitation in power will be very difficult to avoid if we want to solve the problem. Forfeiting dynamic weaving and taking the IDE dependency may be the solution, or maybe it will be adopting an explicit Advice/Advisee contract and a richer security model. I'm just glad research is active on the problem.
I think you are missing my point: Lack of structure is the cause, not the problem. The problem is that from "just reading the source code" you cannot build a coordinate system to represent the state of your running process.
Invisibility creates the same problem, regardless of how structured is your invisible change. And that IS different.
Method overrides are both visible risk-points (you are the one calling the virtual method) and a well-known problem. That's part of the push for design-by-contract language features in research.
Even GOTO is a visible risk-point... they can make your coordinate system unmanageable by complexity or growth, but you are aware of the problem and can potentially grow your coordinate system to cover those cases on demand.
On typical AOP, the binding is defined by the advise, not by the pointcut. Your only hope of expanding you coordinates to know that you cover your code behavior is to include ALL aspects in your code as globals code snippets that can be injected in your code. With static weaving hopefully your aspect population, per project, is limited enough. With dynamic weaving, there is not even that hope.
One of the linked papers makes a very good point of comparing AOP not to GOTO, but to the declarative COME FROM which changes a piece of code after the fact.
No, but you are aware of the call to a virtual method, so by the semantics of the programming language you should always assume it can be overloaded and code to the documented contract (preconditions, postconditions, invariants and errors).
Depending on the language, parts of the contract may or may not be enforced, but you are aware of the risks in that line of code.
That was part of the point in the previous post:
Without doing the weaving explicitly so you can see this change, analyzing the code is hard or impossible. The problem is not readability, it is visibility. As you mention before AOP is well structured, and once the weaving is visible it is typically not that complex to read.
The problem is that you need special tools to SEE in the first place, and these tools have to take the whole project as a whole. This is is a break from previous methodologies where the IDE was a convenience... now it's an essential CASE tool that is part of your language: without it the code does not make sense.
And with dynamic weaving, your tool still cannot speculate on who may wrap your methods at runtime in the future.
Most or all of the problems would be moot if we restricted the flexibility of AOP as a general programming language methodology, but that requires a conscious change in direction in AOP, and more research on what limitations could we take without sacrificing the usefulness of AOP...
- Aspects which keep the method return invariant are safe, but they are a very limited us
As I pointed out previously, yes there are similar known issues in OOP, but they have been studied quite a bit and there are existing solutions.
Also, the points of code injection in OOP are far more evident because of their visibility in the calling source code as method invocations, so they can be part of your coordinate system. In AOP they are just not visible from the analyzed source code, so your coordinate system breaks.
AOP papers in general seemed to ignore the issue and present only the examples that benefit the most from AOP, and many practitioners end up seeing it as a panacea... it's good to see a change in that trend.
I'm not someone to dismiss AOP for this issue; this is a methodology I have been interested for a while now and had some direct research interest in it at some point. But before AOP can be embraced as part of mainstream development, we need to address the problems that arise when it is used in a suboptimal way, as it will when large teams use it for large projects.
I'm sure some solutions will arise, whether that translates into language-feature modifications or just best practice documentation, but we need to be looking at the problem.
As I mentioned in another post, I think this is a sign of maturity, more than weakness, in AOP. It means that it is taken seriously enough for non-toy projects for its compromises to become evident.
Funny, this is not the first time I heard of this complaint and, for example, I wouldn't think Anders Hejlsberg was afraid of learning a new language feature considering his career... (the question on AOP is asked within the first two mins if you don't want to watch the whole thing).
The concern predates the report for quite a bit, and from some reliable sources. This is not a surprise, as I would think the role of companies like forrester is to communicate trends like these, not to create them out of the blue.
You are right, programmers should choose the best tool for the task. But an issue with AOP as commonly proposed is that you can use the wrong tool and do the wrong task whether you choose it or not, because the weaving is not happening on your request (pointcut), but on the aspect's (advice).
Depending on the approach of the AOP framework this could be a risk at the team level (static weaving), or at the user level (dynamic weaving) because keeping track of all the aspects introduced by other people in your code is hard/impossible.
AOP based on declarative annotations could help a lot, but for dynamic weaving (which still can be extremely useful) the main problem doesn't go away.
Maybe providing limitations to the semantics of an aspect (in terms of invariants it must keep) would be a solution, but that would limit AOP to a non-general programming model, and for that we would have to define the classes of problems where it may be 'useful' or 'harmful', or provide a general way to define these limitations by the application (since we assume they are domain-specific).
In any case, this does not seem to me like the kind of criticism coming from people afraid of a "new thing".
Rather, it seems the kind of criticism a new technology faces when applied to 'real world' problems and projects, which is a good sign that AOP is taken seriously enough by mainstream development teams, and that there will be people working on solutions to these problems.
No, the problem with GOTO is that, as a consequence of being an unstructured flow control change, it makes it impossible to trust your reasoning about code because it destroys your ability to scope it.
..."
To quote: "... it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress
I think Dijkstra's point was that any construct that does this is harmful.
Structured constructs are typically less liable to do this, but only because they are visible and the structure is known.
AOP does have the ability to inject arbitrary code in your function that can change its semantics and you cannot see this when reading the affected code.
No matter how structured that change is, its invisibility makes it impossible to fully understand your code from the source code without 'weaving in' all the aspects explicitly. Like GOTO, it destroys your ability to scope your reasoning of the code to the local view.
As much as I love AOP for a class of problems, this is a very valid concern that needs to be addressed.
It's certainly not the first language featureset that faces this problem; OOP can deal with its own issues with design by contract, either through documented best practices or by enforcing it in the language. I haven't seen much in AOP there, beyond the absence of problematic examples (which would typically come from real-world use).
Well, the papers linked in the psot describe the basic problem well enough and they're not charging 250 bucks for the pdfs... not sure what other research results are included in the forrester report, but I doubt there's much you wouldn't find in published academic material if your time is worth less than that... or if you just enjoy reading the research itself.
I think this is due to:
I) Not everyone stresses out on tests, standarized or not.
Particularly in aptitude tests, many people do better because they don't care too much.
II) Some people are conditioned to 'high-stress test' situations, so that the situation becomes routine and they don't stress out.
If this is true, the second factor would suggest the standarized test culture is selective towards:
A)Individuals that train themselves specifically to take tests (with all those 'beat the SAT/GRE/GMAT' courses and books).
It is arguable if it is a good idea to favor this group, as the positive non-test-specific skills represented by this should be (normally) better represented by schoolwork.
B) Alumni from schools with methodologies centered on low-count, heavy-weight tests.
Once more it is arguable if this is the best educational methodology to select for.
Personally, most criticism I have seen against standarized tests has been very sophistic, but from what little information was in the article this does not seem to be the case.
From the point of view of an admissions board, I don't think it will ever be a reason to ignore the tests, just another thing to consider their weight when evaluating a candidate. Unfortunately, there are a lot of graduate programs that do not use personal interviews as part of the admission process.
Also, since we're talking of a standarized test, I don't think it even makes sense to worry about extreme outliers: they're likely to be considered differently anyway.
This is more likely to affect the larger population that does consistently better in less stressful circumstances but show 'normal' performance under pressure. If anything is affected, it would be the minimum bar for test scores, or the interpretation of a CV-vs-TestScore disparity.
You are correct, I should say that C# fully support static inner classes.
N amesTheseDays.privateMember.foo();
...
"Nested type" and "inner class" are, as far as I know, equivalent terms and the latter has been a common term used in both languages. However, this is the first time I know of someone who differentiates the two terms in practical use.
What makes the implicit "this.Outer" the essential feature of an "inner class" in your terminology? I'm also curious as to why you consider it such an important feature.
Once more this seems to be a matter of designer taste, but unlike anonymous inner classes, I do not see how this is particularly useful.
I have seen 2 broad categories where the reference to the outer class is useful:
- Inner classes for logic encapsulation in a complex class: passing the reference explicitly is no pain here, though.
- Anonymous inner classes: most useful because the class declaration itself is overkill, doing the constructor plumbing even more so.
I always saw the non-static inner class as a nice element of syntactic sugar that quickly gets out of control because it solves a non-problem if you ignore anonymous inner classes. In the process they complicate the language with special semantics and syntax for little need. Of course, once you bring this in to support anonymous inner classes it pays for itself. But the problem is that anonymous inner classes have almost always been a crufty solution themselves... 99% of the times I used them effectively they were functors and what I wanted was a method, not a full class.
Ignoring anonymous inner classes for a sec:
In Java, I do not have to pass an instance of my object to the inner class, so I get 'for free' the ability to write this (horrible) syntax:
int x= this.ExtremelyLongNameBecauseWeKnowClassesGetLong
If the class has a non-trivial size (which for non-anonymous classes can easily happen) or the reader of the code is not familiar with the special semantics of Java's non-static inner classes, it's not immediately obvious where this reference came from.
As a programmer I have to make an explicit decision to NOT keep an extra reference in my object. if I forget to put the static modifier, I get this dancing implicit this.Outer 'for free' too, when normally I just don't need and pollutes the contents of the object.
In C#, you have to explicitly decide you'll need a reference to your outer type, and then use it:
public MyFooInnerClass(MyBarOuterClass bar)
{ myBar = bar; }
int x = this.myBar.privateMember.foo();
The latter code seems to me more straightforward and readable, not depending on special semantics to know where myBar came from.
Sure, I have to pass the 'outer' object to the constructor myself instead of letting the compiler do it, but in exchange I don't have to worry about a different instantiation or reference syntax. Anyone who has never seen this done before will not be too surprised this works, and will have little trouble understanding what is going on.
In order to keep things clean in Java in my code I always made inner classes static until I actually NEEDED the outer reference. That is not different than explicitly passing the reference to the outer object in the constructor when you find you need to, only the latter is always an explicit decision on the programmer.
That seems to me a good thing, but once more it's a matter of taste.
What are you talking about? Inner classes are fully supported in C#...
Unless you're talking about anonymous inner classes (a different animal, typically with a different purpose altogether when it comes to design motivation).
This seems to have been a matter of designer taste on the part of Hejlsberg. 2.0 should bring anonymous methods, which aims to solve the same type of problems anonymous classes did, in a neater way.
Hmm... you did say it is 'unlike any other Japanese animation', therefore implying 'any other Japanese animation' == Anime == crap.
Like the parent poster, without your clarification I would interpret this as ignorance on the fact that 'anime' != Dragonball & co, and that Miyazaki's work are not unique in being 'films' rather than cartoons.
Maybe they're not as amazing to your taste as Miyazaki's, but I would not classify the works of any of the following as fundamentally different: Grave of the Fireflies, Metropolis, Perfect Blue, Millenium Actress, Tokyo Godfathers, Voices of a Distant Star, etc. etc. (If you are not familiar with one of these films, I heartily recommend grabbing a copy, you will not regret it).
There's lot of material that can challenge the 'uniqueness' of Miyazaki's work.
Borrowing the parent's argument, It's just like live movies in the US: 90% is crap, and given a native market of crap, whatever is exported decreases the proportion of non-crap by an order of magnitude. US cinema to the rest of the world is not Citizen Kane, it's Lethal Weapon 7.
I happen to agree with you that in the west, Anime is a movement more than anything else, and I also agree the direction of that movement is not something I'd link Miyazaki's (or other's) works more than incidentally.
This is disappointing, because once upon a time I was introduced to anime with the argument that animation != cartoons+toys, and there is plenty of material to confirm this. I guess it just proved more lucrative and popular to import the cartoons+toys frenzy.
Unfortunately, treating Miyazaki's films as a 1-person exception keeps other outstanding work in obscurity.
Bollocks.
Like the parent poster, I have always been flabbergasted at the horrible inefficiency of US public transportation (I also hail from more civilized lands where an automobile is not a living requirement).
Most of the industrialized, and not-so-industrialized world has had decent bus systems for decades that are not 'inherently slow', and sharing the road with cars has little to do with it except in cities with chronic traffic problems.
It's a matter of logistics: US cities just don't put the resources to have frequent or extensive routes because every citizen is assumed to need a car. Every working citizen sees the car as a necessity because no resources have been put into public transportation.
My paranoid side would imagine this was a way to boost consumer spending for the long decades that the automobile industry was the economic driver, but my rational side is says it's just plain dumb-ness.
Considering the interception in both cases still happens before reaching the network, I would agree with the parent poster that it is just not a Federal case.
Arguing about the functional equivalence does not nullify the point: if I put a voice recorder in your office to record your phone conversations, it is not wiretapping.
Whether this recorder is in your phone or in the trash can, or if it's a lip-reading AI program analyzing your security cameara videos, the fact it's the same data shouldn't make a difference.
In any decent local legislation, however, it would be illegal under state law.
You mean that bit about electrometallurgical reprocessing? Did you miss the "specific current developments" part?
All they said about it was it was not being taken seriously, and maybe someone in the future will, and maybe that will work.
For that matter, genetically engineered bacteria that can thrive in radioactive materials and process waste into gold is not being taken seriously either. Damn the skeptics, hopefully in 100 years science will prove them wrong.
Sorry, that's really not more specific than the vague references to advances in reprocessing in the future and the hope that fuel will be in demand.
These are all potential avenues we know about, and have known about for some time, to no effect. Yes, this is due to the political and economical climate.
But they didn't make a good case for change in the political climate. No good reason to think the public will be more nuclear-friendly to support this research, when for half a century it has consistently become nuclear-unfriendly.
We have been expecting oil to run out for a long time, and people have been trying to sell nuclear as a safer, cleaner option to coal since the nuclear reactor was invented. True as it may be, people don't buy it.
If you're going to depend on the magical fairies of the future to fix your nuclear waste problem, it's funny to assume they will not do anything about the energy crisis problem, except to go back to nuclear in spite of the social pressures to use that as a last solution.
This type of speculation has no more substance than the hope that by the time we run out of oil, we'll come up with fusion, or whatever.
It's ignoring a current problem because we hope the future will take a shape that we like, 100 years from now. I'll take it seriously when I get my personal spaceship to the moon, or they release Duke Nuke'em Forever.
Also, a minor nitpick, but what IS a "Brain Scientist"?
Is that like an Eye Doctor? Or a Budget Man?
If you're going to bother to invent technical words (erototoxins) to replace real, existing, technical words (hormones, neurotransmitters et al), or to go ahead and talk about psychopharmacological implants... it would be sensible to name the specialty whose findings you're quoting (neurologists, psychiatrists, cognitive scientists, whatever).
Particularly if you're making the case that memory is brain-damaging sexual abuse (the informed consent bit).
By that logic, to avoid leaving traces in the brain of highly excitatory stimuli, all minors should be stored in sensorial deprivation tanks to be fed approved stimuli by their parents.
It's the only way to avoid brain damage!
Agreed.
After reading the article, I found it sorely lacking in the "New Vision" part, but filled with a pletorah of maybes, could bes, perhaps, and hopefullys.
It's great that they're suggesting a decent Plan B if Yucca fails, but to state that failure of Plan A is the best outcome because some hypothetical future invention will make it obsolete is not very scientific.
To those with boundless faith in the progress of technology: it's not whether science advances at the same rate in the future, it's whether its direction can be predictable.
As of now, by early 20th century speculation, we were supposed to have safe nuclear reactors powering our flying cars, and spaceships moving tourists to the moon.
This article does not even substantiate the speculation with specific current developments in an avenue of research or two. It just makes the assumption someone will come up with something new, soon, that may have something to do with the problem.
I'm not sure about the numbers, but I have a very hard time believing the sun is "the most efficient disposal system we have".
There is a pretty high cost per ton in sending stuff "up there", even ignoring the risks (which imply extra costs).