Are the posted questions getting worse?

  • Okay if I understood your last post I will say -- (1) I do not make sarcastic comments without including an 😉 to let you know I am not being serious.

    Again if it helps (without looking back), perhaps I did shift gears a bit and yes I was not saying that SQL was a dynotopic langugage at any point in time -- in fact the only language I was referring to as dynotopic prehistoric was COBOL.  I hope that clarifies things for you and puts us on the same page going forward.

  • Dennis Jensen wrote:

    Well, Phil Parkin just because a word does not currently exist within any known dictionary does not mean it is not a viable word. In fact, Shakespeare is credited with creating 1700 words and there are many others that created words of their own that later found their way into the official dictionaries. The question is did you understand at least kind of what I was saying (in context) with that non-official word? If yes, then it served its purpose.

    Thinking outside the box is part of the reason I can solve problems fairly quickly as I use approaches that are not always predefined.

    I was simply pointing out that the word does not exist. If Shakespeare were writing in a technical IT forum, I suspect he'd stick to known terms, to ensure he got his point over succinctly. He'd save his more flowery prose for plays and sonnets.

    The absence of evidence is not evidence of absence.
    Martin Rees

    You can lead a horse to water, but a pencil must be lead.
    Stan Laurel

  • Dennis Jensen wrote:

    Thinking outside the box is part of the reason I can solve problems fairly quickly as I use approaches that are not always predefined.

    Thinking inside rectangles is how I solve problems.  The first table in the FROM clause forms the initial state of the rectangle.  If the table has many rows the skinny part of the rectangle is side-to-side.  If there's only 1 row then the rectangle is turned 90 degrees.  If there's computation for which the output is repeatedly referenced, then CROSS APPLY can extend the rectangle to the right (and downward (and upward) too if there's row expansion/(-) within CROSS APPLY).  Each additional element of the FROM clause adds or subtracts (downward (or upward) and/or to the right) to the rectangle as necessary.  There's always a final rectangle which fits or else there wouldn't be a problem 🙂

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • additional JOIN's and CROSS APPLY's apply to the rectangle defined immediately above it (in order of appearance) within the FROM clause

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • Dennis Jensen wrote:

    Okay if I understood your last post I will say -- (1) I do not make sarcastic comments without including an 😉 to let you know I am not being serious.

    Again if it helps (without looking back), perhaps I did shift gears a bit and yes I was not saying that SQL was a dynotopic langugage at any point in time -- in fact the only language I was referring to as dynotopic was COBOL.  I hope that clarifies things for you and puts us on the same page going forward.

    Fair enough.  be advised that it sounded like you were blasting SQL and be advised that it sounded like you were using your COBOL example to reinforce that.

    --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)

  • Phil Parkin wrote:

    Dennis Jensen wrote:

    Well, Phil Parkin just because a word does not currently exist within any known dictionary does not mean it is not a viable word. In fact, Shakespeare is credited with creating 1700 words and there are many others that created words of their own that later found their way into the official dictionaries. The question is did you understand at least kind of what I was saying (in context) with that non-official word? If yes, then it served its purpose.

    Thinking outside the box is part of the reason I can solve problems fairly quickly as I use approaches that are not always predefined.

    I was simply pointing out that the word does not exist. If Shakespeare were writing in a technical IT forum, I suspect he'd stick to known terms, to ensure he got his point over succinctly. He'd save his more flowery prose for plays and sonnets.

    To me dynotopic would mean a focus on powerful or forceful discussions, ideas, or areas of interest.

    The prefix "dyna-" is derived from the Greek word "dýnamis," meaning power or force, often associated with dynamics or energy, for example a dynamometer or "dyno" for short is something that measures torque or RPM of engines. The term "topic" typically refers to a subject or theme of discussion.

  • Okay fair enough and thanks Johnathan AC Roberts that explains dissecting the single word all by itself -- but then I did use a caveat it by saying "within context". So are you saying that you would interpret dynotopic within the context of how it was being used to mean "powerful theme"? I would find that odd. However, since some seem to being having so much trouble with that word -- I went back and editted for you all.

  • Jeff Moden wrote:

    Fair enough.  be advised that it sounded like you were blasting SQL and be advised that it sounded like you were using your COBOL example to reinforce that.

    Okay also fair enough, so I went back and made that clear by adding (aka T-SQL in this case) after mentioning the futuristic hover car. Basically, stating the T-SQL is the futuristic hover car in this case. I hope that resolves that issue.

    Nice Steve Collins that you limit yourself to only working within a box 😉 and while I am assuming you are being verbosely sarcastic I will point out the following in case you were not aware:

    Originally, the box was a reference to the nine-dot problem. The goal of this classic puzzle is simple; Connect all the dots in a 9-dot (3 x 3) array using no more than four straight lines and without lifting your pen or pencil from the page. To solve the puzzle, one must let go of the assumption that the lines must be drawn within the boundaries of the dots which can be viewed as a square or a box. Thus to solve this puzzle one must think outside the box.

    In a figurative sense, the "box" is a metaphor for an unnecessary assumptions, constraints, or precedents which limit creative problem-solving. Like a literal box, an inflexible representation is restrictive and confining. To overcome this impasse to creative problem solving, it may help to change perspectives, question rules (or assumptions), and try different approaches. In other words, "think outside the box."

    Thus your statement seems to say that you only think in very restrictive and confined ways that will neatly fit within your limited box which happens to be rectangular in shape but a static box none-the-less. However, I am going to guess that was not your intention.

  • 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 1 year, 6 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.

Viewing 15 posts - 66,346 through 66,360 (of 66,738 total)

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