Also, while I enjoy the comic, Paul Taylor is either mostly woman or whipped beyond belief.
I disagree. One of the reasons I like Wapsi Square is that the characters are complex. The have strong, self-confident moments, and some obvious self-doubts. We get to see both sides. That easily resonates with every person like me who is extroverted but still feels shy and self-conscious.
I read a number of comics regularly. Very few of them have characters that make me laugh without wanting to laugh at them.
if you moved it from a big class to a little class you may have reduced the size of the stack that's allocated before calling the function.
Without seeing, and profiling, the code in question we probably won't ever know. The first possibility that occurred to me was that it reduced page faults by putting the function close to whatever was calling it. Either of us could be right. This is just another illustration of why programmer instincts are not a reliable guide to what needs optimizing. We're better at doing the optimizations rather than finding opportunities for them.
Embedded, multithreaded and real time code
on
A Review of GCC 4.0
·
· Score: 1
Yup. Embedded stuff has to live by some different performance rules. Sometimes optimizing code that is only using 2% of your CPU cycles is exactly the right thing to do. Two words spring to mind immediately: interrupt handler.
Multithreaded code runs into the same issues for the same reason. When you are holding a lock, work fast. This generally has little to do with whether your CPU is fast enough for the overall throughput. It has to do with handling critical sections of code within particular timing windows so that you can get back to listening for the next input.
The total amount of data transmitted during this challenge -- 500 terabytes -- would take about 250 years to download using a typical 512 kilobit per second household broadband connection."
Correct me if I'm wrong here, but most Linux distributions are still i386 right? It's only the people who use Gentoo who actually compile everything with i686 options right?
One of the original differences between Mandrake and Redhat was that Mandrake compiled everything for Pentium while Redhat was still compiling for 386 or 486.
By "interfaces" I didn't specifically mean the GUI. I don't tend to think in those terms myself. I tend to work on odd networking and embedded stuff. You don't want your interfaces to other components to have unexpected behaviors on stuff that has to run 24x7 without a user anywhere in sight to reset it when it goes wrong.
There are lots of things that can, and arguably should, be documented in a design document. One category that should never be omitted is the interfaces. Whenever a system or subsystem interacts with something else, you need to know how. This includes:
Database schemas. Unless your DB is so well hidden that no one will ever find it, someone will want to read it some day.
APIs you support or use. If there's a standard or a 3rd party product, just list it and the version.
Command line parameters for those little maintenance tools you don't tell the users about. This is a design doc, not a users' guide.
You were at your buddy's place to watch the Super Bowl. The chips ran out in the second quarter. Since you knew there was no way the half time show was going to be as interesting this year, you volunteered to go get more.
On your way out you made a mental note to come back to your buddy's place, rather than your own. This is the return address. You also made a mental note that you needed potato chips and another case of beer. That list is in your buffer.
Your other "friend", a known sponge who still owes several people for beer at various events dating back 3 years now, comes along. While you are at the store, he throws an extra case into the cart. He'll pay you back later.
That annoyed you enough that you forgot whose house you were going back to. You ended up at your place before you realized it. As a result, you missed the first few minutes of the third quarter.
This is interesting on so many levels. First of all, non-French-speaking people are as unlikely to read any French books online as non-English-speakers are to read English books. Secondly, I can't believe that English and French literature come from entirely disparate worldviews that always disagree. Third, I strongly suspect that some of the books Google will be putting online will be translations of French literature. Presumably, many of those are as faithful as possible to the original.
I like your version better than my original, but not for the reason you cited. Yours places the emphasis where it belongs. The reasons are something that only a writer or hard-core (human) language geek would appreciate.
Management does not necessarily mean giving up anything technical. Team leaders who have good technical skills and can handle project management are incredibly valuable.
He was also critical of "orphanware". While there are reasons to be critical of orphanware announced as if it is a live project, it has some benefits. It is certainly possible for a product to reach a point in its lifecycle at which its residual value to its owner is small, or even negative if support is continued. However, at the same time, it may still be valuable to a small group of customers. Releasing it as open source at that point permits customers to make other arrangements for bug fixes and even new features.
Let's not pretend that orphanware is something that it's not. Nonetheless, there are still reasons to be pleased to see it.
My wishlist is short and pretty obvious. I would like to have a supported method of syncing my Palm to my Linux desktop. Yes, I know about KPilot and JPilot. I want a Palm desktop running under Linux that I can sync with that is officially supported.
The second item is a supported development environment under Linux. I'd love to develop PalmOS apps from my Linux desktop. At a minimum, I need a tool chain to compile them. Yeah, I know it exists. It isn't the easiest thing in the world to set up. Ideally, I want an emulator to test them with. With that, there are some Palm apps that I might run on my Linux desktop anyway.
Capitalism is about people trading with each other for what they want. Changes in life expectancy are going to change the value of various things to people. I think we'll find that lots of things become less desired. Some will become more sought after. The system of trading amongst ourselves doesn't have to be scrapped.
Heh, I always get distracted coding helper methods. By the time I'm done, I've rewritten the API three times and only half-implemented each rewrite.
That's one of the best reasons in the world for always keeping your code in a compilable state. When you discover that you need to change something in your interface, your compiler is one of the most valuable tools available. If you missed a caller that should have been changed, it can often tell you. (Yes, I know plenty of languages where that is far from true.)
You have some good points. As Prof. Tolkien once said, "The tail grew in the telling." Keep track of those ideas and keep expanding on them.
DO NOT comment every line. Seriously. Comments are a good thing, but when you comment every single cin and cout, every single bracee and function call, then it can make it a lot harder to find what you are looking for. A good rule of thumb I tell people is to comment every line you have to think about for more than 30 seconds, comment every function and class, and comment every block of code that you have to spend more than 2 minutes pondering over.
Writing good comments is a skill or possibly a set of related skills. One of the things that good comments can do for you is help you find things. They should work with your tools. Putting the right words into your comments so that you can find them when you tell your editor to search for them is invaluable. That's why I correct misspellings in comments. I'm going to search for some of those words some day, and I intend to spell them correctly.
If you've ever worked with code that has gone through several revisions, you know that what things are called in the docs and the GUI is not always what they were originally called when the code was first written. Either change the names in the code, or at least put in a comment that explains the mapping. It will help to preserve your sanity.
If you miracously fix something, understand why. Students seem like they can not resist randomly moving code around, and sometimes this does fix things. If this happens, take some time to understand what you moved and why it might have fixed the problem
Use some kind of version control. If you have nothing else, store old versions somewhere. Better still, install CVS. Figuring out what you changed and why it worked is going to be at least partly a guess if you don't.
One of the best projects I had as a student was one where the professor required us to subject a prototype after a week. He responded to the prototypes with a few small changes to the requirements. He had warned us that that was the intent of the exercise and that we should make the code maintainable.
if (really_awful_error_flag != 0 )
LOG_ERROR("The foobar subsystem is b0rked again!");
Okay, I will grant you that there are more elegant ways of accomplishing the same thing. I tried to distill it down to a small example. I've seen lots of this sort of thing on big systems with homegrown system-wide error logging facilities. When you are unit testing them, sometimes you want to turn that off because you don't have a logging daemon on your workstation. At the same time, you want to turn on your own debugging aids, which are often crude, but effective.
I remember several years ago being involved in a trial work-at-home program. I wasn't the one working from home, but I was on a team with someone who was. Our team communication got better because we started covering every important point in e-mail to be sure that everyone was included.
When I want to be sure there is a record of something I've said to my boss, I send him e-mail. Frequently, it is there for his benefit as much as mine. If I've given him a detailed rundown of the risks of something by e-mail, then he has something to take to his boss if he needs it. If I send him a note about when I'll be on vacation, then he doesn't have to find me to ask me which day if he forgets. E-mail is a very effective way to get information from one person to another in a form where it is harder to forget or lose.
I thought about coming up with a syllabus for myself of C, Haskell, LISP and Perl (which just evades me....)
I'd like to strongly recommend some books. The first is Modern C++ Design by Andrei Alexandrescu. The second is On Lisp by Paul Graham. In conjunction with that, you will need an introductory text on Lisp if you don't already know it and a good book on C++ templates. While I don't know what the best Lisp text currently in print is, I'd be willing to give Graham's ANSI Common Lisp a try on the strength of his other book. And C++ Templates: A Complete Guide by Vandevoorde and Josuttis illuminates a lot of dark corners in templates and explains some new features.
In the end, the goal is to understand how many times Graham and Alexandrescu are talking about the same things using very different languages. C++ templates are in many important ways a compile-time, functional macro language on top of C++ that implement many of the features of Lisp macros. For what it's worth, Bruce Eckel has mentioned this generic programming link in the context of discussing Java generics.
emailing answering machine recordings.. I don't think so. Emailing the entire answering machine recording could backfire. That could easily be used as a DoS against someone's email box ("Let's all leave a message for that ass Professor Doofus tonight!")
You have a good point. I'd use Caller ID and send myself e-mail telling me when the message was received and who it was from.
Are there any other big players or is it all niche stuff after them? Any time I see an other category this large, I have to wonder why. It says to me that there is still a good sized portion of the market in play.
Slashdot Mirror
Also, while I enjoy the comic, Paul Taylor is either mostly woman or whipped beyond belief.
I disagree. One of the reasons I like Wapsi Square is that the characters are complex. The have strong, self-confident moments, and some obvious self-doubts. We get to see both sides. That easily resonates with every person like me who is extroverted but still feels shy and self-conscious.
I read a number of comics regularly. Very few of them have characters that make me laugh without wanting to laugh at them.
if you moved it from a big class to a little class you may have reduced the size of the stack that's allocated before calling the function.
Without seeing, and profiling, the code in question we probably won't ever know. The first possibility that occurred to me was that it reduced page faults by putting the function close to whatever was calling it. Either of us could be right. This is just another illustration of why programmer instincts are not a reliable guide to what needs optimizing. We're better at doing the optimizations rather than finding opportunities for them.
Yup. Embedded stuff has to live by some different performance rules. Sometimes optimizing code that is only using 2% of your CPU cycles is exactly the right thing to do. Two words spring to mind immediately: interrupt handler.
Multithreaded code runs into the same issues for the same reason. When you are holding a lock, work fast. This generally has little to do with whether your CPU is fast enough for the overall throughput. It has to do with handling critical sections of code within particular timing windows so that you can get back to listening for the next input.
The total amount of data transmitted during this challenge -- 500 terabytes -- would take about 250 years to download using a typical 512 kilobit per second household broadband connection."
I guess it's time to upgrade my connection again.
One of the original differences between Mandrake and Redhat was that Mandrake compiled everything for Pentium while Redhat was still compiling for 386 or 486.
By "interfaces" I didn't specifically mean the GUI. I don't tend to think in those terms myself. I tend to work on odd networking and embedded stuff. You don't want your interfaces to other components to have unexpected behaviors on stuff that has to run 24x7 without a user anywhere in sight to reset it when it goes wrong.
Spoken like an experienced Extreme Programmer.
You were at your buddy's place to watch the Super Bowl. The chips ran out in the second quarter. Since you knew there was no way the half time show was going to be as interesting this year, you volunteered to go get more.
On your way out you made a mental note to come back to your buddy's place, rather than your own. This is the return address. You also made a mental note that you needed potato chips and another case of beer. That list is in your buffer.
Your other "friend", a known sponge who still owes several people for beer at various events dating back 3 years now, comes along. While you are at the store, he throws an extra case into the cart. He'll pay you back later.
That annoyed you enough that you forgot whose house you were going back to. You ended up at your place before you realized it. As a result, you missed the first few minutes of the third quarter.
This is interesting on so many levels. First of all, non-French-speaking people are as unlikely to read any French books online as non-English-speakers are to read English books. Secondly, I can't believe that English and French literature come from entirely disparate worldviews that always disagree. Third, I strongly suspect that some of the books Google will be putting online will be translations of French literature. Presumably, many of those are as faithful as possible to the original.
I like your version better than my original, but not for the reason you cited. Yours places the emphasis where it belongs. The reasons are something that only a writer or hard-core (human) language geek would appreciate.
;-)
As for splitting infinitives, the Chicago Manual of Style no longer considers that to be universally wrong. Their advice implies that one should not adopt it as a new idiom, but it is to no longer be feared.
Management does not necessarily mean giving up anything technical. Team leaders who have good technical skills and can handle project management are incredibly valuable.
He was also critical of "orphanware". While there are reasons to be critical of orphanware announced as if it is a live project, it has some benefits. It is certainly possible for a product to reach a point in its lifecycle at which its residual value to its owner is small, or even negative if support is continued. However, at the same time, it may still be valuable to a small group of customers. Releasing it as open source at that point permits customers to make other arrangements for bug fixes and even new features.
Let's not pretend that orphanware is something that it's not. Nonetheless, there are still reasons to be pleased to see it.
My wishlist is short and pretty obvious. I would like to have a supported method of syncing my Palm to my Linux desktop. Yes, I know about KPilot and JPilot. I want a Palm desktop running under Linux that I can sync with that is officially supported.
The second item is a supported development environment under Linux. I'd love to develop PalmOS apps from my Linux desktop. At a minimum, I need a tool chain to compile them. Yeah, I know it exists. It isn't the easiest thing in the world to set up. Ideally, I want an emulator to test them with. With that, there are some Palm apps that I might run on my Linux desktop anyway.
Capitalism is about people trading with each other for what they want. Changes in life expectancy are going to change the value of various things to people. I think we'll find that lots of things become less desired. Some will become more sought after. The system of trading amongst ourselves doesn't have to be scrapped.
Prof. David Friedman is working on a new book, Future Imperfect. He devotes a chapter to some of the possible consequences of practical immortality. It's Chapter XVI: The Last Lethal Disease.
Pop quiz time kids. Anyone who can tell us what TSR stood for without looking it up has been gaming far too long.
Heh, I always get distracted coding helper methods. By the time I'm done, I've rewritten the API three times and only half-implemented each rewrite.
That's one of the best reasons in the world for always keeping your code in a compilable state. When you discover that you need to change something in your interface, your compiler is one of the most valuable tools available. If you missed a caller that should have been changed, it can often tell you. (Yes, I know plenty of languages where that is far from true.)
Writing good comments is a skill or possibly a set of related skills. One of the things that good comments can do for you is help you find things. They should work with your tools. Putting the right words into your comments so that you can find them when you tell your editor to search for them is invaluable. That's why I correct misspellings in comments. I'm going to search for some of those words some day, and I intend to spell them correctly.
If you've ever worked with code that has gone through several revisions, you know that what things are called in the docs and the GUI is not always what they were originally called when the code was first written. Either change the names in the code, or at least put in a comment that explains the mapping. It will help to preserve your sanity.
Use some kind of version control. If you have nothing else, store old versions somewhere. Better still, install CVS. Figuring out what you changed and why it worked is going to be at least partly a guess if you don't.
One of the best projects I had as a student was one where the professor required us to subject a prototype after a week. He responded to the prototypes with a few small changes to the requirements. He had warned us that that was the intent of the exercise and that we should make the code maintainable.
- Fix the first one and the first one only .
Actually, I fix the first one and any similar errors that I know I committed elsewhere.
A corollary to this is:
"When your code compiles cleanly, it is ready for testing and debugging."
I remember several years ago being involved in a trial work-at-home program. I wasn't the one working from home, but I was on a team with someone who was. Our team communication got better because we started covering every important point in e-mail to be sure that everyone was included.
When I want to be sure there is a record of something I've said to my boss, I send him e-mail. Frequently, it is there for his benefit as much as mine. If I've given him a detailed rundown of the risks of something by e-mail, then he has something to take to his boss if he needs it. If I send him a note about when I'll be on vacation, then he doesn't have to find me to ask me which day if he forgets. E-mail is a very effective way to get information from one person to another in a form where it is harder to forget or lose.
I thought about coming up with a syllabus for myself of C, Haskell, LISP and Perl (which just evades me....)
I'd like to strongly recommend some books. The first is Modern C++ Design by Andrei Alexandrescu. The second is On Lisp by Paul Graham. In conjunction with that, you will need an introductory text on Lisp if you don't already know it and a good book on C++ templates. While I don't know what the best Lisp text currently in print is, I'd be willing to give Graham's ANSI Common Lisp a try on the strength of his other book. And C++ Templates: A Complete Guide by Vandevoorde and Josuttis illuminates a lot of dark corners in templates and explains some new features.
In the end, the goal is to understand how many times Graham and Alexandrescu are talking about the same things using very different languages. C++ templates are in many important ways a compile-time, functional macro language on top of C++ that implement many of the features of Lisp macros. For what it's worth, Bruce Eckel has mentioned this generic programming link in the context of discussing Java generics.
emailing answering machine recordings.. I don't think so. Emailing the entire answering machine recording could backfire. That could easily be used as a DoS against someone's email box ("Let's all leave a message for that ass Professor Doofus tonight!")
You have a good point. I'd use Caller ID and send myself e-mail telling me when the message was received and who it was from.
Are there any other big players or is it all niche stuff after them? Any time I see an other category this large, I have to wonder why. It says to me that there is still a good sized portion of the market in play.