If you have to fix up code, then it means it was poorly thought out to begin with.
The only way to write good, bug-free code is to use formal methods. But from what I've seen, maybe 1 in 1000 coders know how to do this. Therefore people keep buying these books on refactoring, extreme programming, and design patterns to try to get a quick fix for their lack of fundamental knowledge.
It reminds me of how people keep buying these diet books, diet shakes, and diet pills to lose weight when everyone knows that exercise + less calorie intake is 100% effective for weight loss. Mathematically checking your code produces lean and bug-free code all the time. But the engineers universities crank out now are SO BAD that they have to search through these silly books in the hopes of making their code less horrible. The books are almost comical in their "great" insights: choose descriptive variable names, test your code, don't have functions that are hundreds of lines long, etc. If a person needs a book to tell them that instead of common sense, they are in the wrong business.
I know a few idiots who could code in C; but never managed to get Java. They couldn't understand anything beyond functional programming.
Functional programming is not C programming. Functional programming is a programming paradigm where the state is maintained by the implementation (usually on a stack) as opposed to maintaining state with assignment statements. C and Java are both imperative programming languages as opposed to functional programming languages. As for bad programmers, there are bad ones in every language.
Don't forget about its use in embedded systems. For every processor that is chugging away at java, there are hundreds running on lean C code: your average car has over 300 embedded processors. With the limited memory and processing power in an embedded systems nothing beats the speed, low memory overhead, and low-level features of C.
I agree that threads are a crappy way of doing parallel processing. It's better to just extend c/c++ with some message passing interface. That way if a programmer actually knows parallel processing, they can incorporate it into their code in a portable manner. And people that don't know any parallel programming can still write an inefficient version of the same thing. For all the hype, parallel programming isn't THAT difficult. After all, something like VHDL or verilog is basically just parallel programming.
I'm on the VHDL side and I agree about schematics being bad. It takes longer to draw them and they are harder to read. To trace signals, you have to highlight the wire and then go on a huge search over the schematic to find it. The whole time you are zooming and unzooming. With a text-based language you can just do a simple search and find the information instantly.
Another thing is how hard it is to modify a schematic.
In VHDL I can easily insert an inverter. In a schematic, you have to spend several minutes tearing up wiring and changing stuff around.
The problem is that people in management don't look at engineers as professionals. They think any jackass can do it, which is why they go and hire 10 buffoons at an offshore site to do an inferior version of the work that 1 competent engineer could do. At my last job I would have to sit typing emails to teach some Malaysians how to do things they should have learned in the first year of college. That's why they don't give us offices where we can get some privacy to do our work in peace.
I'd actually buy one except that I'm into reading technical books and it looks like Amazon hasn't made enough of them available for the Kindle.
One of my reasons is that I think over time it costs less. Technical books are expensive to replace (they cost more and once they go out of print they are easily over $100.) With Kindle, Amazon keeps all your books on their server, so you can always download them again free of charge.
Also it would be cool to carry a Kindle to work and have my entire library of reference books right there without having to lug around a briefcase.
But like I said, until they heavily increase the number of books available for Kindle, I won't spend the money for it.
Not very surprising. Having written code and hardware for a Nasdaq 100 company and a small company, it is obvious that a big company will rarely do anything right. In a big company you have an army of marketing people (that know little to nothing about the product) deciding what "cool" new features the software should have. Even the engineering departments devolve into big political battles. You can't even wipe yourself in the toilet without getting 50 people to sign off on it.
Consider the gazillions of dollars microsoft has spent on R&D. Now consider the new technologies they have produced - I couldn't think of any either. They basically just park their finger in the sphincter and then lift it in the air to see which way the industry winds are blowing and clone someone else's product.
Slashdot Mirror
If you have to fix up code, then it means it was poorly thought out to begin with.
The only way to write good, bug-free code is to use formal methods. But from what I've seen, maybe 1 in 1000 coders know how to do this. Therefore people keep buying these books on refactoring, extreme programming, and design patterns to try to get a quick fix for their lack of fundamental knowledge.
It reminds me of how people keep buying these diet books, diet shakes, and diet pills to lose weight when everyone knows that exercise + less calorie intake is 100% effective for weight loss. Mathematically checking your code produces lean and bug-free code all the time. But the engineers universities crank out now are SO BAD that they have to search through these silly books in the hopes of making their code less horrible. The books are almost comical in their "great" insights: choose descriptive variable names, test your code, don't have functions that are hundreds of lines long, etc. If a person needs a book to tell them that instead of common sense, they are in the wrong business.
Functional programming is not C programming. Functional programming is a programming paradigm where the state is maintained by the implementation (usually on a stack) as opposed to maintaining state with assignment statements. C and Java are both imperative programming languages as opposed to functional programming languages.
As for bad programmers, there are bad ones in every language.
Don't forget about its use in embedded systems. For every processor that is chugging away at java, there are hundreds running on lean C code: your average car has over 300 embedded processors. With the limited memory and processing power in an embedded systems nothing beats the speed, low memory overhead, and low-level features of C.
I agree that threads are a crappy way of doing parallel processing. It's better to just extend c/c++ with some message passing interface. That way if a programmer actually knows parallel processing, they can incorporate it into their code in a portable manner. And people that don't know any parallel programming can still write an inefficient version of the same thing. For all the hype, parallel programming isn't THAT difficult. After all, something like VHDL or verilog is basically just parallel programming.
What makes this funny is that it is probably how it really happened.
I'm on the VHDL side and I agree about schematics being bad. It takes longer to draw them and they are harder to read. To trace signals, you have to highlight the wire and then go on a huge search over the schematic to find it. The whole time you are zooming and unzooming. With a text-based language you can just do a simple search and find the information instantly. Another thing is how hard it is to modify a schematic. In VHDL I can easily insert an inverter. In a schematic, you have to spend several minutes tearing up wiring and changing stuff around.
The problem is that people in management don't look at engineers as professionals. They think any jackass can do it, which is why they go and hire 10 buffoons at an offshore site to do an inferior version of the work that 1 competent engineer could do. At my last job I would have to sit typing emails to teach some Malaysians how to do things they should have learned in the first year of college. That's why they don't give us offices where we can get some privacy to do our work in peace.
I'd actually buy one except that I'm into reading technical books and it looks like Amazon hasn't made enough of them available for the Kindle. One of my reasons is that I think over time it costs less. Technical books are expensive to replace (they cost more and once they go out of print they are easily over $100.) With Kindle, Amazon keeps all your books on their server, so you can always download them again free of charge. Also it would be cool to carry a Kindle to work and have my entire library of reference books right there without having to lug around a briefcase. But like I said, until they heavily increase the number of books available for Kindle, I won't spend the money for it.
More proof that building closer economic ties to China will bring freedom and democracy there.
Not very surprising. Having written code and hardware for a Nasdaq 100 company and a small company, it is obvious that a big company will rarely do anything right. In a big company you have an army of marketing people (that know little to nothing about the product) deciding what "cool" new features the software should have. Even the engineering departments devolve into big political battles. You can't even wipe yourself in the toilet without getting 50 people to sign off on it. Consider the gazillions of dollars microsoft has spent on R&D. Now consider the new technologies they have produced - I couldn't think of any either. They basically just park their finger in the sphincter and then lift it in the air to see which way the industry winds are blowing and clone someone else's product.