• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Coding... where to start???

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #41
    ITIL = New money for old rope. Rope that is covered in crap.

    Comment


      #42
      Originally posted by mailric View Post
      Xml?
      XML is not a programming language per se. Sure I claim to be an XML specialist and you can process and transform it with XSL or Perl or govern the structure with DTDs/Schemas/NVDLs/XDefinitions etc but there's very little to know about the XML itself.

      Besides it is a bad idea as, despite the fact XML is used as an interchange format in many if not most recently coded apps, companies and recruiters are mostly looking for language specific skills, such as Java or C#.

      Comment


        #43
        Originally posted by expat View Post
        Nothing wrong with GOTO except that it doesn't fit some people's structuring systems, and it does offer one more way to write bad code: but that's hard to stop anyway.

        Dijkstra proved that you don't need GOTOs, but it is arguable whether he proved that you shouldn't use them. For example, he also said that a procedure must have only one exit point: I say if you know you're done, GOTO that exit point. Any other way is harder to read, not easier.
        Going back many years now, I have used languages where GOTO was the only construct available and spaghetti code was inevitable. I still occasionally use GOTO for scripting languages where I judge that it makes the code readable, for example in a tight read/write loop. The problem when I moved to COBOL and had to abide by "Though shalt not use GOTO" programming standards was that you ended up setting flags everywhere and having to test them later. It could sometimes be extremely difficult to track down where a flag was getting set or corrupted and that could be a nightmare (and that ain't counting compiler bugs).

        Here's a swift example:

        Code:
        main-loop.
             read input-file at end go to main-exit.
        * a bit of record manipulation here, but not much
             write output-file.
             go to main-loop.
        main-exit.
             close input-file.
             close output-file.
        Obviously you don't want those GOTOs wrapped around a gazillion lines of code; the aim is to have something readable.

        Originally posted by expat View Post
        The real crime is COBOL's ALTER: shot at dawn for using that (but opinions may differ). For those who don't know, that was a command that, when executed, reprogrammed an existing GOTO elsewhere in the code, so that it now goes to somewhere else, not where it says it does.
        I once worked with a guy who had used ALTER to ensure that initialisation code was only executed once, but he was programming for performance rather than maintainability. For less time critical programs we avoided it like the plague.
        Behold the warranty -- the bold print giveth and the fine print taketh away.

        Comment


          #44
          The whole "GOTO considered harmful" business got out of hand a long time ago (although it's now thankfully irrelevant in most languages). So many people are too literal in their interpretation of prescriptive statements of this kind, and completely miss the point.

          Dijkstra was saying that GOTO was harmful because it was frequently used to create unstructured code: spaghetti code can only be created if the language supports random jumping about from place to place. Of course it was, and is, possible to write well-structured code in a language that forces one to rely on GOTO for transfer of control; the point Dijkstra was making was that people relied on GOTO as a way of avoiding the arduous task of actually thinking about how to properly structure their code, instead simply hacking together an unholy mess of disorganised functionality and thinking that they were successful when the most egregious bugs no longer manifested themselves very much.

          It's a bit like the "<table> considered harmful" business in HTML. As a rabid standardista, I am firmly of the belief that using <table> and associated elements for the purposes of controlling the purely visual layout of a web page is epic fail. However the <table> element and its associates do actually have a valid reason for being: to represent the structure of tabular data. Yet even now one occasionally comes across somebody on a mailing list who has some clearly tabular data - say, a five-day weather forecast, or a set of test results - who goes all round the houses trying to find a way of representing it all using <div>s and a bunch of CSS, because they read somewhere that "tables are bad and kill kittens". The irony is that they actually decrease the semantic value of their markup by not using tables as needed.

          Similarly, in languages that are moderately deficient in control structures, GOTO can be used appropriately to better express the intention of the code.

          The fundamental point is that it's not the word/tag/construct that's "harmful", it's how you use it - as Susan Norkin could tell the author of the naughty words filter here on CUK

          Comment


            #45
            Originally posted by Sysman View Post
            ...The problem when I moved to COBOL and had to abide by "Though shalt not use GOTO" programming standards was that you ended up setting flags everywhere and having to test them later. It could sometimes be extremely difficult to track down where a flag was getting set or corrupted and that could be a nightmare (and that ain't counting compiler bugs).

            Here's a swift example:

            Code:
            main-loop.
                 read input-file at end go to main-exit.
            * a bit of record manipulation here, but not much
                 write output-file.
                 go to main-loop.
            main-exit.
                 close input-file.
                 close output-file.
            Obviously you don't want those GOTOs wrapped around a gazillion lines of code; the aim is to have something readable.
            You're supposed to use PERFORMs, not convert spaghetti code into straight-line code.

            Code:
            main-program.
                   perform main-loop thru end-main-loop
                       until 88-input-file-end.
                   close input-file.
                   close output-file.
                   stop run.
            main-loop.
                   perform sub-read-input thru end-sub-read-input.
                   if not 88-input-file-end
                   then
                  * a bit of record manipulation here, but not much
                   write output-file.
            end-main-loop.
                   exit.
            sub-read-input
                   read input-file at end move 'x' to 77-input-file-end.
            end-sub-read-input.
                   exit.
            with appropriate 77/88 levels and of course the obligatory
            Code:
            PROGRAM_ID. EXPAT01.
            that strikes fear into the hearts of the IT departments of 3 continents.
            Last edited by expat; 3 February 2009, 09:18.

            Comment


              #46
              I was slightly nervous typing in my first lines of more-or-less COBOL code for many years, but it was like riding a bike

              So I went off and looked at my website hits for Jan 2009:
              #reqs search term
              ...
              5509 cobol
              ...
              4005 pl/sql

              Hmm, don't think I'll depend on pl/sql for work after all.

              Comment

              Working...
              X