Are the posted questions getting worse?

  • Dennis Jensen wrote:

    Jeff Moden I did try to outline that in context. I was saying I have actually seen this before with a dynotopic prehistoric language (aka Cobol) where the powers to be were not biting the bullet and moving to a better language but they were instead trying to make their dynotopic prehistoric language more relevant. Which if you have ever coded in Cobol you will know that is next to impossible, which means expending at least 5 times the effort that it would take to change to a more viable language and still not guarantee you have a quality solution.

    Further I was not saying someone was promising a futuristic hover car but that one (if not many) actually already existed and were being used.  However, these archaic thinkers could not give up what they were using and embrace the futuristic change but felt it was worth wasting resources to great a dynotopic prehistoric solution which of course is going to fall significantly short of these futuristic hover cars.

    Please, don't malign COBOL. It is a good language and still in use.

     

  • Lynn Pettis wrote:

    Please, don't malign COBOL. It is a good language and still in use.

    Okay you and I will have to agree to disagree on this one. Not that it is still in use because sadly it is, but that it is still a good language. As any language that takes 3 pages to write something that is barely a paragraph in most other languages is to me highly inefficient. Sure it had its purpose back in the early years, but its like racing a 1914 Mercer Type 35-J Raceabout against a Toyota TS050 LMP1 in the LeMans.  It just can no longer compete as it is just to archaic and those using it would be better served by replacing it with a better more progressive language than trying to upgrade the language to be more like its much better counterparts. But again, they would much rather hold onto to the dinosaur they know then upgrade to a quality existing hover car or even an electric hybrid. Final Note: there is nothing you can program in COBOL that cannot be programmed better in one of the current more modern languages. The only reason it is still in use, is because those still using it do not want to bite-the-bullet and upgrade to a better more efficient language for whatever bad reasons they are doing that for. Further it is not like they are getting cheap labor because the number of quality proficient COBOL programmers is a much smaller pool of people thus supply and demand steps in jacking up their rates.

    • This reply was modified 2 years, 3 months ago by Dennis Jensen. Reason: fix typo
  • Dennis Jensen wrote:

    Lynn Pettis wrote:

    Please, don't malign COBOL. It is a good language and still in use.

    Okay you and I will have to agree to disagree on this one. Not that it is still in use because sadly it is, but that it is still a good language. As any language that takes 3 pages to write something that is barely a paragraph in most other languages is to me highly inefficient. Sure it had its purpose back in the early years, but its like racing a 1914 Mercer Type 35-J Raceabout against a Toyota's TS050 LMP1 in the LeMans.  It just can no longer compete as it is just to archaic and those using it would be better served by replacing it with a better more progressive language than trying to upgrade the language to be more like its much better counterparts. But again, they would much rather hold onto to the dinosaur they know then upgrade to a quality existing hover car or even an electric hybrid. Final Note: there is nothing you can program in COBOL that cannot be programmed better in one of the current more modern languages. The only reason it is still in use, is because those still using it do not want to bite-the-bullet and upgrade to a better more efficient language for whatever bad reasons they are doing that for. Further it is not like they are getting cheap labor because the number of quality proficient COBOL programmers is a much smaller pool of people thus supply and demand steps in jacking up their rates.

    Edsger Dijkstra said "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

  • Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well.

     

  • Lynn Pettis wrote:

    Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well. 

    In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career.  My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.

  • Jonathan AC Roberts wrote:

    Lynn Pettis wrote:

    Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well. 

    In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career.  My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.

    I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden wrote:

    Jonathan AC Roberts wrote:

    Lynn Pettis wrote:

    Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well. 

    In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career.  My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.

    I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?

    I started with COBOL and wrote it for more years than I care to remember.

    Far away is close at hand in the images of elsewhere.
    Anon.

  • Jeff Moden wrote:

    Jonathan AC Roberts wrote:

    Lynn Pettis wrote:

    Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well. 

    In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career.  My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.

    I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?

    Around 30 years ago, I spent a couple of years working with Cobol, writing and making amendments to the code. While I can still comprehend every line of it, I made a swift exit from that field as soon as I could.

  • David Burrows wrote:

    Jeff Moden wrote:

    Jonathan AC Roberts wrote:

    Lynn Pettis wrote:

    Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well. 

    In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career.  My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.

    I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?

    I started with COBOL and wrote it for more years than I care to remember.

     

    And now you can even use .NET COBOL. Cobol isn't dead.

     

  • Lynn Pettis wrote:

    And now you can even use .NET COBOL. Cobol isn't dead.

    As I said it would not surprise me if they have continued to try and create a better dinosaur rather than leaving the dinosaur behind. Monty Python is not far from the mark when they said "Folks thought I was daft to build a castle in the swamp but I did it anyway. It sank. So I built a second one and it sank. So I built a third one, it burnt down, fell over, and sank. So a built a fourth and it is still standing."

    So in short if you waste enough resources, you can make a bad idea feasible. Was it daft to do so? Yes but do so they did anyway.

  • Dennis Jensen wrote:

    Lynn Pettis wrote:

    And now you can even use .NET COBOL. Cobol isn't dead.

    As I said it would not surprise me if they have continued to try and create a better dinosaur rather than leaving the dinosaur behind. Monty Python is not far from the mark when they said "Folks thought I was daft to build a castle in the swamp but I did it anyway. It sank. So I built a second one and it sank. So I built a third one, it burnt down, fell over, and sank. So a built a fourth and it is still standing."

    So in short if you waste enough resources, you can make a bad idea feasible. Was it daft to do so? Yes but do so they did anyway.

    So, how would you propose that most of the worlds largest financial institution's replace COBOL?  Or, for the matter, many vary large companies?

    Replace all the mainframes with servers?  Move to the cloud?  A move like that will cost more than most of these organizations make in a year.

    COBOL may not a fun language to write code in, but there is certainly a use for it, and it will not go away anytime soon.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Michael L John wrote:

    So, how would you propose that most of the worlds largest financial institution's replace COBOL?  Or, for the matter, many vary large companies?

    Replace all the mainframes with servers?  Move to the cloud?  A move like that will cost more than most of these organizations make in a year.

    COBOL may not a fun language to write code in, but there is certainly a use for it, and it will not go away anytime soon.

    Oh I am confident that eventually it will take care of itself by virtue of the basic principals of nature.  Survival of the fittest will eventually set in and these megalithic organizations that have built their companies upon prehistoric foundations will eventually be replaced by more agile and nimble future based companies. It just takes a long time for erosion to take down a mountain but it will and it does. Yes they will be able to shore up their ancient foundations for a while (like they are doing now as they are already experiencing that erosion) but eventually patching the dinosaur just will not be enough.

    As for there not being enough money, well heck if they quit wasting it on propping up the old and focused on slowly renovating it to the new. They would future proof themselves but that is not how most megalithic companies think (always short-term thinking versus long-term thinking) and I have seen several of these kinds of companies get completely washed away due to this megalithic thinking.

    In short, time will take them down and wash them away because they are and will continue to be just to slow to react to the changes that have already occurred and are coming unforseen just around the next bend in the curvy road of time.

  • I haven't worked with COBOL in over 20 years.  But I would rather deal with well written and structured COBOL than some of the garbage SQL, C, C#, VB, HTML, ....  (I haven't had to deal with any R or Python, but I'm sure others have ran into the same poorly written code)

    In your calling of COBOL as an out of date language that needs to removed.  I would ask your thoughts about the internal combustion engine?  This dinosaur has been around for longer than COBOL, but we still use it.  Sure modifications have been made to make the more efficient over the years, but it still the same technology.

    Should we ask everyone to stop using them and replace them with something else?  While that may be a nice dream, it isn't going to happen anytime soon.

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • I vaguely remember COBOL from early in my career. I didn't think much of it as a language then, even though I was working in C/C++/Pascal. Of course, I think SQL is a somewhat broken language as well.

    However, COBOL is in use and not likely to go away. If I were younger, I'd have been tempted to (re) learn is a decade ago as there were not many, but some very well-compensated jobs for maintaining old systems.

  • Steve Jones - SSC Editor wrote:

    I vaguely remember COBOL from early in my career. I didn't think much of it as a language then, even though I was working in C/C++/Pascal. Of course, I think SQL is a somewhat broken language as well.

    However, COBOL is in use and not likely to go away. If I were younger, I'd have been tempted to (re) learn is a decade ago as there were not many, but some very well-compensated jobs for maintaining old systems.

    There is a shortage of COBOL developers around here. The salaries being paid for experienced COBOL developers are astronomical.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

Viewing 15 posts - 66,331 through 66,345 (of 66,815 total)

You must be logged in to reply to this topic. Login to reply