The pesky step isn't between building an elegant theoretical model and expressing the code. The pesky step is BEFORE building the elegant theoretical model. When you start somewhere new, it takes you 3-4 months just to start learning your way around the business. Until you really understand how they operate and why they do the things they do, any code you write is likely to be wrong. 6 or 7 months in, you start to learn your way around their code base. It can take a year or more to know your way around their code base well enough to start being really productive when modifying it. At someplace with high turnover, it's entirely possible that there's no one left who actually understands how the business operates.
Compared to the problem of understanding the business, learning a new language well enough to be productive in it is a trivial problem.
Companies and HR departments don't see this, though. They want everyone to be easily-replaceable cogs in their corporate machine. Thinking you can just swap a new programmer for a guy who's been there for 5 years is just as wrong as thinking that the programming language is the biggest problem facing software companies.
Every fad that comes along sells itself with the easy problems, though. Making programming easier for non-programmers has been the holy grail for a good 5 decades. Before that it was probably making computers easier to use for people who don't have soldering irons. "Just use our thing!" they promise, "And you'll just be able to hire chimpanzees to crap out code for you all day long for the cost of a few bananas a day!" Well just because you're using the latest fad doesn't mean you can hire chimpanzees to write your code. Writing code is the easy part. Learning how your business operates and breaking the problems you're trying to solve in software down to sensible logical units, that's the hard part. It's so hard that most businesses have difficulty even expressing everything (or anything) they're trying to accomplish. You need to interrogate them to get any sort of requirements out of them. The programmer has to be the bad cop for this. Their manager is the good cop ("No we don't need any requirements, we'll just start writing code and you can tell us what you want as we go!")
For a lot of the languages you're making your wish for, is the problem the language or its libraries? I've been looking at C++ vs Java since about as long as Java has been around (I remember when Sun introduced Java,) and the nice thing about Java was all the built-in libraries that handled much more stuff than C++ did. I don't recall C++ even having templates the first time I looked at it, much less the STL. And although you could (and still can) revert back to the C standard library in C++, most people don't want to fuck with setting up, say, a socket connection in the C standard library. And although you can easily write a wrapper for them in a few hundred lines of code (Here's my trivial little demo one) I've never actually met another programmer who actually has. You can get a much better one with boost::asio, which is probably what I'd use if I were actually trying to write a high-performance web server or something, but you have to wrap your brain around their programming model. Which I haven't gotten around to doing for boost::asio yet.
I've really only seen people getting serious about writing libraries for C++ in the last decade or so. Boost has come a fantastically long way in that time and adds most of the stuff that the newfangled C++ STL was lacking. In fact, they added a lot of the Boost stuff I've been using to the C++11 spec, pretty much verbatim. I can pretty much change a header include from to the new C standard thing, change the namespace from boost:: to std:: and not change any other code and it'll work. I was actually stunned they kept the thread syntax the way boost did it.
No matter what you're trying to do or the programming paradigm you're trying to do it in, you will never be able to just crap out some code without thinking about its design and what you're trying to accomplish. When people think of the difficulty of programming, that's where the hard part is. Learning a language is easy. Learning to express your instructions to the computer in a way that's maintainable, efficient and reasonably bug-free... that's not so easy. I've seen many companies through the years constrained by the design of their in-house software. Once the business starts changing to meet the demands of its software, you start having problems. "We can't do that because our software won't allow it," is a huge drag on a company. You start losing opportunities not because something is not possible but because something is not possible with the tools you have.
A lot of the programming fads (OO, Functional, Ruby) imply that you can just start crapping out code without thinking much on what you're trying to accomplish. Buying in to that hype is foolish, and potentially damaging to your business. Some of the fads actually do make it easier to write reusable and maintainable code (OO and test-first come to mind, though I haven't drunk enough of the test-first kool-aid to actually write the unit test first. I usually don't wait much longer than the object I'm testing being "mostly done" to write a test for it, though.
If you can cram enough people in, think of all the money you could save in seating! And they'll be so jammed together that even if the plane is bouncing like a basketball, no one would be going anywhere! You wouldn't even need seatbelts! Genius! The airlines could use some sort of people-horn device. Like a shoehorn, but for people!
I haven't flown on a commercial airline in about a decade, but last time I did the International flights used to be a lot more comfortable than domestic ones. I was born in the 70s and flying back then seemed like more of a upscale and trendy thing to do. Since then it's gone to being more like being an an airborne Greyhound bus. If I have the time, I'd much rather drive or take a train. Trains are underrated -- sure they take a couple of days but they're a lot more comfortable than flying, you get to see the country from a much different angle and you meet all manner of interesting people.
I do love to fly though, and have been averaging about one flight ever 2.6 days, skydiving down at the local municipal airport. A one-way ticket to 12000 feet is $28 there. Once you start hanging out at a municipal airport, general aviation starts looking a lot more feasible. There are several guys who fly biplanes there I wouldn't mind hitching a ride with, and several hot air balloon pilots around. Next year in June I'm going to start approaching pilots to see if I can find one who'd be willing to fly around for an hour or two at night on the 4th of July, so I and a few friends can watch the fireworks from the air. If the dropzone were willing to fly their big purple otter that night, we could easily get 6-8 people around the open door, one in the co-pilot's seat and maybe one more standing between the pilot and co-pilot. That'd be enough that the cost of running the thing would be reasonable. So yeah, fuck the airlines, but if you enjoy flying general aviation is still pretty fun.
Ah ctags and cscope are underrated. I used them a lot on a job where I had to read the C standard library and write tests for it. There's so much UNIX crap out there no one knows about. The only other place I've ever seen Lex and Yacc used were by the guy who wrote Awk for that UNIX system. I wrote a trivial Adobe PPD parser with them once, because why not? It didn't implement the full spec, just the bits of it I needed, and it'd pull the data out and build XML tables with it. Oh yeah and some jackhole asked me to write a C comment counter as I had time over the course of a couple of days as part of an interview one time. I busted it out for that. He told me that of all the candidates, mine was the only one that passed all his test cases for it, but he thought I was overqualified for the job. Yuh huh. I guess that goes under the category of "never ask a question you don't want to know the answer to."
I don't think I've ever seen a setjmp/longjmp in any C code I've ever maintained. I'm not sure a lot of C programmers even know it exists. Or setting signal handlers. I've written the only signal handlers I've ever seen in production C code. I had an AIX segv handler that tried to recover enough to print a stack dump before dying. It even worked a few times. You can pretty much bet if it forks, no one else will be able to follow any explanation you can give about how it works. Same thing goes for clone. Most people seem to have trouble with "These two things happen at the same time." Say something like "This spawns a socket server on a thread in the background to provide a command console UI" and their faces just go blank.
I reduced our weekend calls on my last big C project to almost nothing by replacing all the strcpys with bounded strncpys and and cleaning up how the guy set up his strings. Mostly by #defining constants so you could declare a temp buffer of INVENTORY_ID_LEN and be pretty sure a change to its size in the future wouldn't result in you blowing out your stack. Oh yeah, and I'm a bit OCD about memsetting all character arrays to all NULLs before using them. Oh hey, look, our application doesn't segfault twelve times a week anymore. A bit more work with libefence and the only call we got for the next year was apparently an indexing fault in the database we were using. Fixed several double frees, added null checks before strncmps EVERYWHERE and got the thing running like clockwork. Last I heard they'd outsourced the gig to Brazil and were trying to port it all to Java. Wonder how that's going for them...
I'm guessing everyone working at the NSA has an enormous penis. Even the women. And they're probably erect ALL THE TIME. They probably fund their entire operation with the resource given to them by those guys trying to get all their shit out of Nigeria. No doubt none of their credit cards are blocked at Bank of Aemerica, and they probably supplement their income with lottery winnings from the UK (Nigel seems like such a nice young lad) and working from home for a thousand dollars a day.
Really? Try pointing out that document revision control is mandatory under the ISO 9000 process. That should get the ball rolling pretty quickly. Or A ball, anyway.
Yeah... that's not what's going to happen. There are a number of things that could happen, but that's not one of them. If I were guessing, I'd guess a large briefcase of money will quietly change hands and this effort will die a quiet death. If it doesn't, Apple probably already has some other country lined up that would be happy to fill that gap. The least probable thing I can possibly imagine is that thing you just said.
I was contracting at Sun a while back and heard some engineers talking some shit about the Linux kernel on the way to lunch one day. Meanwhile some Sun guy on the project I was on had just coded the entire authentication system using static java methods. Worked great, as long as only one person logged on. They didn't notice this until it was time to take the project live. I've seen plenty of commercially deployed code, buddy, and the one thing you can say about it is it's uniformly shit. I've held positions where I've had to look at chunks of old commercial UNIX source and seen published example drivers for OS/2 and Windows. I wasn't impressed. I wasn't impressed at all.
What I've found over the years is, just because you get paid to develop code for someone doesn't mean you crap unicorns and daisies. I've also found that all of the installations I've run across that were running Oracle (or DB2) really didn't need to be running Oracle or DB2. It's been overkill for every position I've worked at. Of course, they end up needing it anyway because of their crappy table design and because they're afraid to ever throw anything away when they're done with it. But if they'd been paying attention to their business process and designing their tables correctly, they could have saved themselves a LOT of money with a copy of postgres running on some Linux box somewhere!
How about "Set up a global int l and set it to 0, and a global int O and set it to 1. Or sometimes l, depending on what file you're in." This works better or worse, depending on your font. Or in C++, have every class inherit from every other class. I've seen this done.
A couple times I've run across some jackhole who is in love with dynamic shit and who wants to check java object code into an SQL database and dynamically load it into a program. Nothing quite spells fun like wondering where the hell the code is branching to, and spending two days figuring out it's to an object in a database the code to which has been lost 4 years earlier.
For a long time there in the '90's and a bit later, version control wasn't a normal thing. If you had to get management approval to set one up, that usually would start up the sinking feeling about that job sooner rather than later. Nothing quite like having to justify the addition of something they should have never written a line of code without in the first place. Nevermind trying to get overhead for writing unit tests. Assuming unit tests are even possible. For most of the projects I've run across, the coupling is so tight there's no way to get in and test discrete functionality of anything.
For the guys not using version control, "Lose the source code" is a good one. You don't even have to be malicious about it (Though malice helps.) Just build the thing on your personal dev box, deploy the executables to production and never mention it when you leave. Bonus points if they walk you out during a layoff.
"Don't set up a build system" is another good one. Gotta love those projects where you have to run a top-level build three times before it produces an executable!
Oh... I think I saw one of those at the antique store the other day. I was going to grab it until he told me the jack in it wasn't for ethernet. Apparently you had to plug it into a... I believe he called it a "land... line..."
I keep mine in a pocket in my vest with nothing else, or in a pocket in my jumpsuit just above my knee in case I land out or want to take a picture while in the plane. Last time I was doing that one of my jump buddies told me he could just imagine me dropping it out the door and then diving out after it. I suppose that'd be an interesting claim to fill at the cellular store when asking for a replacement...
I'm looking forward to having to support crappily-engineered code in some other language! I'm going to slap the first in-house engineer who suggests we jump on the NetRexx bandwagon.
Gunpoint kind of does that. They give you an achievement, but not for that, because no one is going to give you an achievement for punching a guy *THAT* many times!
Oh, yeah, and you get a level rating of "psychopath"! So... there!
Or at least the drop of a smartphone. Which is odd because pretty much everyone I know but me has cracks in their smartphone screens. I drop mine a couple times a week AND take it skydiving and it remains unbroken. So how the hell are people managing to break their smartphone screens so often?
That's "FUCKING Lotus Notes" to you. And anyone else who's ever used Lotus Notes. Unless you use Notes to justify your six-digit developer salary you probably hate fucking Lotus Notes. I'm honestly surprised any company outside IBM was still using it. Last one I'd heard about was Generous Electric and I think they switched to Exchange over a decade ago.
After IBM tried to replace RETAIN (A data retrieval system written in mainframe assembler) with Notes several times, and failed each time, they decided to just use it as their internal mail system to try to recoup their $6 billion. They're probably $8 billion in the hole now due to lost productivity. Lotus Notes did replace their old mainframe mail system, Profs, but Profs was better. Much better. Stabbing yourself in the eye with a spork would be better than having to use Lotus Notes for any length of time.
Really it's a surprising move on IBM's part, sticking to that stinking pile of shit. For a company with over a century of business experience and an otherwise sane-ish track record, it's a strange thing for them to get stuck on. Continuing on with an extremely bad two-decade business decision really isn't like them at all. They'd be better off if they pulled Profs back off the ol' A-Disk and started using that again.
Slashdot Mirror
Compared to the problem of understanding the business, learning a new language well enough to be productive in it is a trivial problem.
Companies and HR departments don't see this, though. They want everyone to be easily-replaceable cogs in their corporate machine. Thinking you can just swap a new programmer for a guy who's been there for 5 years is just as wrong as thinking that the programming language is the biggest problem facing software companies.
Every fad that comes along sells itself with the easy problems, though. Making programming easier for non-programmers has been the holy grail for a good 5 decades. Before that it was probably making computers easier to use for people who don't have soldering irons. "Just use our thing!" they promise, "And you'll just be able to hire chimpanzees to crap out code for you all day long for the cost of a few bananas a day!" Well just because you're using the latest fad doesn't mean you can hire chimpanzees to write your code. Writing code is the easy part. Learning how your business operates and breaking the problems you're trying to solve in software down to sensible logical units, that's the hard part. It's so hard that most businesses have difficulty even expressing everything (or anything) they're trying to accomplish. You need to interrogate them to get any sort of requirements out of them. The programmer has to be the bad cop for this. Their manager is the good cop ("No we don't need any requirements, we'll just start writing code and you can tell us what you want as we go!")
I've really only seen people getting serious about writing libraries for C++ in the last decade or so. Boost has come a fantastically long way in that time and adds most of the stuff that the newfangled C++ STL was lacking. In fact, they added a lot of the Boost stuff I've been using to the C++11 spec, pretty much verbatim. I can pretty much change a header include from to the new C standard thing, change the namespace from boost:: to std:: and not change any other code and it'll work. I was actually stunned they kept the thread syntax the way boost did it.
No matter what you're trying to do or the programming paradigm you're trying to do it in, you will never be able to just crap out some code without thinking about its design and what you're trying to accomplish. When people think of the difficulty of programming, that's where the hard part is. Learning a language is easy. Learning to express your instructions to the computer in a way that's maintainable, efficient and reasonably bug-free... that's not so easy. I've seen many companies through the years constrained by the design of their in-house software. Once the business starts changing to meet the demands of its software, you start having problems. "We can't do that because our software won't allow it," is a huge drag on a company. You start losing opportunities not because something is not possible but because something is not possible with the tools you have.
A lot of the programming fads (OO, Functional, Ruby) imply that you can just start crapping out code without thinking much on what you're trying to accomplish. Buying in to that hype is foolish, and potentially damaging to your business. Some of the fads actually do make it easier to write reusable and maintainable code (OO and test-first come to mind, though I haven't drunk enough of the test-first kool-aid to actually write the unit test first. I usually don't wait much longer than the object I'm testing being "mostly done" to write a test for it, though.
If you can cram enough people in, think of all the money you could save in seating! And they'll be so jammed together that even if the plane is bouncing like a basketball, no one would be going anywhere! You wouldn't even need seatbelts! Genius! The airlines could use some sort of people-horn device. Like a shoehorn, but for people!
I do love to fly though, and have been averaging about one flight ever 2.6 days, skydiving down at the local municipal airport. A one-way ticket to 12000 feet is $28 there. Once you start hanging out at a municipal airport, general aviation starts looking a lot more feasible. There are several guys who fly biplanes there I wouldn't mind hitching a ride with, and several hot air balloon pilots around. Next year in June I'm going to start approaching pilots to see if I can find one who'd be willing to fly around for an hour or two at night on the 4th of July, so I and a few friends can watch the fireworks from the air. If the dropzone were willing to fly their big purple otter that night, we could easily get 6-8 people around the open door, one in the co-pilot's seat and maybe one more standing between the pilot and co-pilot. That'd be enough that the cost of running the thing would be reasonable. So yeah, fuck the airlines, but if you enjoy flying general aviation is still pretty fun.
Ah ctags and cscope are underrated. I used them a lot on a job where I had to read the C standard library and write tests for it. There's so much UNIX crap out there no one knows about. The only other place I've ever seen Lex and Yacc used were by the guy who wrote Awk for that UNIX system. I wrote a trivial Adobe PPD parser with them once, because why not? It didn't implement the full spec, just the bits of it I needed, and it'd pull the data out and build XML tables with it. Oh yeah and some jackhole asked me to write a C comment counter as I had time over the course of a couple of days as part of an interview one time. I busted it out for that. He told me that of all the candidates, mine was the only one that passed all his test cases for it, but he thought I was overqualified for the job. Yuh huh. I guess that goes under the category of "never ask a question you don't want to know the answer to."
I reduced our weekend calls on my last big C project to almost nothing by replacing all the strcpys with bounded strncpys and and cleaning up how the guy set up his strings. Mostly by #defining constants so you could declare a temp buffer of INVENTORY_ID_LEN and be pretty sure a change to its size in the future wouldn't result in you blowing out your stack. Oh yeah, and I'm a bit OCD about memsetting all character arrays to all NULLs before using them. Oh hey, look, our application doesn't segfault twelve times a week anymore. A bit more work with libefence and the only call we got for the next year was apparently an indexing fault in the database we were using. Fixed several double frees, added null checks before strncmps EVERYWHERE and got the thing running like clockwork. Last I heard they'd outsourced the gig to Brazil and were trying to port it all to Java. Wonder how that's going for them...
I'm guessing everyone working at the NSA has an enormous penis. Even the women. And they're probably erect ALL THE TIME. They probably fund their entire operation with the resource given to them by those guys trying to get all their shit out of Nigeria. No doubt none of their credit cards are blocked at Bank of Aemerica, and they probably supplement their income with lottery winnings from the UK (Nigel seems like such a nice young lad) and working from home for a thousand dollars a day.
Really? Try pointing out that document revision control is mandatory under the ISO 9000 process. That should get the ball rolling pretty quickly. Or A ball, anyway.
Yeah... that's not what's going to happen. There are a number of things that could happen, but that's not one of them. If I were guessing, I'd guess a large briefcase of money will quietly change hands and this effort will die a quiet death. If it doesn't, Apple probably already has some other country lined up that would be happy to fill that gap. The least probable thing I can possibly imagine is that thing you just said.
What I've found over the years is, just because you get paid to develop code for someone doesn't mean you crap unicorns and daisies. I've also found that all of the installations I've run across that were running Oracle (or DB2) really didn't need to be running Oracle or DB2. It's been overkill for every position I've worked at. Of course, they end up needing it anyway because of their crappy table design and because they're afraid to ever throw anything away when they're done with it. But if they'd been paying attention to their business process and designing their tables correctly, they could have saved themselves a LOT of money with a copy of postgres running on some Linux box somewhere!
A couple times I've run across some jackhole who is in love with dynamic shit and who wants to check java object code into an SQL database and dynamically load it into a program. Nothing quite spells fun like wondering where the hell the code is branching to, and spending two days figuring out it's to an object in a database the code to which has been lost 4 years earlier.
For a long time there in the '90's and a bit later, version control wasn't a normal thing. If you had to get management approval to set one up, that usually would start up the sinking feeling about that job sooner rather than later. Nothing quite like having to justify the addition of something they should have never written a line of code without in the first place. Nevermind trying to get overhead for writing unit tests. Assuming unit tests are even possible. For most of the projects I've run across, the coupling is so tight there's no way to get in and test discrete functionality of anything.
For the guys not using version control, "Lose the source code" is a good one. You don't even have to be malicious about it (Though malice helps.) Just build the thing on your personal dev box, deploy the executables to production and never mention it when you leave. Bonus points if they walk you out during a layoff.
"Don't set up a build system" is another good one. Gotta love those projects where you have to run a top-level build three times before it produces an executable!
Kinda like what we did with Russia? If our schools were better we might learn from history. Heh heh heh
It's not a real diamond unless you can taste the tears on it.
Oh... I think I saw one of those at the antique store the other day. I was going to grab it until he told me the jack in it wasn't for ethernet. Apparently you had to plug it into a... I believe he called it a "land... line..."
I keep mine in a pocket in my vest with nothing else, or in a pocket in my jumpsuit just above my knee in case I land out or want to take a picture while in the plane. Last time I was doing that one of my jump buddies told me he could just imagine me dropping it out the door and then diving out after it. I suppose that'd be an interesting claim to fill at the cellular store when asking for a replacement...
I'm looking forward to having to support crappily-engineered code in some other language! I'm going to slap the first in-house engineer who suggests we jump on the NetRexx bandwagon.
You probably could have given a fourteen-year-old a laptop and a copy of ruby on rails and gotten better results.
That's why targeted advertising is bad mmkay?
Ah there we go! Ok! Well I guess I'll worry if a tidal wave hits a nuclear reactor before the Government gets rolling again!
Oh, yeah, and you get a level rating of "psychopath"! So... there!
Yeah but if your dwarves are injured they have to drink water or they'll die of thirst!
Or at least the drop of a smartphone. Which is odd because pretty much everyone I know but me has cracks in their smartphone screens. I drop mine a couple times a week AND take it skydiving and it remains unbroken. So how the hell are people managing to break their smartphone screens so often?
I see the marketroid who typed up the press release accidentally put a 'f' in there.
After IBM tried to replace RETAIN (A data retrieval system written in mainframe assembler) with Notes several times, and failed each time, they decided to just use it as their internal mail system to try to recoup their $6 billion. They're probably $8 billion in the hole now due to lost productivity. Lotus Notes did replace their old mainframe mail system, Profs, but Profs was better. Much better. Stabbing yourself in the eye with a spork would be better than having to use Lotus Notes for any length of time.
Really it's a surprising move on IBM's part, sticking to that stinking pile of shit. For a company with over a century of business experience and an otherwise sane-ish track record, it's a strange thing for them to get stuck on. Continuing on with an extremely bad two-decade business decision really isn't like them at all. They'd be better off if they pulled Profs back off the ol' A-Disk and started using that again.