Programming is different. Your example of needing to know local and dialectical idioms is misleading, because programming language idioms are more abstract and harder to learn than natural language idioms. (I assume you didn't intend the more general use of the word "idiom.")
A natural language idiom is essentially an item of vocabulary. "Flying off the handle" is a natural language idiom idiom; it is complete and includes no new systematic way to vary its meaning. A programming language idiom has any number of opportunities for parameterization and may require learning new language concepts that were not necessary to understand before. So the difference is between learning syntax (and language features) and learning vocabulary. With that established, I think there are three drawbacks to having such a rich set of language syntax and features that users consistently find themselves confronted with novel "idioms":
First, syntax and features are harder to learn than vocabulary. Vocabulary is provided in lists for memorization; grammar is described at great length (or defined mathematically) and cannot simply be memorized in bulk. Learning new syntax requires establishing a new habit of thought, which must be practiced and reinforced before it can be used naturally. New vocabulary items (classes, functions) are just as easily forgotten but much more quickly grasped. (That is, unless the language requires the use of mind-bending vocabulary, like Haskell Monads.)
Second, language syntax or vocabulary can be designed for straightforwardness and quick learning or for power in the hands of a master. Perl language features, especially the ones that one tends to encounter for the first time in unfamiliar code, are of the latter kind. (Not that Perl is unusual in this... quite the contrary.) One can't simply look them up, read the definition, and return to work thirty seconds later.
Third, good practice dictates that a programmer document any language extensions (syntax or vocabulary) that he or she defines and expects others to understand. Appropriate documentation is provided given the expected knowledge of the users. Standard language features are exempt from this practice, however, leaving the users of source code to find their own documentation, which will likely be the standard documentation of the language feature in its full generality, the grokking of which may in itself be a larger project than the perusal of the original code should have been.
It is my opinion, based on a few efforts to use Perl 5 as a scripting and glue language, that Perl repays only those who consistently use the language and have no reservations about getting deeper and deeper into it. It is not possible to exclude or ignore the full diversity of the language when estimating the cost of using Perl, because circumstances can and eventually will force you to learn every feature. This happens even if you do not modify or support other programmers' code, because documentation -- of libraries, of programming techniques, of the language environment, and of language features you do want to use -- so often takes the form of code. What you learn and do not use in your own code, you may forget only to be forced to relearn it later.
This is a drawback of the language, but not necessarily a flaw that needs to be corrected. The same thing is true of C++, which I use quite happily because I accepted (and continue to accept) the necessary commitment. The size and complexity (aka "diversity") of the language is a burden as well as a treasure chest. It is simply the downside of a language design choice which should be noted as part of the essential personality of Perl, as it is for C++.
I don't claim to be an expert in PCA but in a 40-dual core setup I expect that the parallelism of the system needs to be extracted by the programmer..rather than the compiler. With an 80 core single die system the drive for creating a parallizing compiler would be massive (and lucrative).
I don't understand how packaging the cores in a single chip changes the architecture or makes it any easier to write a parallelizing compiler. The memory architecture on a massively multicore chip will probably be based on memory architectures in multiple-CPU systems, with any differences driven by different performance characteristics.
In any case, a parallelizing compiler needs parallelizable code to work with. Using any of the currently popular languages, a compiler will have even more trouble finding parallelization than programmers. No matter where the parallelization comes from, the programmers will have to change, by learning new design techniques or learning new languages.
Using current thinking, an application can be naturally separated into a certain number of threads, and for CPU-intensive applications it's pretty easy to get that number higher than the number of available cores -- if the number of cores is two or four. Eighty? That's a bit harder, to say the least. That will require serious support from languages or new kinds of application frameworks that I can't even imagine.
I can see it now: write contracts in a new template language, use template parameters to control run-time checking, and since it's all pure C++ (no macros), you can produce the contract documentation from the output of gccxml.
I mock, but now I really want to try it. Off to hack my own half-assed version -- Friday nights rule!
Right, because all of us who learned on Apple IIe's and 286s running DOS were completely at a loss when Windows 3.1 came out, Windows 95 shook our faith, Windows 2000 pushed us to the edge, and OSX reduced us to pathetic, babbling morons who beg for change on street corners.
Everyone my age went from the Commodore 64 era to the OSX era in twenty years. It wasn't that hard. What will these kids miss if they start out with a text interface? Easy stuff:
- multitasking (possibly) - using a mouse (possibly) - WIMPy GUI idioms
What will they *not* miss? Important stuff:
- computer basics (turning it on, watching it boot, shutting it down safely, handling the hardware) - program concept (running, stopping, crashing) - file concept (opening, saving, copying, overwriting, losing) - communications methods (email, chat, file transfer) - hyperlinked text documents - typing - basic office software (word processing, spreadsheets, and basic database concepts) - whatever CS concepts you want to teach them
I say the elements they miss will be easily picked up later, and text interfaces offer plenty of opportunity to learn the fundamental, difficult elements that cause big problems for people who don't get them. Some adults just never master WIMP, but these are elementary school kids. They have ten years before their minds turn to concrete.
Plenty of things that are illegal now, and seem unimaginably repugnant, used to be legal. Or at least there was no legal penalty for them, or plenty of disincentive for law enforcement to investigate. Both parties used dirty tricks, but the Democrats were recognized (fairly or unfairly) as more sophisticated, shameless, and successful at cheating, just as Republicans are now. Perhaps that reputation comes inevitably with success.
In any case, it would be a shame if we stopped caring about election fraud and stopped passing laws against new dirty tricks invented by the political parties, especially since the latest tricks are aimed at stopping citizens from voting.
- looking like a dork - not getting there much faster than pedestrians - demanding a bunch of freakin' space to stow my ride when I get there - not even getting a decent workout or saving any energy
So unless you're fat and want to stay that way, a cheap bike or just walking beats it hands down.
There's a tour company in my town that gives tours on segways. I've seen them in use, and they are useless. They can't go fast on pedestrian sidewalks. If part of my downtown real estate is going to be repurposed for transportation, let it be for cyclists. At least those guys are willing to put one foot in front of the other (or move them in little circles, rather) for the planet. It's a small gesture, but what does it say that some people are willing to pay thousands dollars just so they can use coal energy instead of their excess fat? (By the way, I don't begrudge old or handicapped people their transportation, just the fat lazy bastards who look forward to never walking again.)
I've tried the Yahoo Mail Beta three times in the last six months, most recently in August, and I quit each time because the interface just wasn't slick enough, partly due to performance on my laptop (1.4 GHz Celeron with 1GB RAM). I read my mail faster using the old interface, making heavy use of browser tabs. Maybe it's just my machine, but frankly, I'm a little ticked off that all this Web 2.0 stuff hasn't produced ANY real improvement in Yahoo Mail, which has both my primary mail accounts. Somewhere there's a usability sweet spot between the old-fashioned web interface and a slow emulation of an old-fashioned email client, but Yahoo just gives you a choice between the two and calls it progress.
I'm still decently satisfied with the old Yahoo interface, so I'm not ready to jump to the next big thing yet, but if I were, I would take Gmail. Gmail is pretty slick and usably fast. I had issues adjusting to using tags, but with help from someone who really understands them, my Gmail account is in decent shape and much more pleasant to use than Yahoo.
Maybe along with the "Learn to Program" IDE Microsoft could offer a programming magazine for kids, like "Ranger Rick." Typing in programs from a magazine might be more fun for a kid than downloading them.
I think you're on to something with the lingua franca. I learned BASIC on Apple IIe computers, and I remember coming across an IBM-compatible in someone else's school, somehow getting into BASIC, and writing and running complete programs. I remember that some of the Applesoft commands for moving the cursor around on the screen didn't work, and I couldn't figure out how to renumber lines. Other than that, it was all the same.
That isn't just a lingua franca, it's an entire programming interface, and it let me transfer my knowledge from the Apple II line to its mortal enemy and diametrical opposite, the IBM-compatible!
And guess who we have to thank for that? (Hint: Replace the first five letters in "Applesoft BASIC.")
Re OO, I believe you have it completely backward. It's designed to map to the thought processes of people who approach coding intuitively rather than analytically or mathematically. Using OO code is extremely natural for such people. The difficulty of writing it is a tradeoff.
Languages produced for practical use by non-geniuses are almost always OO these days, viz C++, Java, Python. Languages produced by mathematically and theoretically inclined people tend to have OO tacked on later by other people, viz Scheme, Haskell, ML. (Note that Scheme is very OO, but OO in a theoretical sense, so you'll have a hard time convincing J. Average Programmer that it's OO.)
And all the "unnecessary verbiage" is included to help J. Average Programmer work on huge apps in complicated environments with tons of other non-mathematically inclined people. People working on clean, simple, mathematical problems would rather live without it unless they absolutely need it. Once again, viz Scheme and Haskell vs. Java.
I think you're getting theoreticians confused with big-iron, big-problem engineers. Professors come in both types. The mathematicians are on your side.
Then, when this gets frustrating, teach the rugrat how to save the program in a file, and run it that way.
Anything that requires parental intervention is inferior to BASIC.
Oh, and BASIC in old personal computers let you PEEK and POKE arbitrary memory locations, the meanings of which were documented in the manuals shipped with the computers. You could write to video memory, mess with memory-mapped hardware, hack a running OS, stuff like that. I never did it because I read I could permanently damage the computer, but I guess some kids were less wussy than me:-)
In most households he is introduced at an early age to the computer as a toy and treats it as a toy while growing up.
I don't understand. Isn't that exactly how Bill Gates, RMS, and every regular schmoe like me looked at computers when they were kids? Yet we programmed our asses off and ended up becoming professionals.
You can stand behind behind your kids with a whip if you want, saying "NO! Stop having FUN! Grit your teeth and do it GRIMLY like a good worker!" Just remember that treating the computer as a toy has an established track record of producing millionaires and brilliant technologists.
Funny that kids today are pretty good at video games that are longer and more complicated than the ones we played, eh?
What kids are after is fun. I did a ton of programming when I was a kid, and I never seriously considered doing it for a living until after I graduated from college. It was just fun.
What's missing is that programming languages used to be built into the computer. For me, BASIC was there when I booted up the computer. Documentation aimed at complete beginners like me was the norm. It would have been hard *not* to program.
These days the easiest way to start out would be with Python. It seems simple to us, but...
1 - know it exists 2 - know how to download the right version for your computer (not a mac or linux version) 3 - find the installer and know to run it (and know that it's safe) 4 - figure out how to invoke the installed program (ok, that one's easy) 5 - find documentation written for beginning programmers 6 - figure out why python won't run the programs you saved as.doc files
Can you imagine an eight-year-old Windows user with clueless parents doing all that by himself?
I didn't have to download anything or know anything about operating systems. I don't remember having to sort through tons of titles like "Advanced BASIC Beowulf Architectures in 2 Minutes for J2EE Certified Hardware Astroengineers" at the bookstore to find one that was right for me. In fact, I'm pretty sure the book I used came in the same box as the computer. Plus, all the computer magazines had program listings in the back that you could type in.
Microsoft would earn big brownie points with parents if they included an extremely simple IronPython-based (or even Logo-based) "Learn To Program" IDE with every copy of Windows. Twenty years ago, people knew how to write documentation for beginners. (Not children or computerphobes. Not people with congenital learning disabilities. Just beginners, of all kinds and ages.) I'm sure it could be done again.
Aside from working on well-designed apps written by other people and creating a few amusements, I have converted a single-threaded, single-process commercial application to a multithreaded application.
But who care? Everything I learned could be summed up in a bunch of platitudes anyway. Platitudes wouldn't be so damned popular if people didn't cause most of their own problems by ignoring known facts and techniques. So it is with threading.
Episodes I, II, and III may have been decent movies, but they weren't a good-faith attempt to carry on the Star Wars tradition. The original trilogy was a sensation. It amazed people, stuck with people, and continued to win new fans for decades.
The last three were "family films" in the recent tradition: a hodgepodge of elements, each aimed at making the movie tolerable to certain kind of person (including, let us not forget, the rabid fans -- who predictably oohed and ahhed over the little tidbits that were engineered to appeal to them.) This is standard Hollywood technique, and it guarantees mediocre, forgettable movies. Which is not to say that the followups weren't decent. They were decent in the sense that if you had normal movie expectations (entirely uninfluenced by the original trilogy) then you probably weren't pissed off at how you spent $8 and one evening.
However, they were a betrayal in the sense that those involved did NOT attempt to make worthy successors to the original movies. They knew from the start that they were going to make mediocre movies with wide appeal, because it would have been financially irresponsible to do anything else.
It could have been worse -- they might have skimped on the budget. At least we got high-dollar special effects and a pretty good cast. Can you imagine Episodes I-III starring Elizabeth Berkley, Charlie Sheen, and Miguel Ferrer?
creates as many discrete processes as makes sense for the game
I love this comment; wish I had mod points. Most of the difficulty with concurrent programming happens because programmers brutally hack a single-threaded program into an arbitrary number of pieces without looking for the easy, logical way to decompose it. A good programmer thinks like a butcher, cuts at the joints, and doesn't work half as hard as the programmer who saws through a program's bones and tries to knit them back together with mutexes.
I think he's saying that a lot of web sites selling extremely cheap single-purpose Windows utilities sell malware or redundant software that is no easier to use than the already existing functionality in Windows. He may be right. I never buy from software from websites except when I have a recommendation from someone I personally know and trust, because I can't see any other way to differentiate scam artists from honest vendors. Their web design skills aren't any worse.
You're only paid to do your job and you did your job. If they don't listen to your advice that's their problem.
It also may be time for him to ask what you wants to do with his career. He obviously has no credibility with management and will be nothing but an "OMG fix the Internet" monkey. If he ever wants to be anything more, he needs to leave.
Poster, time to start taking yourself seriously and demanding that others do so! Or gain forty pounds, grow a ponytail, and prepare yourself for a life of Cheeto-stained, bottom-of-the-totem-pole geekdom.
My point, which you obviously missed, remains that you either have to subscribe to it 100% to participate in any way.
Incorrect. You can develop and use GPL'ed code without incorporating GPL'ed code into works that you distribute under another license. That means you can run a secret Linux derivative on your own servers, sell a proprietary closed-source application that runs on Linux, and contribute enhancements to the Linux kernel, all without violating the GPL. IBM and Google participate, but they don't "subscribe to it 100%." Just ask them for a peek at their proprietary source code if you don't believe me.
That's not what a web designer does. You can only get it right down to the pixel for users running a single browser at a single screen resolution with a single set of browser settings. A good web designer has to understand what a web page is and design to its strengths and weaknesses, not pretend that he's doing design for television or print media.
So why should you spend a lot of time looking at the code trying to figure out why you get a null pointer when you can step through and see it? Short of first year CS students, it's not much of a learning experience.
It absolutely _should_ be a learning experience. If you don't understand why the segfault can't happen, you don't have sufficient understanding of the code to modify it. If you do understand why the segfault can't happen, then you have an incorrect understanding of the code, because obviously the segfault did happen. Either way you need to learn -- you can't check that section of code in until you prove to your satisfaction that it works. A debugger can't speed up that process at all, so the only work it can speed up is sloppy work. Now don't get me wrong; sometimes you're judged by the standards of sloppy work, and doing careful work will only get you yelled at for being slow. IDEs and debuggers decrease the cost of slapping quick patches on problems, so the cost of creating bugs is lower, and many bosses never bother to ask where a bug came from. They just pat you on the back for fixing it. But you'll never create a stable system that way.
I aggree, but he said inhibit applying to anyone.
Making sloppy coding easy inhibits careful coding because we're human. You look at a huge function with cryptic comments and think, "God, who wrote this? No wonder it contains bugs." You can do the right thing and painstakingly build up an understanding of the function until you understand it well enough to modify it. That will take two hours, and you'll be brain-dead for your lunch date. Or you can fire up the debugger, find the error, trace back to a line that looks like a mistake, change the line, verify that the test case doesn't crash anymore, and get on Slashdot or Boing Boing to find interesting conversation starters for lunch.
Similar choices crop up when writing new code. That's how a fancy IDE with a nice debugger turns every programming task into a test of character. Using a text editor for everything is like living on a farm -- it doesn't exactly build character, it just excludes the temptations that would reveal deficiencies in character:-)
Slashdot Mirror
Selecting people randomly requires demographic guesswork, unless you have an exit poller at every polling place.
Oops. I meant nothing special by "idiom idiom;" it's just a typo that slipped through.
A natural language idiom is essentially an item of vocabulary. "Flying off the handle" is a natural language idiom idiom; it is complete and includes no new systematic way to vary its meaning. A programming language idiom has any number of opportunities for parameterization and may require learning new language concepts that were not necessary to understand before. So the difference is between learning syntax (and language features) and learning vocabulary. With that established, I think there are three drawbacks to having such a rich set of language syntax and features that users consistently find themselves confronted with novel "idioms":
First, syntax and features are harder to learn than vocabulary. Vocabulary is provided in lists for memorization; grammar is described at great length (or defined mathematically) and cannot simply be memorized in bulk. Learning new syntax requires establishing a new habit of thought, which must be practiced and reinforced before it can be used naturally. New vocabulary items (classes, functions) are just as easily forgotten but much more quickly grasped. (That is, unless the language requires the use of mind-bending vocabulary, like Haskell Monads.)
Second, language syntax or vocabulary can be designed for straightforwardness and quick learning or for power in the hands of a master. Perl language features, especially the ones that one tends to encounter for the first time in unfamiliar code, are of the latter kind. (Not that Perl is unusual in this... quite the contrary.) One can't simply look them up, read the definition, and return to work thirty seconds later.
Third, good practice dictates that a programmer document any language extensions (syntax or vocabulary) that he or she defines and expects others to understand. Appropriate documentation is provided given the expected knowledge of the users. Standard language features are exempt from this practice, however, leaving the users of source code to find their own documentation, which will likely be the standard documentation of the language feature in its full generality, the grokking of which may in itself be a larger project than the perusal of the original code should have been.
It is my opinion, based on a few efforts to use Perl 5 as a scripting and glue language, that Perl repays only those who consistently use the language and have no reservations about getting deeper and deeper into it. It is not possible to exclude or ignore the full diversity of the language when estimating the cost of using Perl, because circumstances can and eventually will force you to learn every feature. This happens even if you do not modify or support other programmers' code, because documentation -- of libraries, of programming techniques, of the language environment, and of language features you do want to use -- so often takes the form of code. What you learn and do not use in your own code, you may forget only to be forced to relearn it later.
This is a drawback of the language, but not necessarily a flaw that needs to be corrected. The same thing is true of C++, which I use quite happily because I accepted (and continue to accept) the necessary commitment. The size and complexity (aka "diversity") of the language is a burden as well as a treasure chest. It is simply the downside of a language design choice which should be noted as part of the essential personality of Perl, as it is for C++.
I don't understand how packaging the cores in a single chip changes the architecture or makes it any easier to write a parallelizing compiler. The memory architecture on a massively multicore chip will probably be based on memory architectures in multiple-CPU systems, with any differences driven by different performance characteristics.
In any case, a parallelizing compiler needs parallelizable code to work with. Using any of the currently popular languages, a compiler will have even more trouble finding parallelization than programmers. No matter where the parallelization comes from, the programmers will have to change, by learning new design techniques or learning new languages.
Using current thinking, an application can be naturally separated into a certain number of threads, and for CPU-intensive applications it's pretty easy to get that number higher than the number of available cores -- if the number of cores is two or four. Eighty? That's a bit harder, to say the least. That will require serious support from languages or new kinds of application frameworks that I can't even imagine.
I can see it now: write contracts in a new template language, use template parameters to control run-time checking, and since it's all pure C++ (no macros), you can produce the contract documentation from the output of gccxml.
I mock, but now I really want to try it. Off to hack my own half-assed version -- Friday nights rule!
Right, because all of us who learned on Apple IIe's and 286s running DOS were completely at a loss when Windows 3.1 came out, Windows 95 shook our faith, Windows 2000 pushed us to the edge, and OSX reduced us to pathetic, babbling morons who beg for change on street corners.
Everyone my age went from the Commodore 64 era to the OSX era in twenty years. It wasn't that hard. What will these kids miss if they start out with a text interface? Easy stuff:
- multitasking (possibly)
- using a mouse (possibly)
- WIMPy GUI idioms
What will they *not* miss? Important stuff:
- computer basics (turning it on, watching it boot, shutting it down safely, handling the hardware)
- program concept (running, stopping, crashing)
- file concept (opening, saving, copying, overwriting, losing)
- communications methods (email, chat, file transfer)
- hyperlinked text documents
- typing
- basic office software (word processing, spreadsheets, and basic database concepts)
- whatever CS concepts you want to teach them
I say the elements they miss will be easily picked up later, and text interfaces offer plenty of opportunity to learn the fundamental, difficult elements that cause big problems for people who don't get them. Some adults just never master WIMP, but these are elementary school kids. They have ten years before their minds turn to concrete.
Plenty of things that are illegal now, and seem unimaginably repugnant, used to be legal. Or at least there was no legal penalty for them, or plenty of disincentive for law enforcement to investigate. Both parties used dirty tricks, but the Democrats were recognized (fairly or unfairly) as more sophisticated, shameless, and successful at cheating, just as Republicans are now. Perhaps that reputation comes inevitably with success.
In any case, it would be a shame if we stopped caring about election fraud and stopped passing laws against new dirty tricks invented by the political parties, especially since the latest tricks are aimed at stopping citizens from voting.
More to do with:
- looking like a dork
- not getting there much faster than pedestrians
- demanding a bunch of freakin' space to stow my ride when I get there
- not even getting a decent workout or saving any energy
So unless you're fat and want to stay that way, a cheap bike or just walking beats it hands down.
There's a tour company in my town that gives tours on segways. I've seen them in use, and they are useless. They can't go fast on pedestrian sidewalks. If part of my downtown real estate is going to be repurposed for transportation, let it be for cyclists. At least those guys are willing to put one foot in front of the other (or move them in little circles, rather) for the planet. It's a small gesture, but what does it say that some people are willing to pay thousands dollars just so they can use coal energy instead of their excess fat? (By the way, I don't begrudge old or handicapped people their transportation, just the fat lazy bastards who look forward to never walking again.)
I've tried the Yahoo Mail Beta three times in the last six months, most recently in August, and I quit each time because the interface just wasn't slick enough, partly due to performance on my laptop (1.4 GHz Celeron with 1GB RAM). I read my mail faster using the old interface, making heavy use of browser tabs. Maybe it's just my machine, but frankly, I'm a little ticked off that all this Web 2.0 stuff hasn't produced ANY real improvement in Yahoo Mail, which has both my primary mail accounts. Somewhere there's a usability sweet spot between the old-fashioned web interface and a slow emulation of an old-fashioned email client, but Yahoo just gives you a choice between the two and calls it progress.
I'm still decently satisfied with the old Yahoo interface, so I'm not ready to jump to the next big thing yet, but if I were, I would take Gmail. Gmail is pretty slick and usably fast. I had issues adjusting to using tags, but with help from someone who really understands them, my Gmail account is in decent shape and much more pleasant to use than Yahoo.
Maybe along with the "Learn to Program" IDE Microsoft could offer a programming magazine for kids, like "Ranger Rick." Typing in programs from a magazine might be more fun for a kid than downloading them.
I think you're on to something with the lingua franca. I learned BASIC on Apple IIe computers, and I remember coming across an IBM-compatible in someone else's school, somehow getting into BASIC, and writing and running complete programs. I remember that some of the Applesoft commands for moving the cursor around on the screen didn't work, and I couldn't figure out how to renumber lines. Other than that, it was all the same.
That isn't just a lingua franca, it's an entire programming interface, and it let me transfer my knowledge from the Apple II line to its mortal enemy and diametrical opposite, the IBM-compatible!
And guess who we have to thank for that? (Hint: Replace the first five letters in "Applesoft BASIC.")
I can see having a sip or two at 10, but teaching your kids to brew their own might bring a child welfare worker to your door!
Languages produced for practical use by non-geniuses are almost always OO these days, viz C++, Java, Python. Languages produced by mathematically and theoretically inclined people tend to have OO tacked on later by other people, viz Scheme, Haskell, ML. (Note that Scheme is very OO, but OO in a theoretical sense, so you'll have a hard time convincing J. Average Programmer that it's OO.)
And all the "unnecessary verbiage" is included to help J. Average Programmer work on huge apps in complicated environments with tons of other non-mathematically inclined people. People working on clean, simple, mathematical problems would rather live without it unless they absolutely need it. Once again, viz Scheme and Haskell vs. Java.
I think you're getting theoreticians confused with big-iron, big-problem engineers. Professors come in both types. The mathematicians are on your side.
Anything that requires parental intervention is inferior to BASIC.
Oh, and BASIC in old personal computers let you PEEK and POKE arbitrary memory locations, the meanings of which were documented in the manuals shipped with the computers. You could write to video memory, mess with memory-mapped hardware, hack a running OS, stuff like that. I never did it because I read I could permanently damage the computer, but I guess some kids were less wussy than me :-)
I don't understand. Isn't that exactly how Bill Gates, RMS, and every regular schmoe like me looked at computers when they were kids? Yet we programmed our asses off and ended up becoming professionals.
You can stand behind behind your kids with a whip if you want, saying "NO! Stop having FUN! Grit your teeth and do it GRIMLY like a good worker!" Just remember that treating the computer as a toy has an established track record of producing millionaires and brilliant technologists.
Funny that kids today are pretty good at video games that are longer and more complicated than the ones we played, eh?
.doc files
What kids are after is fun. I did a ton of programming when I was a kid, and I never seriously considered doing it for a living until after I graduated from college. It was just fun.
What's missing is that programming languages used to be built into the computer. For me, BASIC was there when I booted up the computer. Documentation aimed at complete beginners like me was the norm. It would have been hard *not* to program.
These days the easiest way to start out would be with Python. It seems simple to us, but...
1 - know it exists
2 - know how to download the right version for your computer (not a mac or linux version)
3 - find the installer and know to run it (and know that it's safe)
4 - figure out how to invoke the installed program (ok, that one's easy)
5 - find documentation written for beginning programmers
6 - figure out why python won't run the programs you saved as
Can you imagine an eight-year-old Windows user with clueless parents doing all that by himself?
I didn't have to download anything or know anything about operating systems. I don't remember having to sort through tons of titles like "Advanced BASIC Beowulf Architectures in 2 Minutes for J2EE Certified Hardware Astroengineers" at the bookstore to find one that was right for me. In fact, I'm pretty sure the book I used came in the same box as the computer. Plus, all the computer magazines had program listings in the back that you could type in.
Microsoft would earn big brownie points with parents if they included an extremely simple IronPython-based (or even Logo-based) "Learn To Program" IDE with every copy of Windows. Twenty years ago, people knew how to write documentation for beginners. (Not children or computerphobes. Not people with congenital learning disabilities. Just beginners, of all kinds and ages.) I'm sure it could be done again.
Aside from working on well-designed apps written by other people and creating a few amusements, I have converted a single-threaded, single-process commercial application to a multithreaded application.
But who care? Everything I learned could be summed up in a bunch of platitudes anyway. Platitudes wouldn't be so damned popular if people didn't cause most of their own problems by ignoring known facts and techniques. So it is with threading.
Episodes I, II, and III may have been decent movies, but they weren't a good-faith attempt to carry on the Star Wars tradition. The original trilogy was a sensation. It amazed people, stuck with people, and continued to win new fans for decades.
The last three were "family films" in the recent tradition: a hodgepodge of elements, each aimed at making the movie tolerable to certain kind of person (including, let us not forget, the rabid fans -- who predictably oohed and ahhed over the little tidbits that were engineered to appeal to them.) This is standard Hollywood technique, and it guarantees mediocre, forgettable movies. Which is not to say that the followups weren't decent. They were decent in the sense that if you had normal movie expectations (entirely uninfluenced by the original trilogy) then you probably weren't pissed off at how you spent $8 and one evening.
However, they were a betrayal in the sense that those involved did NOT attempt to make worthy successors to the original movies. They knew from the start that they were going to make mediocre movies with wide appeal, because it would have been financially irresponsible to do anything else.
It could have been worse -- they might have skimped on the budget. At least we got high-dollar special effects and a pretty good cast. Can you imagine Episodes I-III starring Elizabeth Berkley, Charlie Sheen, and Miguel Ferrer?
I love this comment; wish I had mod points. Most of the difficulty with concurrent programming happens because programmers brutally hack a single-threaded program into an arbitrary number of pieces without looking for the easy, logical way to decompose it. A good programmer thinks like a butcher, cuts at the joints, and doesn't work half as hard as the programmer who saws through a program's bones and tries to knit them back together with mutexes.
I think he's saying that a lot of web sites selling extremely cheap single-purpose Windows utilities sell malware or redundant software that is no easier to use than the already existing functionality in Windows. He may be right. I never buy from software from websites except when I have a recommendation from someone I personally know and trust, because I can't see any other way to differentiate scam artists from honest vendors. Their web design skills aren't any worse.
But can you play Minesweeper? Seriously. If you say yes, I'll be so impressed my next laptop will probably be a ThinkPad.
It also may be time for him to ask what you wants to do with his career. He obviously has no credibility with management and will be nothing but an "OMG fix the Internet" monkey. If he ever wants to be anything more, he needs to leave.
Poster, time to start taking yourself seriously and demanding that others do so! Or gain forty pounds, grow a ponytail, and prepare yourself for a life of Cheeto-stained, bottom-of-the-totem-pole geekdom.
Incorrect. You can develop and use GPL'ed code without incorporating GPL'ed code into works that you distribute under another license. That means you can run a secret Linux derivative on your own servers, sell a proprietary closed-source application that runs on Linux, and contribute enhancements to the Linux kernel, all without violating the GPL. IBM and Google participate, but they don't "subscribe to it 100%." Just ask them for a peek at their proprietary source code if you don't believe me.
That's not what a web designer does. You can only get it right down to the pixel for users running a single browser at a single screen resolution with a single set of browser settings. A good web designer has to understand what a web page is and design to its strengths and weaknesses, not pretend that he's doing design for television or print media.
It absolutely _should_ be a learning experience. If you don't understand why the segfault can't happen, you don't have sufficient understanding of the code to modify it. If you do understand why the segfault can't happen, then you have an incorrect understanding of the code, because obviously the segfault did happen. Either way you need to learn -- you can't check that section of code in until you prove to your satisfaction that it works. A debugger can't speed up that process at all, so the only work it can speed up is sloppy work. Now don't get me wrong; sometimes you're judged by the standards of sloppy work, and doing careful work will only get you yelled at for being slow. IDEs and debuggers decrease the cost of slapping quick patches on problems, so the cost of creating bugs is lower, and many bosses never bother to ask where a bug came from. They just pat you on the back for fixing it. But you'll never create a stable system that way.
Making sloppy coding easy inhibits careful coding because we're human. You look at a huge function with cryptic comments and think, "God, who wrote this? No wonder it contains bugs." You can do the right thing and painstakingly build up an understanding of the function until you understand it well enough to modify it. That will take two hours, and you'll be brain-dead for your lunch date. Or you can fire up the debugger, find the error, trace back to a line that looks like a mistake, change the line, verify that the test case doesn't crash anymore, and get on Slashdot or Boing Boing to find interesting conversation starters for lunch.
Similar choices crop up when writing new code. That's how a fancy IDE with a nice debugger turns every programming task into a test of character. Using a text editor for everything is like living on a farm -- it doesn't exactly build character, it just excludes the temptations that would reveal deficiencies in character :-)