Why do you need a book for that? I tend to use other resources precisely because I can dive in as far as I want, past what any single book would contain, in order to understand anything I come across that doesn't quite make sense yet. It's much cheaper to get this information from places other than one-book-per-technology.
You know what, I'm sick of this argument. Even if I don't choose PHP for any of my projects, it matters to me who chooses it and how popular it becomes.
Why?
1) The more people who think it's a good language and start using it, the more poorly-written, insecure web sites there will be. Yes, you can write secure pages in PHP, but you can also write secure pages in assembler. Do you think either one is a good idea?
2) The more people who think it's a good idea to uses PHP, the more people are in need of third-party libraries. This means fewer third-party developers working on libraries for decent languages.
3) The more people who use PHP, the more projects are floating around, and the chances of me having to maintain one increases. Have you ever had a PHP project dumped in your lap? Did you appreciate it?
So no, I don't buy the argument that I should just keep quiet and let people use whatever they want to use, because it DOES affect me. I believe that the proverbial "we" would progress much faster in all areas of computing if certain languages just died. Too bad I don't think natural selection works in the current market place because I don't believe it truly is a free market.
This only works for the smallest of projects - imagine if a CVS commit took 5 hours while waiting for the new code to build and another hour while waiting for some tools to check over coding standards and static analysis? Hah! Ignoring the non-atomic nature of CVS and the race conditions that will happen, I'm not waiting 4 hours per check-in!
A better idea is to run these things nightly, with automatic notifications going to the appropriate parties.
A good idea to get you started would be to write testcases for the problems you debug and solve manually. This has a few benefits:
- You are now familiar with the functionality of that piece of code, so writing a test should be easy.
- Having a test ensures that no future code changes will cause the same bug (it is very embarassing to re-introduce a fixed bug).
- Having a test also ensures that other code changes don't affect anything related to this functionality working. This can also help uncover unnecessary coupling - when this testcase fails in the future because something seemingly unrelated changed, you can investigate what is really going on because you will be alerted to it much sooner.
SPOILER: Re:Another Example
on
Java Puzzlers
·
· Score: 2, Informative
Since there is a String class that exists within the bad class, this prototype:
public static void main(String[] args)
is the same as this:
public static void main(bad.String[] args)
and java can't find any main to execute because it is looking for:
IPv6 has built-in support for re-configuring upstream routers to find your machine on a new network, with a new IP, automatically? Where an I read more about that?
Wrong, wrong, wrong! This is my last post on this topic, because I'm sick of repeating myself.
Memory management is not some "machine level" skill. It's basic resource management. It is the same as handling any other resource: open files, database connections, ANYTHING. If you read my last post, you would have understood this. I'm not talking about implementing a memory manager, I'm talking about simply acquiring a resource and freeing it up again the right place. This is basic programming, and anyone who can't structure their code to handle resources will cause problems. If they can't handle memory management, then I argue that they can't handle ANY resource management, and Java or no Java, resource management is important. No JVM or language will replace knowing how to manage resources. Sorry.
Please don't confuse being skilled with assembly and being a skilled programmer. A skilled programmer will make the best of whatever language he or she is given. If they are using assembly, and they see areas where they can be more efficient, they will create new libraries and languages, and the best of them will be re-used for many years.
I'm not trying to single out Java here; sometimes, I think Java is the right tool for the job. My point is to single out this flawed logic of yours:
it still costs me more to hire programmers who don't generate memory leaks than to use their less-qualified peers and a JVM
My point is this: "programmers who don't generate memory leaks" are generally programmers who are skilled at programming in general. They understand computers and how they work; they understand programming languages and how to use them to get the job done. They understand how to encapsulate things, how to separate concerns, how to keep cohesiveness to a minimum, and how to get the most from their tools.
If you would rather have someone without these skills, just because you think Java protects you from the poor programming they will produce, then you're mistaken. The mistakes these unskilled programmers make span way beyond memory management, and if you think that memory management is some special case that is different from maintaining database connections, open files, or any other resource, you're wrong. These "cheaper" programmers will be more expensive in the long run.
Programming skills are important, and no language can protect you from those who don't have them. Don't single out memory management as the cause of your problems. Poor developers are the cause, and hiring cheaper developers who don't understand this stuff just because you think Java will protect them just perpetuates the problem.
Productivity may be slightly hindered by the language (how easy is it to encapsulate functionality into easy-to-use packages), but I argue that it is dominated much more by the easy-to-use packages that are used.
Java certainly helps here, but good libraries can be written in many languages. In fact, most libraries are written in C so that they can be used from many languages. A library written in C plus a small wrapper for the language-du-jour is a library usable from many languages. If you have good developers on your team, libraries will be written and re-used, and productivity will be high.
Productivity comes from writing solid libraries so that you don't have to duplicate effort. Productivity comes from understanding how technologies work before you use them, so that you can avoid bug fixes, re-architecting the product, etc.
My point is that a majority of productivity doesn't come from the language, and neither does a majority of the bug-avoidance. Java may help you in a few small ways, but if you are telling me that you'd rather have people with fewer skills just because you think Java will make up for it, you're mistaken.
In fact, I argue that when you take the time to write maintainable C or C++ code (which isn't much more time that throwing crap together), you AUTOMATICALLY get to a point where memory allocation becomes second nature.
With a well-structured program with separate modules and a functional API, allocation and deallocation just fit right in. There's rarely a case where you forget to clean up memory, just like with proper structure, you rarely forget to close a file. It's the same problem, and it has the same solution, but in C/C++, I get performance and a lower memory footprint out of it too.
Maintainable code and performance are not mutually exclusive.
If you are hiring programmers who can't understand simple memory allocation and deallocation, you are more likely to run into a maintenance nightmare.
Good programmers know how to write structured code that's easy to maintain, and a side effect of this is that memory allocation becomes second nature (like most other "problem": buffer overruns, memory leaks, etc). When you write good code, these problems rarely exist. The code structure sees to it.
Just because Java tries to save you from one issue doesn't mean you can throw programmers with fewer skills at it and get the same result. Quality will suffer, because there are sill plenty of mistakes to be made in Java, and they all cost your bottom line just as much.
*Every* major distribution has a full package manager that does dependency installation for you - automatically!
Even if you want to install something that isn't packaged for your distribution, you can still install the dependencies with the package manager, and what they depend on recursively will also be installed.
Oh, you can update everything on your system with one command, too.
Things have vastly improved since the days of manually tracking down software. Well, in Linux they have.
Also, of course, I could never share documents with others at work.
I think the beauty of a text-only format like TeX and LaTeX is that you can share it with everyone. In fact, more people can make small additions to a TeX document than they can a Word document. There's also nothing for them to install, you can store the document in a revision control system and get meaningfull history (diffs), there's no hidden information inside of it, etc.
Except dogs are more like humans than other animals like chickens. In my mind, eating a chicken is better because it is further from cannibalism. I wouldn't eat any apes or gorillas either.
Remember that buffer overflows are not the only security vulnerability. Currently they happen to be a large one, but there were many exploits that were possible simply because of bad logic.
I remember an IIS flaw that was exploited because the server decoded a URL, checked to see if it was valid (i.e. not pointing to some arbitrary thing outside the document root), then before opening the file, decoded it AGAIN! This second decode was done without a second check, meaning that a URL that decoded twice into something harmful passed through.
Managed code does fix some things, but it's not a cure-all.
Unless the system doesn't boot from CD by default (like all the computers where I work) and you need a BIOS password to change the option (like all the computers where I work) and the case is locked so it isn't easy to reset the bios (like all the computeres where I work).
Slashdot Mirror
Why do you need a book for that? I tend to use other resources precisely because I can dive in as far as I want, past what any single book would contain, in order to understand anything I come across that doesn't quite make sense yet. It's much cheaper to get this information from places other than one-book-per-technology.
And if they die... then they aren't a beating-heart donor.
Great!
You know what, I'm sick of this argument. Even if I don't choose PHP for any of my projects, it matters to me who chooses it and how popular it becomes.
Why?
1) The more people who think it's a good language and start using it, the more poorly-written, insecure web sites there will be. Yes, you can write secure pages in PHP, but you can also write secure pages in assembler. Do you think either one is a good idea?
2) The more people who think it's a good idea to uses PHP, the more people are in need of third-party libraries. This means fewer third-party developers working on libraries for decent languages.
3) The more people who use PHP, the more projects are floating around, and the chances of me having to maintain one increases. Have you ever had a PHP project dumped in your lap? Did you appreciate it?
So no, I don't buy the argument that I should just keep quiet and let people use whatever they want to use, because it DOES affect me. I believe that the proverbial "we" would progress much faster in all areas of computing if certain languages just died. Too bad I don't think natural selection works in the current market place because I don't believe it truly is a free market.
-Serp
What if I checked in a header file that is included in many places? What if the build runs the testcases?
The point is that even for a CVS check-in to take 5 minutes is absurd.
This only works for the smallest of projects - imagine if a CVS commit took 5 hours while waiting for the new code to build and another hour while waiting for some tools to check over coding standards and static analysis? Hah! Ignoring the non-atomic nature of CVS and the race conditions that will happen, I'm not waiting 4 hours per check-in!
A better idea is to run these things nightly, with automatic notifications going to the appropriate parties.
A good idea to get you started would be to write testcases for the problems you debug and solve manually. This has a few benefits:
- You are now familiar with the functionality of that piece of code, so writing a test should be easy.
- Having a test ensures that no future code changes will cause the same bug (it is very embarassing to re-introduce a fixed bug).
- Having a test also ensures that other code changes don't affect anything related to this functionality working. This can also help uncover unnecessary coupling - when this testcase fails in the future because something seemingly unrelated changed, you can investigate what is really going on because you will be alerted to it much sooner.
Since there is a String class that exists within the bad class, this prototype:
public static void main(String[] args)
is the same as this:
public static void main(bad.String[] args)
and java can't find any main to execute because it is looking for:
public static void main(java.lang.String[] args)
See?
IPv6 has built-in support for re-configuring upstream routers to find your machine on a new network, with a new IP, automatically? Where an I read more about that?
Wrong, wrong, wrong! This is my last post on this topic, because I'm sick of repeating myself.
Memory management is not some "machine level" skill. It's basic resource management. It is the same as handling any other resource: open files, database connections, ANYTHING. If you read my last post, you would have understood this. I'm not talking about implementing a memory manager, I'm talking about simply acquiring a resource and freeing it up again the right place. This is basic programming, and anyone who can't structure their code to handle resources will cause problems. If they can't handle memory management, then I argue that they can't handle ANY resource management, and Java or no Java, resource management is important. No JVM or language will replace knowing how to manage resources. Sorry.
Please don't confuse being skilled with assembly and being a skilled programmer. A skilled programmer will make the best of whatever language he or she is given. If they are using assembly, and they see areas where they can be more efficient, they will create new libraries and languages, and the best of them will be re-used for many years.
I'm not trying to single out Java here; sometimes, I think Java is the right tool for the job. My point is to single out this flawed logic of yours:
it still costs me more to hire programmers who don't generate memory leaks than to use their less-qualified peers and a JVM
My point is this: "programmers who don't generate memory leaks" are generally programmers who are skilled at programming in general. They understand computers and how they work; they understand programming languages and how to use them to get the job done. They understand how to encapsulate things, how to separate concerns, how to keep cohesiveness to a minimum, and how to get the most from their tools.
If you would rather have someone without these skills, just because you think Java protects you from the poor programming they will produce, then you're mistaken. The mistakes these unskilled programmers make span way beyond memory management, and if you think that memory management is some special case that is different from maintaining database connections, open files, or any other resource, you're wrong. These "cheaper" programmers will be more expensive in the long run.
Programming skills are important, and no language can protect you from those who don't have them. Don't single out memory management as the cause of your problems. Poor developers are the cause, and hiring cheaper developers who don't understand this stuff just because you think Java will protect them just perpetuates the problem.
Productivity may be slightly hindered by the language (how easy is it to encapsulate functionality into easy-to-use packages), but I argue that it is dominated much more by the easy-to-use packages that are used.
Java certainly helps here, but good libraries can be written in many languages. In fact, most libraries are written in C so that they can be used from many languages. A library written in C plus a small wrapper for the language-du-jour is a library usable from many languages. If you have good developers on your team, libraries will be written and re-used, and productivity will be high.
Productivity comes from writing solid libraries so that you don't have to duplicate effort. Productivity comes from understanding how technologies work before you use them, so that you can avoid bug fixes, re-architecting the product, etc.
My point is that a majority of productivity doesn't come from the language, and neither does a majority of the bug-avoidance. Java may help you in a few small ways, but if you are telling me that you'd rather have people with fewer skills just because you think Java will make up for it, you're mistaken.
You can have both!
In fact, I argue that when you take the time to write maintainable C or C++ code (which isn't much more time that throwing crap together), you AUTOMATICALLY get to a point where memory allocation becomes second nature.
With a well-structured program with separate modules and a functional API, allocation and deallocation just fit right in. There's rarely a case where you forget to clean up memory, just like with proper structure, you rarely forget to close a file. It's the same problem, and it has the same solution, but in C/C++, I get performance and a lower memory footprint out of it too.
Maintainable code and performance are not mutually exclusive.
If you are hiring programmers who can't understand simple memory allocation and deallocation, you are more likely to run into a maintenance nightmare.
Good programmers know how to write structured code that's easy to maintain, and a side effect of this is that memory allocation becomes second nature (like most other "problem": buffer overruns, memory leaks, etc). When you write good code, these problems rarely exist. The code structure sees to it.
Just because Java tries to save you from one issue doesn't mean you can throw programmers with fewer skills at it and get the same result. Quality will suffer, because there are sill plenty of mistakes to be made in Java, and they all cost your bottom line just as much.
*Every* major distribution has a full package manager that does dependency installation for you - automatically!
Even if you want to install something that isn't packaged for your distribution, you can still install the dependencies with the package manager, and what they depend on recursively will also be installed.
Oh, you can update everything on your system with one command, too.
Things have vastly improved since the days of manually tracking down software. Well, in Linux they have.
I'm a long term linux user.
I've never encountered it.
Also, of course, I could never share documents with others at work.
I think the beauty of a text-only format like TeX and LaTeX is that you can share it with everyone. In fact, more people can make small additions to a TeX document than they can a Word document. There's also nothing for them to install, you can store the document in a revision control system and get meaningfull history (diffs), there's no hidden information inside of it, etc.
If you want to be pedantic, you need more checks. You can't source what's not a file.
:)
I have a ~/.DEITY directory full of gods
Haha, have "+5 insightful" twice in a post and get modded insightful!
Mods: The parent post was *informative*. See how it works? Not insightful, but informative.
Mod this up, if you get it (am I too late?)
I agree, and that's why I like izarc - it has this feature too.
It may not be about the money, but it still costs plenty to keep a trademark. Some money needs to be charged just to break even.
Except dogs are more like humans than other animals like chickens. In my mind, eating a chicken is better because it is further from cannibalism. I wouldn't eat any apes or gorillas either.
o g_feature1.shtml
http://www.genomenewsnetwork.org/articles/11_01/D
Remember that buffer overflows are not the only security vulnerability. Currently they happen to be a large one, but there were many exploits that were possible simply because of bad logic.
I remember an IIS flaw that was exploited because the server decoded a URL, checked to see if it was valid (i.e. not pointing to some arbitrary thing outside the document root), then before opening the file, decoded it AGAIN! This second decode was done without a second check, meaning that a URL that decoded twice into something harmful passed through.
Managed code does fix some things, but it's not a cure-all.
Welcome to grammar school.
All possessive pronouns do not use apostrophes.
His
Hers
Yours
Mine
Theirs
Ours
Its
There is no magic to this rule.
Unless the system doesn't boot from CD by default (like all the computers where I work) and you need a BIOS password to change the option (like all the computers where I work) and the case is locked so it isn't easy to reset the bios (like all the computeres where I work).
So, how would you boot from CD now?