Python and Ruby are pretty popular and far from weird. Logo was designed for kids, and many of us have fond memories of using it as kids, so it isn't odd that people recommend it.
Java is actually a really poor choice. Java started as a language for set-top boxes but it made it big time because it was a pretty successful attempt to address the concerns of large-scale commercial software development in the late 1990s:
Reliability, for which the language designers chose garbage collection, exceptions, and lack of direct memory access. Those choices are pretty good for beginners, though it's a drag that you have to learn about exceptions right away before you can write any real programs.
Easy, manageable deployment. Beginners don't lose anything here. But now it gets bad....
Easy no-brainer mixing of code from different sources. That means a literally global package namespace based on domain names: com.yourcompany.Foo instead of Foo. For professionals, using this system for a few weeks, especially with IDE support, is enough to convince you that every language should do it that way. It just works without thinking. But for kids and beginners? They get frustrated at having to type a bunch of lengthy imports. They don't need a literally global namespace, but they have to pay the keystroke-and-readability cost of it anyway.
Conceptual tractability of extremely large programs. That means no macros and no operator overloading. The lack of operator overloading is a real frustration for beginners. Beginners don't like special cases; special cases just slow them down and take up extra space in their brains. Why are operators and methods different? If operators don't belong to classes, why can't I define functions that don't belong to classes? Why can classes override toString() but not +?
A language that isn't bristling with features but which contains a fairly idiot-friendly implementation of class-based OO, the most widely understood form of OO in the industry. These two priorities conflict a bit. After adding objects, interfaces, and polymorphism, they started to feel like the language was complicated enough, so they left out everything else. I think that's why there are no namespaces and no free-standing functions -- they hit the limit of their conceptual budget had to do some brutal elimination of features. Classes are used as namespaces and as homes for functions that should be free-standing -- which is a really confusing overloading of the class concept if you're a beginner.
Good-enough performance for the compilers and VMs of the time. That's where we got the stupid difference between Objects and built-ins. It's obvious to professionals why it makes sense -- avoid the overhead of heap Objects with built-in mutexes! But beginners shouldn't have to be exposed to weird language inconsistencies that exist solely as performance hacks.
An easy transition, both intellectually and emotionally, for C++ programmers. That basically determined the entire syntax and (see above) determined that the OO system would be a simplification of C++ classes. Obviously beginners don't benefit from the fact that Java has a lot of superficial similarities to C++, and once again they pay the price without reaping the benefits.
Those are just the warts that come to mind right now. The worst thing about Java is that its warts and oddities can only be explained by saying, "You'll understand someday when you have to work on huge software systems," which to kids sounds the same as, "You'll understand when you're older," the classic parental cop-out.
I think for kids it's better to use a language based on a clean set of abstract concepts, because when a kid asks "Why?" you want to be able to give him an answer that he can grasp without having any experience of large-scale software engineering. Otherwise you're just teaching him that he'll never understand the reasons for things, and the most important decisions are made by people who know better than him. That's not the right lesson to teach a kid, unless you want him to grow up intellectually passive and easily controlled.
I think Python would be great for a first language for kids. Pascal would be a great second language, or a first language for kids who have a desire to be hard-core.
It's easy to forget how fascinating something like Pascal or C++ is the first time you learn it. "Each piece of data lives in memory as a pattern of bits. Because memory is just strings of bits, the program must know what kind of data is encoded in the bits before the memory can be interpreted as a data value."
If you're a jaded C++ programmer, reading that makes you think, "Oh, hell, I see where this is going. I'm going to have to declare the type of every single &^*)&*ing variable. Why the hell do I still have to do this stupid stuff in 2008? Screw it; I've had my fill of shared_ptr<vector<shared_ptr<shared_ptr<Blob> > > > > > > > > > > > > > > and I don't waste my time on type declarations unless I get paid for it."
A kid, on the other hand, thinks "Oh. So that's how it works. I knew Python was too good to be true! The computer doesn't 'just know.' There's a way that it knows, and I'm going to understand it! I'm going to know the secret!"
And then polymorphism, which is especially cool if it's presented to you from two directions, like a cheap paperback thriller bringing two strands of the plot together. Motivation... implementation... motivation... implementation... motivation... implementation... until suddenly you are blown away by the awesome power and simplicity of the vtable.
It gets a lot harder to appreciate things like that when you get old and jaded.
Scheme! There's something great about starting out with an interpreted language - instant results keep kids interested.
Scheme also has the advantage of two brilliant books for beginners, The Little Schemer and The Seasoned Schemer. I think eleven-year-olds would get a kick out of the fact that these books are written for adults, written in fact to be challenging and engaging for adults, yet are written in a very simple format with very simple language, exactly as if they were written for children. The message to adults -- set aside your burden of knowledge, become childlike, start from scratch with Scheme. The message to kids -- this is an area where you can approach serious stuff on equal terms with adults.
As a child, it is always gratifying change to hear that adults would understand better if they were more childlike and less handicapped by experience. That alone is enough to fire a kid's enthusiasm for programming.
I second this post. The Java platform has tons of tools, amenities, and libraries. All you need is a decent language: take your pick! Java the language is now the C of the Java world: it's the lowest common denominator, the systems programming language, and the application language of choice for conservative no-nonsense types.
Scala is the C++ of Java-land: a sophisticated multiparadigm programming language that does everything Java does and more. On the other hand when you compare Scala against C++'s weaknesses, Scala is the anti-C++: terseness through type inference, excellent support for functional programming, small and clean language core, and able to be described in a twenty-page white paper. Suck that, C++!
There are three things that hold python back in scientific computing as far as I am aware and they are iteration, recursion and multithreading.
Finally somebody mentioned threading! I came in here specifically to find out whether 3.0 has any threading improvements. The Python FAQ has long said that they can't get rid of the global interpreter lock for two reasons: It might make Python twice as slow, and it would break all C extensions. If Python 3000 is going to break the C extensions anyway, this would be a perfect time to ditch the GIL. (I don't think anyone would object to making single-threaded Python twice as slow, except maybe web developers.)
I don't see any mention of it anywhere, though, so I'm not optimistic:-(
This is the most valuable post on the page by far, because you only have to read the ensuing discussion to see that the article is correct. Developers who share a common belief in the supremacy of MVC as a pattern can't agree on what Model, View, and Controller mean, even in simple, commonplace situations.
It matters because MVC is promoted as the orthodox and usually correct way to do user interfaces. Nobody gets fired for using MVC.
Why is this bad? Applying a pattern you don't understand is a recipe for obscure, needlessly complicated code. Many people apply MVC, and few people understand it. The results are predictable, yet we believe that programmers should keep striving to follow the MVC pattern.
I think it's time that programmers start demanding clarification every time they hear the term MVC. "MVC? That can mean a bunch of different things. What do you mean by it?" That should cut down on careless and uninformed use of the term.
it is exploitative for any enterprise to pay less than fair compensation in any exchange
I only demand to be compensated for some pain or loss on my part. I don't need to be compensated for pleasure. Should I be jealous of the benefit another party gets when I engage in a mutually beneficial exchange? If I give a gift to someone, should they be angry if I enjoy giving it more than they enjoy receiving it?
Ah, but you said "enterprise." I do believe that companies are inherently more prone to evil than the people they comprise, and they need careful watching and manipulation (by consumers and by regulators) to make sure they don't abuse their economic power or legal status (which is important when dealing with special legal entities such as corporations.) However, when assessing a mutually beneficial exchange with another party, I don't see any need to add a special penalty if the other party is a business entity instead of a person.
most modern companies enterprises take more from the community than they deserve or return
You are playing a subtle game with words here -- if "taking" is bad then you must be referring to some loss or cost incurred by another party. There is surely nothing wrong with "taking" pleasure from someone without incurring any cost or displeasure for them, so you are strictly using the word "take" to refer to the case where one party gets something and as a result the other party loses something.
In this case Netflix may get something from the work around the prize, but what do they take, and who do they take it from? Do they "take" the time and effort of the participants? The participants don't seem to feel that their time and effort are being "lost" in any way, so I don't see how that is possible.
They may "take" some right to any IP generated by the winner, but they will pay one million dollars for it, and any participant who feels that is unfair is free to keep his algorithm to himself instead of submitting his results and claiming the prize.
exploitation is exploitation, self imposed or not; as well, contests are, by their very nature, one-sided, there must be a loser, if there is to be a winner, therefore, competition is only valuable within the framework of co-operation, otherwise, yes, it is exploitative
see? oh well probably not....
I think you don't understand the concept of "fun." Read the article and the comments and tell me that the people "working" at this competition aren't getting paid handsomely. If money is the only compensation that means anything to you, you must be an economist. Congrats, you're doing your part to keep up economics' reputation as the "dismal science."
If it's exploitative for a company to provide enjoyment and intellectual stimulation to a lot of people and benefit financially as a result, then I guess publishing companies don't deserve my support, either. And the movie studios... theater companies... restaurants... and of course any bands that get paid for gigs are just a bunch of ruthless exploiters.
I guess the only commercial entertainment that's okay is what I can enjoy completely passively, without any mental effort at all. That way I'm not being exploited, right? Because work is an awful, awful thing;-)
Wake up; it's not the nineteenth century or even the twentieth century. Everyone has a natural appetite for work, and unlike our unfortunate ancestors, ours is not overwhelmed and sickened by the work required for mere survival. You're addressing a relatively privileged group of people; we earn enough to support ourselves on less work than we have an appetite for. As a result, we don't have to regard all work as a curse imposed on us by necessity. Work freely done and enjoyed is a blessing.
If you insist that our entire appetite for work be channeled through grim-faced contract negotiations, then that blessing is ruined. What's the point of ruining our fun? So you can save us from the misery suffered by our great-grandparents?
Obviously none of what I said applies to call center employees, game company employees, and technical support employees. They should pay careful attention to what you say;-)
She may know more about her aptitude for math than her uncle does. Her uncle clearly has a lot at stake in this decision and may be applying some wishful thinking with regard to his niece's abilities. I wouldn't be surprised if she already told him she wasn't very good at math, but he dismissed it as false modesty or a product of sexism.
My sister and I were both good at specific types of thinking and knew what our strengths and weaknesses were, but we were both valedictorians who aced all our classes and aced both parts of the SAT, so the adults around us tended to think we were both brilliant at everything.
My sister got a near-perfect score on her math SATs, but she knew from her calculus class that she had no aptitude for math. She couldn't solve the problems the "right way," but was bright and diligent enough to memorize all the homework problems and solve problems on her calculus tests by pattern matching -- remembering the homework problem that most resembled the test problem, recreating the solution from memory, and making whatever logical adjustments were required. She understood math when it was explained to her and could make corrections in the solutions, but she couldn't come up with original solutions by herself when given a problem she hadn't seen before. She made her way through high school and college calculus by brute intellectual force -- getting solid As in both, at the cost of lots of crying and shrieking and hurling of books -- and now she has a PhD in history.
I made it through high school literature the same way (minus the crying and shrieking.) If I was primed to see something in a literary work, I could usually see it. Given a literary work with no guidance, it was long gruelling work for me to find any patterns except the ones that resembled ones I had studied in class. I couldn't spot patterns that were generalizations of ones I had already studied. It was a huge frustration to me, and very humbling, that I worked so hard at literature and had so little insight to show for it.
Like my sister and this guy's niece did in math, I aced my English classes and aced the verbal SATs. I even got a 5 on the AP American Literature test. My parents thought I was an intellectually well-rounded kid, but I knew better.
And the bigger and harder their model is, the more ridiculously overconfident they are.
The difficulty of economics is well illustrated by how easily the stock market and the finance industry are swayed by intellectual fads. Of course, good models can't replace fads, because they don't promise neverending risk-free market-beating returns. What you really need is models so complicated that no one can tell whether they're good or bad.
"We have solid everdense that Eye-rack, heh heh heh, uh, 'scuse me, Eye-rack possesses a, er, Helo, er, Halo, Hello, er, sumthinerother. Halo my baby, Halo my darling, halo my, er, gonna bomb their asses. Gonna bomb their asses back to the, um, bombed age. Cuz' that's what happens when you threaten 'muricans with Hellos of Mass Destruction."
Sure it does. The kid gets a kick out of observing and interacting with simple physical phenomena. That's the kind of pleasure that a construction kit offers. A construction kit only seems complex if you think the only way to have fun with it is to build something complex and impressive. If he likes the Levitron, then he'll like playing with basic mechanical pieces (levers, pulleys, gears, batteries, lights, switches) and connecting them together in simple ways.
I.e., by showing an interest in the simple toys mentioned in the summary, the kid has showed he will enjoy playing with a construction set regardless of whether he actually manages to construct a steampunk twitter client out of it.
Simple means different things to different people. What's simpler, a robotics kit or a Sony AIBO?
To one kind of kid, the AIBO is obviously simpler. It's already put together! And it works! What could be simpler than that?
To another kind of kid, the robotics kit is simple. You can understand how it works! You can build your own working gadgets!
To the second kind of kid, the AIBO is intimidating and disheartening. What hope is there of understanding it? Can you even take it apart and put it back together without breaking it? The message is: This is for professionals. Sit through another fifteen years of school and then maybe you'll get to be one of the experts who builds toys, but for now just push the buttons and be entertained.
Other people have answered the "gadget" part of the question better than I can, so I'll pretend I'm a good Slashdotter who didn't read the summary carefully.
1. Fiddling around with things doesn't get you very far without learning the theoretical tools to help you reason about the systems you build. The kid needs math and physics books! Books that teach theory through problems are lots of fun. Some of these are disguised as puzzle books or problem books, but a straight-up problem book (with no theory or exposition) would be too frustrating on its own. All my favorites are sitting neglected on the bookshelves at my parent's house, so unfortunately I can't recommend any.
2. Pop science is pretty good for kids, because it can actually be challenging and educational. (I'm not a big fan of pop science for adults; it's deceptively gratifying.) He'll find those on his own if you just let him loose in a good bookstore.
3. If the kid is a budding geek, you might as well give him a head start on the things he'll find challenging, as well as the things that will come easily to him. You know, how to deal with slippery stuff that can't be defined and figured out, such as people, emotions, and poorly defined ideas like "honesty" and "democracy." For that you just need to give him some toys that aren't fun to use alone (such as sports gear) and some unsupervised time with other kids.
While a lot of CS academics like languages that are powerful for the code you have to write (which is a good reason), do not be surprised when programmers in the real world pick languages that are powerful for the code they don't have to write (aka modules/libraries).
I bet that's aimed at the comp.lang.lisp crowd:-) "Nah, there's no library for X, but why does it matter when it only takes a few hundred lines to implement X in Lisp?"
Besides the availability and quality of libraries, a language's culture and institutions are critical. CPAN is a boon. Javadoc is my favorite thing about Java and the one feature/practice I wish was present in all the other languages I use. Modern package management systems (apt-get et al.) have modernized and streamlined the experience of C development in a dramatic way. Writing in C used to involve a lot of pain in searching for libraries, packaging the libraries for your platform, and managing the installation and deinstallation of the libraries. Now you can just have to package your own code and let the package manager handle your dependencies. Let's hope other languages that are lacking a distribution system figure out how to piggyback on the Unix package managers.
Compare programming in Perl, Ruby, or even C to the state of affairs in Common Lisp -- my favorite language-as-a-language -- where gossip on comp.lang.lisp is the means of finding a library, a url posted on comp.lang.lisp is the means of distribution, and soliciting example code on comp.lang.lisp is the means of documentation. The situation has improved dramatically thanks to CLiki, but CLiki seems to be the work of few next-gen Lispers who understand that such a site is de rigeour, rather than a natural practice by the community as a whole. You get the feeling that many old-school Lispers don't think there's any real advantage to the lazy, ignorance-enabling, immediate gratification way of doing things.
Personally, I love being able to just download a library, install it in a standard way, look at a few examples on the library's web site, and refer to the automatically-generated documentation as needed, but I understand that some people find such a procedure to be utterly tasteless and devoid of adventure. When I was a high schooler taking Latin I, I remember thinking how wonderful it would be if suddenly everything I tried to read was in Latin. Everything at the supermarket -- just a blank package labeled in Latin. Street signs: all the same color and shape, just Latin text. I could struggle through and maybe get bad grades for a year, and then I'd be ninja at Latin. Nowadays such a prospect, while still exciting, fills me with panic. I have too many responsibilities. It would take me three hours to plan and execute a trip to the grocery store. I couldn't check whether the pharmacist handed me the right pill bottle. I'd lose my job. Where would I find a date who wouldn't be weirded out by my unexplainable ineptitude? Starting a project where I had to write most of the libraries myself would feel the same way.
I think all programmers now admit that convenience can trump aesthetics, and real convenience trumps potential convenience, but it's the younger generation that will drive progress, because they simply aren't willing to put up with a language that has no libraries and no community institutions. Most people writing new languages these days take it for granted that their language has to provide good documentation and immediate, natural integration with a vast array of libraries. A decent C ffi no longer suffices, unless your language feels like C and has a traditional code-compile-run cycle. At the moment the only good platforms for a new language are Java and the.NET CLR. Here's hoping Parrot takes off, too, so we have a access to an amenity-rich, library-rich language platform for short-lived programs that need to start up quickly.
Eclipse is a viable alternative for cross-platform GUI development. (Cue the "Java is slow" crowd.) You may end up writing a little bit of JNI boilerplate to interface with libraries, but that's actually quite easy and will account for a trivial proportion of developing any GUI application. Eclipse's plug-in architecture is a great fit for sophisticated, incrementally-developed scientific applications. Plus, the plug-in model and the liberal licensing mean that commercial and open-source code can coexist nicely.
To the original poster: I think you should hire a company to develop an open source application based on a plugin architecture (Eclipse, Qt, and Netbeans all have some support for plugins) that is thoroughly documented and friendly to third-party extensions. That way you aren't dependent on the whims and interests of open-source volunteers, but you create an open platform that encourages open-source contributions and, if your platform becomes popular enough, commercial offerings as well.
There are a two general and powerful emacs tools that every user should know: keyboard macros and query-replace-regexp.
To record a keyboard macro, hit C-x ( to start recording, type your macro, and hit C-x ) to stop. Bind F5 or another function key to call-last-kbd-macro so it's easy to run a macro many times.
Then practice;-) Learn to use C-a, C-e, and incremental search in your macros, so you can just hit F5 F5 F5... to perform a repetitive editing task across an entire file. You will be slow at composing the macros at first, but once you get the hang of it, you'll want to do everything using keyboard macros. (That might be a reasonable approach for some folks, but I recommend you keep going -- there's treasure everywhere!)
Once you're good at keyboard macros, the next thing to learn is query-replace-regexp. The hardest thing about query-replace-regexp is that emacs regexp syntax is a bit of an outlier in the regexp family. Once you get over that (which I haven't entirely) you're a ninja.
After those two, you should google around for more tips of enthusiastic emacs users, and generally keep an ear to the ground. Occasionally you'll hear of some command that is a perfect fit for your work or your brain or both.
Finally, elisp programming is essential for serious users. You don't have to immediately set aside time to learn it, but definitely do not shy away from it when you need it. You'll need a very basic understanding to tweak your.emacs file, and your knowledge can grow from there. I've only written half a dozen elisp functions for editing (rather than configuration) but I use a couple of them at least once a week. The first editing command I created in elisp took me half a day to write and debug, but then I used it dozens of times a day for three weeks -- pretty good ROI!
Re:My advice - don't look for satisfaction in game
on
How Do Games Grow Up?
·
· Score: 1
Strategy games improve planning and leadership abilities.
I agree that video games can challenge your reflexes, spatial thinking, and short-term tactical planning, but you have to be kidding if you think strategy games improve leadership abilities. As for long-term planning, strategy games are pretty lightweight compared to, oh, planning your high school schedule, planning your college degree, planning your career, buying a house, having a kid, or retiring. Even commonplace stuff like planning a small product deployment or planning a dinner party for eight people dwarfs anything you'll experience in a video game.
If you're old enough to be buying your own games, real-life planning has already outstripped video games.
Playing piano is great and all for novelty, but it's not really a useful skill.
I know this is kind of lost knowledge in our day and age, and probably the shocking the first time you contemplate it, but a significant percentage of normal people, probably at least one in four, can actually learn an instrument well enough to provide pleasure to themselves and the people around them.
Yeah. Very lucky indeed. To get a decent course in software engineering, with an emphasis on interviewing techniques and information analysis. You don't really *need* to just code something out of the blue and be lucky to meet the requirements. It's not necessarily a process of trial and error.
The only requirements you can get from users are the ones that they consciously understand and can verbalize effectively. There are painstaking processes you can go through with the users to develop that understanding together. One of the best, in my experience, is showing them working software, or a good mock-up.
Don't think of an unusable early version as a failure. Think of it as a requirements gathering tool, and compare its cost to the cost of doing comprehensive up-front requirements gathering without it.
Slashdot Mirror
Python and Ruby are pretty popular and far from weird. Logo was designed for kids, and many of us have fond memories of using it as kids, so it isn't odd that people recommend it.
Java is actually a really poor choice. Java started as a language for set-top boxes but it made it big time because it was a pretty successful attempt to address the concerns of large-scale commercial software development in the late 1990s:
Those are just the warts that come to mind right now. The worst thing about Java is that its warts and oddities can only be explained by saying, "You'll understand someday when you have to work on huge software systems," which to kids sounds the same as, "You'll understand when you're older," the classic parental cop-out.
I think for kids it's better to use a language based on a clean set of abstract concepts, because when a kid asks "Why?" you want to be able to give him an answer that he can grasp without having any experience of large-scale software engineering. Otherwise you're just teaching him that he'll never understand the reasons for things, and the most important decisions are made by people who know better than him. That's not the right lesson to teach a kid, unless you want him to grow up intellectually passive and easily controlled.
I think Python would be great for a first language for kids. Pascal would be a great second language, or a first language for kids who have a desire to be hard-core.
It's easy to forget how fascinating something like Pascal or C++ is the first time you learn it. "Each piece of data lives in memory as a pattern of bits. Because memory is just strings of bits, the program must know what kind of data is encoded in the bits before the memory can be interpreted as a data value."
If you're a jaded C++ programmer, reading that makes you think, "Oh, hell, I see where this is going. I'm going to have to declare the type of every single &^*)&*ing variable. Why the hell do I still have to do this stupid stuff in 2008? Screw it; I've had my fill of shared_ptr<vector<shared_ptr<shared_ptr<Blob> > > > > > > > > > > > > > > and I don't waste my time on type declarations unless I get paid for it."
A kid, on the other hand, thinks "Oh. So that's how it works. I knew Python was too good to be true! The computer doesn't 'just know.' There's a way that it knows, and I'm going to understand it! I'm going to know the secret!"
And then polymorphism, which is especially cool if it's presented to you from two directions, like a cheap paperback thriller bringing two strands of the plot together. Motivation... implementation... motivation... implementation... motivation... implementation... until suddenly you are blown away by the awesome power and simplicity of the vtable.
It gets a lot harder to appreciate things like that when you get old and jaded.
Scheme! There's something great about starting out with an interpreted language - instant results keep kids interested.
Scheme also has the advantage of two brilliant books for beginners, The Little Schemer and The Seasoned Schemer. I think eleven-year-olds would get a kick out of the fact that these books are written for adults, written in fact to be challenging and engaging for adults, yet are written in a very simple format with very simple language, exactly as if they were written for children. The message to adults -- set aside your burden of knowledge, become childlike, start from scratch with Scheme. The message to kids -- this is an area where you can approach serious stuff on equal terms with adults.
As a child, it is always gratifying change to hear that adults would understand better if they were more childlike and less handicapped by experience. That alone is enough to fire a kid's enthusiasm for programming.
I second this post. The Java platform has tons of tools, amenities, and libraries. All you need is a decent language: take your pick! Java the language is now the C of the Java world: it's the lowest common denominator, the systems programming language, and the application language of choice for conservative no-nonsense types.
Scala is the C++ of Java-land: a sophisticated multiparadigm programming language that does everything Java does and more. On the other hand when you compare Scala against C++'s weaknesses, Scala is the anti-C++: terseness through type inference, excellent support for functional programming, small and clean language core, and able to be described in a twenty-page white paper. Suck that, C++!
Finally somebody mentioned threading! I came in here specifically to find out whether 3.0 has any threading improvements. The Python FAQ has long said that they can't get rid of the global interpreter lock for two reasons: It might make Python twice as slow, and it would break all C extensions. If Python 3000 is going to break the C extensions anyway, this would be a perfect time to ditch the GIL. (I don't think anyone would object to making single-threaded Python twice as slow, except maybe web developers.)
I don't see any mention of it anywhere, though, so I'm not optimistic :-(
This is the most valuable post on the page by far, because you only have to read the ensuing discussion to see that the article is correct. Developers who share a common belief in the supremacy of MVC as a pattern can't agree on what Model, View, and Controller mean, even in simple, commonplace situations.
It matters because MVC is promoted as the orthodox and usually correct way to do user interfaces. Nobody gets fired for using MVC.
Why is this bad? Applying a pattern you don't understand is a recipe for obscure, needlessly complicated code. Many people apply MVC, and few people understand it. The results are predictable, yet we believe that programmers should keep striving to follow the MVC pattern.
I think it's time that programmers start demanding clarification every time they hear the term MVC. "MVC? That can mean a bunch of different things. What do you mean by it?" That should cut down on careless and uninformed use of the term.
If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.
it is exploitative for any enterprise to pay less than fair compensation in any exchange
I only demand to be compensated for some pain or loss on my part. I don't need to be compensated for pleasure. Should I be jealous of the benefit another party gets when I engage in a mutually beneficial exchange? If I give a gift to someone, should they be angry if I enjoy giving it more than they enjoy receiving it?
Ah, but you said "enterprise." I do believe that companies are inherently more prone to evil than the people they comprise, and they need careful watching and manipulation (by consumers and by regulators) to make sure they don't abuse their economic power or legal status (which is important when dealing with special legal entities such as corporations.) However, when assessing a mutually beneficial exchange with another party, I don't see any need to add a special penalty if the other party is a business entity instead of a person.
most modern companies enterprises take more from the community than they deserve or return
You are playing a subtle game with words here -- if "taking" is bad then you must be referring to some loss or cost incurred by another party. There is surely nothing wrong with "taking" pleasure from someone without incurring any cost or displeasure for them, so you are strictly using the word "take" to refer to the case where one party gets something and as a result the other party loses something.
In this case Netflix may get something from the work around the prize, but what do they take, and who do they take it from? Do they "take" the time and effort of the participants? The participants don't seem to feel that their time and effort are being "lost" in any way, so I don't see how that is possible.
They may "take" some right to any IP generated by the winner, but they will pay one million dollars for it, and any participant who feels that is unfair is free to keep his algorithm to himself instead of submitting his results and claiming the prize.
exploitation is exploitation, self imposed or not; as well, contests are, by their very nature, one-sided, there must be a loser, if there is to be a winner, therefore, competition is only valuable within the framework of co-operation, otherwise, yes, it is exploitative
see? oh well probably not....
I think you don't understand the concept of "fun." Read the article and the comments and tell me that the people "working" at this competition aren't getting paid handsomely. If money is the only compensation that means anything to you, you must be an economist. Congrats, you're doing your part to keep up economics' reputation as the "dismal science."
If it's exploitative for a company to provide enjoyment and intellectual stimulation to a lot of people and benefit financially as a result, then I guess publishing companies don't deserve my support, either. And the movie studios... theater companies... restaurants... and of course any bands that get paid for gigs are just a bunch of ruthless exploiters.
I guess the only commercial entertainment that's okay is what I can enjoy completely passively, without any mental effort at all. That way I'm not being exploited, right? Because work is an awful, awful thing ;-)
Wake up; it's not the nineteenth century or even the twentieth century. Everyone has a natural appetite for work, and unlike our unfortunate ancestors, ours is not overwhelmed and sickened by the work required for mere survival. You're addressing a relatively privileged group of people; we earn enough to support ourselves on less work than we have an appetite for. As a result, we don't have to regard all work as a curse imposed on us by necessity. Work freely done and enjoyed is a blessing.
If you insist that our entire appetite for work be channeled through grim-faced contract negotiations, then that blessing is ruined. What's the point of ruining our fun? So you can save us from the misery suffered by our great-grandparents?
Obviously none of what I said applies to call center employees, game company employees, and technical support employees. They should pay careful attention to what you say ;-)
Noob question: can you simulate high network latency and other network performance problems between VMs?
http://www.google.com/url?sa=t&source=web&ct=res&cd=5&url=http%3A%2F%2Fcs.anu.edu.au%2F~Peter.Strazdins%2Fseminars%2FdJVM.pdf&ei=FK0kSafSAZSo0gScxs3FDw&usg=AFQjCNHrPDWFanLbyUu3kX-lEkzZrWR6bw&sig2=jcMo0CIWzGg_nZVLvDHpxA
My first thought on reading this post was that the super-long Google url WAS the cluster-aware distributed virtual machine.
So, how long until Google reveals its next project: Compile C++ to a Google URL, and visit the URL to see your program running?
She may know more about her aptitude for math than her uncle does. Her uncle clearly has a lot at stake in this decision and may be applying some wishful thinking with regard to his niece's abilities. I wouldn't be surprised if she already told him she wasn't very good at math, but he dismissed it as false modesty or a product of sexism.
My sister and I were both good at specific types of thinking and knew what our strengths and weaknesses were, but we were both valedictorians who aced all our classes and aced both parts of the SAT, so the adults around us tended to think we were both brilliant at everything.
My sister got a near-perfect score on her math SATs, but she knew from her calculus class that she had no aptitude for math. She couldn't solve the problems the "right way," but was bright and diligent enough to memorize all the homework problems and solve problems on her calculus tests by pattern matching -- remembering the homework problem that most resembled the test problem, recreating the solution from memory, and making whatever logical adjustments were required. She understood math when it was explained to her and could make corrections in the solutions, but she couldn't come up with original solutions by herself when given a problem she hadn't seen before. She made her way through high school and college calculus by brute intellectual force -- getting solid As in both, at the cost of lots of crying and shrieking and hurling of books -- and now she has a PhD in history.
I made it through high school literature the same way (minus the crying and shrieking.) If I was primed to see something in a literary work, I could usually see it. Given a literary work with no guidance, it was long gruelling work for me to find any patterns except the ones that resembled ones I had studied in class. I couldn't spot patterns that were generalizations of ones I had already studied. It was a huge frustration to me, and very humbling, that I worked so hard at literature and had so little insight to show for it.
Like my sister and this guy's niece did in math, I aced my English classes and aced the verbal SATs. I even got a 5 on the AP American Literature test. My parents thought I was an intellectually well-rounded kid, but I knew better.
And the bigger and harder their model is, the more ridiculously overconfident they are.
The difficulty of economics is well illustrated by how easily the stock market and the finance industry are swayed by intellectual fads. Of course, good models can't replace fads, because they don't promise neverending risk-free market-beating returns. What you really need is models so complicated that no one can tell whether they're good or bad.
And that's exactly how we created the credit crisis.
"We have solid everdense that Eye-rack, heh heh heh, uh, 'scuse me, Eye-rack possesses a, er, Helo, er, Halo, Hello, er, sumthinerother. Halo my baby, Halo my darling, halo my, er, gonna bomb their asses. Gonna bomb their asses back to the, um, bombed age. Cuz' that's what happens when you threaten 'muricans with Hellos of Mass Destruction."
Sure it does. The kid gets a kick out of observing and interacting with simple physical phenomena. That's the kind of pleasure that a construction kit offers. A construction kit only seems complex if you think the only way to have fun with it is to build something complex and impressive. If he likes the Levitron, then he'll like playing with basic mechanical pieces (levers, pulleys, gears, batteries, lights, switches) and connecting them together in simple ways.
I.e., by showing an interest in the simple toys mentioned in the summary, the kid has showed he will enjoy playing with a construction set regardless of whether he actually manages to construct a steampunk twitter client out of it.
Simple means different things to different people. What's simpler, a robotics kit or a Sony AIBO?
To one kind of kid, the AIBO is obviously simpler. It's already put together! And it works! What could be simpler than that?
To another kind of kid, the robotics kit is simple. You can understand how it works! You can build your own working gadgets!
To the second kind of kid, the AIBO is intimidating and disheartening. What hope is there of understanding it? Can you even take it apart and put it back together without breaking it? The message is: This is for professionals. Sit through another fifteen years of school and then maybe you'll get to be one of the experts who builds toys, but for now just push the buttons and be entertained.
Other people have answered the "gadget" part of the question better than I can, so I'll pretend I'm a good Slashdotter who didn't read the summary carefully.
1. Fiddling around with things doesn't get you very far without learning the theoretical tools to help you reason about the systems you build. The kid needs math and physics books! Books that teach theory through problems are lots of fun. Some of these are disguised as puzzle books or problem books, but a straight-up problem book (with no theory or exposition) would be too frustrating on its own. All my favorites are sitting neglected on the bookshelves at my parent's house, so unfortunately I can't recommend any.
2. Pop science is pretty good for kids, because it can actually be challenging and educational. (I'm not a big fan of pop science for adults; it's deceptively gratifying.) He'll find those on his own if you just let him loose in a good bookstore.
3. If the kid is a budding geek, you might as well give him a head start on the things he'll find challenging, as well as the things that will come easily to him. You know, how to deal with slippery stuff that can't be defined and figured out, such as people, emotions, and poorly defined ideas like "honesty" and "democracy." For that you just need to give him some toys that aren't fun to use alone (such as sports gear) and some unsupervised time with other kids.
While a lot of CS academics like languages that are powerful for the code you have to write (which is a good reason), do not be surprised when programmers in the real world pick languages that are powerful for the code they don't have to write (aka modules/libraries).
I bet that's aimed at the comp.lang.lisp crowd :-) "Nah, there's no library for X, but why does it matter when it only takes a few hundred lines to implement X in Lisp?"
Besides the availability and quality of libraries, a language's culture and institutions are critical. CPAN is a boon. Javadoc is my favorite thing about Java and the one feature/practice I wish was present in all the other languages I use. Modern package management systems (apt-get et al.) have modernized and streamlined the experience of C development in a dramatic way. Writing in C used to involve a lot of pain in searching for libraries, packaging the libraries for your platform, and managing the installation and deinstallation of the libraries. Now you can just have to package your own code and let the package manager handle your dependencies. Let's hope other languages that are lacking a distribution system figure out how to piggyback on the Unix package managers.
Compare programming in Perl, Ruby, or even C to the state of affairs in Common Lisp -- my favorite language-as-a-language -- where gossip on comp.lang.lisp is the means of finding a library, a url posted on comp.lang.lisp is the means of distribution, and soliciting example code on comp.lang.lisp is the means of documentation. The situation has improved dramatically thanks to CLiki, but CLiki seems to be the work of few next-gen Lispers who understand that such a site is de rigeour, rather than a natural practice by the community as a whole. You get the feeling that many old-school Lispers don't think there's any real advantage to the lazy, ignorance-enabling, immediate gratification way of doing things.
Personally, I love being able to just download a library, install it in a standard way, look at a few examples on the library's web site, and refer to the automatically-generated documentation as needed, but I understand that some people find such a procedure to be utterly tasteless and devoid of adventure. When I was a high schooler taking Latin I, I remember thinking how wonderful it would be if suddenly everything I tried to read was in Latin. Everything at the supermarket -- just a blank package labeled in Latin. Street signs: all the same color and shape, just Latin text. I could struggle through and maybe get bad grades for a year, and then I'd be ninja at Latin. Nowadays such a prospect, while still exciting, fills me with panic. I have too many responsibilities. It would take me three hours to plan and execute a trip to the grocery store. I couldn't check whether the pharmacist handed me the right pill bottle. I'd lose my job. Where would I find a date who wouldn't be weirded out by my unexplainable ineptitude? Starting a project where I had to write most of the libraries myself would feel the same way.
I think all programmers now admit that convenience can trump aesthetics, and real convenience trumps potential convenience, but it's the younger generation that will drive progress, because they simply aren't willing to put up with a language that has no libraries and no community institutions. Most people writing new languages these days take it for granted that their language has to provide good documentation and immediate, natural integration with a vast array of libraries. A decent C ffi no longer suffices, unless your language feels like C and has a traditional code-compile-run cycle. At the moment the only good platforms for a new language are Java and the .NET CLR. Here's hoping Parrot takes off, too, so we have a access to an amenity-rich, library-rich language platform for short-lived programs that need to start up quickly.
Eclipse is a viable alternative for cross-platform GUI development. (Cue the "Java is slow" crowd.) You may end up writing a little bit of JNI boilerplate to interface with libraries, but that's actually quite easy and will account for a trivial proportion of developing any GUI application. Eclipse's plug-in architecture is a great fit for sophisticated, incrementally-developed scientific applications. Plus, the plug-in model and the liberal licensing mean that commercial and open-source code can coexist nicely.
To the original poster: I think you should hire a company to develop an open source application based on a plugin architecture (Eclipse, Qt, and Netbeans all have some support for plugins) that is thoroughly documented and friendly to third-party extensions. That way you aren't dependent on the whims and interests of open-source volunteers, but you create an open platform that encourages open-source contributions and, if your platform becomes popular enough, commercial offerings as well.
There's an emacs keybinding, but as far as I can tell, it just handles navigation within a file and basic editing commands: cut, copy, and paste.
There are a two general and powerful emacs tools that every user should know: keyboard macros and query-replace-regexp.
To record a keyboard macro, hit C-x ( to start recording, type your macro, and hit C-x ) to stop. Bind F5 or another function key to call-last-kbd-macro so it's easy to run a macro many times.
Then practice ;-) Learn to use C-a, C-e, and incremental search in your macros, so you can just hit F5 F5 F5... to perform a repetitive editing task across an entire file. You will be slow at composing the macros at first, but once you get the hang of it, you'll want to do everything using keyboard macros. (That might be a reasonable approach for some folks, but I recommend you keep going -- there's treasure everywhere!)
Once you're good at keyboard macros, the next thing to learn is query-replace-regexp. The hardest thing about query-replace-regexp is that emacs regexp syntax is a bit of an outlier in the regexp family. Once you get over that (which I haven't entirely) you're a ninja.
After those two, you should google around for more tips of enthusiastic emacs users, and generally keep an ear to the ground. Occasionally you'll hear of some command that is a perfect fit for your work or your brain or both.
Finally, elisp programming is essential for serious users. You don't have to immediately set aside time to learn it, but definitely do not shy away from it when you need it. You'll need a very basic understanding to tweak your .emacs file, and your knowledge can grow from there. I've only written half a dozen elisp functions for editing (rather than configuration) but I use a couple of them at least once a week. The first editing command I created in elisp took me half a day to write and debug, but then I used it dozens of times a day for three weeks -- pretty good ROI!
Strategy games improve planning and leadership abilities.
I agree that video games can challenge your reflexes, spatial thinking, and short-term tactical planning, but you have to be kidding if you think strategy games improve leadership abilities. As for long-term planning, strategy games are pretty lightweight compared to, oh, planning your high school schedule, planning your college degree, planning your career, buying a house, having a kid, or retiring. Even commonplace stuff like planning a small product deployment or planning a dinner party for eight people dwarfs anything you'll experience in a video game.
If you're old enough to be buying your own games, real-life planning has already outstripped video games.
Playing piano is great and all for novelty, but it's not really a useful skill.
I know this is kind of lost knowledge in our day and age, and probably the shocking the first time you contemplate it, but a significant percentage of normal people, probably at least one in four, can actually learn an instrument well enough to provide pleasure to themselves and the people around them.
Yeah. Very lucky indeed. To get a decent course in software engineering, with an emphasis on interviewing techniques and information analysis. You don't really *need* to just code something out of the blue and be lucky to meet the requirements. It's not necessarily a process of trial and error.
The only requirements you can get from users are the ones that they consciously understand and can verbalize effectively. There are painstaking processes you can go through with the users to develop that understanding together. One of the best, in my experience, is showing them working software, or a good mock-up.
Don't think of an unusable early version as a failure. Think of it as a requirements gathering tool, and compare its cost to the cost of doing comprehensive up-front requirements gathering without it.
Always code from scratch. The time saved from complete understanding of your own code is hard to describe.
Maybe you need to get better at understanding code you didn't write.