Testing and shipping computers from the first world is more expensive than buying used computers locally. Third world countries do have demand for computers, and there are companies that meet that demand at very low cost.
That explains why there are no groups soliciting donations in the US. It's better to recycle the computer and just give money to an NGO that buys computers on the local market.
Can you recommend tools for Linux and Windows, preferably free (as in beer)?
I'd like to produce some demos for my friends and coworkers a la the outstanding Slime video you can find on this page.
Some programs provide a very powerful working environment but leave new users wondering, "How am I supposed to use these features to get something done?" A video is the best answer.
video : big powerful program:: code examples : big complex API
I don't think balance is a good idea if it means every weapon, unit, or strategy has a use on every map. Maps should be unbalanced. The advantage goes to the player smart enough to figure out which weapons, units, or strategies are effective on a given map.
That can ruin the replay value, but replay value is somewhat inimicable to the "Aha!" moment you get when you realize the key to a map. Sure, after you figure out the killer strategy on a map, it isn't challenging anymore, but you get a rush from figuring it out, and you can apply that insight to more complicated maps. It's like solving a math problem or a chess exercise.
Real life situations are usually unbalanced, too. One strategy dominates, one side has an unbeatable advantage -- but the actors may or may not figure it out in time to take advantage of it.
I wonder how much money is being made off DRM by companies like Microsoft that know it will never work. When the guys with the money (the media companies in this case) want something impossible, and want it badly enough, smart tech vendors can make a lot of money by playing along.
Why would musicians be limited to stock kernel distributions? Many (most?) distributions apply kernel patches. I'm sure most musicians would rather use a special distribution designed for audio than spend hours learning how to tweak a general purpose Linux distro.
If few physicists understand string theory, they should leave it to the supergeniuses and start working on theories they DO understand, instead of waiting in awe for the string theorists to make it comprehensible to them. It would at least result in some intellectual diversity. Who knows? Maybe they'll come up with an alternative that's good enough to attract some disgruntled supergeniuses, and then we won't have all our eggheads in one basket. (Sorry, I couldn't resist! I meant what I said seriously; it wasn't just a lead-in to the joke.)
If you work on commercial software, the type of license may determine whether you can use the code in your product.
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 1
Just out of curiousity, why would the Unicode consortium take their cues from the Japanese government when the government's lists are intentionally, controversially streamlined and Unicode's desire is to be comprehensive?
I understand there must be controversy and compromises for efficiency when a government is defining a writing system for official use, but I don't understand why Unicode would pay any attention to such an effort. After all, Unicode includes characters for writing systems that have been dead for thousands of years. I bet the Iraqi government doesn't accept birth certificates filled out in cuneiform.
Re:Because you'll end up at Lisp.
on
Lisp and Ruby
·
· Score: 1
Lisp is the same way. Everything's a list, or an AST to use your perspective. Yay, hooray. But it doesn't let you group things, it doesn't let you collect, isolate, and distinguish concepts.
No wonder you have a bad impression of Lisp. Whoever taught you Lisp without showing you how to define variables, functions, classes, methods, loops, conditional statements, macros, etc. should be shot. No way to "collect, isolate, and distinguish concepts" indeed. Common Lisp actually has an extremely rich collection of such constructs -- like C++, it borders on being too rich in ways to express program organization.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
MVC is a really poor abstraction that is never really implemented in a pure fashion.
One of the nice things about it is that you don't have to go all the way. The people who introduced to MVC did so quite enthusiastically and in great detail, yet working together I don't think we ever produced a pure MVC design. Our understanding of MVC just illuminated the design space and served as an excellent starting point.
I saw an article floating around awhile back criticizing MVC and offering alternative GUI patterns, many of which were MVC with one or more restrictions relaxed. Those alternatives are actually what most people end up coding -- full-blown MVC is usually overkill, a starting point from which a less elaborate design can be created.
Neither is Java a C++-esque language, but that's what the Sun marketeers fooled a lot of people into thinking. You can't establish a new language without getting enough people to buy in and commit to the language, and you can't get enough people to buy in and commit to the language without making the conservative crowd think it's a just a cleaner, spiffier version of something they already know.
Sun did a good job of simultaneously pitching Java to forward thinkers and to conservatives. If they're doing the same thing with Fortress, then I predict that some of the best and ultimately most important features of Fortress are being downplayed to avoid spooking the uber-conservative Fortran crowd.
The PS3 wizards may be far better known that Carmack. If someone can come up with a superior set of concepts for asymmetrical, hardware-aware programming, plus maybe tools and a language to go with it, it will be a sea change in programming. It would be interesting to see if these new wizards are kids coming out of college or an industry job where they worked with languages and tools for distributed systems. But really, who knows where the ideas will come from.
It will suck terribly if programming asymmetrical systems like the PS3 continues to be as hard in the future as it is now.
Thanks; that will help. I'm really wondering about trial and error (since compiler can't always predict which instruction sequence runs faster) and all the optimizations that are computationally unfeasible for normal use. It seems odd that turning on all the optimizations only costs seconds when applied to a few hundred lines of code -- if it's easier to come up with too-slow compiler optimizations than fast ones, I wonder why I don't have access to those slow optimizations when I really want them!
2) I'd wager that the reason "the type of people who use Unix" prefer it that way is only because they are used to it from using Unix.
Preferring it that way is a simple matter of being used to adhering to case-sensitive naming conventions. Programming in most languages will teach you that, as will sharing large amounts of data and files with colleagues. (When using mathematical notation, also, it is often helpful to use capitalization consistently.) On my system, for my work, if I know the type and approximate contents of the file I'm looking for, then I usually know its capitalization.
On the other hand, when I receive personal files from friends or name files for my friends, such as photographs, capitalization follows no system at all, so case-insensitive alphabetization makes more sense. Also, it isn't a big deal to look at a case-insensitively alphabetized list and mentally filter out the items with the wrong capitalization, so techies will be less burdened under the new way than non-techies were under the old way.
what is easier to remember? Whether a filename starts with S, or whether a filename starts with a capital or lowercase?
It's the right way to sort for the kinds of people who were Unix users twenty years ago: programmers, scientists, and engineers. You're right that it's one of those things that will have to be "fixed" before Linux is "ready for the desktop." But it wasn't wrong in the first place -- it was (and still is, in most cases) right for the people who use it. The only reason to change it is to take over the world.
Sigh. I feel the same way thinking about that as I do when a local dive turns into a Starbucks or an Urban Outfitters. It makes we want to go help the Californians ruin Bozeman for a while.
Modenr compilers apply optimizations on a so sophisticated level that would be a nightmare for a human to support such a solution optimized.
There are three quite simple things that humans can do that aren't commonly available in compilers.
First, a human gets to start with the compiler output and work from there:-) He can even compare the output of several compilers.
Second, a human can experiment and discover things accidentally. I recently compiled some trivial for loops to demonstrate that array bounds checking doesn't have a catastrophic effect on performance. With the optimizer cranked up, the loop containing a bounds check was faster than the loop with the bounds check removed. That did not inspire confidence.
Third, a human can concentrate his effort for hours or days on a single section of code that profiling revealed to be critical and test it using real data. Now, I know JIT compilers and some specialized compilers can do this stuff, but as far as I know I can't tell gcc, "Compile this object file, and make the foo function as fast as possible. Here's some data to test it with. Let me know on Friday how far you got, and don't throw away your notes, because we might need further improvements."
I hope I'm wrong about my third point (please please please) so feel free to post links proving me wrong. You'll make me dance for joy, because I do NOT have time to write assembly, but I have a nice fast machine here that is usually idle overnight.
We SHOULD make the comparison, because software is just as vital to our economy as those other things, yet we don't demand it, we aren't willing to pay, vendors won't deliver, and government doesn't regulate it.
You seem to be saying that people who purchase software tend to harm the economy by purchasing cheaper, lower-quality software than they should. How in the world did you make that determination? Perhaps most software is made to an appropriate level of quality, with some being better and more expensive than it should be, as well as some being worse and cheaper.
To go another step, if I were to claim that hundreds of millions of dollars were wasted every year making software needlessly good, and this unnecessary dedication to quality was harming the economy, how would you refute that?
The only answer for security in C is "write it yourself?" You've got to be kidding.
Unless everyone writing C is still writing insecure code by default, which sounds unlikely since most people at least pretend to have wised up, there must be open source input validation libraries and/or some secure replacement for the standard C library.
If you can't find high-quality open-source libraries that are secure by design (and I'd be surprised if you couldn't), then "Don't use C!" is much better advice than "Write it yourself."
Continuing the file metaphor is analogous to driving your car with reins. You're advocating the continued use of a metaphor and its associated terminology that is probably based on a 1950's or 1960's office.
Sure, a better metaphor would be great. But no one is pitching a newer, better metaphor; they're pitching piece-of-paper and typewriter metaphors which are older and worse. So far there is no reasonable alternative to continuing to improve the file metaphor, yet some people (you don't have to look far for them on this page) assume that eliminating the file metaphor is an instant win, merely because it's alien to beginners.
I have many friends and relatives who all struggle with basic computer concepts and usage.... I think they're not the oddity, I think they're becoming the standard.... Properly operating and maintaining a computer today is already challenging for your typical middle-class college student.
They have glitches and complaints, but they get what they want done, done. Find me a user who hasn't figured out how to play music, write papers, send email, and buy stuff off Amazon. Complaining is natural; I complain about having $1200 worth of work done on my car a few weeks ago, and about the fact that the brake light goes on and off even though the brakes and fluids are fine. (Probably the brake fluid floaty is sticking, I'm told.) It doesn't stop me from getting around town. My sister teachers history to college students. They are required to turn in all papers via email. Some of them bitch and moan, but they all manage it -- without exception. And they aren't the cream of the crop, either.
How many of them are actually users? There's no reason to design interfaces for people who won't use them in the first place.
I would guess that most of the true novice users in Slashdotters' families are older folks who decided years ago to avoid computers altogether, then changed their minds and started learning. That doesn't seem like such a large group of people, especially since some of them graduate from novice status pretty quickly. In any case, that group will basically disappear within a decade. (If you don't decide to learn in 2007 at the age of 60, you probably won't decide to learn in 2017 at the age of 70.)
Then there are those who are considered hopeless noobs because they use IE, ask stupid-sounding questions, and don't understand why it's bad to open a strange.doc file. I wouldn't call them novices; they probably rock at WIMP and can figure out most of the things they want to do with the computer.
"Documentation" is exactly why the IDE becomes more useful -- it knows things about the code that it would not otherwise know.
And yes, absent-mindedness is what type checking catches. When you do something so off-the-wall wrong that the types aren't correct, it's because you weren't paying attention, made a major brain fart, forget to finish typing an expression, mixed up the names of two methods, forgot to implement one branch of the control flow, that kind of thing. That's absent-mindedness.
Mistakes of understanding, where the programmer can actually look carefully at the code and think it's right when it isn't, are rarely caught by the Java type system, because they result in types being correct and values being wrong. You can split types into subclasses according to their semantics (instead of just behavior) and put narrowing casts in your code to serve as logical assertions, but the Java compiler will not analyze your code to see if those assertions might be triggered -- the Java type system is not very helpful in that respect. Therefore, mistakes of understanding slip through, and compile-time type checking mostly catches mistakes of inattention.
Slashdot readers are computer users. I'm going to guess that most contributors are either in the computer industry or serious hobbyists. Most people, however, have other things to worry about.
Err, the vast majority of non-Slashdotters are literate and employed. How many jobs require reading and writing but not computer usage? Clerks, call center employees, receptionists, and store managers must use PCs running complex applications. Delivery drivers, auto mechanics, factory workers, and checkers all use special-purpose computers. You have to use a computerized kiosk just to apply for a job at Target. Two decades ago, if you had described the current situation, many people would have predicted that all these jobs requiring "computer skills" would be reserved for a small class of nerdy weirdos, and all "normal" people would be locked out. That seems silly now -- we don't think the manager at the grocery store is part of a technological oligarchy because he uses a PC -- but that fear used to be a respectable opinion. Who can say that the next twenty years won't bring a similar change?
Slashdot Mirror
Testing and shipping computers from the first world is more expensive than buying used computers locally. Third world countries do have demand for computers, and there are companies that meet that demand at very low cost.
That explains why there are no groups soliciting donations in the US. It's better to recycle the computer and just give money to an NGO that buys computers on the local market.
I'd like to produce some demos for my friends and coworkers a la the outstanding Slime video you can find on this page.
Some programs provide a very powerful working environment but leave new users wondering, "How am I supposed to use these features to get something done?" A video is the best answer.
video : big powerful program :: code examples : big complex API
I don't think balance is a good idea if it means every weapon, unit, or strategy has a use on every map. Maps should be unbalanced. The advantage goes to the player smart enough to figure out which weapons, units, or strategies are effective on a given map.
That can ruin the replay value, but replay value is somewhat inimicable to the "Aha!" moment you get when you realize the key to a map. Sure, after you figure out the killer strategy on a map, it isn't challenging anymore, but you get a rush from figuring it out, and you can apply that insight to more complicated maps. It's like solving a math problem or a chess exercise.
Real life situations are usually unbalanced, too. One strategy dominates, one side has an unbeatable advantage -- but the actors may or may not figure it out in time to take advantage of it.
I wonder how much money is being made off DRM by companies like Microsoft that know it will never work. When the guys with the money (the media companies in this case) want something impossible, and want it badly enough, smart tech vendors can make a lot of money by playing along.
Why would musicians be limited to stock kernel distributions? Many (most?) distributions apply kernel patches. I'm sure most musicians would rather use a special distribution designed for audio than spend hours learning how to tweak a general purpose Linux distro.
Job security through obscurity?
If few physicists understand string theory, they should leave it to the supergeniuses and start working on theories they DO understand, instead of waiting in awe for the string theorists to make it comprehensible to them. It would at least result in some intellectual diversity. Who knows? Maybe they'll come up with an alternative that's good enough to attract some disgruntled supergeniuses, and then we won't have all our eggheads in one basket. (Sorry, I couldn't resist! I meant what I said seriously; it wasn't just a lead-in to the joke.)
If you work on commercial software, the type of license may determine whether you can use the code in your product.
Just out of curiousity, why would the Unicode consortium take their cues from the Japanese government when the government's lists are intentionally, controversially streamlined and Unicode's desire is to be comprehensive?
I understand there must be controversy and compromises for efficiency when a government is defining a writing system for official use, but I don't understand why Unicode would pay any attention to such an effort. After all, Unicode includes characters for writing systems that have been dead for thousands of years. I bet the Iraqi government doesn't accept birth certificates filled out in cuneiform.
No wonder you have a bad impression of Lisp. Whoever taught you Lisp without showing you how to define variables, functions, classes, methods, loops, conditional statements, macros, etc. should be shot. No way to "collect, isolate, and distinguish concepts" indeed. Common Lisp actually has an extremely rich collection of such constructs -- like C++, it borders on being too rich in ways to express program organization.
One of the nice things about it is that you don't have to go all the way. The people who introduced to MVC did so quite enthusiastically and in great detail, yet working together I don't think we ever produced a pure MVC design. Our understanding of MVC just illuminated the design space and served as an excellent starting point.
I saw an article floating around awhile back criticizing MVC and offering alternative GUI patterns, many of which were MVC with one or more restrictions relaxed. Those alternatives are actually what most people end up coding -- full-blown MVC is usually overkill, a starting point from which a less elaborate design can be created.
Neither is Java a C++-esque language, but that's what the Sun marketeers fooled a lot of people into thinking. You can't establish a new language without getting enough people to buy in and commit to the language, and you can't get enough people to buy in and commit to the language without making the conservative crowd think it's a just a cleaner, spiffier version of something they already know.
Sun did a good job of simultaneously pitching Java to forward thinkers and to conservatives. If they're doing the same thing with Fortress, then I predict that some of the best and ultimately most important features of Fortress are being downplayed to avoid spooking the uber-conservative Fortran crowd.
If it every gets released, it will be an awesome advertisement for the engine it uses.
"Our engine turns vaporware into real products!"
"So easy to use, even the Duke Nukem Forever team can finish a game!"
The PS3 wizards may be far better known that Carmack. If someone can come up with a superior set of concepts for asymmetrical, hardware-aware programming, plus maybe tools and a language to go with it, it will be a sea change in programming. It would be interesting to see if these new wizards are kids coming out of college or an industry job where they worked with languages and tools for distributed systems. But really, who knows where the ideas will come from.
It will suck terribly if programming asymmetrical systems like the PS3 continues to be as hard in the future as it is now.
Thanks; that will help. I'm really wondering about trial and error (since compiler can't always predict which instruction sequence runs faster) and all the optimizations that are computationally unfeasible for normal use. It seems odd that turning on all the optimizations only costs seconds when applied to a few hundred lines of code -- if it's easier to come up with too-slow compiler optimizations than fast ones, I wonder why I don't have access to those slow optimizations when I really want them!
Preferring it that way is a simple matter of being used to adhering to case-sensitive naming conventions. Programming in most languages will teach you that, as will sharing large amounts of data and files with colleagues. (When using mathematical notation, also, it is often helpful to use capitalization consistently.) On my system, for my work, if I know the type and approximate contents of the file I'm looking for, then I usually know its capitalization.
On the other hand, when I receive personal files from friends or name files for my friends, such as photographs, capitalization follows no system at all, so case-insensitive alphabetization makes more sense. Also, it isn't a big deal to look at a case-insensitively alphabetized list and mentally filter out the items with the wrong capitalization, so techies will be less burdened under the new way than non-techies were under the old way.
It's the right way to sort for the kinds of people who were Unix users twenty years ago: programmers, scientists, and engineers. You're right that it's one of those things that will have to be "fixed" before Linux is "ready for the desktop." But it wasn't wrong in the first place -- it was (and still is, in most cases) right for the people who use it. The only reason to change it is to take over the world.
Sigh. I feel the same way thinking about that as I do when a local dive turns into a Starbucks or an Urban Outfitters. It makes we want to go help the Californians ruin Bozeman for a while.
There are three quite simple things that humans can do that aren't commonly available in compilers.
First, a human gets to start with the compiler output and work from there :-) He can even compare the output of several compilers.
Second, a human can experiment and discover things accidentally. I recently compiled some trivial for loops to demonstrate that array bounds checking doesn't have a catastrophic effect on performance. With the optimizer cranked up, the loop containing a bounds check was faster than the loop with the bounds check removed. That did not inspire confidence.
Third, a human can concentrate his effort for hours or days on a single section of code that profiling revealed to be critical and test it using real data. Now, I know JIT compilers and some specialized compilers can do this stuff, but as far as I know I can't tell gcc, "Compile this object file, and make the foo function as fast as possible. Here's some data to test it with. Let me know on Friday how far you got, and don't throw away your notes, because we might need further improvements."
I hope I'm wrong about my third point (please please please) so feel free to post links proving me wrong. You'll make me dance for joy, because I do NOT have time to write assembly, but I have a nice fast machine here that is usually idle overnight.
I understand your confusion. It's a sick truth that people don't face up to easily, like Jake Gittes in Chinatown:
You seem to be saying that people who purchase software tend to harm the economy by purchasing cheaper, lower-quality software than they should. How in the world did you make that determination? Perhaps most software is made to an appropriate level of quality, with some being better and more expensive than it should be, as well as some being worse and cheaper.
To go another step, if I were to claim that hundreds of millions of dollars were wasted every year making software needlessly good, and this unnecessary dedication to quality was harming the economy, how would you refute that?
The only answer for security in C is "write it yourself?" You've got to be kidding.
Unless everyone writing C is still writing insecure code by default, which sounds unlikely since most people at least pretend to have wised up, there must be open source input validation libraries and/or some secure replacement for the standard C library.
If you can't find high-quality open-source libraries that are secure by design (and I'd be surprised if you couldn't), then "Don't use C!" is much better advice than "Write it yourself."
Sure, a better metaphor would be great. But no one is pitching a newer, better metaphor; they're pitching piece-of-paper and typewriter metaphors which are older and worse. So far there is no reasonable alternative to continuing to improve the file metaphor, yet some people (you don't have to look far for them on this page) assume that eliminating the file metaphor is an instant win, merely because it's alien to beginners.
They have glitches and complaints, but they get what they want done, done. Find me a user who hasn't figured out how to play music, write papers, send email, and buy stuff off Amazon. Complaining is natural; I complain about having $1200 worth of work done on my car a few weeks ago, and about the fact that the brake light goes on and off even though the brakes and fluids are fine. (Probably the brake fluid floaty is sticking, I'm told.) It doesn't stop me from getting around town. My sister teachers history to college students. They are required to turn in all papers via email. Some of them bitch and moan, but they all manage it -- without exception. And they aren't the cream of the crop, either.
How many of them are actually users? There's no reason to design interfaces for people who won't use them in the first place.
.doc file. I wouldn't call them novices; they probably rock at WIMP and can figure out most of the things they want to do with the computer.
I would guess that most of the true novice users in Slashdotters' families are older folks who decided years ago to avoid computers altogether, then changed their minds and started learning. That doesn't seem like such a large group of people, especially since some of them graduate from novice status pretty quickly. In any case, that group will basically disappear within a decade. (If you don't decide to learn in 2007 at the age of 60, you probably won't decide to learn in 2017 at the age of 70.)
Then there are those who are considered hopeless noobs because they use IE, ask stupid-sounding questions, and don't understand why it's bad to open a strange
And yes, absent-mindedness is what type checking catches. When you do something so off-the-wall wrong that the types aren't correct, it's because you weren't paying attention, made a major brain fart, forget to finish typing an expression, mixed up the names of two methods, forgot to implement one branch of the control flow, that kind of thing. That's absent-mindedness.
Mistakes of understanding, where the programmer can actually look carefully at the code and think it's right when it isn't, are rarely caught by the Java type system, because they result in types being correct and values being wrong. You can split types into subclasses according to their semantics (instead of just behavior) and put narrowing casts in your code to serve as logical assertions, but the Java compiler will not analyze your code to see if those assertions might be triggered -- the Java type system is not very helpful in that respect. Therefore, mistakes of understanding slip through, and compile-time type checking mostly catches mistakes of inattention.
I base my nontechnical decisions on the lyrics to the Fraggle Rock theme song.
Err, the vast majority of non-Slashdotters are literate and employed. How many jobs require reading and writing but not computer usage? Clerks, call center employees, receptionists, and store managers must use PCs running complex applications. Delivery drivers, auto mechanics, factory workers, and checkers all use special-purpose computers. You have to use a computerized kiosk just to apply for a job at Target. Two decades ago, if you had described the current situation, many people would have predicted that all these jobs requiring "computer skills" would be reserved for a small class of nerdy weirdos, and all "normal" people would be locked out. That seems silly now -- we don't think the manager at the grocery store is part of a technological oligarchy because he uses a PC -- but that fear used to be a respectable opinion. Who can say that the next twenty years won't bring a similar change?