Question: if it's providing a heat sink for the cooling system, how is it infecting people? Isn't the chilling process a closed loop? How is the cooling tower water making it into the facility air? Explaining that would be illuminating, and I appreciate what you already wrote.
Enterprise Maintenance Systems are something of a domain for me. All right, it's my primary domain. Those old maintenance systems are easily replaced, save the people-factor. The FAA signoffs for newer EAM replacements are a lot easier than internal quality units will admit. Again, it's a people issue, not a technology issue.
Yeah, actually, it is flawed... for everyone but the top 1% that benefits from a collusive environment that expects more than 40 hours because "you're a professional".
Upper IT management here. Your assertions are correct if you add "lazy" to the managers described above. We all deal with cost pressures, but we're inadequately supplied with the information to make a good decision more frequently than not.
21 CFR Part 11. The FDA does in fact force pharmas and medical device makers to review and QA/QC software. There is no such shield from the FDA. You either lied or made it up, but you're sad either way.
"That's amusing. Google has re-invented Go Computer's PenPoint. That's how they ran multiple semi-persistent applications on their tablet in the late 1980s."
You must mean Terminate and Stay Resident computing, invented before Go Computer's PenPoint, which is how everyone in the DOS world ran multiple semi-persistent applications on their computers in the mid 80s.
Which is predated by any multiprocessing system that can suspend any process to run another... so, kinda not stealing.
Pike and Thompson are not computer scientists, they are practitioners. The difference between Thompson's contributions and Knuth's contributions, for example, illustrate this exact point.
Your guess would be wrong. Apache is the core webserver for lots of application servers; i.e. you're getting Apache every time you install Oracle IAS or WebSphere. Dunno about WebLogic but I'd guess that applies as well. Your 10% goes up, way up.
... because clearly, you like setting the bar impossibly high for yourself.
You will never know the code as well as the original developer. so stop trying. For very old cases >10 years, that developer was also the analyst who gathered the requirements, further cementing you to a 3rd-bit player in the drama. Let it go.
You *can* maintain someone else's code, though, if you can do a few things:
-dispense with ego
-learn to *read* code, especially as a reviewer
-ask lots of questions
As a maintenance programmer, you have to be fearless about asking questions, even if they dead-end you. You asked. You were thrust into a bad spot, you do your best to figure out where you're at. Assess the situation. There's no rush to fix anything, it's not like the problem's going anywhere and no one is hiring clueless mission-critical coders.
Start small. Start really small, like just reading the code as you might in a code review and see if you can spot trends. If you've been doing this awhile, you can start picking up on the strengths and weaknesses of the author(s). At the very least you can start to immerse yourself in the style and convention, making translation to the actual algorithms easier, i.e. what's this bit doing? I'm not embarrassed to say I've professionally reviewed code that I could never write -- it was VB and ASP -- but I know what object-oriented code should look like, should be capable of doing, and this wasn't it. It wasn't even good procedural/ iterative code... but that's besides the point. The point is, I know when to use a while loop, a for loop, and when to unroll the loop. It's the kind of knowledge that comes in handy no matter what language I'm looking at. Declarative? No problem, it's set-based thinking and straight Boolean logic. Functional? Fine, let's start busting down the parentheticals. It's also about moving data into a register, eventually.
So, you start small, you read the code, you trace some data by hand, a little, and then... run the fuckin' thing with a debugger, step by step, and watch the data move. If it takes you all day to run it once, you're entirely ready on day two to start messing with it. You've likely done what only the original developer has ever done, and that's seen data at the top run straight through to the bottom.
Actually, the big draw is the ability to read the display in any light conditions, i.e. outside in sunlight. The crossover effect this would have on handhelds for a workforce would be tremendous.
PHP does the same things as C++? Really? And C++ lacks standard libraries to process XML, connect to DBs..? Interesting assertions. Cite sources, because from what I understand, C++ has tons of libraries and templates, and does things that lots of languages including PHP cannot do... operating systems, real-time applications, and compilers spring to mind.
mod +1 insightful and correct: infrastructure is defined as the basis for an economy and society. It is not in public interest to run more than one gas line, water supply line, or sewer line. It is impossible to run separate highways -- and outsourcing mgmt of same is proving as ridiculous as govt mgmt -- so why then do we allow the pretense of the last mile?
The problem is a historical outsourcing of this infrastructure component to a regulated monopoly (AT&T). NYC circa 1911 had hundreds of indie wires connecting buildings; granting a monopoly to AT&T with open-access covenants solved this and cleaned up the problem. Today, the problem is largely solved but the divorce of managing the infrastructure versus providing services on it did not take place. In other words, break up Verizon and SBC and every other last-mile provider, separating the physical transport from the value-added services.
Just think of it this way: Verizon or some other company contracts with a muni or county to provide last-mile service. Taxes pay for the connectivity, the wires, the fiber, what have you. Verizon provides -- and only provides -- a central office space with connections to the local infrastructure. Your services are provided by people leasing space in the CO and interconnecting. Last mile is provided by your town or county. Services are provided by whoever can lease a spot on the floor and cover operating costs.
I mean, we don't run Main Street any differently, do we?
The assumption underlying the question is that these 1st-year students are going to become programmers/ developers/ software engineers. In other words, practitioners as opposed to researchers. This is the elephant in the room for computer science today.
Professors tend to teach the pure CS model of programming, i.e. data structures, lexical parsing, algorithms, everything you saw in your 1994 syllabus. They do this because, guess what, they are researchers and pure computer scientists. Rarely do you get a 15 year veteran of software engineering teaching an algorithms class; for one thing, these people are too busy solving real-world problems like schedule slippage and feature creep to manage a graduate-level course load. So why, then, is CS continuing to teach CS when what students want is software engineering? I don't know. I think it's all they can teach.
So, I think Scheme/ Haskell is very good at bringing 1st year SCIENTISTS into programming, if only to get them looking at the basic problems of CS and not necessarily engineering software for a big corporation.
For software engineers, or people who want to ply their trade for a big corp or small firm or for their own benefit, I would say the platform matters more, not the language. Big corps wants J2EE expertise, big-time messaging and integration opportunities there... so learn Java, SQL, and how app servers work. You might try the dot-NET platform if you want to make a living to Microsoft-centered projects; there's tons of work for Sharepoint devs so C# and getting practical experience with the vast dot-NET library will help you immeasurably.
Along the way, though, you'll need to learn how to develop solid, robust code. CS programs don't each this very well, if at all. Self-study is the only practical route, aside from the ultimate teacher of experience. Experience, however, suffers from a chicken-egg scenario: if my feedback loop of experience reinforces bad practice, how will I detect it? This, I think, is the major shortfall of CS/ Engineering programs.
Couple this with the undeniable trend of moving all entry-level programming jobs away form US graduates, and you have almost no way of becoming a 15-yr vet of software engineering, capable of solving a variety of issues on a variety of platforms. You'll never get that chance unless you are willing to live like your outsourced counterparts, wherever they may be. Public companies care about anonymous shareholders more than the citizenry of their incorporated location.
Ah well. I finally managed to put these thoughts together somewhat coherently, so I'm done.
Slashdot Mirror
Question: if it's providing a heat sink for the cooling system, how is it infecting people? Isn't the chilling process a closed loop? How is the cooling tower water making it into the facility air? Explaining that would be illuminating, and I appreciate what you already wrote.
--#
Enterprise Maintenance Systems are something of a domain for me. All right, it's my primary domain. Those old maintenance systems are easily replaced, save the people-factor. The FAA signoffs for newer EAM replacements are a lot easier than internal quality units will admit. Again, it's a people issue, not a technology issue.
Cite the law or retract. Carriers restrict updates because they can, no law required.
Yeah, actually, it is flawed... for everyone but the top 1% that benefits from a collusive environment that expects more than 40 hours because "you're a professional".
It's bullshit and you know it.
--#
Rock star performance is achievable by anyone who gets to focus on just one thing at a time. It's also called being a prima donna, not a rock star.
--#
... then everyone gets to where they need to be in the shortest time possible. Except me, because I know where I'm going.
Shep did this even one better back in the 50s.
Upper IT management here. Your assertions are correct if you add "lazy" to the managers described above. We all deal with cost pressures, but we're inadequately supplied with the information to make a good decision more frequently than not.
21 CFR Part 11. The FDA does in fact force pharmas and medical device makers to review and QA/QC software. There is no such shield from the FDA. You either lied or made it up, but you're sad either way.
--#
Since it has its own power generation plants, for one.
Oh, you mean a wider grid like, say, the entire Northeast Corridor of Amtrak?
"That's amusing. Google has re-invented Go Computer's PenPoint. That's how they ran multiple semi-persistent applications on their tablet in the late 1980s."
You must mean Terminate and Stay Resident computing, invented before Go Computer's PenPoint, which is how everyone in the DOS world ran multiple semi-persistent applications on their computers in the mid 80s.
Which is predated by any multiprocessing system that can suspend any process to run another... so, kinda not stealing.
--#
Dude, come back when you have turn-by-turn navigation on Ovi Maps. Or when Android is *completely* ported to the N900.
--#
"Actually -- because the new generation DOESNT LEARN C++ its why code is getting so sloppy now"
You could make the same statement, with more force, about COBOL and FORTRAN, sonny.
--#
Pike and Thompson are not computer scientists, they are practitioners. The difference between Thompson's contributions and Knuth's contributions, for example, illustrate this exact point.
--#
Your guess would be wrong. Apache is the core webserver for lots of application servers; i.e. you're getting Apache every time you install Oracle IAS or WebSphere. Dunno about WebLogic but I'd guess that applies as well. Your 10% goes up, way up.
--#
... because clearly, you like setting the bar impossibly high for yourself.
You will never know the code as well as the original developer. so stop trying. For very old cases >10 years, that developer was also the analyst who gathered the requirements, further cementing you to a 3rd-bit player in the drama. Let it go.
You *can* maintain someone else's code, though, if you can do a few things:
-dispense with ego
-learn to *read* code, especially as a reviewer
-ask lots of questions
As a maintenance programmer, you have to be fearless about asking questions, even if they dead-end you. You asked. You were thrust into a bad spot, you do your best to figure out where you're at. Assess the situation. There's no rush to fix anything, it's not like the problem's going anywhere and no one is hiring clueless mission-critical coders.
Start small. Start really small, like just reading the code as you might in a code review and see if you can spot trends. If you've been doing this awhile, you can start picking up on the strengths and weaknesses of the author(s). At the very least you can start to immerse yourself in the style and convention, making translation to the actual algorithms easier, i.e. what's this bit doing? I'm not embarrassed to say I've professionally reviewed code that I could never write -- it was VB and ASP -- but I know what object-oriented code should look like, should be capable of doing, and this wasn't it. It wasn't even good procedural/ iterative code... but that's besides the point. The point is, I know when to use a while loop, a for loop, and when to unroll the loop. It's the kind of knowledge that comes in handy no matter what language I'm looking at. Declarative? No problem, it's set-based thinking and straight Boolean logic. Functional? Fine, let's start busting down the parentheticals. It's also about moving data into a register, eventually.
So, you start small, you read the code, you trace some data by hand, a little, and then... run the fuckin' thing with a debugger, step by step, and watch the data move. If it takes you all day to run it once, you're entirely ready on day two to start messing with it. You've likely done what only the original developer has ever done, and that's seen data at the top run straight through to the bottom.
--#
... Castle Wolfenstein was created.
Actually, the big draw is the ability to read the display in any light conditions, i.e. outside in sunlight. The crossover effect this would have on handhelds for a workforce would be tremendous.
PHP does the same things as C++? Really? And C++ lacks standard libraries to process XML, connect to DBs..? Interesting assertions. Cite sources, because from what I understand, C++ has tons of libraries and templates, and does things that lots of languages including PHP cannot do... operating systems, real-time applications, and compilers spring to mind.
Mmmmm... you live in a different world than everyone else. Sometimes people really do have it coming.
The penal system's method of punishment immediately sprung to mind.
mod +1 insightful and correct: infrastructure is defined as the basis for an economy and society. It is not in public interest to run more than one gas line, water supply line, or sewer line. It is impossible to run separate highways -- and outsourcing mgmt of same is proving as ridiculous as govt mgmt -- so why then do we allow the pretense of the last mile?
The problem is a historical outsourcing of this infrastructure component to a regulated monopoly (AT&T). NYC circa 1911 had hundreds of indie wires connecting buildings; granting a monopoly to AT&T with open-access covenants solved this and cleaned up the problem. Today, the problem is largely solved but the divorce of managing the infrastructure versus providing services on it did not take place. In other words, break up Verizon and SBC and every other last-mile provider, separating the physical transport from the value-added services.
Just think of it this way: Verizon or some other company contracts with a muni or county to provide last-mile service. Taxes pay for the connectivity, the wires, the fiber, what have you. Verizon provides -- and only provides -- a central office space with connections to the local infrastructure. Your services are provided by people leasing space in the CO and interconnecting. Last mile is provided by your town or county. Services are provided by whoever can lease a spot on the floor and cover operating costs.
I mean, we don't run Main Street any differently, do we?
-BA
Nope, I'm just glad to see you.
The assumption underlying the question is that these 1st-year students are going to become programmers/ developers/ software engineers. In other words, practitioners as opposed to researchers. This is the elephant in the room for computer science today.
Professors tend to teach the pure CS model of programming, i.e. data structures, lexical parsing, algorithms, everything you saw in your 1994 syllabus. They do this because, guess what, they are researchers and pure computer scientists. Rarely do you get a 15 year veteran of software engineering teaching an algorithms class; for one thing, these people are too busy solving real-world problems like schedule slippage and feature creep to manage a graduate-level course load. So why, then, is CS continuing to teach CS when what students want is software engineering? I don't know. I think it's all they can teach.
So, I think Scheme/ Haskell is very good at bringing 1st year SCIENTISTS into programming, if only to get them looking at the basic problems of CS and not necessarily engineering software for a big corporation.
For software engineers, or people who want to ply their trade for a big corp or small firm or for their own benefit, I would say the platform matters more, not the language. Big corps wants J2EE expertise, big-time messaging and integration opportunities there... so learn Java, SQL, and how app servers work. You might try the dot-NET platform if you want to make a living to Microsoft-centered projects; there's tons of work for Sharepoint devs so C# and getting practical experience with the vast dot-NET library will help you immeasurably.
Along the way, though, you'll need to learn how to develop solid, robust code. CS programs don't each this very well, if at all. Self-study is the only practical route, aside from the ultimate teacher of experience. Experience, however, suffers from a chicken-egg scenario: if my feedback loop of experience reinforces bad practice, how will I detect it? This, I think, is the major shortfall of CS/ Engineering programs.
Couple this with the undeniable trend of moving all entry-level programming jobs away form US graduates, and you have almost no way of becoming a 15-yr vet of software engineering, capable of solving a variety of issues on a variety of platforms. You'll never get that chance unless you are willing to live like your outsourced counterparts, wherever they may be. Public companies care about anonymous shareholders more than the citizenry of their incorporated location.
Ah well. I finally managed to put these thoughts together somewhat coherently, so I'm done.
--#