Absolutely right. If the time and effort required to obtain something is real, and the satisfaction derived from it is real, then why does it matter if the object itself is virtual?
The fact that people care so much about a silly game is, however, pathetic in my opinion.
I second Python. It's simple, it's a quick way to get to cool stuff, its features can be learned incrementally, and it's powerful enough to give the most interested kids a lot of room to grow and implement cool projects. If not Python, choose another language with:
1. A REPL
2. Simple, readable syntax
3. Few and simple language features
4. Enough libraries that beginners can do "cool" stuff with a little hand-holding.
Of course, if you're teaching kids with brains, patience, and ambition, do them a favor and teach them something that will blow their minds, like Haskell. For a lot of kids, high school is the last time they'll have the patience and curiosity to do something that expands their mental repertoire but has no obvious immediate payoff. (Used to be college, but kids these days....)
At the other extreme, if you know your students are lazy and likely to stick with one language their entire lives, I hear C works for that.
Try giving them short programs or functions that repeatedly allocate memory, open and close files, write to disk, spawn threads, etc., and have them estimate the performance characteristics. Even better, show them a simple program written two different ways (using processes vs. threads, caching data in RAM vs. a file, looping over data chunks that fit in processor cache vs. looping over larger chunks), and let them predict the relative performance.
Best would be showing them two implementations of something from a current project.
After everyone submits their guesses, show them the true performance figures and everyone can figure out together why it works that way. Whoever's prediction was closest gets to go home early on Friday.
I've never seen a software tutorial in this format, and I think it rocks. From one incomplete, casual viewing, I picked up a couple of features and added them to my repertoire, and I've been using slime for a couple of months. Thanks, Marco!
I'd like to see more software tutorials in this format. There's something more exciting here than rehashing language wars, guys!
Out of every hundred fat patients a doctor sees, sixty will tell him that they eat right and exercise regularly. Ten are lying to the doctor and the other fifty are lying to themselves. You have to have an objective measure to beat them over the head with, and BMI is the cheapest one. As bad as the BMI is, it's more reliable than asking patients about their lifestyle factors.
There's too much confusion in this thread about what the 56.2% is about. Here's the relevant quote:
Among software developers, Evans Data has found a rising trend toward including open source modules. While 38.1 percent said they used OSS modules in their applications in Spring of 2001, in the most recent survey, 56.2 percent said they had.
I interpret that as excluding platforms and tools such as CVS, Linux, Perl, and Emacs.
Clearly the survey as about using Boost, Log4J (does that date me as a Java developer?), embedded Perl and Python, and other OSS entities as software modules.
The answer to every usability question is not "copy Microsoft" or "make it work like Windows." Linux is a different system, and any attempt to put a Windows-clone GUI on top of it will give us a crippled system with a hard-to-discern inconsistencies that are more insidious to Windows users than obvious differences are. A policy of making the Linux GUI a clone of Windows will make the Linux desktop cheap-feeling and mediocre forever.
A ridiculous example of equating "different from Windows" with "too hard" is the article's comment about Helix Player. "Helix Player" is no less intuitive than "WinAmp," it's simpy different, and not arbitrarily so, because it would be a lie (and probably illegal) to call it "WinAmp."
What makes Windows popular and "easy" today is its history. Microsoft went through years of trial and error during which the Windows GUI was turned into a (relatively) intuitive handle on the Windows system. Windows was popular during this awkward growing period because of a variety of forces that no longer apply today. Microsoft seized the one and only chance to make a crappy, immature desktop GUI a commercial success, and now they have the advantage of a huge user base.
Linux simply can't replicate what happened with Windows. It must become polished before it becomes popular, and there aren't any shortcuts.
The goal for Linux GUIs must be to make Linux as easy to learn and understand as possible, not to make Linux into a Windows work-alike.
I know people prefer absolutes and questions with only one answer, but here's a question everyone has a different answer to:
If you told your customers that henceforth your products would run twice as slowly, but you would deliver new features twice as fast, what would they say?
Sure, there are developers out there who really need to program in C for some good reason, but there are even more developers clinging to C (and C++, the way most people use it) whose customers would be thrilled if they ditched C for a less demanding language.
By the way, the "twice as slow" part doesn't have to happen. My company has been using C++ to build systems that span the numerics, hardware, and application areas, and alternating hard and soft layers* has been a big win for us. It's awesome to fire up a REPL and use our software components to experiment, dissect some data, replicate a bug in isolation, or give a quick tour to a new developer. Since none of the "soft" code is critical to performance, there's no downside.
I saw plenty of those job advertisements when I was looking a few years ago. I'll tell you what they specify: ridiculously self-inflated people. I had people tell me I should give myself credit for a year of Oracle experience because I wrote the JDBC code for a product that in some instantiations was backed by an Oracle database.
WTF does "Oracle experience" mean in a resume or job advert anyway? Once I sat beside a DB admin and helped him write queries to find bogus data in a QA database. Does that count?
Most software is developed for internal use. The fact that developers in India can do this for an American company as cost-effectively as on-site developers is a sad, sad sign.
There is practically no connection between corporate developers and their users. New versions of intranet applications roll out regularly with no contact between IT and the users except training on the new system. Setting aside a few exceptional people, the ideas of observing the users work and asking them questions about their workflow are just that - ideas.
This is sheer incompetence, by managers and developers. If corporate software development were done even halfway competently, it would be impossible for developers on the other side of the world to compete.
Anyone care to explain the reasons behind this absurd situation?
I'm exactly the kind of guy you're looking for, and I spent almost a year unemployed in 2002. You didn't have a chance to hire me then, and you won't have a chance to hire me next time I'm available. I've never found a job through anything other than personal contacts. Unless the system changes, I expect that to hold true for the rest of my life.
The next time I'm looking for a job, I'll send out half a dozen resumes a week, just like last time. But you'll never see them. Neither will anyone else in your position. I simply won't make it through the filters. No Oracle, no Windows, no CORBA, no Peoplesoft. I can say I have "X experience" for only about two dozen X, and I can say I have "3 years X experience" for only three or four X. Three years ago, I was even worse off than that. In the whole year, I saw less than half a dozen job listings that I was technically eligible to apply for.
Here's a hoot - find Andrei Alexandrescu's resume and see how well he fits the "requirements" in your job adverts. Maybe he wouldn't even make it past your HR filter.
American technical fields will suffer from this trend, but business professions will benefit from an influx of hard-sciences majors. Some people get into communications and marketing because that's what they want to know and do well, and some people go there to duck effective systems of evaluations - tests, right answers, the possibility of failure. There just aren't enough of the first type of person to fill the demand for marketers and finance guys, so companies end up with a lot of deadwood.
Enter a horde of science types with basic business and communications skills....
Now companies can simultaneously reduce their percentage of deadwood and increase their intellectual diversity. Bingo!
Convincing a bunch of satisfied users that they're actually miserable and need to switch to your product is a great strategy - if you can afford to spend millions of dollars on TV ads. One guy whining in a Forbes interview isn't going to get anywhere.
Linux users know what it's like to run Linux. Lecturing to them about what Linux is like, using OpenBSD as a standard, is
condescending, because they already know about Linux; and
self-centered, because it addresses the issue from your perspective, not theirs.
Tell people about what OpenBSD does right, using Linux as the standard, and maybe you'll get somewhere.
There are only a few "common apps" because it takes a huge investment of manpower to write apps like OpenOffice or Firefox. I think the potential winners in this are be people who want to create or simply use non-common, GUI-style apps.
Here's why: Few people want to put in years of effort learning to make production-quality apps, and many aren't able to because they have a hard enough time already keeping up their output on their "real" job. As a result, most cool things with limited audiences are stillborn. Filesharing, web browsing, and word processing programs make it because they have enormous user bases. Make GUI programming simpler, and more cool things will be created for medium-sized audiences.
I expect GUI library designers to discover ways to make programming easier by using simpler, less efficient models and using extra threads to make up the loss in efficiency. Ingenious people will find a way. Simplifying the task of GUI programming will mean that more creative tinkerers will build real apps instead of quirky, crash-prone prototypes.
If single-threaded performance improvements slow down, and the available computing power is spread out among multiple cores, anyone persisting in writing single-threaded code will fall behind in performance.
Remember the old days when people used fancy tricks to implement naturally concurrent solutions as single-threaded programs? The future is going to be just the opposite. Any day now we'll see a rush toward langages with special support for quick, clear, safe parallelism, just like we've seen scripting languages catch on for web programming.
I'm wracking my brains for lasting excuses to value human performances over computer performances. You know, the kind of excuses that keep working no matter how good the computers get.
AI is supremely cool stuff, but when I imagine the issues we'll inevitably have to deal with -- this century or next -- it scares the hell out of me.
I'm gonna go struggle with my moral dilemma now.
A Chair is still a chair. It is not by it's case suddenly a fish.
When I read, "A Chair is...." I am prepared to read the rest of the sentence very differently than if I read, "A chair is...."
A sentence containing "Chair" is assuredly different in meaning from a sentence that contains "chair" instead.
As for learned shape memory, I suspect you're talking about reading. I'm talking about not needing to read. If you look through a page of case-sensitive code for Buf_Check, you won't read symbols like foo_this or BAR_THAT. In a case-insensitive language, you have to read those symbols to recognize that they aren't equal to Buf_Check.
If you are using a case insensitive language and reading code by some joker who's using "Variable" "VARIABLE" and "VaRiaBLe" then you just use your editor to select-all and convert-to-lower-case.
So case insensitivity is a good feature, but it's a mistake to take advantage of it?
Either you want to systematically vary case to convey information, or you want to be that careless joker who randomly types the same name in different ways. Which is it?
it doesn't match human readable languages or other human experience
Not true! Case is important in many systems for writing natural languages. In English prose, case provides information for every letter except the first in a sentence.
More importantly, specialized written notations tend to make case significant. Physics books don't arbitrarily switch back and forth between e and E to represent an electron, and no one writes CL to indicate chlorine. or hCl for hydrochloric acid. You'll fail math if you expect a to be the same as A.
Examples abound: case is almost always significant.
Case insensitivity makes reading code more cognitively challenging by forcing developers to mentally map a large set of possible names to a single entity. It's much easier if you know that each symbol has a unique name. Consider the task of scanning up from the line you're writing to find the previous call to a function named Buf_Check. In a case-sensitive language, you're looking for a single name with a unique shape and appearance. In a case-insensitive language, you're looking for any one of many representatives of a class of names that have many different shapes and appearances.
That's a high price to pay just to avoid correcting typos.
So he's going to create a distantly related, conceptually very different language and give it a familiar-looking syntax so Fortran programmers are willing to try it?
I'm sorry, folks, Java was make to look like C so it wouldn't be rejected out of hand by the hordes of troglodyte programmers who judge a language by its syntax. There are a few other similarities, but Java is more different from C than Python is from Perl.
The Java designers (i.e., marketers) did a great job; plenty of people were fooled. "Curly braces, semicolons, int... I guess I can learn this language."
If you don't agree that they're very, very different languages, think about the common mistakes people make in C versus the common mistakes people make in Java.
Slashdot Mirror
Absolutely right. If the time and effort required to obtain something is real, and the satisfaction derived from it is real, then why does it matter if the object itself is virtual?
The fact that people care so much about a silly game is, however, pathetic in my opinion.
1. A REPL
2. Simple, readable syntax
3. Few and simple language features
4. Enough libraries that beginners can do "cool" stuff with a little hand-holding.
Of course, if you're teaching kids with brains, patience, and ambition, do them a favor and teach them something that will blow their minds, like Haskell. For a lot of kids, high school is the last time they'll have the patience and curiosity to do something that expands their mental repertoire but has no obvious immediate payoff. (Used to be college, but kids these days....)
At the other extreme, if you know your students are lazy and likely to stick with one language their entire lives, I hear C works for that.
I also hate you. PDF is just terrible for online browsing. Don't do this to your readers!
Best would be showing them two implementations of something from a current project.
After everyone submits their guesses, show them the true performance figures and everyone can figure out together why it works that way. Whoever's prediction was closest gets to go home early on Friday.
I'd like to see more software tutorials in this format. There's something more exciting here than rehashing language wars, guys!
Out of every hundred fat patients a doctor sees, sixty will tell him that they eat right and exercise regularly. Ten are lying to the doctor and the other fifty are lying to themselves. You have to have an objective measure to beat them over the head with, and BMI is the cheapest one. As bad as the BMI is, it's more reliable than asking patients about their lifestyle factors.
It's as close to deliberate slander as you can get without going to jail.
I interpret that as excluding platforms and tools such as CVS, Linux, Perl, and Emacs.
Clearly the survey as about using Boost, Log4J (does that date me as a Java developer?), embedded Perl and Python, and other OSS entities as software modules.
A ridiculous example of equating "different from Windows" with "too hard" is the article's comment about Helix Player. "Helix Player" is no less intuitive than "WinAmp," it's simpy different, and not arbitrarily so, because it would be a lie (and probably illegal) to call it "WinAmp."
What makes Windows popular and "easy" today is its history. Microsoft went through years of trial and error during which the Windows GUI was turned into a (relatively) intuitive handle on the Windows system. Windows was popular during this awkward growing period because of a variety of forces that no longer apply today. Microsoft seized the one and only chance to make a crappy, immature desktop GUI a commercial success, and now they have the advantage of a huge user base.
Linux simply can't replicate what happened with Windows. It must become polished before it becomes popular, and there aren't any shortcuts. The goal for Linux GUIs must be to make Linux as easy to learn and understand as possible, not to make Linux into a Windows work-alike.
If you told your customers that henceforth your products would run twice as slowly, but you would deliver new features twice as fast, what would they say?
Sure, there are developers out there who really need to program in C for some good reason, but there are even more developers clinging to C (and C++, the way most people use it) whose customers would be thrilled if they ditched C for a less demanding language.
By the way, the "twice as slow" part doesn't have to happen. My company has been using C++ to build systems that span the numerics, hardware, and application areas, and alternating hard and soft layers* has been a big win for us. It's awesome to fire up a REPL and use our software components to experiment, dissect some data, replicate a bug in isolation, or give a quick tour to a new developer. Since none of the "soft" code is critical to performance, there's no downside.
*http://c2.com/cgi/wiki?AlternateHardAndSoftLayers
I saw plenty of those job advertisements when I was looking a few years ago. I'll tell you what they specify: ridiculously self-inflated people. I had people tell me I should give myself credit for a year of Oracle experience because I wrote the JDBC code for a product that in some instantiations was backed by an Oracle database.
WTF does "Oracle experience" mean in a resume or job advert anyway? Once I sat beside a DB admin and helped him write queries to find bogus data in a QA database. Does that count?
Most software is developed for internal use. The fact that developers in India can do this for an American company as cost-effectively as on-site developers is a sad, sad sign. There is practically no connection between corporate developers and their users. New versions of intranet applications roll out regularly with no contact between IT and the users except training on the new system. Setting aside a few exceptional people, the ideas of observing the users work and asking them questions about their workflow are just that - ideas. This is sheer incompetence, by managers and developers. If corporate software development were done even halfway competently, it would be impossible for developers on the other side of the world to compete. Anyone care to explain the reasons behind this absurd situation?
I'm exactly the kind of guy you're looking for, and I spent almost a year unemployed in 2002. You didn't have a chance to hire me then, and you won't have a chance to hire me next time I'm available. I've never found a job through anything other than personal contacts. Unless the system changes, I expect that to hold true for the rest of my life.
The next time I'm looking for a job, I'll send out half a dozen resumes a week, just like last time. But you'll never see them. Neither will anyone else in your position. I simply won't make it through the filters. No Oracle, no Windows, no CORBA, no Peoplesoft. I can say I have "X experience" for only about two dozen X, and I can say I have "3 years X experience" for only three or four X. Three years ago, I was even worse off than that. In the whole year, I saw less than half a dozen job listings that I was technically eligible to apply for.
Here's a hoot - find Andrei Alexandrescu's resume and see how well he fits the "requirements" in your job adverts. Maybe he wouldn't even make it past your HR filter.
American technical fields will suffer from this trend, but business professions will benefit from an influx of hard-sciences majors. Some people get into communications and marketing because that's what they want to know and do well, and some people go there to duck effective systems of evaluations - tests, right answers, the possibility of failure. There just aren't enough of the first type of person to fill the demand for marketers and finance guys, so companies end up with a lot of deadwood.
Enter a horde of science types with basic business and communications skills....
Now companies can simultaneously reduce their percentage of deadwood and increase their intellectual diversity. Bingo!
Linux users know what it's like to run Linux. Lecturing to them about what Linux is like, using OpenBSD as a standard, is
Tell people about what OpenBSD does right, using Linux as the standard, and maybe you'll get somewhere.
No more middle-click for new tab in Firefox.
Can someone definitively confirm or deny this? I was almost convinced to try one out.
Here's why: Few people want to put in years of effort learning to make production-quality apps, and many aren't able to because they have a hard enough time already keeping up their output on their "real" job. As a result, most cool things with limited audiences are stillborn. Filesharing, web browsing, and word processing programs make it because they have enormous user bases. Make GUI programming simpler, and more cool things will be created for medium-sized audiences.
I expect GUI library designers to discover ways to make programming easier by using simpler, less efficient models and using extra threads to make up the loss in efficiency. Ingenious people will find a way. Simplifying the task of GUI programming will mean that more creative tinkerers will build real apps instead of quirky, crash-prone prototypes.
If single-threaded performance improvements slow down, and the available computing power is spread out among multiple cores, anyone persisting in writing single-threaded code will fall behind in performance.
Remember the old days when people used fancy tricks to implement naturally concurrent solutions as single-threaded programs? The future is going to be just the opposite. Any day now we'll see a rush toward langages with special support for quick, clear, safe parallelism, just like we've seen scripting languages catch on for web programming.
I'm wracking my brains for lasting excuses to value human performances over computer performances. You know, the kind of excuses that keep working no matter how good the computers get. AI is supremely cool stuff, but when I imagine the issues we'll inevitably have to deal with -- this century or next -- it scares the hell out of me. I'm gonna go struggle with my moral dilemma now.
When I read, "A Chair is...." I am prepared to read the rest of the sentence very differently than if I read, "A chair is...."
A sentence containing "Chair" is assuredly different in meaning from a sentence that contains "chair" instead.
As for learned shape memory, I suspect you're talking about reading. I'm talking about not needing to read. If you look through a page of case-sensitive code for Buf_Check, you won't read symbols like foo_this or BAR_THAT. In a case-insensitive language, you have to read those symbols to recognize that they aren't equal to Buf_Check.
So case insensitivity is a good feature, but it's a mistake to take advantage of it?
Either you want to systematically vary case to convey information, or you want to be that careless joker who randomly types the same name in different ways. Which is it?
it doesn't match human readable languages or other human experience
Not true! Case is important in many systems for writing natural languages. In English prose, case provides information for every letter except the first in a sentence.
More importantly, specialized written notations tend to make case significant. Physics books don't arbitrarily switch back and forth between e and E to represent an electron, and no one writes CL to indicate chlorine. or hCl for hydrochloric acid. You'll fail math if you expect a to be the same as A.
Examples abound: case is almost always significant.
Case insensitivity makes reading code more cognitively challenging by forcing developers to mentally map a large set of possible names to a single entity. It's much easier if you know that each symbol has a unique name. Consider the task of scanning up from the line you're writing to find the previous call to a function named Buf_Check. In a case-sensitive language, you're looking for a single name with a unique shape and appearance. In a case-insensitive language, you're looking for any one of many representatives of a class of names that have many different shapes and appearances.
That's a high price to pay just to avoid correcting typos.
So he's going to create a distantly related, conceptually very different language and give it a familiar-looking syntax so Fortran programmers are willing to try it?
I'm sorry, folks, Java was make to look like C so it wouldn't be rejected out of hand by the hordes of troglodyte programmers who judge a language by its syntax. There are a few other similarities, but Java is more different from C than Python is from Perl.
The Java designers (i.e., marketers) did a great job; plenty of people were fooled. "Curly braces, semicolons, int... I guess I can learn this language."
If you don't agree that they're very, very different languages, think about the common mistakes people make in C versus the common mistakes people make in Java.