will we be seeing a back-end to GCC for this FPGA?
Hardly. The languages for which gcc has front-ends (C, Fortran, C++, Ada, etc.) are heavily biased toward CPUs that process a stream of instructions: load, store, add, and, branch, compare, etc. The highly parallelized and pipelined designs that make FPGAs so much faster than microprocessors can't be expressed in software languages, and producing a good hardware design that is equivalent to a given C program is, well, a much harder problem than creating hardware designers who can design in VHDL and Verilog.
Put another way, getting a good hardware design from a good software developer is as likely as getting a good software design from a bad software developer, because it's just as hard. (The first company that cracks either of these nuts will instantly become a household name, so don't worry about missing it.) Hopefully, as FPGAs reduce the barrier to entry in hardware design, the number of VHDL/Verilog designers will rise to meet demand.
I think what you're saying is that the market is skewed. There are plenty of happy developers who get paid to do their favorite thing in the world. However, since the only barriers to entry are loving programming and having lots of free time, there are many, many people scrambling to get those jobs.
There is no requirement that software developers get a four year professional degree after college. There is no artificial barrier that guarantees that anybody who jumps through hoops X, Y, and Z will enjoy high demand for their skills. If medicine were like software development, there would be tens of thousands of frustrated neurosurgeons working as nurses and bitching about how there aren't any jobs.
Software isn't like law or medicine; it's more like music and sports. It's hard to figure out when to give up trying, and many talented people fall through the cracks because of bad luck or because their skills can only blossom in a certain setting that they can't arrange or that just doesn't exist. Whether you're an aspiring software architect who ends up working as a help desk guy or an aspiring pro linebacker who ends up as a high school gym teacher, it hurts like hell to figure out at twenty-five or thirty that you've put fifteen years of your life into learning skills that will never put you over $50k per year.
I'm guessing this is something that displays on my computer monitor? Thanks but no thanks. I'm waiting for the wall-sized ones.
And the remaining diminishing returns aren't worth an order-of-magnitude loss of productivity.
If you're an order of magnitude less productive in an office than at home, that's a perfectly acceptable reason to telecommute. Why in the world would that be, though? I telecommute now (forcibly, since my coworkers are out of town), and the isolation really sucks. It's more awkward to ask for help, so people only do it formally for big problems, never informally for small problems. We've essentially neutered ourselves into only providing value on projects we're officially assigned to. Mostly we limit ourselves to what we can accomplish by ourselves, which makes us less ambitious than we should be.
One of the charms of my old job was that people regularly came to me with hard problems, small or large, and in return I could go pick their brains when I needed to. This resulted in everyone having at least a basic grasp of everyone else's work, not to mention the small efficiencies that come from everyone doing what they're good at.
Now I do that more with the guys I drink beer with than with my coworkers. It's boring and frustrating.
The telephone is much better than email, but you have no hand gestures and no whiteboard, and when the other guy isn't talking, you have zero feedback. Is he impatient? Shifting his weight? Looking confused? The more you replicate the face-to-face experience, the better it gets: videophones, virtual whiteboards, etc. There's a long way to go before it gets as good as face-to-face. And you can't borrow or lend a book through virtual reality unless it's an e-book (barf!)
The most valuable people to me aren't the other guys on my team; they're the guys on other teams with whom I get together and discuss hard problems and hard decisions. If you're just answering emails, checking in code, and closing out bugs, as another poster put it, you can do that just fine remotely. Sharing knowledge and brainwaves to help each other solve hard problems is an entirely different animal that doesn't work well remotely.
In a face-to-face environment, you can peel off and have a twenty minute chat with your coworker about what you're each doing. Sometimes you can solve each other's problems, or help them solve them by asking questions. A twenty minute face-to-face chat can communicate a huge amount of information, especially when everyone has a whiteboard. Email can't accomplish that. The art of being as expressive in pure text as one is when speaking is very, very rare, and doing it at the same speed is pretty freaky. Doing it at the same speed with no access to the audience's feedback simply can't be done.
Suppose you each spend your twenty minutes on email instead: ten minutes of that time writing an email, five minutes reading the other guy's email, and five minutes writing a response. First, a ten-minute email is going to be very short or very poorly written. (We get much more information from poorly composed speech than from poorly composed prose.) It will convey very little of what you're working on. Second, without cues from the other person, you don't know how to skip past the parts he knows about and add more detail when he doesn't understand. Third, if your buddy senses that you're glossing over something (that you may or may not be aware of), you won't know until the end of the twenty minutes. Finally, there isn't time for multiple back-and-forths. In conversation, it's routine to go deep into exchanges of I say "X," you say "but Y," I say "Y'", you say "No, Y~, in fact, Y~3*!", I say, "Oh, yeah, we're probably doing that wrong," then I pop back up to the top level and continue talking about X. That back and forth probably wouldn't happen if we were communicating via email, and if it did, it would take hours instead of minutes.
Email example: "My gut instinct tells me you hookie-dookie won't scale. The flooge calculation will tell you whether it will or not. I don't know if you're familiar with it, but you can find it in 'Algorithms, Orangutans, and Phlogiston,' by Rivest and a few other guys. The way it applies to your hookie-dookie is...." After five minutes of typing, you send the email.
Face-to-face example: "Did you do the flooge calculation?" "Yes, of course." "Did you get something on the same order of magnitude as 1,000?" "No, more like tens of millions." "That smells fishy to me. Let's run through it together." "Wait, I'll go get Serge. He's the guy who did our calculation, and he understands the math better than me." That takes less than a minute, and already you're well on your way to solving the problem. Face-to-face saves even more time if flooge isn't the problem: twenty seconds worth of chatting vs. five minutes of email.
That's like saying the technological problems of flying cars have been solved. They aren't solved for me until I get my flying car/ideal telecommuting kit.
Plus, everyone is too formal in videoconferences. It isn't human. You can't take a virtual walk together. You have to stay in front of a friggin' camera like a Hollywood actor instead of going to the coffeeshop together and bitching about the boss like normal human beings. It's awkward to interrupt, so no one does it. People sit like statues when they're listening and talk for minutes at a time when they're speaking, even when only two people are on. And when you're done, you don't feel like you've had a break, you feel like you're ready for one.
Maybe those problems that will pass when people get used to it. I'll take a wait-and-see approach.
Business vs. security? No contest. Why do you think security regulations that supposedly protect us from terrorists also help companies hide bad behavior from citizens, and the Pentagon's budget is filled with boondoggle projects it doesn't even want? The military and the security complex aren't political power centers -- yet.
No, pyite has it right -- I'm talking about the class called "Abstract Algebra," "Modern Algebra," or "Groups, Rings, and Fields," a senior-level class taken mostly by math majors and scientists who plan on going to grad school.
Doing algebra proofs for a few semesters makes you careful about designing datatypes. Does this bundle of data behave well as a whole? Can I make it behave well? Can I construct it as a combination of simpler datatypes? How do I define 0 and 1? A datatype with an algebraic structure is easier to program than a datatype that doesn't follow a useful set of rules.
That's why algebra itself is a good topic, but the type of course is more important. Upper-level algebra is a pure math course focused on proofs and counterexamples rather than calculating results. It's good to know, viscerally, as a result of brutal experience, that changing one or two simple assumptions can make a long proof short or an impossible proof easy, and vice-versa. Programs are proofs, so this instinct is crucial for doing software requirements, estimates, and design.
Any pure math course will teach this just as well as algebra, but courses more focused on calculating results will not. Most colleges teach three of four upper-level pure math classes that focus on preparing math majors for grad school: algebra and analysis are universal, and topology is fairly common. Set theory is by far the best course for computer science majors, but it is less common than it should be. Undergraduate courses in statistics, linear algebra, numerical analysis, differential equations, complex analysis, and vector calculus usually skimp on proofs. Almost all of the assigned problems and test problems should be proofs.
By "throw it all away," do you mean ditch school and go for a job with what you have? That's a bad idea. If you mean switch to computer science or math as a degree, by all means do it! Just make sure you work in the math classes somehow. If you get a CS degree, make sure you take the upper-level algebra and set theory courses from the math department, and if you get a math degree, make sure you take *at least* an upper-level operating systems class, computer architecture, and the basic theory class (usually called something like "Automata Theory and Formal Languages.")
Exactly. Article writer has no knowledge in the area.
Or perhaps you're missing the point.
The article writer isn't saying that a smart, conscientious C programmer can't copy strings correctly 98% of the time. He's saying it isn't good enough to meet that standard, and most languages do better. Even C++ allows you to simply write string s2 = s1.
To do the same thing in C, the programmer must know or check the length of s1, know or check the length of s2 (actually, know or check whether s2 points to any memory at all), possibly reallocate memory for s2, and copy exactly the right number of characters from s1 to s2. There are many possibilities for a typo or a lack of caffeine to open a security hole.
this problem of stupid/lazy programmer
No one denies that requiring several lines of finicky code to perform a simple operation separates the mental weenies from mental he-men. If your ego is the biggest thing on the line when you create software, by all means, keep using C for everything.
Re:The Economist... only 20 years behind the times
on
Unusual Open Source
·
· Score: 1
Markets can certainly solve environmental problems, but it doesn't make sense to ask them to do so "without intervention." Even the mythical "free market" invoked by politicians depends on government intervention to enforce laws enabling property ownership and contracts.
Some economists (and most politicians, businessmen, and lobbyists) like to define "market" in such a way that only their favored conditions qualify as a market, but if you take a fairly bland definition like Wikipedia's (A market is a social arrangement that allows buyers and sellers to discover information and carry out a voluntary exchange) then it's easy to imagine a market that solves environmental problems. Simply make it illegal to harm the environment! Current markets depend on external legal structures that outlaw theft, fraud, and a bevy of other actions that would result in a less desirable market (by some measure.) What's the difference?
Over the last year plus I've noticed more articles that tend to view Open Source projects as akin to 'hardnosed' business methods. I think they represent the establishment coming to a positive consensus about Open Source methods and projects.
That makes a certain amount of sense. Calling Open Source formal, heirarchical, and controlled could be a business-world way of establishing friendly relations by handing out generic compliments, like telling your new co-worker, "That's a nice shirt," or, "You have such a charming wife."
There are different ways of organizing a project. Some are better than others, and some are worse than nothing. The article suffers from a lack of specifics, and everyone will read it differently. By "rigid control structures," geeks are going to read, "The project leaders can vet and veto contributions," while business types will infer, "Contributors must get project leaders' permission before working on enhancements, and those who don't follow orders get locked out of the project."
Business types may also take the hundred thousands abandoned projects on SourceForge as a bad showing by open source. Geeks will understand that many of those failed projects were learning projects (guilty!), keep-busy projects by temporarily unemployed geeks, projects naively started by beginners, and projects abandoned when the prime developer went to college and discovered girls.
As a geek of some kind or another, let me point out that the coining of the word "anarchism" did not invalidate the existing usage of "anarchy" any more than the coining of "libertarianism" changed the meaning of "liberty."
Really? Is it really straightforward to look at assembly and know what the computer is doing? Assembly language tells you exactly what happens in a simple little machine with a certain number of registers where everything happens in a known order. Many modern CPUs are thousands of times more complex than the abstract machine described by their instruction set; they match the behavior of the abstract machine without containing a physical instance of it. Unless you're dealing with a very simple processor (probably an embedded one), the idea that you can know "what's REALLY going on inside that computer" is just a comforting fantasy that will be ripped out from under you sooner or later.
What is important is not the "realiness" (apologies, Stephen Colbert) of the abstraction you're working with. The important thing is to learn how to understand an abstraction and write good code for it, whether that abstraction is a J2EE application container or an assembly language interpreter. Then programmers start to ask the right questions: What am I promised by this abstraction, and what is merely accidental? How might different instantiations of this abstraction differ?
These are slightly different questions than the questions asked by a programmer who believes in thinking about "what's REALLY going on inside that computer," and in my opinion, they're much better. In the real world, you often have no control over or foreknowledge of which "real thing" your code will be running on, only which abstractions it will implement.
I disagree wholeheartedly with this. The first thing a beginner encounters in Java is a truckload of infrastructure and boilerplate that only makes sense to people who have worked on real programming projects. I want a beginner's critical thinking engaged and encouraged from day one; I don't want to start him out doing a bunch of work he doesn't understand the reason for. Either he'll get used to working that way (and I'll be responsible for lowering his IQ), or he'll decide that programming is for people with a slavish disposition.
It depends on how you look at it. I wouldn't call it science. Rather, I would split it up this way:
Proving the algorithm correct: MATH
Proving mathematical properties of the algorithm (e.g., big O stuff): MATH
Observing how the algorithm works on synthetic examples: (experimental) MATH or (speculative) ENGINEERING
Observing how the algorithm works on real-world examples: ENGINEERING (or market research) (or social SCIENCE, but I think that's a real stretch)
The best part is, now Micro$oft's excuse for fixing bugs so slowly -- the massive QA overhead created by their love for their customers -- just got stronger! With six versions of Windows to test for every bug fix, it will be too expensive to release updates. Any bugs discovered in Windows 2007 will bypass the debugging and QA process and become part of the release tests for Windows 2015.
Nobody I know (read: no techies) read Stand on Zanzibar, but I get the feeling that it's required reading at internet and media companies. Mr. and Mrs. Everywhere are scarily close, and Gmail is making them closer. What happens when every citizen's internet connection becomes a flattering, subtly manipulative mirror?
Major props to you for doing this. You're going to learn a lot about reuse from having your old code sitting around. I second putting it in Subversion.
This paragraph is about C++. Unfortunately, I don't know how to write it for your languages! Combine your code into libraries, and keep each library in a separate directory with its own Makefile. That way, you end up doing less Makefile hacking. To add one of your libraries, just copy the directory into your project, change the project's include path, and add the library file to the project's link step. It's much easier to do that for each library than to cut and paste code or cut or try to add one source file at a time. To learn all of these things, find a basic-to-intermediate tutorial for your compiler.
Rough translation for non-C++ languages: Store your code in such a way that it can be reused with a minimum of effort. Try to package your code at an appropriate granularity for reuse. If you reuse your code by cutting and pasting or by massive scripting, you've picked the wrong granularity.
Store documentation with each library. Ideally, you should be able to use the library without looking at the source code. If you can routinely reuse your own code by looking at the documentation instead of the source, you will be a pleasure for other programmers to work with.
Also consider keeping the third-party libraries you use in a similar repository. For a C++ programmer, that means Boost, XML libraries, etc. If the library is updated more often than you use it, store a small text file that says, "Foo library, good for bar, obtain from baz.org." You'll tend to use the same libraries over and over, which will make it easier to combine the modules you write into programs.
Practice all these things, then add a little theoretical CS and some management skills, and you'll be a better software developer than I was when I landed my first development job.
I'm not trolling. I don't dislike Firefox or have serious problems with it. I love it. I'm tired of one thing: I keep reading articles about users' Firefox memory problems, and every one has a dig against the users who have experienced problems. They're wrong for assuming it's a memory leak, wrong for not filing good enough bug reports, wrong because it isn't a bug, wrong because they don't understand how their system reports memory use. Wrong wrong wrong, always wrong. Even the mention of memory leaks here is only a prelude to moving on to a more acceptable explanation.
Suppose you and your friend both like to go hiking in the forest at night. Suppose your friend says he saw Bigfoot once. Now suppose that every time you see an animal in the forest -- a bear, a deer, a squirrel, a woodchuck -- you call up your friend and tell him about how you saw something that he might have mistaken for Bigfoot. He'd start to get pretty pissed at you, right? That's the reaction I have to this article and the others like it.
What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature.
I'm not one of the guys filing bug reports or asking for a fix. It only affects me when I surf porn, which is hardly a critical activity. However, this dismissive attitude toward users -- who have legitimate problems, after all, and aren't making stuff up for laughs -- really bothers me.
"What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature."
I'm tired of reading stuff like this. And then you say, "He didn't call it a feature."
What's going on? This is like watching a political talk show on CNBC. Deny, deny, deny. Convince people to trust you instead of their own eyes.
Wait! I forgot! I'm insane! You're right, I must have hallucinated the part where he said, "What you get out of it is faster performance as you navigate the web. For those who remain concerned, here's how the feature works." In fact, I probably made up your reply. I'm just replying to myself. Maybe this will finally convince those guys at Bellevue to let me stay a while.
Every time I close all the tabs in my browser session except two or three, then check a few hours later and see that Firefox is sluggish and hogging a few hundred megabytes, I go to the police and ask them to take me into protective custody. I'm obviously a danger to myself and others. When I'm not responsible enough to seek psychiatric help, I just stare at my monitor and tell myself, "You only see three tabs there, but that's because you're crazy. You still have all those dozens of porn tabs open. You just can't see them because you went blind masturbating."
Seriously, what's with all the song and dance? Firefox obviously has at least one problem, probably several, that leads to bad performance for many users, under certain circumstances. Call it a UI problem, call it a documentation problem, I don't care, just call it a problem. Don't call it a feature or a misunderstanding. Don't pick a feature that can't account for many of the reported problems and say, "Aha! This is THE Firefox memory leak that's bothering everyone. See? It's a feature!" The denials and talk-arounds on this issue are what you would expect from a political party, not an open-source software project.
Of course, I only know all this because I use Firefox. It's the best. The memory problems would only be a minor annoyance if I didn't have to constantly read about how I'm crazy or stupid.
Slashdot Mirror
Hardly. The languages for which gcc has front-ends (C, Fortran, C++, Ada, etc.) are heavily biased toward CPUs that process a stream of instructions: load, store, add, and, branch, compare, etc. The highly parallelized and pipelined designs that make FPGAs so much faster than microprocessors can't be expressed in software languages, and producing a good hardware design that is equivalent to a given C program is, well, a much harder problem than creating hardware designers who can design in VHDL and Verilog.
Put another way, getting a good hardware design from a good software developer is as likely as getting a good software design from a bad software developer, because it's just as hard. (The first company that cracks either of these nuts will instantly become a household name, so don't worry about missing it.) Hopefully, as FPGAs reduce the barrier to entry in hardware design, the number of VHDL/Verilog designers will rise to meet demand.
I think what you're saying is that the market is skewed. There are plenty of happy developers who get paid to do their favorite thing in the world. However, since the only barriers to entry are loving programming and having lots of free time, there are many, many people scrambling to get those jobs.
There is no requirement that software developers get a four year professional degree after college. There is no artificial barrier that guarantees that anybody who jumps through hoops X, Y, and Z will enjoy high demand for their skills. If medicine were like software development, there would be tens of thousands of frustrated neurosurgeons working as nurses and bitching about how there aren't any jobs.
Software isn't like law or medicine; it's more like music and sports. It's hard to figure out when to give up trying, and many talented people fall through the cracks because of bad luck or because their skills can only blossom in a certain setting that they can't arrange or that just doesn't exist. Whether you're an aspiring software architect who ends up working as a help desk guy or an aspiring pro linebacker who ends up as a high school gym teacher, it hurts like hell to figure out at twenty-five or thirty that you've put fifteen years of your life into learning skills that will never put you over $50k per year.
I'm guessing this is something that displays on my computer monitor? Thanks but no thanks. I'm waiting for the wall-sized ones.
And the remaining diminishing returns aren't worth an order-of-magnitude loss of productivity.
If you're an order of magnitude less productive in an office than at home, that's a perfectly acceptable reason to telecommute. Why in the world would that be, though? I telecommute now (forcibly, since my coworkers are out of town), and the isolation really sucks. It's more awkward to ask for help, so people only do it formally for big problems, never informally for small problems. We've essentially neutered ourselves into only providing value on projects we're officially assigned to. Mostly we limit ourselves to what we can accomplish by ourselves, which makes us less ambitious than we should be.
One of the charms of my old job was that people regularly came to me with hard problems, small or large, and in return I could go pick their brains when I needed to. This resulted in everyone having at least a basic grasp of everyone else's work, not to mention the small efficiencies that come from everyone doing what they're good at.
Now I do that more with the guys I drink beer with than with my coworkers. It's boring and frustrating.
The telephone is much better than email, but you have no hand gestures and no whiteboard, and when the other guy isn't talking, you have zero feedback. Is he impatient? Shifting his weight? Looking confused? The more you replicate the face-to-face experience, the better it gets: videophones, virtual whiteboards, etc. There's a long way to go before it gets as good as face-to-face. And you can't borrow or lend a book through virtual reality unless it's an e-book (barf!)
In a face-to-face environment, you can peel off and have a twenty minute chat with your coworker about what you're each doing. Sometimes you can solve each other's problems, or help them solve them by asking questions. A twenty minute face-to-face chat can communicate a huge amount of information, especially when everyone has a whiteboard. Email can't accomplish that. The art of being as expressive in pure text as one is when speaking is very, very rare, and doing it at the same speed is pretty freaky. Doing it at the same speed with no access to the audience's feedback simply can't be done.
Suppose you each spend your twenty minutes on email instead: ten minutes of that time writing an email, five minutes reading the other guy's email, and five minutes writing a response. First, a ten-minute email is going to be very short or very poorly written. (We get much more information from poorly composed speech than from poorly composed prose.) It will convey very little of what you're working on. Second, without cues from the other person, you don't know how to skip past the parts he knows about and add more detail when he doesn't understand. Third, if your buddy senses that you're glossing over something (that you may or may not be aware of), you won't know until the end of the twenty minutes. Finally, there isn't time for multiple back-and-forths. In conversation, it's routine to go deep into exchanges of I say "X," you say "but Y," I say "Y'", you say "No, Y~, in fact, Y~3*!", I say, "Oh, yeah, we're probably doing that wrong," then I pop back up to the top level and continue talking about X. That back and forth probably wouldn't happen if we were communicating via email, and if it did, it would take hours instead of minutes.
Email example: "My gut instinct tells me you hookie-dookie won't scale. The flooge calculation will tell you whether it will or not. I don't know if you're familiar with it, but you can find it in 'Algorithms, Orangutans, and Phlogiston,' by Rivest and a few other guys. The way it applies to your hookie-dookie is ...." After five minutes of typing, you send the email.
Face-to-face example: "Did you do the flooge calculation?" "Yes, of course." "Did you get something on the same order of magnitude as 1,000?" "No, more like tens of millions." "That smells fishy to me. Let's run through it together." "Wait, I'll go get Serge. He's the guy who did our calculation, and he understands the math better than me." That takes less than a minute, and already you're well on your way to solving the problem. Face-to-face saves even more time if flooge isn't the problem: twenty seconds worth of chatting vs. five minutes of email.
Plus, everyone is too formal in videoconferences. It isn't human. You can't take a virtual walk together. You have to stay in front of a friggin' camera like a Hollywood actor instead of going to the coffeeshop together and bitching about the boss like normal human beings. It's awkward to interrupt, so no one does it. People sit like statues when they're listening and talk for minutes at a time when they're speaking, even when only two people are on. And when you're done, you don't feel like you've had a break, you feel like you're ready for one.
Maybe those problems that will pass when people get used to it. I'll take a wait-and-see approach.
Business vs. security? No contest. Why do you think security regulations that supposedly protect us from terrorists also help companies hide bad behavior from citizens, and the Pentagon's budget is filled with boondoggle projects it doesn't even want? The military and the security complex aren't political power centers -- yet.
No, pyite has it right -- I'm talking about the class called "Abstract Algebra," "Modern Algebra," or "Groups, Rings, and Fields," a senior-level class taken mostly by math majors and scientists who plan on going to grad school.
Doing algebra proofs for a few semesters makes you careful about designing datatypes. Does this bundle of data behave well as a whole? Can I make it behave well? Can I construct it as a combination of simpler datatypes? How do I define 0 and 1? A datatype with an algebraic structure is easier to program than a datatype that doesn't follow a useful set of rules.
That's why algebra itself is a good topic, but the type of course is more important. Upper-level algebra is a pure math course focused on proofs and counterexamples rather than calculating results. It's good to know, viscerally, as a result of brutal experience, that changing one or two simple assumptions can make a long proof short or an impossible proof easy, and vice-versa. Programs are proofs, so this instinct is crucial for doing software requirements, estimates, and design.
Any pure math course will teach this just as well as algebra, but courses more focused on calculating results will not. Most colleges teach three of four upper-level pure math classes that focus on preparing math majors for grad school: algebra and analysis are universal, and topology is fairly common. Set theory is by far the best course for computer science majors, but it is less common than it should be. Undergraduate courses in statistics, linear algebra, numerical analysis, differential equations, complex analysis, and vector calculus usually skimp on proofs. Almost all of the assigned problems and test problems should be proofs.
By "throw it all away," do you mean ditch school and go for a job with what you have? That's a bad idea. If you mean switch to computer science or math as a degree, by all means do it! Just make sure you work in the math classes somehow. If you get a CS degree, make sure you take the upper-level algebra and set theory courses from the math department, and if you get a math degree, make sure you take *at least* an upper-level operating systems class, computer architecture, and the basic theory class (usually called something like "Automata Theory and Formal Languages.")
Exactly. Article writer has no knowledge in the area.
Or perhaps you're missing the point.
The article writer isn't saying that a smart, conscientious C programmer can't copy strings correctly 98% of the time. He's saying it isn't good enough to meet that standard, and most languages do better. Even C++ allows you to simply write string s2 = s1.
To do the same thing in C, the programmer must know or check the length of s1, know or check the length of s2 (actually, know or check whether s2 points to any memory at all), possibly reallocate memory for s2, and copy exactly the right number of characters from s1 to s2. There are many possibilities for a typo or a lack of caffeine to open a security hole.
this problem of stupid/lazy programmer
No one denies that requiring several lines of finicky code to perform a simple operation separates the mental weenies from mental he-men. If your ego is the biggest thing on the line when you create software, by all means, keep using C for everything.
Some economists (and most politicians, businessmen, and lobbyists) like to define "market" in such a way that only their favored conditions qualify as a market, but if you take a fairly bland definition like Wikipedia's (A market is a social arrangement that allows buyers and sellers to discover information and carry out a voluntary exchange) then it's easy to imagine a market that solves environmental problems. Simply make it illegal to harm the environment! Current markets depend on external legal structures that outlaw theft, fraud, and a bevy of other actions that would result in a less desirable market (by some measure.) What's the difference?
That makes a certain amount of sense. Calling Open Source formal, heirarchical, and controlled could be a business-world way of establishing friendly relations by handing out generic compliments, like telling your new co-worker, "That's a nice shirt," or, "You have such a charming wife."
Business types may also take the hundred thousands abandoned projects on SourceForge as a bad showing by open source. Geeks will understand that many of those failed projects were learning projects (guilty!), keep-busy projects by temporarily unemployed geeks, projects naively started by beginners, and projects abandoned when the prime developer went to college and discovered girls.
As a geek of some kind or another, let me point out that the coining of the word "anarchism" did not invalidate the existing usage of "anarchy" any more than the coining of "libertarianism" changed the meaning of "liberty."
Really? Is it really straightforward to look at assembly and know what the computer is doing? Assembly language tells you exactly what happens in a simple little machine with a certain number of registers where everything happens in a known order. Many modern CPUs are thousands of times more complex than the abstract machine described by their instruction set; they match the behavior of the abstract machine without containing a physical instance of it. Unless you're dealing with a very simple processor (probably an embedded one), the idea that you can know "what's REALLY going on inside that computer" is just a comforting fantasy that will be ripped out from under you sooner or later.
What is important is not the "realiness" (apologies, Stephen Colbert) of the abstraction you're working with. The important thing is to learn how to understand an abstraction and write good code for it, whether that abstraction is a J2EE application container or an assembly language interpreter. Then programmers start to ask the right questions: What am I promised by this abstraction, and what is merely accidental? How might different instantiations of this abstraction differ?
These are slightly different questions than the questions asked by a programmer who believes in thinking about "what's REALLY going on inside that computer," and in my opinion, they're much better. In the real world, you often have no control over or foreknowledge of which "real thing" your code will be running on, only which abstractions it will implement.
I disagree wholeheartedly with this. The first thing a beginner encounters in Java is a truckload of infrastructure and boilerplate that only makes sense to people who have worked on real programming projects. I want a beginner's critical thinking engaged and encouraged from day one; I don't want to start him out doing a bunch of work he doesn't understand the reason for. Either he'll get used to working that way (and I'll be responsible for lowering his IQ), or he'll decide that programming is for people with a slavish disposition.
Proving the algorithm correct: MATH
Proving mathematical properties of the algorithm (e.g., big O stuff): MATH
Observing how the algorithm works on synthetic examples: (experimental) MATH or (speculative) ENGINEERING
Observing how the algorithm works on real-world examples: ENGINEERING (or market research) (or social SCIENCE, but I think that's a real stretch)
Don't be a defeatist. We're bound to triumph if we give the drug companies everything they ask for.
The best part is, now Micro$oft's excuse for fixing bugs so slowly -- the massive QA overhead created by their love for their customers -- just got stronger! With six versions of Windows to test for every bug fix, it will be too expensive to release updates. Any bugs discovered in Windows 2007 will bypass the debugging and QA process and become part of the release tests for Windows 2015.
Nobody I know (read: no techies) read Stand on Zanzibar, but I get the feeling that it's required reading at internet and media companies. Mr. and Mrs. Everywhere are scarily close, and Gmail is making them closer. What happens when every citizen's internet connection becomes a flattering, subtly manipulative mirror?
Major props to you for doing this. You're going to learn a lot about reuse from having your old code sitting around. I second putting it in Subversion.
This paragraph is about C++. Unfortunately, I don't know how to write it for your languages! Combine your code into libraries, and keep each library in a separate directory with its own Makefile. That way, you end up doing less Makefile hacking. To add one of your libraries, just copy the directory into your project, change the project's include path, and add the library file to the project's link step. It's much easier to do that for each library than to cut and paste code or cut or try to add one source file at a time. To learn all of these things, find a basic-to-intermediate tutorial for your compiler.
Rough translation for non-C++ languages: Store your code in such a way that it can be reused with a minimum of effort. Try to package your code at an appropriate granularity for reuse. If you reuse your code by cutting and pasting or by massive scripting, you've picked the wrong granularity.
Store documentation with each library. Ideally, you should be able to use the library without looking at the source code. If you can routinely reuse your own code by looking at the documentation instead of the source, you will be a pleasure for other programmers to work with.
Also consider keeping the third-party libraries you use in a similar repository. For a C++ programmer, that means Boost, XML libraries, etc. If the library is updated more often than you use it, store a small text file that says, "Foo library, good for bar, obtain from baz.org." You'll tend to use the same libraries over and over, which will make it easier to combine the modules you write into programs.
Practice all these things, then add a little theoretical CS and some management skills, and you'll be a better software developer than I was when I landed my first development job.
Suppose you and your friend both like to go hiking in the forest at night. Suppose your friend says he saw Bigfoot once. Now suppose that every time you see an animal in the forest -- a bear, a deer, a squirrel, a woodchuck -- you call up your friend and tell him about how you saw something that he might have mistaken for Bigfoot. He'd start to get pretty pissed at you, right? That's the reaction I have to this article and the others like it.
What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature.
I'm not one of the guys filing bug reports or asking for a fix. It only affects me when I surf porn, which is hardly a critical activity. However, this dismissive attitude toward users -- who have legitimate problems, after all, and aren't making stuff up for laughs -- really bothers me.
From TFA:
"What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature."
I'm tired of reading stuff like this. And then you say, "He didn't call it a feature."
What's going on? This is like watching a political talk show on CNBC. Deny, deny, deny. Convince people to trust you instead of their own eyes.
Wait! I forgot! I'm insane! You're right, I must have hallucinated the part where he said, "What you get out of it is faster performance as you navigate the web. For those who remain concerned, here's how the feature works." In fact, I probably made up your reply. I'm just replying to myself. Maybe this will finally convince those guys at Bellevue to let me stay a while.
Every time I close all the tabs in my browser session except two or three, then check a few hours later and see that Firefox is sluggish and hogging a few hundred megabytes, I go to the police and ask them to take me into protective custody. I'm obviously a danger to myself and others. When I'm not responsible enough to seek psychiatric help, I just stare at my monitor and tell myself, "You only see three tabs there, but that's because you're crazy. You still have all those dozens of porn tabs open. You just can't see them because you went blind masturbating."
Seriously, what's with all the song and dance? Firefox obviously has at least one problem, probably several, that leads to bad performance for many users, under certain circumstances. Call it a UI problem, call it a documentation problem, I don't care, just call it a problem. Don't call it a feature or a misunderstanding. Don't pick a feature that can't account for many of the reported problems and say, "Aha! This is THE Firefox memory leak that's bothering everyone. See? It's a feature!" The denials and talk-arounds on this issue are what you would expect from a political party, not an open-source software project.
Of course, I only know all this because I use Firefox. It's the best. The memory problems would only be a minor annoyance if I didn't have to constantly read about how I'm crazy or stupid.