There are some people who, when playing Minesweeper, simply HAVE to click at least once a second, even if they haven't figured out a safe place to click yet. IDEs let that type of person code away with minimum frustration. Just sit down and start banging the tab-completion key. Unfortunately, we're all a little bit like that, so we're all a little bit susceptible to that temptation.
What the grandparent means is that if you can't sit down and just type in your code without a bunch of IDE help, you probably aren't ready to start coding yet. You need to refresh yourself on the APIs you're using, sip some coffee, think about the code you're going to write, and get it right the first time. It's hard to maintain that discipline, and IDEs make it harder. If you tend to be less careful than you should (and don't we all?), using an IDE is like an alcoholic living across the street from a liquor store.
OTOH, much commercial coding is done on a trial and error basis. Why bother trying to get something exactly right when the API documentation you're using is unreliable, your boss cares how fast you do it more than how well, and you won't find out what you were really supposed to implement until you've delivered the first version anyway? Under those conditions, you might as well use a tool that lets you spew the code out as fast as possible, because that's the optimal behavior.
Seriously, I think the usefulness of an IDE depends on what you're doing. If you're doing simple modifications of a large codebase that uses many large APIs, then an IDE is handy for navigating all that stuff. If you're doing difficult, critical work that depends on a small or nonexistent set of external APIs, then a text editor will keep you honest and not help you code when you aren't ready yet.
The standard Linux desktop environment is GNOME and it uses GTK, so it is likely that you already have GTK on your system. Even those who are still stuck with an older system such as KDE usually have GTK installed.
Flamebait. KDE is a very lively project that provides all the bells and whistles and releases new versions on a regular basis. I give GNOME a chance every year or so, most recently a few months ago with Ubuntu, yet KDE has remained my preferred environment since 2001. GNOME vs. KDE is a matter of taste, not a matter of one being more standard or technically ahead of the other, though I'm sure each one is ahead in some areas.
less experiened users have a smaller mental leap to get into the "PC space" that geeks are so used to
If you're living in the industrialized world, you have about twenty years before that sentence is laughable in every social, racial, economic, and cultural category. Twenty years from now it will only apply to children raised by wild dogs. I'm not saying the distinction between computer geeks and casual users will disappear, only that tomorrow's casual user will be pretty savvy by yesterday's standards. If you want to design for today's "less experienced users," you'd better start looking at the job market in developing countries and hope the $100 laptop doesn't get there first, because today's less experienced user is an ephemeral reflection of a moment in history.
Native computer users, which are the only ones worth considering if you're taking a long view, are comfortable with artificiality. They find 3D graphics attractive, but they regard 3D UI logic as additional complexity, and like any UI complexity, it must pay for itself by providing extra power or convenience. That is the attitude that users take toward 3D user interfaces, but most people cheerleading for 3D UI logic have no idea how to use the extra dimension for power or convenience, only that it's "obviously" superior to 2D because obviously the extra dimension will turn out to be useful somehow.
Supposedly, as soon as enough clever people understand this idea (which has been touted for decades, but obviously needs just a little bit more cheerleading,) the applications will appear and take off like wildfire. Think about it -- if creating superior 3D interfaces for common tasks like managing files, handling office documents, or browsing linked collections of documents (like the web) were so easy, wouldn't it have been done already? There are plenty of smart and well-funded people at Microsoft and MIT's Media Lab and such places, but none of them have done anything comparable to Doug Engelbart's demo. There aren't demos on YouTube or Google Video that make me say "Wow!" or even make me look forward to having a 3D interface. I haven't seen anything superior to what I can run on Linux right now except special-purpose applications that I have no use for.
The truth is, the idea of 3D interfaces and the technology to implement them have both been around for a long time, and nothing really impressive has resulted. The problem of creating 3D interfaces that are materially superior to 2D interfaces turns out to be very hard for almost all tasks, so hard that even the smartest and best-equipped people in the world can't come up with prototypes worth showing off to the public. It's time to admit that the idea that 3D interfaces will be far superior to 2D interfaces remains nothing but an unsubstantiated intuition, even after decades of enthusiasm.
Don't make them learn anything they can't grasp the need for. That eliminates Java, C++, and a host of other languages that impose burdens that pay off in performance, large-scale maintainability, portability, and other things that aren't of any use to the kids.
In the best case, everything they type will have meaning and value to them. Instant feedback is also a plus. That means your best bet is a dynamically typed languages with a REPL. Many other posters have suggested languages/environments with convenient access to graphics; from my own experience, I would say graphics are nice but far from essential. That's your call, though, since you know the kids better than any of us do.
Here's a suggestion that may be a bit... out there. Teaching Haskell to kids might be risky, but it's guaranteed to be easier than teaching it to adults, especially experienced programmers.
Just to have a good time and give others the pleasure of seeing him? There are good reasons to go. He appreciates friends, so he is not entirely devoid of human feeling.
He is refusing the prize not for lack of good consequences but because there are bad consequences as well. First, he believes that prizes promote an incorrect understanding of how and why mathematics should be done. Second, the prize would elevate his position in the mathematical community and bring responsibilities he does not want to deal with.
If making a half-baked sketch and passing it off to the best mathematicians in world to fill in the details were all it took to solve major problems and take credit for it, no problem would remain unsolved for a decade, let alone a century.
Many people have laid out sketches where the gaps and hand-waving concealed glossed over such hard problems that no proof resulted. That it took only a few years to fill in the details, and the first mathematicians to do so gave full credit to Perelman, proves that Perelman actually did the hard work and left relatively easy parts unspecified.
Of course, many people before him provided important pieces. Perelman was simply the one who supplied the last batch of brilliant contributions. It's a bit like thrusting the final spear into the mammoth and sitting down for a well-deserved rest while someone else butchers and cooks it.
I have a whole shelf of math books here and read a few research papers in college. I also read school textbooks and popular math books when I was a kid. I have absolutely no idea what you're talking about. The review was simply bad, bad, bad writing of the type produced by someone under the influence of drugs, mania, or unrecognized stupidity. Math attracts more than its share of such crapola but far less than philosophy, religion, poetry, science fiction, and psychedelic rock. This stuff is never published in professionally edited (*ahem*, take a note, Slashdot editors) publications in any field.
I include page-downs in the category of things where nicely snappy smoothness should be visually indistinguishable from jerkiness.
Jumping around should be jumpy when there are no sensible intermediate states. Progressive search or hopping to the beginning of the next paragraph, for instance, should happen instantaneously. Why show the cursor zipping along through the intervening text or show the document scrolling? This might help a new user understand the concept of finding the next match, but that is a rare and minor problem at best. When performing progressive search through a large document, such as when viewing a large manual as a single web page or consulting a 500 page PDF reference manual, the implementation must choose between being blindingly fast or inconveniently slow. In smaller documents, smooth scrolling might help the user see where the jump is taking them, but asking the user to infer location from motion is asking them to perform integration. It's friendlier to provide a static indicator of approximately where in the document the jump has taken them. A scrollbar does this nicely.
I agree with you on automatic window rearrangements, because many windows look basically alike, and rearrangement can cause a window to resize, appear, or disappear. Motion helps the user's brain connect a window's new appearance and location with its old appearance and location faster than the user could figure it out by inspecting the content of the windows.
The human mind actually has a built-in, hard-wired function in the brain of identifying graphical movement - and it doesn't work when things jump around, only when they smoothly slide around.
This can easily and probably was scientifically tested.
It can and was tested by the invention of motion pictures over a century ago. When the brain sees identical objects appearing in different places at different times, it recognizes them as the same object and infers that they have moved. All it takes is sufficiently quick refresh. Modern graphics hardware is plenty fast, much faster than the framerate of motion pictures.
In fact, most GUIs that tout "smooth scrolling" as a nifty feature -- IE being a notorious example -- simply slow down the scrolling to an annoying speed, because if scrolling is quick and responsive you can't tell the difference between "smooth" and "jumpy."
I agree 100%. Jumpiness makes sense. Computer, and the programs and data that inhabit them, are not physical objects and do not behave like physical objects. UI gurus have been declaring for years that normal human beings cannot accept this and will never understand anything that was not familiar to humans on the savannahs of Africa 100,000 years ago.
Pointing out that a UI behavior has no counterpart in the "real" world says nothing about whether it will be difficult for people to understand and exploit the behavior. That argument has been discredited by years of experience. The first bogeyman of this type was the word processor convention that text typed into a document was not permanent until the user asked for the file to be saved. This, it was said, would limit the use of word processing to a small group of slightly autistic subhumans who were willing to sacrifice their humanity and live by the machine's laws. (Or so it sounded to me.)
This bizarre principle, discredited in practice, is still upheld by ideologues who believe that the tendency to create rational systems and mold the world to resemble them is somehow inhuman -- as if the engineers, scientists, car mechanics, accountants, and programmers of the world were not human beings expressing a deeply human trait but monsters weaving a toxic and alien thread into human society.
Who created the machines? In whose image were they made? A person who has no technical skill, who cannot program a VCR or learn the common GUI conventions, should not be considered more human for it, any more than a person should be considered more human for being unable to sing, dance, or make a child laugh.
That's not OOP, that's good programming in any style: procedural, functional, object-oriented, whatever. If you think it's object-oriented programming, you must not think it's possible to write good programs outside the object-oriented paradigm, which is simply wrong. Most OOP detractors I deal with trace their distaste to guys like you who think that every good idea is OO. Static typing is OO, dynamic typing is OO, code reviews are OO, general relativity is OO, democracy is OO, motherhood and apple pie are OO. Maybe if you pull OO down from that pedestal you'll stop seeing OO in everything and start seeing good programming instead.
When people stopped preaching to other people ("do it, it's good for you") and started thinking about their own butts ("screw good for me, I'd rather be and look successful.") It's the difference between meddling idealism and self-centered pleasure-seeking.
To the Safari Bookshelf I would add a little bit of spare time and free machines so you can follow along. Tinkering with a working system to observe all the parts in action is an essential part of learning (and implicitly assumed by the O'Reilly books I've read,) but it isn't usually tolerated on real systems and real schedules. Management quite reasonably tends to look unfavorably on any further work once a system is working acceptably. To make up for this, they should set aside free time and machines for tinkering so their employees continue to develop. (It goes without saying that if your company doesn't give you the time, steal it. They'll benefit in the long run.)
I always found that everybody struggled with something in school. Probably the greatest equalizer in terms of seeing people struggle was foreign languages.
The problem is that they only struggle at their weaknesses, so they learn to associate effort with failure (or at least lack of achievement and potential.) Doug works hard at English and only spends ten minutes on his math homework; therefore, Doug sucks at English and might have a future in math.
That's competing, not teaching. The actual teaching and practice of baseball in little league is horribly boring - how to call and catch a pop-fly, what base to throw to. It's designed just like school, to be inclusive and to ensure all kids get rudimentry skills. The Little League World Series is an All-Star competition; the kids who needed coaching during the intra-league season, are most likely not part of those teams. Academic parallels to the Little League example are Science Olympiad or AcDec. The kids who win the competition are those who are self-motivated; those that only know what they get from school, are usually not good enough to compete.
There's a big difference between youth sports and academics. The rules of youth sports are designed with the explicit goal that coaches are motivated to help every kid, good and bad, improve his performance. (Later on, in school sports, the worst athletes end up excluded for the same reason the best students are excluded: their performance makes no difference to the perceived success or failure of their teachers.) In baseball, advanced kids get subtle training on their form and drilling on coverage patterns. If there's a guy on first and the batter hits a ground ball to the third baseman, the right fielder covers a bad throw to first, so it's the center fielder's job to cover a bad throw to second. If the center fielder doesn't react immediately when the ball is hit, a bad throw to second could go to the right field fence. He has to think through the possibilities before every pitch. There's a ton of stuff to know, way more than any seven year old can absorb, and the coach makes sure each kid is working at his full potential, no matter what that is, because depending on the breaks, a marginal difference in the skill of any single kid, from the best to the worst, can make the difference between winning and losing.
(Maybe I just came from a place where people care more about baseball than academics, but I think the difference is due to incentives. If a kid is going to dependably score above grade level on the state standardized tests, then there's nothing to gain from giving him any further instruction.)
Academic Decathlon is quite the opposite of self-motivated, self-directed work, at least in my experience. I worked with my school's Academic Decathlon team for a week (with the intention of joining and competing) and later helped the team study for some of the math stuff, and it was nothing but piles of 3-ring binders full of shallow information on a bunch of topics. There were books involved, but according to the strategy the team had decided to follow, actually reading the books was deemed an inefficient use of time until I had the binder stuff down cold. The math material, which was supposed to be my specialty, was just a summary of the basic high school math curriculum. In fact, the only math the seniors hadn't already covered in class was a bit of calculus they hadn't got to yet and basic combinatorics (mCn and mPn, which their Algebra II teacher had skipped for some reason.) My role in this supposedly high-level contest was to tutor the non-math-oriented people on stuff they had already covered in class. I.e, remedial work. So I decided it was just more machine stuff, just a contest to see who could master a predefined set of easy material more completely and efficiently than the next guy, with less emphasis on problem-solving and more emphasis on memorization (i.e., less fun by my taste.)
There are plenty of talented athletes who find thier sport easy as children.
Nope, sports are organized in such a way that you keep playing until you lose. In the Little League World Series, only about twenty kids in the entire world get to feel like their sport is "easy." In individual sports like tennis, you get inserted into a state ranking system, and if you're too good for that, a national system. In basketball, your team may go undefeated by winning the postseason tournament, but you don't score every time down the floor. You face little defeats and failures every time you step on the court. It's the same for little kids playing soccer. Of *course* you don't score every time you touch the ball.
It isn't quite the same way with addition and subtraction and true/false questions about American history. Classroom stimulation is carefully engineered to a narrow level of challenge, and the maximum level of challenge increases mechanically from year to year absolutely independently of the capabilities of the students. An inferior basketball opponent may accidentally make a brilliant move once in a while, but a sixth grade textbook does not "accidentally" contain a chapter written on a ninth-grade level.
There are plenty of super talented basketball players who dominate the playgrounds because they refused to listen to coaching.
They ended up on the playground because they failed (or gave up) on the challenge presented to them, not because of a lack of challenge.
the people who make the most of their talents in any walk of life are the ones who pursue self-directed activities
Yeah, like computer programming. Or solving problems a few chapters ahead in the math book. Hah. If you make your own math, you're a genius. Granted, geniuses can't be stopped. Everyone else ends up repeating themselves eventually, like writing a bunch of lame-ass computer programs in BASIC that draw patterns on the screen or implement text adventures or quiz them on math problems. Been there, done that, got sick of my own mind after several years of Applesoft BASIC and gave up programming for an equal number of years. Creating your own variations on what you've learned is an essential part of learning, but it's just masturbation after a point unless you're brilliant enough to develop the field by yourself. Nobody except a genius gets very far without external stimulation.
Why do you think top colleges insist on extracurriculars? It isn't because they don't value academic work, and it is only in small part because they value "well-rounded students." It's mainly because they know that given the lack of challenging academics in US high schools, if you don't accomplish anything beyond academics, you're probably either a) lazy, or b) a bit dull.
You can probably tell I'm a little bitter. Yeah, I'm bitter. I'm bitter because I when I played high school tennis I used to get up on Saturday morning, go to the tennis courts by myself, hit a few hundred practice serves, and feel good about it. Yeah, I'm a good player, I work hard, I'm proud of myself. That's the way I was trained to think. But academically, I was trained to think that if I had to work hard at something, I must suck at it. I was plagued by that feeling all throughout college and am still plagued by it to this day. "Oh man, I had to think really hard to do that proof, so I must actually suck at math despite all the evidence to the contrary." "Wow, that physics problem set was hard, which is too bad because I thought I might actually be good at physics. No, wait, just because a few problems in a problem set for a senior-level class are hard for me, a sophomore, doesn't mean I suck at physics. Yes it does... NO NO IT DOES NOT... stop embarrassing yourself and pick another field."
That's the kind of mentality that public school drilled into me. Basically, for the first
Technology is also about customization. A smart kid gets about twenty minutes of useful information from the chalkboard every day. The rest of it is for the other kids, and he is forced to do remedial work for 80% of his day and maybe read books during lecture if his teachers let him. (Yes, I had a few jerk teachers who wouldn't let me read books in class.) In their current form, schools punish intelligence with boredom.
Kids who are ahead the rest of the class are considered finished projects. They're ignored. You can create honors classes, but then the kids who are ahead of the honors classes are ignored. Why do anything for them? They're "done," so you just leave them there like cookies on the cooling rack.
Technology can change that, or at least give the smart kids a chance to make progress. Face it, the kids who are ahead will always be ignored, because teachers are never judged by success, only by the failure rate on standardized tests. So give the kids as much opportunity to make academic progress as possible -- give everyone an interactive curriculum! You can ignore the smart kids as always, but the smart kids will spend their time learning instead of sleeping, sneaking peeks at Isaac Asimov novels, and wondering if next year will be the year that they actually learn something in school.
Nobody thinks it's weird that someone talented at an academic subject says, "X was always easy for me." How many people can say, "Basketball was always easy for me," or, "Violin was always easy for me?" Nobody! Only academics is set up so that someone who is good at, say, math, will never encounter any challenging math until they reach college. Everything else runs the way it should -- no matter how good you are, there's always a challenge to keep you working.
Only computer-based interactive curricula can provide an appropriate pace for all students.
What would really advance the state of the art is an "everything is an object" operating system.
What's cool about "everything is a..." is that code and understanding for dealing with one entity (such as disk files) can be applied toward other entities (such as network connections). "Everything is an object" only helps if the objects share important characteristics that make them similar to work with. Using a basic definition of "object" -- a piece of data and operations for manipulating it -- Unix qualifies as an "everything is an object" operating system. The operations (i.e., system calls) that may be applied to an object depend on its type (file descriptor, process, network device, etc.) with no operations that may be applied to all objects, leaving no common logic for interacting with the objects. "Everything is a foo" is only helpful if there is a useful set of operations that can be applied to all foos.
"Everything is a bar," on the other hand, would be very useful, because even if they don't have good beer, every bar has someplace to take a leak.
They expect to transition their entire codebase to C++, so I assume they don't depend on Matlab libraries that they don't have the means (and rights) to port to C++ as well -- either that or they're willing to interface their C++ code to the Matlab libraries they depend on.
Matlab also allows the expensive guys with math PhDs to work quickly in a pleasant, familiar, supportive environment. Those guys are smart enough to learn C++ and deal with memory management and templates (often helpful for supremely efficient math code), but it's not a good use of their time if it can be avoided. If you need C++, let the cheap programmers transcribe the Matlab work into C++ and do the tedious job of debugging in C++, while the math guys stay happy and productive in Matlab.
Lastly, this is not the kind of question that will get answered well on Slashdot. People who have never used matlab will make assumptions and not understand that it is very unlikely that C++ will have the kind of simulation and and capabilities that Matlab does.
Absolutely correct. Coincidentally, yesterday at the bookstore I saw a book on network programming in Matlab, which was a big surprise (to my non-Matlab-using mind).
Trying to write C++ code and develop the math at the same time means that you have four times the trouble debugging.
Actually, if functional units are done in sequence, then the debugging in the second language will be trivial. After writing, testing, and debugging the Foo function in Matlab, the C++ work will be little more than transcription.
If you can interface Matlab to C++, you can even use the same tests for both codebases.
The company I am currently at is doing this now, and as a DBA, I haveto put up with the crap from the increased workload, so bottom line, it is a net LOSS for the company.
It's funny that you can declare the process a net loss for your company with even mentioning how well the development work is going. It seems like that would be a big factor in evaluating the success of the process. Or would you have us believe that more work for you is *always* a bad thing, regardless of how useful that work is to other people?
Specifically, how do you convince them that you're cutting corners like they want when you're actually doing good work? All these new languages/frameworks/methodologies promise that all unnecessary cruft has been taken out, which leaves me the choice of skipping something important (and plunging the project into chaos) or taking a lot of abuse from management for "not understanding the urgency of the situation."
I need a language/framework/methodology with built-in timewasting, so I always have something expendable to sacrifice when management starts screaming, "Days matter! Days matter! Everyone has to pull out all the stops or they're not team players!"
Don't forget about searching other people's documents. This is going to save a lot of bandwidth between government intelligence agencies and the Yahoos and AT&Ts of the world. I can imagine a Chinese (or US) policeman going to the address bar in his browser and typing in a keyword search:
Chinese government agent: "gg agency_id:7789 jurisdiction:china privacy_invasion:name,address,ip democracy"
Google: "Results 1-10 of about 1,755,000 for democracy"
Government agent: "I better surf over to www.government-agent-jobs.cn before I get replaced by a Perl script, 'cause my job just got wayyyy to easy. But first..."
Government agent: "gg agency_id:7789 jurisdiction:jp privacy_invasion:images,video bukkake home movie"
Google: "Invalid agency id for jurisdiction 'Japan'. No bukkake found."
Slashdot Mirror
There are some people who, when playing Minesweeper, simply HAVE to click at least once a second, even if they haven't figured out a safe place to click yet. IDEs let that type of person code away with minimum frustration. Just sit down and start banging the tab-completion key. Unfortunately, we're all a little bit like that, so we're all a little bit susceptible to that temptation.
What the grandparent means is that if you can't sit down and just type in your code without a bunch of IDE help, you probably aren't ready to start coding yet. You need to refresh yourself on the APIs you're using, sip some coffee, think about the code you're going to write, and get it right the first time. It's hard to maintain that discipline, and IDEs make it harder. If you tend to be less careful than you should (and don't we all?), using an IDE is like an alcoholic living across the street from a liquor store.
OTOH, much commercial coding is done on a trial and error basis. Why bother trying to get something exactly right when the API documentation you're using is unreliable, your boss cares how fast you do it more than how well, and you won't find out what you were really supposed to implement until you've delivered the first version anyway? Under those conditions, you might as well use a tool that lets you spew the code out as fast as possible, because that's the optimal behavior.
Seriously, I think the usefulness of an IDE depends on what you're doing. If you're doing simple modifications of a large codebase that uses many large APIs, then an IDE is handy for navigating all that stuff. If you're doing difficult, critical work that depends on a small or nonexistent set of external APIs, then a text editor will keep you honest and not help you code when you aren't ready yet.
Flamebait. KDE is a very lively project that provides all the bells and whistles and releases new versions on a regular basis. I give GNOME a chance every year or so, most recently a few months ago with Ubuntu, yet KDE has remained my preferred environment since 2001. GNOME vs. KDE is a matter of taste, not a matter of one being more standard or technically ahead of the other, though I'm sure each one is ahead in some areas.
If you're living in the industrialized world, you have about twenty years before that sentence is laughable in every social, racial, economic, and cultural category. Twenty years from now it will only apply to children raised by wild dogs. I'm not saying the distinction between computer geeks and casual users will disappear, only that tomorrow's casual user will be pretty savvy by yesterday's standards. If you want to design for today's "less experienced users," you'd better start looking at the job market in developing countries and hope the $100 laptop doesn't get there first, because today's less experienced user is an ephemeral reflection of a moment in history.
Native computer users, which are the only ones worth considering if you're taking a long view, are comfortable with artificiality. They find 3D graphics attractive, but they regard 3D UI logic as additional complexity, and like any UI complexity, it must pay for itself by providing extra power or convenience. That is the attitude that users take toward 3D user interfaces, but most people cheerleading for 3D UI logic have no idea how to use the extra dimension for power or convenience, only that it's "obviously" superior to 2D because obviously the extra dimension will turn out to be useful somehow.
Supposedly, as soon as enough clever people understand this idea (which has been touted for decades, but obviously needs just a little bit more cheerleading,) the applications will appear and take off like wildfire. Think about it -- if creating superior 3D interfaces for common tasks like managing files, handling office documents, or browsing linked collections of documents (like the web) were so easy, wouldn't it have been done already? There are plenty of smart and well-funded people at Microsoft and MIT's Media Lab and such places, but none of them have done anything comparable to Doug Engelbart's demo. There aren't demos on YouTube or Google Video that make me say "Wow!" or even make me look forward to having a 3D interface. I haven't seen anything superior to what I can run on Linux right now except special-purpose applications that I have no use for.
The truth is, the idea of 3D interfaces and the technology to implement them have both been around for a long time, and nothing really impressive has resulted. The problem of creating 3D interfaces that are materially superior to 2D interfaces turns out to be very hard for almost all tasks, so hard that even the smartest and best-equipped people in the world can't come up with prototypes worth showing off to the public. It's time to admit that the idea that 3D interfaces will be far superior to 2D interfaces remains nothing but an unsubstantiated intuition, even after decades of enthusiasm.
In the best case, everything they type will have meaning and value to them. Instant feedback is also a plus. That means your best bet is a dynamically typed languages with a REPL. Many other posters have suggested languages/environments with convenient access to graphics; from my own experience, I would say graphics are nice but far from essential. That's your call, though, since you know the kids better than any of us do.
Here's a suggestion that may be a bit... out there. Teaching Haskell to kids might be risky, but it's guaranteed to be easier than teaching it to adults, especially experienced programmers.
Just to have a good time and give others the pleasure of seeing him? There are good reasons to go. He appreciates friends, so he is not entirely devoid of human feeling.
He is refusing the prize not for lack of good consequences but because there are bad consequences as well. First, he believes that prizes promote an incorrect understanding of how and why mathematics should be done. Second, the prize would elevate his position in the mathematical community and bring responsibilities he does not want to deal with.
If making a half-baked sketch and passing it off to the best mathematicians in world to fill in the details were all it took to solve major problems and take credit for it, no problem would remain unsolved for a decade, let alone a century.
Many people have laid out sketches where the gaps and hand-waving concealed glossed over such hard problems that no proof resulted. That it took only a few years to fill in the details, and the first mathematicians to do so gave full credit to Perelman, proves that Perelman actually did the hard work and left relatively easy parts unspecified.
Of course, many people before him provided important pieces. Perelman was simply the one who supplied the last batch of brilliant contributions. It's a bit like thrusting the final spear into the mammoth and sitting down for a well-deserved rest while someone else butchers and cooks it.
*blinks in astonishment*
I have a whole shelf of math books here and read a few research papers in college. I also read school textbooks and popular math books when I was a kid. I have absolutely no idea what you're talking about. The review was simply bad, bad, bad writing of the type produced by someone under the influence of drugs, mania, or unrecognized stupidity. Math attracts more than its share of such crapola but far less than philosophy, religion, poetry, science fiction, and psychedelic rock. This stuff is never published in professionally edited (*ahem*, take a note, Slashdot editors) publications in any field.
I include page-downs in the category of things where nicely snappy smoothness should be visually indistinguishable from jerkiness.
Jumping around should be jumpy when there are no sensible intermediate states. Progressive search or hopping to the beginning of the next paragraph, for instance, should happen instantaneously. Why show the cursor zipping along through the intervening text or show the document scrolling? This might help a new user understand the concept of finding the next match, but that is a rare and minor problem at best. When performing progressive search through a large document, such as when viewing a large manual as a single web page or consulting a 500 page PDF reference manual, the implementation must choose between being blindingly fast or inconveniently slow. In smaller documents, smooth scrolling might help the user see where the jump is taking them, but asking the user to infer location from motion is asking them to perform integration. It's friendlier to provide a static indicator of approximately where in the document the jump has taken them. A scrollbar does this nicely.
I agree with you on automatic window rearrangements, because many windows look basically alike, and rearrangement can cause a window to resize, appear, or disappear. Motion helps the user's brain connect a window's new appearance and location with its old appearance and location faster than the user could figure it out by inspecting the content of the windows.
I agree 100%. Jumpiness makes sense. Computer, and the programs and data that inhabit them, are not physical objects and do not behave like physical objects. UI gurus have been declaring for years that normal human beings cannot accept this and will never understand anything that was not familiar to humans on the savannahs of Africa 100,000 years ago.
Pointing out that a UI behavior has no counterpart in the "real" world says nothing about whether it will be difficult for people to understand and exploit the behavior. That argument has been discredited by years of experience. The first bogeyman of this type was the word processor convention that text typed into a document was not permanent until the user asked for the file to be saved. This, it was said, would limit the use of word processing to a small group of slightly autistic subhumans who were willing to sacrifice their humanity and live by the machine's laws. (Or so it sounded to me.)
This bizarre principle, discredited in practice, is still upheld by ideologues who believe that the tendency to create rational systems and mold the world to resemble them is somehow inhuman -- as if the engineers, scientists, car mechanics, accountants, and programmers of the world were not human beings expressing a deeply human trait but monsters weaving a toxic and alien thread into human society.
Who created the machines? In whose image were they made? A person who has no technical skill, who cannot program a VCR or learn the common GUI conventions, should not be considered more human for it, any more than a person should be considered more human for being unable to sing, dance, or make a child laugh.
That's not OOP, that's good programming in any style: procedural, functional, object-oriented, whatever. If you think it's object-oriented programming, you must not think it's possible to write good programs outside the object-oriented paradigm, which is simply wrong. Most OOP detractors I deal with trace their distaste to guys like you who think that every good idea is OO. Static typing is OO, dynamic typing is OO, code reviews are OO, general relativity is OO, democracy is OO, motherhood and apple pie are OO. Maybe if you pull OO down from that pedestal you'll stop seeing OO in everything and start seeing good programming instead.
When people stopped preaching to other people ("do it, it's good for you") and started thinking about their own butts ("screw good for me, I'd rather be and look successful.") It's the difference between meddling idealism and self-centered pleasure-seeking.
To the Safari Bookshelf I would add a little bit of spare time and free machines so you can follow along. Tinkering with a working system to observe all the parts in action is an essential part of learning (and implicitly assumed by the O'Reilly books I've read,) but it isn't usually tolerated on real systems and real schedules. Management quite reasonably tends to look unfavorably on any further work once a system is working acceptably. To make up for this, they should set aside free time and machines for tinkering so their employees continue to develop. (It goes without saying that if your company doesn't give you the time, steal it. They'll benefit in the long run.)
The problem is that they only struggle at their weaknesses, so they learn to associate effort with failure (or at least lack of achievement and potential.) Doug works hard at English and only spends ten minutes on his math homework; therefore, Doug sucks at English and might have a future in math.
There's a big difference between youth sports and academics. The rules of youth sports are designed with the explicit goal that coaches are motivated to help every kid, good and bad, improve his performance. (Later on, in school sports, the worst athletes end up excluded for the same reason the best students are excluded: their performance makes no difference to the perceived success or failure of their teachers.) In baseball, advanced kids get subtle training on their form and drilling on coverage patterns. If there's a guy on first and the batter hits a ground ball to the third baseman, the right fielder covers a bad throw to first, so it's the center fielder's job to cover a bad throw to second. If the center fielder doesn't react immediately when the ball is hit, a bad throw to second could go to the right field fence. He has to think through the possibilities before every pitch. There's a ton of stuff to know, way more than any seven year old can absorb, and the coach makes sure each kid is working at his full potential, no matter what that is, because depending on the breaks, a marginal difference in the skill of any single kid, from the best to the worst, can make the difference between winning and losing.
(Maybe I just came from a place where people care more about baseball than academics, but I think the difference is due to incentives. If a kid is going to dependably score above grade level on the state standardized tests, then there's nothing to gain from giving him any further instruction.)
Academic Decathlon is quite the opposite of self-motivated, self-directed work, at least in my experience. I worked with my school's Academic Decathlon team for a week (with the intention of joining and competing) and later helped the team study for some of the math stuff, and it was nothing but piles of 3-ring binders full of shallow information on a bunch of topics. There were books involved, but according to the strategy the team had decided to follow, actually reading the books was deemed an inefficient use of time until I had the binder stuff down cold. The math material, which was supposed to be my specialty, was just a summary of the basic high school math curriculum. In fact, the only math the seniors hadn't already covered in class was a bit of calculus they hadn't got to yet and basic combinatorics (mCn and mPn, which their Algebra II teacher had skipped for some reason.) My role in this supposedly high-level contest was to tutor the non-math-oriented people on stuff they had already covered in class. I.e, remedial work. So I decided it was just more machine stuff, just a contest to see who could master a predefined set of easy material more completely and efficiently than the next guy, with less emphasis on problem-solving and more emphasis on memorization (i.e., less fun by my taste.)
There
Nope, sports are organized in such a way that you keep playing until you lose. In the Little League World Series, only about twenty kids in the entire world get to feel like their sport is "easy." In individual sports like tennis, you get inserted into a state ranking system, and if you're too good for that, a national system. In basketball, your team may go undefeated by winning the postseason tournament, but you don't score every time down the floor. You face little defeats and failures every time you step on the court. It's the same for little kids playing soccer. Of *course* you don't score every time you touch the ball.
It isn't quite the same way with addition and subtraction and true/false questions about American history. Classroom stimulation is carefully engineered to a narrow level of challenge, and the maximum level of challenge increases mechanically from year to year absolutely independently of the capabilities of the students. An inferior basketball opponent may accidentally make a brilliant move once in a while, but a sixth grade textbook does not "accidentally" contain a chapter written on a ninth-grade level.
They ended up on the playground because they failed (or gave up) on the challenge presented to them, not because of a lack of challenge.
Yeah, like computer programming. Or solving problems a few chapters ahead in the math book. Hah. If you make your own math, you're a genius. Granted, geniuses can't be stopped. Everyone else ends up repeating themselves eventually, like writing a bunch of lame-ass computer programs in BASIC that draw patterns on the screen or implement text adventures or quiz them on math problems. Been there, done that, got sick of my own mind after several years of Applesoft BASIC and gave up programming for an equal number of years. Creating your own variations on what you've learned is an essential part of learning, but it's just masturbation after a point unless you're brilliant enough to develop the field by yourself. Nobody except a genius gets very far without external stimulation.
Why do you think top colleges insist on extracurriculars? It isn't because they don't value academic work, and it is only in small part because they value "well-rounded students." It's mainly because they know that given the lack of challenging academics in US high schools, if you don't accomplish anything beyond academics, you're probably either a) lazy, or b) a bit dull.
You can probably tell I'm a little bitter. Yeah, I'm bitter. I'm bitter because I when I played high school tennis I used to get up on Saturday morning, go to the tennis courts by myself, hit a few hundred practice serves, and feel good about it. Yeah, I'm a good player, I work hard, I'm proud of myself. That's the way I was trained to think. But academically, I was trained to think that if I had to work hard at something, I must suck at it. I was plagued by that feeling all throughout college and am still plagued by it to this day. "Oh man, I had to think really hard to do that proof, so I must actually suck at math despite all the evidence to the contrary." "Wow, that physics problem set was hard, which is too bad because I thought I might actually be good at physics. No, wait, just because a few problems in a problem set for a senior-level class are hard for me, a sophomore, doesn't mean I suck at physics. Yes it does... NO NO IT DOES NOT ... stop embarrassing yourself and pick another field."
That's the kind of mentality that public school drilled into me. Basically, for the first
Technology is also about customization. A smart kid gets about twenty minutes of useful information from the chalkboard every day. The rest of it is for the other kids, and he is forced to do remedial work for 80% of his day and maybe read books during lecture if his teachers let him. (Yes, I had a few jerk teachers who wouldn't let me read books in class.) In their current form, schools punish intelligence with boredom.
Kids who are ahead the rest of the class are considered finished projects. They're ignored. You can create honors classes, but then the kids who are ahead of the honors classes are ignored. Why do anything for them? They're "done," so you just leave them there like cookies on the cooling rack.
Technology can change that, or at least give the smart kids a chance to make progress. Face it, the kids who are ahead will always be ignored, because teachers are never judged by success, only by the failure rate on standardized tests. So give the kids as much opportunity to make academic progress as possible -- give everyone an interactive curriculum! You can ignore the smart kids as always, but the smart kids will spend their time learning instead of sleeping, sneaking peeks at Isaac Asimov novels, and wondering if next year will be the year that they actually learn something in school.
Nobody thinks it's weird that someone talented at an academic subject says, "X was always easy for me." How many people can say, "Basketball was always easy for me," or, "Violin was always easy for me?" Nobody! Only academics is set up so that someone who is good at, say, math, will never encounter any challenging math until they reach college. Everything else runs the way it should -- no matter how good you are, there's always a challenge to keep you working.
Only computer-based interactive curricula can provide an appropriate pace for all students.
What's cool about "everything is a ..." is that code and understanding for dealing with one entity (such as disk files) can be applied toward other entities (such as network connections). "Everything is an object" only helps if the objects share important characteristics that make them similar to work with. Using a basic definition of "object" -- a piece of data and operations for manipulating it -- Unix qualifies as an "everything is an object" operating system. The operations (i.e., system calls) that may be applied to an object depend on its type (file descriptor, process, network device, etc.) with no operations that may be applied to all objects, leaving no common logic for interacting with the objects. "Everything is a foo" is only helpful if there is a useful set of operations that can be applied to all foos.
"Everything is a bar," on the other hand, would be very useful, because even if they don't have good beer, every bar has someplace to take a leak.
They expect to transition their entire codebase to C++, so I assume they don't depend on Matlab libraries that they don't have the means (and rights) to port to C++ as well -- either that or they're willing to interface their C++ code to the Matlab libraries they depend on.
Matlab also allows the expensive guys with math PhDs to work quickly in a pleasant, familiar, supportive environment. Those guys are smart enough to learn C++ and deal with memory management and templates (often helpful for supremely efficient math code), but it's not a good use of their time if it can be avoided. If you need C++, let the cheap programmers transcribe the Matlab work into C++ and do the tedious job of debugging in C++, while the math guys stay happy and productive in Matlab.
Absolutely correct. Coincidentally, yesterday at the bookstore I saw a book on network programming in Matlab, which was a big surprise (to my non-Matlab-using mind).
Actually, if functional units are done in sequence, then the debugging in the second language will be trivial. After writing, testing, and debugging the Foo function in Matlab, the C++ work will be little more than transcription.
If you can interface Matlab to C++, you can even use the same tests for both codebases.
Specifically, how do you convince them that you're cutting corners like they want when you're actually doing good work? All these new languages/frameworks/methodologies promise that all unnecessary cruft has been taken out, which leaves me the choice of skipping something important (and plunging the project into chaos) or taking a lot of abuse from management for "not understanding the urgency of the situation."
I need a language/framework/methodology with built-in timewasting, so I always have something expendable to sacrifice when management starts screaming, "Days matter! Days matter! Everyone has to pull out all the stops or they're not team players!"
Don't forget about searching other people's documents. This is going to save a lot of bandwidth between government intelligence agencies and the Yahoos and AT&Ts of the world. I can imagine a Chinese (or US) policeman going to the address bar in his browser and typing in a keyword search:
Chinese government agent: "gg agency_id:7789 jurisdiction:china privacy_invasion:name,address,ip democracy"
Google: "Results 1-10 of about 1,755,000 for democracy"
Government agent: "I better surf over to www.government-agent-jobs.cn before I get replaced by a Perl script, 'cause my job just got wayyyy to easy. But first..."
Government agent: "gg agency_id:7789 jurisdiction:jp privacy_invasion:images,video bukkake home movie"
Google: "Invalid agency id for jurisdiction 'Japan'. No bukkake found."
Government agent: "Awwwww."