Become a fan of Slashdot on Facebook


Forgot your password?

Comment Dominant force doesn't matter. Early adopter does. (Score 2, Insightful) 370

The adoption of a new technology is generally not driven by those who dominate once it is widespread. It tends to be driven by early adopters, who are willing to spend the money to try out a new technology. They either prove it, or they have tons of problems. As soon as somebody proves a technology is viable, a business shmuck at some large company can make a successful pitch that "This is the future, etc, etc...and it's already proven technology so the company doesn't have to worry about hiccups, etc, etc".

That is why Porn killed Betamax. Not because Porn represents a large market share, but because Porn was willing to be an early adopter of VHS. They proved that video sales and rental via VHS was viable. Once that happened, the major video players we unwilling to take a bet on Betamax, no matter how superior it was, because they looked at the Porn industry and saw that VHS was already in use, and therefore, the business plan and technical hurdles were done for them, guaranteed.

Comment Re:Another reason... (Score 1) 314

Generally, yes. My point was that older programs like that (hell, new programs too, who are we kidding) tend to have poor behavioral documentation, meaning that small features and bits of logic which are important to the company are captured only in code. Meaning you needed to start the rewrite before the old geezers who maintained the old system retired, because otherwise you will have new engineers who are not familiar with the language or tools, trying to dig ultra-deep into unfamiliar software for answers.

Hell, to your point that the language being COBOL doesn't matter that much, you're probably right. Take any competent C programmer who has never looked at large open source project X, and ask him to find and modify the code for feature Y. It will take him waaaaay longer on his own than if he has access to a programmer who has been hacking on the source for a while.

Comment Re:Errr (Score 1) 307

Hmmm. credentials please? citations maybe? I don't claim to be an expert, but blanket dissmisiveness with no details or citations is not going to convince me, since I do know a hell of a lot about both computers and arithmetic in alternative bases.

My opinions are just that, opinions, especially regarding tertiary machines, since, to my knowledge, a truly usable one has never been demonstrated.

So it's possible that what I said is not actually true, but my opinion is based on first hand experience and opinions of others who have been in the field of computing for a very long time. So as I said, it will take more than a general statement with no backup to change my mind.

Comment Re:Forget Linux skills... (Score 1) 208

wait a just said that linux skills won't get you chicks, but the quote states that computer hacking skills are included. Even if you consider that linux skills != computer hacking skills, then surely it's not a far stretch from there, and at the very least, linux skills are probably a prerequisite to computer hacking skills...

Comment Re:Errr (Score 1) 307

I do in fact believe that there are infinite possible bases. The problem is creating unique symbols. It is not enough to claim you have a base-1024 number system, you must create 1024 unique symbols for the system. For an infinity-base number system, you need infinite unique symbols.

The limit to creation of computers which function in bases other than two is mostly limited by the capabilities of the human brain. We have enough trouble juggling binary. each additional number adds significantly increasing complexity.

I believe that it has been theorized that the most efficient machine would actually be tertiary (i.e. one more than binary), and numbers past that have diminishing returns. The Tertiary system would offer several distinct advantages in data manipulation, especially in dealing with odd numbers. It also offers a third state for decision making, although debate rages over what the best use for that third state would be, probably something akin to "maybe". Arguably, The third "maybe" state of a decision is a primary limiting factor in the creation of AI, since the "maybe" state is a critical part of human intelligence and decision making.

Theoretically, a base-10 computer would also be an excellent choice. Even though exceedingly complex to design at a electronic level, the advantages would be immeasurable (programming in the same base as we naturally think would make everything far easier and less error prone). Even though base-10 is significantly more complex, the alignments of the patterns of numbers are such that it optimizes the use of the number system quite well. This is exactly why humans naturally went to it without quite understanding what they had done.

Comment Another reason... (Score 2, Interesting) 314

Why would you want to replace 2 billion lines of working COBOL code?

Easy...COBOL, while still in use and working well now, is not a language which is still is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.

"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"

Well, what's what is that:

a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.

(a) implies problem #2:

b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.

Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.

This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...

Slashdot Top Deals

"The geeks shall inherit the earth." -- Karl Lehenbauer