Seems like event listeners ought to be registered as weak refs by default to prevent this sort of problem...
It's easy to imagine situations in which weak refs would be useful, but in practice, I've written a couple thousand lines of GUI code over the last several months, and I can't recall a single instance where I would I have preferred a weak reference over a strong one. In the vast majority of cases I want the listener to have the same lifetime as the object it listeners to. In all of the remaining cases, I want to dispose the listener at some definite time, and at that time I am able to unregister the listener. I know that isn't much experience, but I think it's enough to claim that weak refs should not be the default: if they were the default, I would have to do a lot of extra typing to ask for strong refs, and I would probably have a few subtle bugs where I accepted the default. Strong refs are the more common case, and they fail in much safer and more deterministic manner. (If you leak memory because of strong refs, you always leak memory, and you always leak the same amount for a given workload workload. If your listeners randomly disappear because you accidentally used safe refs, you may have a hard time reproducing it in testing.)
On the other hand, I can imagine situations where weak references would greatly simplify things. Those situations basically boil down to the following: the listener's role is to operate on a third object, whose lifetime is unpredictable, in response to listenee events. The listener weakly references the third object, and the third object strongly references the listener. When the third object becomes eligible for garbage collection, so does the listener. Of course, when the listenee is disposed, the listener continues to live because it is referenced by the third object, which may not be desired.
On one hand, they *could* use whatever known and tested solutions are successfully used by other datacenters. On the other, they could implement the wishful fantasies of a Slashdotter who has seen too many action movies. Decisions, decisions.
I think you mean the American public's tendency to look beyond power and even beyond law when deciding right and wrong. Societies that show automatic deference to money and power, regardless of how it is obtained, become corrupt, stagnant, inefficient societies. In free societies, the public has no problem accepting a scenario where the bad guy has money and the law on his side.
Of course, the idea's appeal is undoubtedly strengthened by factors of jealousy and frustrated ambitions, but a mindset that doesn't even admit the possibility of ill-gotten wealth, that regards "undeserved power" as an oxymoron, will be ruled by thugs and parasites.
Nobody except me? Check out the Eclipse newsgroups; it does happen to plenty of people. Regardless, there are a couple hundred different plugins distributed in official Eclipse releases, and you sure as hell don't use them all, so how would you know Eclipse is stable for all users?
As for data loss, the corruption happens in Eclipse's stored state in the.metadata directory. I don't keep my projects in the workspace, but from what I've read, people who do can just import their projects from a corrupt workspace into a new workspace without any loss. So, no data loss is involved, but if you invest a lot of time in setting up your workspace (customizing lots of settings, arranging perspectives, etc.) it can be a pain in the ass. I use the basic Eclipse RCP install (Europa) with one third-party plugin (PyDev, which is rock-solid AFAIK) and only a handful of non-default preference settings, so it's just an annoyance for me.
The only non-Eclipse plugin I have installed is PyDev, and I only have eight or nine plugin projects in my workspace, all but four of which are binary plugin projects that wrap third-party libraries. The application I'm working on is fairly simple. Eclipse should be able to handle it easily.
The workspace-corrupting crashes seem to happen while I'm manipulating GUI components (opening submenus, expanding trees, etc.) whereas long resource-intensive operations like product exports produce the apparently harmless (but annoying) out-of-memory and PermGen errors. Based on that I would guess that corruption happens when a bug in native code crashes Eclipse while it's updating state. I'm using gtk2 x86 Linux; maybe the native code layer is more stable on your platform.
Also, though I'm not sure it's relevant, I should mention that to test my app, I always export it rather than launching it from Eclipse. I started doing this a month ago for unrelated reasons, and it hasn't improved Eclipse's stability.
Yes, absolutely. I maintain a separate Eclipse install as my target platform and don't run any of my own plugins in the IDE. The only non-Eclipse plugin installed in my IDE is PyDev. I keep my projects outside the workspace; all the config files for the plugins I develop are kept in the project directories and versioned. Nothing is kept in the workspace except internal state maintained by Eclipse and its plugins. When Eclipse gets borked, I just create a new workspace and recreate all my projects, pointing them at the same project directories and same files as with the corrupted workspace. In other words, nothing I create or manage has to be fixed to get Eclipse working again.
Some developers who have a lot to lose from throwing away their workspace state have gone to a great deal of trouble to figure out which Eclipse workspace files to delete to solve certain problems; they'll look at the error log and go fishing around in the.metadata directory to try to fix things. Deleting the entire.metadata directory fixes almost anything, but that's tantamount to creating a new workspace.
I'm using Eclipse to develop an RCP app. The Eclipse platform provides a lot of functionality to build on, and aside from a slow start-up, it doesn't cause any sluggishness or instability in my app.
The Eclipse IDE, on the other hand, is infuriating. I have currently have workspaces named 2007-10-04, 2007-10-11, 2007-10-19, 2007-10-21, and 2007-10-25 because that's how often Eclipse irretrievably corrupts my workspaces. I've become so used to it that instead of deleting and replacing the corrupted workspace, I just create a new one and periodically delete all the corrupted ones.
Not to mention the constant out-of-memory and PermGen errors. I bumped up the startup values for memory and permgen, but I still have to restart Eclipse every couple of days.
Still, using the Eclipse IDE is an acceptable sacrifice to be able to program on the Eclipse platform and take advantage of its amenities. Next time I start a new project of this kind, I may try NetBeans (just to see if the grass is greener,) but I probably wouldn't consider writing a Java GUI app from scratch. I would write it on top of the Eclipse platform or something similar. It's worth it to get things like application update functionality for minimal work.
It's a graphics system in the same spirit as LOGO. Kids might not even realize they're programming, which might be a handy feature with some kids, especially older ones. Teachers should check it out.
So really, LOGO wasn't all that "good". Why then does it have a "following"? Is it just one of those "touchy/feely" ideas that where hatched as a way to "enlighten" the world, but ultimately fail the "any shred of practical use" test?
A "practical use" test would rule out action figures, holes in the backyard, wading pools, jungle gyms, Hardy Boys mysteries, and basically everything else that a seven-year-old touches. If I were a troll, I would ask, "Why do you hate childhood?"
The great thing about LOGO is that the turtle graphics system somehow prompts kids to start challenging themselves with puzzles that require geometric reasoning to answer. It's a lot of fun, and they love the fact that everyone can see what they're doing. The turtle graphics commands are much cooler than plotting things using pixel coordinates. They present very little barrier between conception and execution, whereas plotting in a pixel-based coordinate system is lame and painstaking.
I agree with this, both from my personal experience and the experience of my parents as teachers. My father teaches history at an extremely unselective college, and he never, or rarely, has students that struggle with historical concepts. Instead, the ones who fail are the ones who simply can't read well enough to get a decent exposure to the material, and can't read and write well enough to provide reasonable answers on written tests, even when they have gleaned sufficient understanding from lectures and films.
My mother taught high school math, mostly geometry, and she always said that her students would find it much easier to learn geometry if that's ALL they were learning -- but, in fact, she had to spend a great deal of time tutoring them on basic algebra. A lack of confidence in basic algebra makes it impossible to do anything with geometry except Euclid-style proofs, so inability to do algebra robs kids of the opportunity to do "easy" geometry problems to get their confidence up and build their basic understanding.
Not to mention that in both learning and (especially) in practical application, it is often necessary to know the underlying building blocks much better than the more advanced techniques before the advanced techniques become even minimally useful. For example, in order to do elementary calculus, it is necessary to be fluent in basic algebra. The assumption that a passing ability at algebra is a sufficient foundation for a passing ability at calculus is false and harmful (and nominally disbelieved by educators,) yet it is implicit in the structure of school curricula.
Also, you need to decide how far in math you need to go. For calculus not all books are created equal. Find a simple book that has easy to understand examples but does not go too far. Make sure it has a few chapters on limits only- you need to know these to know calculus.
I agree with the recommendation to start with books that cover less material, for a slightly different reason. Introductory books focus all their attention on getting you from point A to point B. Advanced books, working with similar amounts of space, must take you from A to B to C to D and beyond. Obviously they have to skimp on how to get from A to B, and they don't have room for lots of easy problems to help you get from A to B.
Also, most math books are written to serve as textbooks for classroom courses. The scope of the book is assumed to be proportional to the pace of the course, which is assumed to be proportional to the preparation and aptitude of the students. If you've always had difficulty, you should start with books that contain less material, even if you hope to move to more advanced topics eventually. The introductory books will cater better to your current needs. You can always replace them with more advanced books later.
The harder the math is, and the harder it is for you, the more problems you need to work. Obviously the "understanding" part is necessary, too, but sometimes understanding comes in dribs and drabs, and often it only comes after much experience. After working many problems, you suddenly see the pattern (Aha!) that the teacher or textbook was trying to explain to you. Educators sometimes assume that if you don't get it immediately, the only remedy is to try a different teaching method (tactile learning, culturally appropriate stories, and whatever else they can come up with.) That's simply wrong -- don't get discourage if you don't immediately understand something without any practice. You should use whatever means of learning and understanding works best for you, but it just takes a while for some things to sink in. (Different things present difficulties for different people.) Sometimes too many ways of explaining something are just confusing and overwhelming -- sometimes you just have to work through problems over and over again until it finally clicks.
Plus, understanding does not guarantee facility with solving problems, and facility with solving problems is a very large advantage when it comes to the rest of your education. Consider the significance of calculus to learning college physics: If you're slick with calculus problems, you spend most of your time thinking about physics, and you actually get a deeper understanding of calculus in the process. If you have a hard time solving calculus problems, then you don't have any time to learn much about physics, because you spend all your time struggling with the calculus. I'm sure the same thing applies to economics. "Understanding" of calculus concepts won't save you if you have to spend eight hours struggling to solve the math problems in your econ homework, while your classmates knock out the math in two hours, spend two hours discussing the concepts with each other, and then spend four hours drinking and chasing women. You work twice as much, and they're still ahead. (Plus they have more fun and are fresh and energetic the next day.)
So, work problems. Working problems helps you understand things in the first place, helps cement your understanding, and helps you get faster and more confident in your work, which enables you to work and learn more efficiently.
I agree. Sometimes it's the trivial stuff where jargon is the most vital. When you have three enhancements to make for the next release, and they all increasing throughput by making the dinklewhacker more efficient, and your boss has no idea how the dinklewhacker works, it's extremely helpful to give each one a distinctive name early on so you can just say,
Me: "I'm working on the Fonz Blueberry Crepe; it'll be done tomorrow. The Baconmobile was underscoped and might take weeks."
Boss: "Okay. I'll let Acme know."
But my boss despises jargon. He wants everything to be described in meaningful words, and if the distinctions are too slight for him to comprehend, he gets angry. So we have conversations like this:
"You know the one where the dinklewhacker's cache fills up with redundant entries? That one will be fixed tomorrow."
"Wait... that one that makes performance better, right?"
"Um, yeah...."
"That's the one that we absolutely must have in the next release for Acme."
"Um, actually, I'm not sure about that...."
"Oh, no, they definitely need it. What's the other thing you're working on?"
"Ummmm... whatever. The other one is the one where the dinklewhacker's cache size is inappropriate when the wind blows from the south."
"Yes, that one will be done tomorrow. You just told me."
"Actually, no."
"What the hell are you talking about? You just said it. Are you trying to set a world record for violating your own promises?"
"That's not what I said...."
"I'm not stupid; I understand English. Just speak in plain terms for me instead of this programmer mumbo-jumbo."
"Ummmmmmmmmm.... See, for the first one, the cache size would be fine, except for the fact that we fill it up with redundant data."
"Well, there's an obvious fix to that. We stop putting redundant data in it. Why wasn't this fixed already?"
"Uh, that fix will be done tomorrow. Then there's another case where under certain conditions we badly miscalculate the amount of data that needs to be cached, making the cache effectively useless."
"How is that different?"
"Instead of caching the wrong data, we cache the right data, but not enough of it."
"How can it be the right data if we are throwing away data we should be caching? You obviously don't understand this enough to be working that it."
It isn't the AI's fault. If you don't enjoy playing "well" and would rather use a strategy that the game doesn't reward, then the game just isn't designed to your tastes. A friend of mine gave up playing AoE2 against me because he didn't like the way you have to play to win. Well-rehearsed economic expansion, early reconnaissance, clever raids, harassment, *always* having a plan to counterattack and protect your villagers in case of a raid, predicting the long-term course of the game based on the abundance of different resources on the board, harassment building, he wanted none of it. He just wanted to build big beautiful armies and stage a climactic battle.
The one time the game went his way was also the last time we played. We were separated from each other by a wide strip of forest that we had to chop through before we could fight. That gave him time to construct a pretty fortress and a grand army and prepare for battle. He marshalled a magnificent army built around high-gold-value mounted units on a map with very little gold and lots of wood. A decent number of his high-value units survived the initial battle, and he thought it was just a matter of mopping up. He didn't believe me when I told him he was losing. The mopping up phase turned into a glorious slaughter as I ramped up production of villagers and pikemen (no-gold-cost anti-mounted units) so fast that he simply couldn't butcher them fast enough. With the humongous amount of wood I had (because of all the chopping we had to do to breach the barrier between us) I built barracks and town centers all over the board, mostly undefended except for a few walls, and he couldn't destroy those fast enough either. Replacing his own units was uneconomical because he had to sell wood at rock-bottom prices to get gold. His no-gold units were poorly upgraded, and mine were fully upgraded. He couldn't attack by building because my cheap, weak pikemen were swarming all over the board; his villagers needed an escort to go anywhere.
Afterwards I explained all that to him, and he said, "Why the hell did they make a game where you have to think about all that stupid shit when all you really want to do is have a war?"
Bots also have a terrible inability to fully commit to a strategy or to change strategies quickly. A good short-term RTS strategy often involves inflicting terrible damage through a phase of committed, unbalanced, unsustainable action that also damages the attacker's civilization but leaves him in a position to recover faster than the opponent.
If current RTS bots resemble their cousins from five or ten years ago (I haven't played in a while,) an emotionally-balanced bot would take a bold, successful strategy and "balance" all of the effectiveness out of it, leaving a milquetoast strategy that does no harm to his own civilization and usually no harm to the other guy's civilization, either.
I tried that once - buying a cheap pair of shoes. I ended up with tendonitis in my foot and had to hobble around for two weeks until it cleared up. Threw out the shoes and went back to a quality pair.
Seconded. Cheap athletic shoes just don't cut it for me; I get overuse injuries if I try to maintain the same activity level I have in my $80-$90 shoes.
I also got terrible blisters and knee soreness (caused by an awkward gait) from a cheap pair of hiking boots that just wouldn't unstiffen. Not only did they not unstiffen even after trying every bizarre home remedy in the book (running over them with a car, etc.) but they disintegrated the third time I wore them. The sole on one boot started coming off with five miles left in a thirty mile hike, and by the time I finished the hike, it was halfway off and flopping with each step.
By contrast, I could throw my nice Vasque hiking boots on right now, despite having not worn hiking boots in months, and hike all day without getting a single blister. They cost more than the cheap pair (~$150 vs ~$60) but they've protected my feet well, they don't take long to break in, and they provide many more miles per dollar.
And when it will expand a bit, offer some serious variety, and someone figures there's a market for something that underpowered with an oversized battery and an SXGA+ screen, THAT is when things'll get interesting.
I disagree; it won't be very interesting at all. Light weight, durability, power efficiency (which requires a relatively modern mobile processor,) and a nice screen drive up the cost so much that upgrading to an overkill midrange processor doesn't really affect the price. If the price premium between "adequate for ssh, remote desktop, and most web browsing" and "adequate for anything I can do on a desktop" is only $100, what first-world person would be excited about the cheaper option?
But they could sue other not-for-profit enterprises into oblivion. Surely that would help somehow. I mean, it's not quite coming to mind how, but I'm pretty sure it almost always helps. Maybe they could sue the people who buy the computers and the kids who end up using them, too.
Anyway, I'd take the time to break it down and explain it to you, but I have to go prepare a Powerpoint presentation for my finance class.
A better analogy is the guy who goes to college and meets a bunch of smart, sexy, fascinating women [named Haskell, Erlang, and Lisp] and then lets his parents [college loans] pressure him into marrying a dull hometown girl [named COBOL] with a dowry [a job offer] and good family connections [predictable future employment.]
Have you ever known anybody to say: "There are just too many girls to choose from, I guess I'll go hide in the basement."?
Yes, though they're saying it with their actions. And the people that say it are many, maybe most, single men.
I think an overabundances of choices accounts for lots of single apathy, but not when it comes to people sitting at home. Here's what I've seen (or guessed) about chronically dateless guys I've known (and been):
They have a firm idea of what they want and ignore every woman who doesn't qualify. A surfeit of choices can make people believe that any insanely detailed fantasy will be realized sooner or later, so this one can be chalked up to choice overload.
Their behavior deters women from expressing interest, and they quite sensibly decide not to press women who don't show interest.
They're so inexperienced that they can't recognize interest, which has the same effect as 2.
They're too proud to date the women who show interest in them.
They're depressed or have other mental problems.
The guys who have a surfeit of choices are usually out there enjoying them, maybe not by screwing everything that winks at them, but by socializing and enjoying the mutual exchange of attention.
(OT Male geek loneliness horse race! 2 comes out of the gate early, asserting a strong lead well before puberty. 3 quickly comes galloping up to share the lead by trapping cautious, self-conscious guys who won't move without knowing and can't learn without moving. 2 falls down immediately among non-geeks but maintains its position on the geek track by afflicting younger guys who can't express confidence because they're paranoid about accidentally seeming like smug assholes. 4 holds steady behind 2 and 3, seeming to bide its time. But it's a long race! 2, 3, and 4 steadily tire as geeks escape their clutches through alcohol and other drugs. 5 is the slowest horse on the track, but he's also the only one maintaining his speed. In fact, he's accelerating! He seems to be feeding off the cumulative effects of 2, 3, and 4. At age 35, 5 makes his move and surges into the lead! It's all #5 down the back stretch! And yes, at the finish line, when everyone is old and wrinkly and it's too late to care, 5 is the only horse left on his feet. What a race, ladies and gentlemen. Let's hear it for mental illness. Um... damn, that was a downbeat horse race. Let me emphasize that even though lots and lots of geeks were harmed in the making of this race, most of them were pastured out to stud while they were still young enough to enjoy it.)
The delay isn't because of multiple cores or processors, it's because of kindergarten design mistakes in a certain kind of architecture, and it's been a solved problem for a long time.
It's a solved problem if you're a smart programmer sitting down to write a program. It isn't a solved problem if you need a simple rich client and somehow want to get out of doing it yourself:-) That isn't to say I don't work with bright developers, but they don't want to do the boring work either. Writing simple clients for various internal systems is boring work, and boring work is supposed to be handled by less capable people. A simple concurrency framework that makes it easy to follow the rules would make that possible. It would also enable better developers to dash out a working app without even thinking, which is an advantage that's easy to underestimate.
From what I've seen so far, a lot of these libraries are much like logging or unit testing frameworks: sure, you can use one, but it's almost as much effort as just incorporating the equivalent functionality in your design from scratch.
That's what I normally do when I need multithreading for throughput; I write a nice high-level API that just happens to map perfectly to my needs, and I implement it using locks, mutexes, and conditions. It works, but it feels a bit like writing my own linked list implementation. I'd like to have a menagerie of well-polished frameworks that are each a decent match for a large class of problems.
I always find it amusing (in a sad kind of way) how people talk about Herb Sutter's "call to action" over this. It's not that I've got anything against Herb himself: he's a decent writer, an excellent speaker, and a guy who can use the word "expert" legitimately in areas like C++. But it's also not like he's the first guy to notice that modern desktop computer architectures have been heading for parallelisation rather than increased speed for several years now.
Despite being right in the thick of this culture shift myself -- I'm sure I'm not the only one here who has been talking about this for a while, and is just seeing management catch up -- I don't think this is going to be that big of a deal for most people.
There are two reasons everybody talks about it. First, like you say, he is an excellent writer, and it's a widely-read article, so it's a quick way to make an offhand reference to the idea. Secondly, The architectural shift may have been old news, but the big splash he made was his prediction that yes, it *will* be a big deal for most programmers. It isn't an uncontroversial statement. He disagrees with your assessment that most programmers will be able to opt out of concurrent programming.
Your average desktop PC is more than powerful enough for most things that most people do with it: Internet communications, writing documents, working with databases, shop floor software, and the like. As long as the operating system is reasonably smart about scheduling, the guys writing these common types of applications don't really have to know anything about multithreading, locking, message passing, and all that jazz.
This is the basis of the disagreement. My desktop has plenty of power, but too often I see apps balk or become unresponsive because of poor handling of concurrency. Even popular, high-profile apps with lots of resources behind them occasionally suffer, and less-used apps can be quite horrible about chronically locking up for a few seconds as you go about your work. The hardware can't be blamed when an application can't keep up with a human user wielding a mouse and keyboard. When several applications are being used at the same time, the OS can be held partly responsible, but when you're using a single application, there's no question. The problem is poor handling of concurrency by programmers.
The effects of the inability to handle concurrency were visible as soon as multithreaded GUI systems hit the corporate desktop. The average corporate coder simply can't write a reliable and responsive GUI application, so as soon as web programming emerged as an alternative, corporate development abandoned the rich client. Now almost every internal business application gets shoehorned into a web interface. Rich clients are notorious for having terrible performance, real and/or perceived, and it isn't because the actual computing workload exceeds the capacity of the hardware. It's because of poor programming. (I admit, half the time it's because programmers clog up the network with data. The other half of the time, it's because concurrency handling in the GUI sucks.)
As to what those conventions are, I just don't buy the whole "choice overload" theory. There are relatively few basic models for parallel processing: for example, you can have no shared state and communicate only through message passing, or you can have shared state. In the latter case, you then have the question of how to make sure that the sharing is safe, which leads to lock-based or lock-free approaches. Funky toys like transactional memory run at a slightly higher level than this, but they are ultimately constructed from the same building blocks, and again there are only a small number of approaches at this level to consider.
I don't think those building blocks are what people are calling a framework in this case; they mean something higher-level and more concrete that has design implications for the rest of the system, rather than being moldable into any design. That's why there are so many of them. Consider the multiplicity of logging frameworks for C++, despite them all being made out of file handles and objects.
Because there is no one true way to write a parallel program (it really depends on the algorithm), there will always be multiple frameworks to choose from. O well! The people who write parallel programs are typically smart enough to deal with excessive choices. (No comment on others).
You're right; there's nothing more tragic than watching a programmer butcher his well-written program in a futile attempt to make it fit the only concurrency model he knows. Closely associating a language with a single, well-designed concurrency framework would at best do the same thing for it that Rails did for Ruby: bring it a flurry of popularity in the short run and damage its reputation in the long run as people doggedly apply the framework to unsuitable problems and blame the language for the results.
On the other hand, at some point we're all supposed to face up to the end of the free lunch, and a fad for an exotic kind of concurrency might be a clumsy, spasmodic step in the right direction.
Slashdot Mirror
On the other hand, I can imagine situations where weak references would greatly simplify things. Those situations basically boil down to the following: the listener's role is to operate on a third object, whose lifetime is unpredictable, in response to listenee events. The listener weakly references the third object, and the third object strongly references the listener. When the third object becomes eligible for garbage collection, so does the listener. Of course, when the listenee is disposed, the listener continues to live because it is referenced by the third object, which may not be desired.
On one hand, they *could* use whatever known and tested solutions are successfully used by other datacenters. On the other, they could implement the wishful fantasies of a Slashdotter who has seen too many action movies. Decisions, decisions.
I think you mean the American public's tendency to look beyond power and even beyond law when deciding right and wrong. Societies that show automatic deference to money and power, regardless of how it is obtained, become corrupt, stagnant, inefficient societies. In free societies, the public has no problem accepting a scenario where the bad guy has money and the law on his side.
Of course, the idea's appeal is undoubtedly strengthened by factors of jealousy and frustrated ambitions, but a mindset that doesn't even admit the possibility of ill-gotten wealth, that regards "undeserved power" as an oxymoron, will be ruled by thugs and parasites.
Nobody except me? Check out the Eclipse newsgroups; it does happen to plenty of people. Regardless, there are a couple hundred different plugins distributed in official Eclipse releases, and you sure as hell don't use them all, so how would you know Eclipse is stable for all users?
.metadata directory. I don't keep my projects in the workspace, but from what I've read, people who do can just import their projects from a corrupt workspace into a new workspace without any loss. So, no data loss is involved, but if you invest a lot of time in setting up your workspace (customizing lots of settings, arranging perspectives, etc.) it can be a pain in the ass. I use the basic Eclipse RCP install (Europa) with one third-party plugin (PyDev, which is rock-solid AFAIK) and only a handful of non-default preference settings, so it's just an annoyance for me.
As for data loss, the corruption happens in Eclipse's stored state in the
The only non-Eclipse plugin I have installed is PyDev, and I only have eight or nine plugin projects in my workspace, all but four of which are binary plugin projects that wrap third-party libraries. The application I'm working on is fairly simple. Eclipse should be able to handle it easily.
The workspace-corrupting crashes seem to happen while I'm manipulating GUI components (opening submenus, expanding trees, etc.) whereas long resource-intensive operations like product exports produce the apparently harmless (but annoying) out-of-memory and PermGen errors. Based on that I would guess that corruption happens when a bug in native code crashes Eclipse while it's updating state. I'm using gtk2 x86 Linux; maybe the native code layer is more stable on your platform.
Also, though I'm not sure it's relevant, I should mention that to test my app, I always export it rather than launching it from Eclipse. I started doing this a month ago for unrelated reasons, and it hasn't improved Eclipse's stability.
Yes, absolutely. I maintain a separate Eclipse install as my target platform and don't run any of my own plugins in the IDE. The only non-Eclipse plugin installed in my IDE is PyDev. I keep my projects outside the workspace; all the config files for the plugins I develop are kept in the project directories and versioned. Nothing is kept in the workspace except internal state maintained by Eclipse and its plugins. When Eclipse gets borked, I just create a new workspace and recreate all my projects, pointing them at the same project directories and same files as with the corrupted workspace. In other words, nothing I create or manage has to be fixed to get Eclipse working again.
.metadata directory to try to fix things. Deleting the entire .metadata directory fixes almost anything, but that's tantamount to creating a new workspace.
Some developers who have a lot to lose from throwing away their workspace state have gone to a great deal of trouble to figure out which Eclipse workspace files to delete to solve certain problems; they'll look at the error log and go fishing around in the
I'm using Eclipse to develop an RCP app. The Eclipse platform provides a lot of functionality to build on, and aside from a slow start-up, it doesn't cause any sluggishness or instability in my app.
The Eclipse IDE, on the other hand, is infuriating. I have currently have workspaces named 2007-10-04, 2007-10-11, 2007-10-19, 2007-10-21, and 2007-10-25 because that's how often Eclipse irretrievably corrupts my workspaces. I've become so used to it that instead of deleting and replacing the corrupted workspace, I just create a new one and periodically delete all the corrupted ones.
Not to mention the constant out-of-memory and PermGen errors. I bumped up the startup values for memory and permgen, but I still have to restart Eclipse every couple of days.
Still, using the Eclipse IDE is an acceptable sacrifice to be able to program on the Eclipse platform and take advantage of its amenities. Next time I start a new project of this kind, I may try NetBeans (just to see if the grass is greener,) but I probably wouldn't consider writing a Java GUI app from scratch. I would write it on top of the Eclipse platform or something similar. It's worth it to get things like application update functionality for minimal work.
It's a graphics system in the same spirit as LOGO. Kids might not even realize they're programming, which might be a handy feature with some kids, especially older ones. Teachers should check it out.
http://www.contextfreeart.org/
A "practical use" test would rule out action figures, holes in the backyard, wading pools, jungle gyms, Hardy Boys mysteries, and basically everything else that a seven-year-old touches. If I were a troll, I would ask, "Why do you hate childhood?"
The great thing about LOGO is that the turtle graphics system somehow prompts kids to start challenging themselves with puzzles that require geometric reasoning to answer. It's a lot of fun, and they love the fact that everyone can see what they're doing. The turtle graphics commands are much cooler than plotting things using pixel coordinates. They present very little barrier between conception and execution, whereas plotting in a pixel-based coordinate system is lame and painstaking.
I agree with this, both from my personal experience and the experience of my parents as teachers. My father teaches history at an extremely unselective college, and he never, or rarely, has students that struggle with historical concepts. Instead, the ones who fail are the ones who simply can't read well enough to get a decent exposure to the material, and can't read and write well enough to provide reasonable answers on written tests, even when they have gleaned sufficient understanding from lectures and films.
My mother taught high school math, mostly geometry, and she always said that her students would find it much easier to learn geometry if that's ALL they were learning -- but, in fact, she had to spend a great deal of time tutoring them on basic algebra. A lack of confidence in basic algebra makes it impossible to do anything with geometry except Euclid-style proofs, so inability to do algebra robs kids of the opportunity to do "easy" geometry problems to get their confidence up and build their basic understanding.
Not to mention that in both learning and (especially) in practical application, it is often necessary to know the underlying building blocks much better than the more advanced techniques before the advanced techniques become even minimally useful. For example, in order to do elementary calculus, it is necessary to be fluent in basic algebra. The assumption that a passing ability at algebra is a sufficient foundation for a passing ability at calculus is false and harmful (and nominally disbelieved by educators,) yet it is implicit in the structure of school curricula.
I agree with the recommendation to start with books that cover less material, for a slightly different reason. Introductory books focus all their attention on getting you from point A to point B. Advanced books, working with similar amounts of space, must take you from A to B to C to D and beyond. Obviously they have to skimp on how to get from A to B, and they don't have room for lots of easy problems to help you get from A to B.
Also, most math books are written to serve as textbooks for classroom courses. The scope of the book is assumed to be proportional to the pace of the course, which is assumed to be proportional to the preparation and aptitude of the students. If you've always had difficulty, you should start with books that contain less material, even if you hope to move to more advanced topics eventually. The introductory books will cater better to your current needs. You can always replace them with more advanced books later.
The harder the math is, and the harder it is for you, the more problems you need to work. Obviously the "understanding" part is necessary, too, but sometimes understanding comes in dribs and drabs, and often it only comes after much experience. After working many problems, you suddenly see the pattern (Aha!) that the teacher or textbook was trying to explain to you. Educators sometimes assume that if you don't get it immediately, the only remedy is to try a different teaching method (tactile learning, culturally appropriate stories, and whatever else they can come up with.) That's simply wrong -- don't get discourage if you don't immediately understand something without any practice. You should use whatever means of learning and understanding works best for you, but it just takes a while for some things to sink in. (Different things present difficulties for different people.) Sometimes too many ways of explaining something are just confusing and overwhelming -- sometimes you just have to work through problems over and over again until it finally clicks.
Plus, understanding does not guarantee facility with solving problems, and facility with solving problems is a very large advantage when it comes to the rest of your education. Consider the significance of calculus to learning college physics: If you're slick with calculus problems, you spend most of your time thinking about physics, and you actually get a deeper understanding of calculus in the process. If you have a hard time solving calculus problems, then you don't have any time to learn much about physics, because you spend all your time struggling with the calculus. I'm sure the same thing applies to economics. "Understanding" of calculus concepts won't save you if you have to spend eight hours struggling to solve the math problems in your econ homework, while your classmates knock out the math in two hours, spend two hours discussing the concepts with each other, and then spend four hours drinking and chasing women. You work twice as much, and they're still ahead. (Plus they have more fun and are fresh and energetic the next day.)
So, work problems. Working problems helps you understand things in the first place, helps cement your understanding, and helps you get faster and more confident in your work, which enables you to work and learn more efficiently.
If humans didn't have to do all that laboriously by hand (click... click... click... click...) then what good would all those certifications be?
;-)
Let's hope the AFL-CIO never gets interested in technical issues
It isn't the AI's fault. If you don't enjoy playing "well" and would rather use a strategy that the game doesn't reward, then the game just isn't designed to your tastes. A friend of mine gave up playing AoE2 against me because he didn't like the way you have to play to win. Well-rehearsed economic expansion, early reconnaissance, clever raids, harassment, *always* having a plan to counterattack and protect your villagers in case of a raid, predicting the long-term course of the game based on the abundance of different resources on the board, harassment building, he wanted none of it. He just wanted to build big beautiful armies and stage a climactic battle.
:-)
The one time the game went his way was also the last time we played. We were separated from each other by a wide strip of forest that we had to chop through before we could fight. That gave him time to construct a pretty fortress and a grand army and prepare for battle. He marshalled a magnificent army built around high-gold-value mounted units on a map with very little gold and lots of wood. A decent number of his high-value units survived the initial battle, and he thought it was just a matter of mopping up. He didn't believe me when I told him he was losing. The mopping up phase turned into a glorious slaughter as I ramped up production of villagers and pikemen (no-gold-cost anti-mounted units) so fast that he simply couldn't butcher them fast enough. With the humongous amount of wood I had (because of all the chopping we had to do to breach the barrier between us) I built barracks and town centers all over the board, mostly undefended except for a few walls, and he couldn't destroy those fast enough either. Replacing his own units was uneconomical because he had to sell wood at rock-bottom prices to get gold. His no-gold units were poorly upgraded, and mine were fully upgraded. He couldn't attack by building because my cheap, weak pikemen were swarming all over the board; his villagers needed an escort to go anywhere.
Afterwards I explained all that to him, and he said, "Why the hell did they make a game where you have to think about all that stupid shit when all you really want to do is have a war?"
Different strokes for different folks
Bots also have a terrible inability to fully commit to a strategy or to change strategies quickly. A good short-term RTS strategy often involves inflicting terrible damage through a phase of committed, unbalanced, unsustainable action that also damages the attacker's civilization but leaves him in a position to recover faster than the opponent.
If current RTS bots resemble their cousins from five or ten years ago (I haven't played in a while,) an emotionally-balanced bot would take a bold, successful strategy and "balance" all of the effectiveness out of it, leaving a milquetoast strategy that does no harm to his own civilization and usually no harm to the other guy's civilization, either.
Seconded. Cheap athletic shoes just don't cut it for me; I get overuse injuries if I try to maintain the same activity level I have in my $80-$90 shoes.
I also got terrible blisters and knee soreness (caused by an awkward gait) from a cheap pair of hiking boots that just wouldn't unstiffen. Not only did they not unstiffen even after trying every bizarre home remedy in the book (running over them with a car, etc.) but they disintegrated the third time I wore them. The sole on one boot started coming off with five miles left in a thirty mile hike, and by the time I finished the hike, it was halfway off and flopping with each step.
By contrast, I could throw my nice Vasque hiking boots on right now, despite having not worn hiking boots in months, and hike all day without getting a single blister. They cost more than the cheap pair (~$150 vs ~$60) but they've protected my feet well, they don't take long to break in, and they provide many more miles per dollar.
I disagree; it won't be very interesting at all. Light weight, durability, power efficiency (which requires a relatively modern mobile processor,) and a nice screen drive up the cost so much that upgrading to an overkill midrange processor doesn't really affect the price. If the price premium between "adequate for ssh, remote desktop, and most web browsing" and "adequate for anything I can do on a desktop" is only $100, what first-world person would be excited about the cheaper option?
But they could sue other not-for-profit enterprises into oblivion. Surely that would help somehow. I mean, it's not quite coming to mind how, but I'm pretty sure it almost always helps. Maybe they could sue the people who buy the computers and the kids who end up using them, too.
Anyway, I'd take the time to break it down and explain it to you, but I have to go prepare a Powerpoint presentation for my finance class.
A better analogy is the guy who goes to college and meets a bunch of smart, sexy, fascinating women [named Haskell, Erlang, and Lisp] and then lets his parents [college loans] pressure him into marrying a dull hometown girl [named COBOL] with a dowry [a job offer] and good family connections [predictable future employment.]
- They have a firm idea of what they want and ignore every woman who doesn't qualify. A surfeit of choices can make people believe that any insanely detailed fantasy will be realized sooner or later, so this one can be chalked up to choice overload.
- Their behavior deters women from expressing interest, and they quite sensibly decide not to press women who don't show interest.
- They're so inexperienced that they can't recognize interest, which has the same effect as 2.
- They're too proud to date the women who show interest in them.
- They're depressed or have other mental problems.
The guys who have a surfeit of choices are usually out there enjoying them, maybe not by screwing everything that winks at them, but by socializing and enjoying the mutual exchange of attention.(OT Male geek loneliness horse race! 2 comes out of the gate early, asserting a strong lead well before puberty. 3 quickly comes galloping up to share the lead by trapping cautious, self-conscious guys who won't move without knowing and can't learn without moving. 2 falls down immediately among non-geeks but maintains its position on the geek track by afflicting younger guys who can't express confidence because they're paranoid about accidentally seeming like smug assholes. 4 holds steady behind 2 and 3, seeming to bide its time. But it's a long race! 2, 3, and 4 steadily tire as geeks escape their clutches through alcohol and other drugs. 5 is the slowest horse on the track, but he's also the only one maintaining his speed. In fact, he's accelerating! He seems to be feeding off the cumulative effects of 2, 3, and 4. At age 35, 5 makes his move and surges into the lead! It's all #5 down the back stretch! And yes, at the finish line, when everyone is old and wrinkly and it's too late to care, 5 is the only horse left on his feet. What a race, ladies and gentlemen. Let's hear it for mental illness. Um... damn, that was a downbeat horse race. Let me emphasize that even though lots and lots of geeks were harmed in the making of this race, most of them were pastured out to stud while they were still young enough to enjoy it.)
The effects of the inability to handle concurrency were visible as soon as multithreaded GUI systems hit the corporate desktop. The average corporate coder simply can't write a reliable and responsive GUI application, so as soon as web programming emerged as an alternative, corporate development abandoned the rich client. Now almost every internal business application gets shoehorned into a web interface. Rich clients are notorious for having terrible performance, real and/or perceived, and it isn't because the actual computing workload exceeds the capacity of the hardware. It's because of poor programming. (I admit, half the time it's because programmers clog up the network with data. The other half of the time, it's because concurrency handling in the GUI sucks.)
I don't think those building blocks are what people are calling a framework in this case; they mean something higher-level and more concrete that has design implications for the rest of the system, rather than being moldable into any design. That's why there are so many of them. Consider the multiplicity of logging frameworks for C++, despite them all being made out of file handles and objects.You're right; there's nothing more tragic than watching a programmer butcher his well-written program in a futile attempt to make it fit the only concurrency model he knows. Closely associating a language with a single, well-designed concurrency framework would at best do the same thing for it that Rails did for Ruby: bring it a flurry of popularity in the short run and damage its reputation in the long run as people doggedly apply the framework to unsuitable problems and blame the language for the results.
On the other hand, at some point we're all supposed to face up to the end of the free lunch, and a fad for an exotic kind of concurrency might be a clumsy, spasmodic step in the right direction.