At the risk of getting downmodded for a me-too post, I'll back up olesk's statement by saying that I, too, work for a large Swiss bank (in the IT department) and I can tell you that we have several pretty large IT systems specifically devoted to checking out customers. Obviously, I can't go into details but I can say they were expensive to build and they cost the bank money to keep running. Big banks are by nature hyper-conservative and rarely spend money unless it will result in more money...either directly or by avoiding fines or minimizing risks. The customer-vetting systems are of the latter sort.
The lesson: Swiss banks are insanely strict about the customers they take on, yet some "bad apples" do get through the firewalls. As I understand it, it's these bad apples that they're working with governments to ferret out (and in the end, it will benefit the *bank* by shining their already bright reputations...reputation is everything to these firms!).
I help make software purchasing decisions for my enterprise, a large European investment bank. One of the critical factors we use in deciding to adopt a new product is how stable it is, and that in turn is based on how mature it is...and version number (or, rather, version history) is one of the key data points in determining maturity. I can tell you point-blank that starting the versioning at something greater than 0 or 1 is an instant disqualification -- it sends a HUGE signal that this product has been rushed out the door or that the vendor is for some reason trying to hide something. I have encountered holes in the version histories of products in the past, for various legitimate reasons (product was merged with another product, features were added that were so substantial they changed the nature of the product, or the product was only advancing its minor version so the major version number was dropped -- something Sun seems to do a lot) and yes, they triggered a whole lot of questions to the vendor about the actual maturity of the product. Note that the tacit assumption here is that we WILL ask for a version history, so it'll be very apparent that your product doesn't start its numbering at 0 or 1.
Starting your product at version 5.0 is a BAD IDEA.
"Knowing the language" is one of the last things on my list of items to check off when interviewing developers. I could care less that they can rip out Java or C# in 10 minutes...and if that's their primary skill, then I don't want them around.
I want people that can solve problems, not language hacks. If the project is so straightforward it only requires skill with a language, then I'll outsource it to India (or China or Russia...or South Dakota, etc.). Sounds like the original poster is someone I'd hire, because he's NOT familiar with the language yet he clearly has the wherewithal to solve the problem at hand.
I used to go to great lengths to document my code. Then one day I started keeping track of the time I spend documenting code, correcting old/mistaken documentation, and digging myself out of misunderstandings caused by poor documentation. I quickly realized I spend a substantial amount of time doing the latter (can't remember the percentage...don't have a brain for numbers) -- so I started just deleting ALL the documentation in the code I edited before I did anything else with it.
And I watched my productivity increase. Substantially.
Some documentation is a good thing...but the lion's share just gets in the way. Documentation belongs in user's manuals and programming guides, not in source code.
That said, aside from the use of code viewers like doxygen and trips through the debugger, I have found the most useful way to understand code is to get one's hands on a Subject Matter Expert: either the original programmer or designer, or (better yet) a power-user who can tell you what the program -should- be doing and what it -does- do. Such folks are far more valuable than any pile of documentation.
[Disclaimer: I am a "software researcher" -- I have spent the past 20 years rummaging through -other- people's code, trying to make enough sense of it to determine why it runs slowly, consumes too many resources, or is hard to maintain. So my view of the issue may be a little different than most.]
I work for a large financial organization, on just this problem. From our perspective, the issue isn't whether parallel programming is too hard...we've adapted to various programming trends over the years just fine...the real question is how to manage the disruption of a new paradigm like this. Unlike other paradigms, parallelism has the capacity to apply to so many situations that you end up with a boil-the-ocean problem -- especially now that our codebases are truely ginormous, in constant flux, and fully mission-critical. How do you find the best spots in your codebase to parallelize without parallelizing the whole damned thing?
Some say, "well, just run a profiler on your code and parallelize the slowest functions!". Well, that's a start, but parallel technologies are not all created equal -- one code might be perfectly appropriate for threaded execution on a multicore chip but a complete waste of time on an FPGA or GPU. And parallelizing compilers, when they -do- work, often produce code that is horribly inefficient on a conventional processor (which seriously complicates the transition to production use). And yes, I know that there are tools out there that purport to sniff out candidate code...but their expense and lack of track record inhibits their adoption (at least where I work).
The reason parallization isn't popular yet in the enterprise is partly tooling, partly training...and partly decision-making. It requires substantial expertise to find good parallelization candidates -- and it takes even more expertise to explain to a budget-holder why the port costs as much as it does. The parallelization paradigm requires hardware AND software AND expertise and all of these parts have to be precisely fit or the solution suffers tremendously. But progress -is- being made, every time a project lead wins support to move one of the business's codes to FPGA or GPU or multicore or Clearspeed or whatever -- regardless of whether its successful or not.
The barriers to adoption aren't really all that unusual and won't keep parallelization from happening...its just going to take time for this meme to penetrate into the larger companies whose money will drive the paradigm into full-scale adoption. I think we're at the stage now where we need real live working demonstrations of valuable business code running in real production environments, both in order to convince our management that its worth spending money to foster this paradigm, and to learn what does and does not work.
I started college as a physics major, switched to math when I realized I couldn't make heads or tails of Schroedinger's wave equation, and got a job after college as a programmer "because I knows maff". Years later, I picked up the math books again...but not the calculus tome or the threatingly thin textbook on topology.
It was my History of Math book that I turned to, primarily to satisfy my curiosity about what my kid's being taught in school. What smacked me in the face after a few lines of the first chapter is that the HISTORICAL context is far, far more important than the theory, in -any- subject -- including computer programming.
Looking back (I've been a developer for 25 years), I realize that I'm largely a self-taught engineer, but I've learned the most through the stories of other engineers. The historical context of a subject provides the framework for our minds to make sense of the theory -and- relate that theory to actual practice and problem-solving.
So I only partially agree with the idea that we should be teaching new engineers theory over trade skills. I think there are four factors, each of roughly equal weight: theory, trade skills, history, and experimentation. The history supports the theory and provides a bridge to trade skills...the experimentation supports the trade skills and provides a bridge to the real world.
By "experimentation" I really mean open-ended play: give students a technical playground they can mess around with the technologies they're learning about, and encourage them to use it. Like many IT engineers of my age, I did this by hacking around with the university's computers, and then again with my own PC or with the company's computers. Hacking is essential to becoming a good IT engineer, IMO (and by "hacking" I mean it in the classical 1980's sense of the word, not the modern negative meaning).
Unless you're financially strapped, I'd go for the Perl job in a flash and I'll tell you why. You say you have a lot of Microsoft experience already -- that's good. But with Perl experience as well, you can invoke what I like to call the "old longhair effect" -- you can appear to some uninformed IT managers as having a breadth and depth of experience greater than you actually may. This has benefits, if you don't abuse it: like getting picked for challenging projects, being asked for your technical opinion in business decisions, and having greater freedom to choose your next job -- all of which also adds to your actual expertise immensely. Now obviously, this won't work in that small Unix web shop with the Perl job...its more something to bank on for future positions in bigger corps.
Get yerself all Unixed up while you can! I can tell you from experience that it has nice benefits.
There's a company called Headway Software, makes a tool called reView (...I think it has a different name now) that generates UML-like diagrams of source code annotated with a buttload of metrics. I'd love to see the reView tool run against this C/C++ database and the resulting trees stored for perusal.
Metrics are going to be a key adjunct to this database. All the metrics tools like reView, PMD, Parasoft's tools, etc. produce would be useful.
Even more useful would be pattern metrics -- CheckStyle and PMD can recognize some common design patterns and one of them (PMD?) has the ability to be extended with custom pattern recognizers. With a database this big, it should be feasible to produce proof substantiating the claim to bestness of just about any practice.
In his defense, Wolfram doesn't actually take credit for all the things he appears to be taking credit for -- the Notes section (almost as large as the main body of the book) explains the history of CA, chaos theory, etc. and the connections he's making into them. I haven't yet found an idea in the first four chapters that Wolfram claims is his own that he -doesn't- then explain the history of in the Notes. Its an annoying habit that he tries to explain away as "a writing style intended to stress the importance of rather dull and vague mathematical ideas" (my paraphrase...I don't have the book in front of me). Wolfram is very much engrossed in his own discovery process but, while annoying, it doesn't invalidate the work (at least, not for me).
I'm only on chapter 4 of Wolfram's opus 'A New Kind of Science' but reading about the Riemann Hypothesis just screams out connections with Wolfram's work. ANKOS is littered with these odd little diagrams of cellular automata, many of which exhibit prime number relationships.
Slashdot Mirror
At the risk of getting downmodded for a me-too post, I'll back up olesk's statement by saying that I, too, work for a large Swiss bank (in the IT department) and I can tell you that we have several pretty large IT systems specifically devoted to checking out customers. Obviously, I can't go into details but I can say they were expensive to build and they cost the bank money to keep running. Big banks are by nature hyper-conservative and rarely spend money unless it will result in more money...either directly or by avoiding fines or minimizing risks. The customer-vetting systems are of the latter sort.
The lesson: Swiss banks are insanely strict about the customers they take on, yet some "bad apples" do get through the firewalls. As I understand it, it's these bad apples that they're working with governments to ferret out (and in the end, it will benefit the *bank* by shining their already bright reputations...reputation is everything to these firms!).
I help make software purchasing decisions for my enterprise, a large European investment bank. One of the critical factors we use in deciding to adopt a new product is how stable it is, and that in turn is based on how mature it is...and version number (or, rather, version history) is one of the key data points in determining maturity. I can tell you point-blank that starting the versioning at something greater than 0 or 1 is an instant disqualification -- it sends a HUGE signal that this product has been rushed out the door or that the vendor is for some reason trying to hide something. I have encountered holes in the version histories of products in the past, for various legitimate reasons (product was merged with another product, features were added that were so substantial they changed the nature of the product, or the product was only advancing its minor version so the major version number was dropped -- something Sun seems to do a lot) and yes, they triggered a whole lot of questions to the vendor about the actual maturity of the product. Note that the tacit assumption here is that we WILL ask for a version history, so it'll be very apparent that your product doesn't start its numbering at 0 or 1.
Starting your product at version 5.0 is a BAD IDEA.
"Knowing the language" is one of the last things on my list of items to check off when interviewing developers. I could care less that they can rip out Java or C# in 10 minutes...and if that's their primary skill, then I don't want them around.
I want people that can solve problems, not language hacks. If the project is so straightforward it only requires skill with a language, then I'll outsource it to India (or China or Russia...or South Dakota, etc.). Sounds like the original poster is someone I'd hire, because he's NOT familiar with the language yet he clearly has the wherewithal to solve the problem at hand.
I used to go to great lengths to document my code. Then one day I started keeping track of the time I spend documenting code, correcting old/mistaken documentation, and digging myself out of misunderstandings caused by poor documentation. I quickly realized I spend a substantial amount of time doing the latter (can't remember the percentage...don't have a brain for numbers) -- so I started just deleting ALL the documentation in the code I edited before I did anything else with it.
And I watched my productivity increase. Substantially.
Some documentation is a good thing...but the lion's share just gets in the way. Documentation belongs in user's manuals and programming guides, not in source code.
That said, aside from the use of code viewers like doxygen and trips through the debugger, I have found the most useful way to understand code is to get one's hands on a Subject Matter Expert: either the original programmer or designer, or (better yet) a power-user who can tell you what the program -should- be doing and what it -does- do. Such folks are far more valuable than any pile of documentation.
[Disclaimer: I am a "software researcher" -- I have spent the past 20 years rummaging through -other- people's code, trying to make enough sense of it to determine why it runs slowly, consumes too many resources, or is hard to maintain. So my view of the issue may be a little different than most.]
I work for a large financial organization, on just this problem. From our perspective, the issue isn't whether parallel programming is too hard...we've adapted to various programming trends over the years just fine...the real question is how to manage the disruption of a new paradigm like this. Unlike other paradigms, parallelism has the capacity to apply to so many situations that you end up with a boil-the-ocean problem -- especially now that our codebases are truely ginormous, in constant flux, and fully mission-critical. How do you find the best spots in your codebase to parallelize without parallelizing the whole damned thing?
Some say, "well, just run a profiler on your code and parallelize the slowest functions!". Well, that's a start, but parallel technologies are not all created equal -- one code might be perfectly appropriate for threaded execution on a multicore chip but a complete waste of time on an FPGA or GPU. And parallelizing compilers, when they -do- work, often produce code that is horribly inefficient on a conventional processor (which seriously complicates the transition to production use). And yes, I know that there are tools out there that purport to sniff out candidate code...but their expense and lack of track record inhibits their adoption (at least where I work).
The reason parallization isn't popular yet in the enterprise is partly tooling, partly training...and partly decision-making. It requires substantial expertise to find good parallelization candidates -- and it takes even more expertise to explain to a budget-holder why the port costs as much as it does. The parallelization paradigm requires hardware AND software AND expertise and all of these parts have to be precisely fit or the solution suffers tremendously. But progress -is- being made, every time a project lead wins support to move one of the business's codes to FPGA or GPU or multicore or Clearspeed or whatever -- regardless of whether its successful or not.
The barriers to adoption aren't really all that unusual and won't keep parallelization from happening...its just going to take time for this meme to penetrate into the larger companies whose money will drive the paradigm into full-scale adoption. I think we're at the stage now where we need real live working demonstrations of valuable business code running in real production environments, both in order to convince our management that its worth spending money to foster this paradigm, and to learn what does and does not work.
I started college as a physics major, switched to math when I realized I couldn't make heads or tails of Schroedinger's wave equation, and got a job after college as a programmer "because I knows maff". Years later, I picked up the math books again...but not the calculus tome or the threatingly thin textbook on topology.
It was my History of Math book that I turned to, primarily to satisfy my curiosity about what my kid's being taught in school. What smacked me in the face after a few lines of the first chapter is that the HISTORICAL context is far, far more important than the theory, in -any- subject -- including computer programming.
Looking back (I've been a developer for 25 years), I realize that I'm largely a self-taught engineer, but I've learned the most through the stories of other engineers. The historical context of a subject provides the framework for our minds to make sense of the theory -and- relate that theory to actual practice and problem-solving.
So I only partially agree with the idea that we should be teaching new engineers theory over trade skills. I think there are four factors, each of roughly equal weight: theory, trade skills, history, and experimentation. The history supports the theory and provides a bridge to trade skills...the experimentation supports the trade skills and provides a bridge to the real world.
By "experimentation" I really mean open-ended play: give students a technical playground they can mess around with the technologies they're learning about, and encourage them to use it. Like many IT engineers of my age, I did this by hacking around with the university's computers, and then again with my own PC or with the company's computers. Hacking is essential to becoming a good IT engineer, IMO (and by "hacking" I mean it in the classical 1980's sense of the word, not the modern negative meaning).
Unless you're financially strapped, I'd go for the Perl job in a flash and I'll tell you why. You say you have a lot of Microsoft experience already -- that's good. But with Perl experience as well, you can invoke what I like to call the "old longhair effect" -- you can appear to some uninformed IT managers as having a breadth and depth of experience greater than you actually may. This has benefits, if you don't abuse it: like getting picked for challenging projects, being asked for your technical opinion in business decisions, and having greater freedom to choose your next job -- all of which also adds to your actual expertise immensely. Now obviously, this won't work in that small Unix web shop with the Perl job...its more something to bank on for future positions in bigger corps.
Get yerself all Unixed up while you can! I can tell you from experience that it has nice benefits.
There's a company called Headway Software, makes a tool called reView (...I think it has a different name now) that generates UML-like diagrams of source code annotated with a buttload of metrics. I'd love to see the reView tool run against this C/C++ database and the resulting trees stored for perusal.
Metrics are going to be a key adjunct to this database. All the metrics tools like reView, PMD, Parasoft's tools, etc. produce would be useful.
Even more useful would be pattern metrics -- CheckStyle and PMD can recognize some common design patterns and one of them (PMD?) has the ability to be extended with custom pattern recognizers. With a database this big, it should be feasible to produce proof substantiating the claim to bestness of just about any practice.
In his defense, Wolfram doesn't actually take credit for all the things he appears to be taking credit for -- the Notes section (almost as large as the main body of the book) explains the history of CA, chaos theory, etc. and the connections he's making into them. I haven't yet found an idea in the first four chapters that Wolfram claims is his own that he -doesn't- then explain the history of in the Notes. Its an annoying habit that he tries to explain away as "a writing style intended to stress the importance of rather dull and vague mathematical ideas" (my paraphrase...I don't have the book in front of me). Wolfram is very much engrossed in his own discovery process but, while annoying, it doesn't invalidate the work (at least, not for me).
I'm only on chapter 4 of Wolfram's opus 'A New Kind of Science' but reading about the Riemann Hypothesis just screams out connections with Wolfram's work. ANKOS is littered with these odd little diagrams of cellular automata, many of which exhibit prime number relationships.