• 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!

VB6 - Cobol of the future?

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

    #51
    Originally posted by xoggoth View Post
    What a gloriously GEEKY comment atW!. I really must rewrite my apps to make them more complex! The product requires colourful stuff for kids. Much of it is to do with rendering images and there were several things in that area that one had to avoid in VB6.
    You need to switch to using DirectDraw in your apps - this way it should be pretty fast.

    Comment


      #52
      Originally posted by VectraMan View Post
      No offence, but the argument seems to be "I didn't write very good C++ code, therefore C# is better".
      I don't think I wrote very good C++ and I only started writing pretty good C# recently, however the point here is that I saved a lot of time by using C# rather than C++ and got 95% of performance: these days the art is to do things in parallel to use multiple cores (8 in my primary server), I don't think there is even standard threading mechanism in C++.

      As far as I am concerned C++ is a legacy and low OS level language, plus games a rewritten in it - it will stay, but 90% of new stuff won't be in C++: .NET or Java, or for web some Ruby or PHP.

      Comment


        #53
        VB6 - Cobol of the future?

        Insult to COBOL. It's still going strong, because it is fit for purpose.

        Comment


          #54
          Originally posted by expat View Post
          Insult to COBOL. It's still going strong, because it is fit for purpose.
          COBOL.NET

          It's the future, I tell you.

          Comment


            #55
            Originally posted by AtW View Post
            I don't think there is even standard threading mechanism in C++.
            Why on earth should a language have a standard threading mechanism?

            As far as I am concerned C++ is a legacy and low OS level language, plus games a rewritten in it - it will stay, but 90% of new stuff won't be in C++: .NET or Java, or for web some Ruby or PHP.
            Surely the issue here is desktop vs. server app. I've never seen any .NET desktop apps, and everybody here has been saying WinForms is crap. Correct me if I'm wrong but .NET is 99% used on the server end spitting out HTML, whereas things actually run on the desktop are more than likely C++ . I doubt that will change.
            Will work inside IR35. Or for food.

            Comment


              #56
              Originally posted by VectraMan View Post
              Why on earth should a language have a standard threading mechanism?
              Why to have standards at all? Why not have different size of int and long on different systems, it is soooooooo fun to use sizeof() all the time, genious invention of Kernigan and Ritchie! For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.


              Surely the issue here is desktop vs. server app. I've never seen any .NET desktop apps, and everybody here has been saying WinForms is carp. Correct me if I'm wrong but .NET is 99% used on the server end spitting out HTML, whereas things actually run on the desktop are more than likely C++ . I doubt that will change.
              WinForms is crap indeed - performance wise. You can still do the job though, just they could have made it better.

              I am mainly developing tools now that have either web front end or just console based stuff that runs for a long time to prepare output (index) that is useful by front end.

              If C++ is used mainly on desktop then I think it's future is going down because a lot of stuff is moved to the web GUI. C++ is just not the RAD language that one can use, I hated spending time debugging C++ app and I still hate sometimes doing it in C#, but I sure as hell debug less weird issues in C# than I was in C++. Sure I was not great in C++, but most people are not great with it.

              Comment


                #57
                Originally posted by AtW View Post
                For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.
                They're also trying to add garbage collection - although I believe that in the first iteration they only plan to add/remove some facilitating features of C++ without mandating a standard GC implementation.

                Comment


                  #58
                  Originally posted by bored View Post
                  They're also trying to add garbage collection
                  I think they will probably fail with this one - doubt C++ type would accept garbage collection as a concept.

                  It seems to work okayish in .NET, but it is a complete bull that there can't be any leaks with garbage collection - there sure can. Also in heavy multithreading situation garbage collector will stop all threads when cleaning up, there is a setting for multithreaded garbage collection but I found it is buggy in .NET 2.0, so I don't use it - had to rewrite part of SKA to heavily reuse memory - suddenly usage of each core increased considerably as GC had less work to do

                  Comment


                    #59
                    Originally posted by Churchill View Post
                    COBOL.NET

                    It's the future, I tell you.
                    No.

                    COBOL is fit for purpose because it is reliable in the extreme. It doesn't make your algorithms easy, but it does protect your data.

                    It was invented before there was a Microsoft.

                    Hmm.

                    Comment


                      #60
                      Originally posted by AtW View Post
                      For your information C++ governing body is urgently trying to add standard threading mechanism to it, because we have entered parallel execution code that needs programmer to do the job - having threads is essential for it.
                      What I mean is that I call CreateThread() if I want a thread (which I think is what you do in C#). That's an API call; not sure why anybody thinks functions of the API should be part of the language.

                      Re: garbage collection: you could implement it in C++ easily enough, but you'd be using your own customized operator new/delete and a custom ptr container class everywhere. You couldn't just do it automatically for everything without changing the code, like you could if it was built into the compiler.

                      Which is the point: In C++ you get full control, which is why it's always going to be the best platform where you need full control. Java and C# makes you use this stuff, and although I'll admit that 99% of the time it isn't an issue, as ATW says sometimes the garbage collection gets in the way. I hope they don't try to put it into C++.
                      Will work inside IR35. Or for food.

                      Comment

                      Working...
                      X