4 ms·

Sounds like they need to realize that some programmers can learn a language as they go... At least, well enough to fix problems and do minor changes. You don'

Sounds like they need to realize that some programmers can learn a language as they go... At least, well enough to fix problems and do minor changes. You don't need someone fluent in the language for every problem. They also need to realize that sometimes it really is cheaper/better to start from scratch than to try to prop up a dying system. Complaining about the cost of programmers while refusing to do a rewrite is pointless. You've picked your path.

16s 15y ago
Many of these older languages do things that younger programmers are taught not to do. If you've only ever programmed in OOP/Java, Ruby or .Net, I'm not sure you'll "learn as you go" as you'll have to go against much of what you learned in college or at your startup. If you are able to do that (think outside of what you've been taught), then you'll be fine, if not, you'll fail and complain and suggest that it be re-written in Ruby, etc. Edit: And if they do re-write it, they'll use C++ code written like C code. Not that there is anything wrong with that, but just know that they "think different" and you have to adapt to their way, not them to yours.
- CountHackulus 15y ago
  This is especially true of COBOL where PERFORM statements are like an internal subroutine ending with a goto. It looks like heracy when you first see how it was implemented 30 years ago. Arbitrary unions are pretty neat too but look like black magic to the uninitiated.
dagw 15y ago
Doing a rewrite of, say, an APL system without programmers with a really deep understanding of APL on the team will most likely end in failure and misery. So you're still faced with the problem of finding and hiring people who know APL. Also letting some RoR hacker, who heard about APL for the first time 3 days ago, loose on your super critical production code, probably isn't that great an idea either
- gaius 15y ago
  A former employer spent literally 9-figures on repeated attempts to port a legacy app from VAX BASIC to C++ on Unix. God only knows how much they would need to do APL...
- jharsman 15y ago
  Provided you still have source code and development tools available, the problem in cases like this usually isn't the language. Even APL is pretty easy to pick up if you have a book or someone to teach you. The bigger issue is that the application you need to fix is mission critical, undocumented and contains massive amounts of spaghetti code. There usually aren't any tests, source control might not be used and it's far from certain there are automated builds or deploy scripts. In some cases you might not even have source or the tools to use it, and then you have much bigger problems. But the language usually isn't the main problem.
wglb 15y ago
With this stuff, it isn't so much the language as the culture. You may be right in your second to paragraphs, however. All of this mainframe stuff was designed when machines were vastly more expensive than the programmers tending to them. In any modern context, the computers that make us productive cost on the order of magnitude of a chair, not a building.

16s 15y ago

Many of these older languages do things that younger programmers are taught not to do. If you've only ever programmed in OOP/Java, Ruby or .Net, I'm not sure you'll "learn as you go" as you'll have to go against much of what you learned in college or at your startup. If you are able to do that (think outside of what you've been taught), then you'll be fine, if not, you'll fail and complain and suggest that it be re-written in Ruby, etc. Edit: And if they do re-write it, they'll use C++ code written like C code. Not that there is anything wrong with that, but just know that they "think different" and you have to adapt to their way, not them to yours.

CountHackulus 15y ago
This is especially true of COBOL where PERFORM statements are like an internal subroutine ending with a goto. It looks like heracy when you first see how it was implemented 30 years ago. Arbitrary unions are pretty neat too but look like black magic to the uninitiated.

dagw 15y ago

Doing a rewrite of, say, an APL system without programmers with a really deep understanding of APL on the team will most likely end in failure and misery. So you're still faced with the problem of finding and hiring people who know APL. Also letting some RoR hacker, who heard about APL for the first time 3 days ago, loose on your super critical production code, probably isn't that great an idea either

gaius 15y ago
A former employer spent literally 9-figures on repeated attempts to port a legacy app from VAX BASIC to C++ on Unix. God only knows how much they would need to do APL...
jharsman 15y ago
Provided you still have source code and development tools available, the problem in cases like this usually isn't the language. Even APL is pretty easy to pick up if you have a book or someone to teach you. The bigger issue is that the application you need to fix is mission critical, undocumented and contains massive amounts of spaghetti code. There usually aren't any tests, source control might not be used and it's far from certain there are automated builds or deploy scripts. In some cases you might not even have source or the tools to use it, and then you have much bigger problems. But the language usually isn't the main problem.

wglb 15y ago

With this stuff, it isn't so much the language as the culture. You may be right in your second to paragraphs, however. All of this mainframe stuff was designed when machines were vastly more expensive than the programmers tending to them. In any modern context, the computers that make us productive cost on the order of magnitude of a chair, not a building.