boost::signal2 and boost::bind add signals and slots, too, and they seem more intuitive to use than QT's version. They've also been accepted into the language standard in C++11, though I'm still using the boost versions of a lot of the C++11 stuff for compatibility with older compilers. They make a great addition to library code -- I use signals in data factories to signal the availability of new objects. They're also pretty bulletproof in terms of type safety. The compiler will detect that you're trying to attach a incompatible function at compile time and you can adjust the parameters as you need to with bind. Just don't forget to pass the "this" pointer to objects!
No destructors just kills java for me. Yes, I know you have things kind of like destructors that can run at GC time but they're not guaranteed to. That means I have to rely on the programmer to remember to call close before his object goes out of scope, and he's not going to be able to in all cases. That in turn means he's going to be leaking resources. Which seems to be why a lot of the production MQ servers I've seen pretty much HAVE to be rebooted every three days.
Some time ago I was working for a company that was using Jmeter for functional testing. Don't ask me why, but it seemed to be pretty effective for them. At some point they added an SSH sampler into the mix for it. This worked just fine when you were developing the test and running it from the GUI, but when we ran the test from the command line, it would hang when it should have exited. I went digging around in the ssh sampler code and found that he was closing his ssh connection in what passes for a destructor in Java. This was getting called when the GUI exited, but not from the command line. So the ssh connection would remain open and java would sit there not doing anything, so no GC event could ever take place. Essentially a deadlock with exit waiting ssh to close and that waiting on a GC to happen.
I fixed it by moving the ssh close connection to somewhere else, but it was still rather awkward and would prevent the ssh connection from being reused. You'd have to create a brand new one each time you wanted to use one.
Java seems to encourage this sloppy mentality that you don't have to worry about any resources because the language is garbage collected. If you're going to program in it correctly, it requires as much discipline as C++, and at least as much unit testing. I've met very few java programmers who have either.
Yes. Dynamic binding and loading is ugly and clunky.Errors you don't catch at compile time are errors that you have to write tests for. You know who writes tests? No one, that's who! So in practice, errors you don't catch at compile time are errors your users are going to catch. And then you have to debug through an ugly clunky maze of dynamic binding and loading.
But don't get me wrong. I can be... objective... Ok, look. Back in the day we stood at a crossroads. Do we make our changes to C to make it OO fairly lightweight and mostly retain the C syntax, or do we radically change the entire feel of the language. Objective C went for the lightweight approach. Object instances are essentially just pointers to dynamically allocated memory syntactic sugar for pointers to functions around methods. Very C-like idiom and honestly a pretty elegant method of handling things. If you just want C with objective C is worth looking at. It's one step past maintaining some structs with pointers to functions and maintaining OO and inheritance manually, and that's not necessarily a bad thing.
C++ took longer to get where it was going, but it essentially set out for the strictness of ADA in a C like language. It's much more touchy about types and is geared toward catching as much as it can at compile time. Before they got the STL and the C++11 changes rolled in, it was really kind of a pain in the ass to use. It's big and clunky, has a lot of rules to memorize and its error messages are hideous. But in the right hands, with the right libraries, it can be incredibly concise, remarkably fast and a ridiculously powerful tool. In my opinion, one worth learning.
In either case, the first thing you should learn is a unit testing framework for that language. No matter what kind of coding you're doing, there's simply not a good excuse to avoid unit testing any code you're planning to deploy anymore.
And yeah if you go the C++ route, QT is some mighty tasty kool-aid. Sure you have to run their pre-precompiler on your code and will find it much harder if you want to just hook some random non-QT object you have into your system. Sure they demand that their includes be in a specific place in your code. But it's delicious kool-aid! Go ahead, give it a try! I was just playing around the other day with a QT window into which I'd stuffed a QImage that I had loaded up with some pixels from a GDAL raster driver, and it was less than 500 lines of code (Source code's on github if anyone's interested.) Gotta say that was pretty impressive, though still a fairly trivial example.
Is there something hugely profitable that I've missed about running a company into the ground? It seems to be all the rage lately, been seeing it at HP, at IBM, at Sun, couple smaller companies I've worked at in the past. Some jackhole will come in, talk a big game, cut tiny little perks that used to be given to employees to the bone, spend a couple billion dollars on some idiotic shit like another company or a shiny new headquarters that's later discovered to be riddled with asbestos and sitting on top of a colony of leprosy-ridden armadillos and then jettisons with a $50 million golden parachute while the company burns. This has happened far too many times recently to be coincidence!
A good way to tell if your company has been thus afflicted is to look at the quality of the coffee now compared to the quality a couple years ago. At one such company that I worked at a few years ago, I one day remarked to my test minion that the coffee at the company was so good that you hardly even minded the urine. After the VC's took over and replaced it with, I want to say, "Peet's Coffee", the coffee there was so bad that the urine was an improvement!
Yes! We are now calling it a "stream!" The "stream" will have the ability to be more in-your-face! It will be the NUMBER ONE choice for social blaggers within a couple of years! Everyone is going to want Google+'s stream in their face! NUMBER ONE!
The Republican National Convention. Apparently they'd rather not dwell on who owned who, or who had syphilis, or who handed out smallpox blankets or who detonated "devices." They say that those who don't learn from history are doomed to repeat it. What I've learned from history is that given any nifty new toy, we'll use it and use it without regard for the consequences and we'll fuck anyone over for a buck. A brief list of everyone we've fucked over in the past: Everyone. And now we're fucking over future generations who aren't going to have a very nice planet to live on, so a few energy barons can own an even larger percentage of the world than they already do.
"Safe" is a relative term with those things. Underground tests well away from populated areas would at least mitigate the fallout. There are very few places on earth you can explode a nuclear device where it won't affect a civilian population, but we seemed to go out of our way to explode them near populated areas. We'd also invite reporters or the army to witness the explosion from a "safe" distance away -- two or three miles from ground zero for the blast. We shamelessly experimented on our own people and anyone else. You know, shit they'd rather the high schools didn't teach you in AP History.
We didn't stop at 2 nuclear bombs. We exploded them and exploded them like they were goddamn tic-tacs. We didn't even do that safely -- we exploded them near our own civilian populations, telling the people that it was harmless and not to worry about that fallout. Judging from our track record with the things, some politician in Washington had read too many comic books and was hoping that some of the civilians would develop super powers. Instead, they just got lymphoma and birth defects. We made those goddamn things and put them in the hands of the least responsible people on the planet and stopped only after irreparable harm was done to thousands of lives. So yeah, you can draw that analogy if you want to but I don't think it points to as rosy a future as you might think it does.
Funnily enough a lot of the time I'm talking about Ruby on Rails and Ruby's Active Record. They're a very good example of a project that says "Oh look how easy it is to build a web page with our thing!" with a trivial example. Last time I looked at it, I started having to look at implementation-level details of the packages almost immediately. I also remember it being an awful lot of code for what I needed. I really only needed about 10% of the functionality Rails provided, and had no way to scale down to just that.
Funnily enough I went through that phase where liked ruby, but am now back to the point where I'd rather just use perl with "use strict;". If I'm going to do OO development, I'm going to do it in C++ or Java.
Yeah, the quality of the open source programs that I look at is usually far superior than anything I've ever seen inside a corporation. Although... at one company I worked for, I had to audit the source code for the original AT&T C standard library. That was obviously done by people who knew what they were doing. I also recently submitted a pull request to the gnu flex maintainer on github. Flex seems to generate some pretty decent code, but the code it uses to do it is a maze of global variables. I did manage to tweak it to generate a C++ class that works for me without the #include fuckery that flex typically requires, but I don't know if the maintainer is going to actually like that change. Doesn't matter to me, I can just use my version from now on.
I'd be happy to just go into a company and write unit tests for their code, but in most cases that would require dictating huge design changes to a lot of their code. If I take over a code base, I like to start writing unit tests for new development and bug fixes (Write the test prior to fixing the bug.) Last project I worked on was an old C code base with hundreds or possibly thousands of global variables. In some cases there were multiple global variables for the same value, and they got used in different places and often had to be set to different values in order for the code to work correctly. It might not have been too bad to go through and make sure it was just passing everything it used, but it was a lot of code and it kind of all needed to be changed at the same time. Much too much of an effort for the team that was working on it.
Or is just complex and unfamiliar. The problem with these frameworks is they work great when they work, but you only ever see them working because they've been published with the most trivial example. When you actually start trying to do things with them, you have to know implementation-level details of the framework in order to make it work for you. By the time you've invested all that time, you may as well have written something less generic that actually does what you want.
Oh and when I say they work great, I was kind of lying. I have a favorite example. A while back a developer I was working with wrote some Spring/Hibernate code to pull records in from the database and print a billing report. Soon as he handed it off to me, I thought "What happens if I throw 100000 records at this?" Well what happened is that it crashed. So I cut the number in half and it still crashed. Down around 30000 records, it started taking about half an hour and THEN crashing.
Turns out he was using the framework to pull all the records from a couple of different tables and doing the join in Java. The SQL join I wrote to test the code took a couple of minutes to run on a million records and returned the correct output. On a hundred thousand it was neighborhood of 10 seconds.
Now the Spring/Hibernate people will be quick to point out that you can edit some XML file or something and make the framework do a join for you, thus solving that problem. And that is true, if you know a fair bit about the framework. And you'd have to know a fair bit about all the other frameworks they used on that project, too. By the time you got done learning all the frameworks they were using to the level of detail where you could actually be that effective with them, you could have written the application they'd built 10 times over.
Fortunately this story has a happy ending. The team ended up deciding to run the original developer's code against the billing database several times a day so that it would never have so many records to process that it would crash, thus solving the problem once and for all!
I'm curious to see how often they have random people tell them they're their father, or ask them if they can lend a hand. It might not be that many, if they can also crush bone with their bionic hands.
I'd tell her to never apologize for who she is and never let anyone tell her she can't do something because she's a girl.
Also if you have an indoor skydiving facility near you, I'd take her to do that and spring for the video. I'd say 6-10 minutes each. You may as well keep experiencing new stuff up until you die, and it's quite memorable. Hell if I was you I'd go on a tandem skydive too. What have you got to be afraid of at this point? And maybe a hot air balloon ride, too. You'd be surprised how easy it is to find a hot air balloon pilot in a given area, and that's something you can take the entire family to do. Knock out that bucket list and make some memories for everyone!
Slashdot Mirror
boost::signal2 and boost::bind add signals and slots, too, and they seem more intuitive to use than QT's version. They've also been accepted into the language standard in C++11, though I'm still using the boost versions of a lot of the C++11 stuff for compatibility with older compilers. They make a great addition to library code -- I use signals in data factories to signal the availability of new objects. They're also pretty bulletproof in terms of type safety. The compiler will detect that you're trying to attach a incompatible function at compile time and you can adjust the parameters as you need to with bind. Just don't forget to pass the "this" pointer to objects!
Some time ago I was working for a company that was using Jmeter for functional testing. Don't ask me why, but it seemed to be pretty effective for them. At some point they added an SSH sampler into the mix for it. This worked just fine when you were developing the test and running it from the GUI, but when we ran the test from the command line, it would hang when it should have exited. I went digging around in the ssh sampler code and found that he was closing his ssh connection in what passes for a destructor in Java. This was getting called when the GUI exited, but not from the command line. So the ssh connection would remain open and java would sit there not doing anything, so no GC event could ever take place. Essentially a deadlock with exit waiting ssh to close and that waiting on a GC to happen.
I fixed it by moving the ssh close connection to somewhere else, but it was still rather awkward and would prevent the ssh connection from being reused. You'd have to create a brand new one each time you wanted to use one.
Java seems to encourage this sloppy mentality that you don't have to worry about any resources because the language is garbage collected. If you're going to program in it correctly, it requires as much discipline as C++, and at least as much unit testing. I've met very few java programmers who have either.
But don't get me wrong. I can be... objective... Ok, look. Back in the day we stood at a crossroads. Do we make our changes to C to make it OO fairly lightweight and mostly retain the C syntax, or do we radically change the entire feel of the language. Objective C went for the lightweight approach. Object instances are essentially just pointers to dynamically allocated memory syntactic sugar for pointers to functions around methods. Very C-like idiom and honestly a pretty elegant method of handling things. If you just want C with objective C is worth looking at. It's one step past maintaining some structs with pointers to functions and maintaining OO and inheritance manually, and that's not necessarily a bad thing.
C++ took longer to get where it was going, but it essentially set out for the strictness of ADA in a C like language. It's much more touchy about types and is geared toward catching as much as it can at compile time. Before they got the STL and the C++11 changes rolled in, it was really kind of a pain in the ass to use. It's big and clunky, has a lot of rules to memorize and its error messages are hideous. But in the right hands, with the right libraries, it can be incredibly concise, remarkably fast and a ridiculously powerful tool. In my opinion, one worth learning.
In either case, the first thing you should learn is a unit testing framework for that language. No matter what kind of coding you're doing, there's simply not a good excuse to avoid unit testing any code you're planning to deploy anymore.
And yeah if you go the C++ route, QT is some mighty tasty kool-aid. Sure you have to run their pre-precompiler on your code and will find it much harder if you want to just hook some random non-QT object you have into your system. Sure they demand that their includes be in a specific place in your code. But it's delicious kool-aid! Go ahead, give it a try! I was just playing around the other day with a QT window into which I'd stuffed a QImage that I had loaded up with some pixels from a GDAL raster driver, and it was less than 500 lines of code (Source code's on github if anyone's interested.) Gotta say that was pretty impressive, though still a fairly trivial example.
A good way to tell if your company has been thus afflicted is to look at the quality of the coffee now compared to the quality a couple years ago. At one such company that I worked at a few years ago, I one day remarked to my test minion that the coffee at the company was so good that you hardly even minded the urine. After the VC's took over and replaced it with, I want to say, "Peet's Coffee", the coffee there was so bad that the urine was an improvement!
Yes! We are now calling it a "stream!" The "stream" will have the ability to be more in-your-face! It will be the NUMBER ONE choice for social blaggers within a couple of years! Everyone is going to want Google+'s stream in their face! NUMBER ONE!
Huh, did I screw up my link or is New Slashdot just being retarded?
Would they be more or less effective than these? It'd be hard to beat that price point.
Goddamn interns keep inhaling the helium to talk like the Chipmunks.
Feel free to put a feature request in with the NSA to please make their viruses easier to spot in the future.
The Republican National Convention. Apparently they'd rather not dwell on who owned who, or who had syphilis, or who handed out smallpox blankets or who detonated "devices." They say that those who don't learn from history are doomed to repeat it. What I've learned from history is that given any nifty new toy, we'll use it and use it without regard for the consequences and we'll fuck anyone over for a buck. A brief list of everyone we've fucked over in the past: Everyone. And now we're fucking over future generations who aren't going to have a very nice planet to live on, so a few energy barons can own an even larger percentage of the world than they already do.
"Safe" is a relative term with those things. Underground tests well away from populated areas would at least mitigate the fallout. There are very few places on earth you can explode a nuclear device where it won't affect a civilian population, but we seemed to go out of our way to explode them near populated areas. We'd also invite reporters or the army to witness the explosion from a "safe" distance away -- two or three miles from ground zero for the blast. We shamelessly experimented on our own people and anyone else. You know, shit they'd rather the high schools didn't teach you in AP History.
We didn't stop at 2 nuclear bombs. We exploded them and exploded them like they were goddamn tic-tacs. We didn't even do that safely -- we exploded them near our own civilian populations, telling the people that it was harmless and not to worry about that fallout. Judging from our track record with the things, some politician in Washington had read too many comic books and was hoping that some of the civilians would develop super powers. Instead, they just got lymphoma and birth defects. We made those goddamn things and put them in the hands of the least responsible people on the planet and stopped only after irreparable harm was done to thousands of lives. So yeah, you can draw that analogy if you want to but I don't think it points to as rosy a future as you might think it does.
Funnily enough I went through that phase where liked ruby, but am now back to the point where I'd rather just use perl with "use strict;". If I'm going to do OO development, I'm going to do it in C++ or Java.
I set up UUCP to uunet once. Does that count? I think I still have a box of bangs around somewhere, I guess I could do it again.
But with ACTUAL GUITAR! We have the technology! Rocksmith tries to go i in that direction, though I don't know how well it does.
Yeah, the quality of the open source programs that I look at is usually far superior than anything I've ever seen inside a corporation. Although... at one company I worked for, I had to audit the source code for the original AT&T C standard library. That was obviously done by people who knew what they were doing. I also recently submitted a pull request to the gnu flex maintainer on github. Flex seems to generate some pretty decent code, but the code it uses to do it is a maze of global variables. I did manage to tweak it to generate a C++ class that works for me without the #include fuckery that flex typically requires, but I don't know if the maintainer is going to actually like that change. Doesn't matter to me, I can just use my version from now on.
I'd be happy to just go into a company and write unit tests for their code, but in most cases that would require dictating huge design changes to a lot of their code. If I take over a code base, I like to start writing unit tests for new development and bug fixes (Write the test prior to fixing the bug.) Last project I worked on was an old C code base with hundreds or possibly thousands of global variables. In some cases there were multiple global variables for the same value, and they got used in different places and often had to be set to different values in order for the code to work correctly. It might not have been too bad to go through and make sure it was just passing everything it used, but it was a lot of code and it kind of all needed to be changed at the same time. Much too much of an effort for the team that was working on it.
Oh and when I say they work great, I was kind of lying. I have a favorite example. A while back a developer I was working with wrote some Spring/Hibernate code to pull records in from the database and print a billing report. Soon as he handed it off to me, I thought "What happens if I throw 100000 records at this?" Well what happened is that it crashed. So I cut the number in half and it still crashed. Down around 30000 records, it started taking about half an hour and THEN crashing.
Turns out he was using the framework to pull all the records from a couple of different tables and doing the join in Java. The SQL join I wrote to test the code took a couple of minutes to run on a million records and returned the correct output. On a hundred thousand it was neighborhood of 10 seconds.
Now the Spring/Hibernate people will be quick to point out that you can edit some XML file or something and make the framework do a join for you, thus solving that problem. And that is true, if you know a fair bit about the framework. And you'd have to know a fair bit about all the other frameworks they used on that project, too. By the time you got done learning all the frameworks they were using to the level of detail where you could actually be that effective with them, you could have written the application they'd built 10 times over.
Fortunately this story has a happy ending. The team ended up deciding to run the original developer's code against the billing database several times a day so that it would never have so many records to process that it would crash, thus solving the problem once and for all!
Remember: The needs of the many outweigh the needs of the few!
Short sighted leadership making cars no one wanted had nothing to do with it.
Heh heh. Now current workstation has the Monkey Virus!
Oh, I thought someone just took a shit on my Slashdot today. So... It's going to stay that way, huh? Huh...
I'm curious to see how often they have random people tell them they're their father, or ask them if they can lend a hand. It might not be that many, if they can also crush bone with their bionic hands.
Also if you have an indoor skydiving facility near you, I'd take her to do that and spring for the video. I'd say 6-10 minutes each. You may as well keep experiencing new stuff up until you die, and it's quite memorable. Hell if I was you I'd go on a tandem skydive too. What have you got to be afraid of at this point? And maybe a hot air balloon ride, too. You'd be surprised how easy it is to find a hot air balloon pilot in a given area, and that's something you can take the entire family to do. Knock out that bucket list and make some memories for everyone!
Oh, Jesus... Jesus Christ!