Announcement

Collapse
No announcement yet.

Vulkan-Hpp Launches, Official C++ API For Vulkan

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

  • #21
    Originally posted by duby229 View Post
    Maybe I'm just older than you guys are and just remember more stuff.

    http://info.softwaretoolbox.com/opc-...nates-downtime
    This just shows an OPC interface FROM controllers (for example from robots) TO a linux machine running business code (COBOL) and databases. The controller shown is a controllogix which is the US equivalent of siemens and uses proprietary programming languages.

    Quote from this document: "The software was written in Pascal with some inline sections in assembler. The pseudocode was written in pseudo Cobol due to appreciation of Cobol's PERFORM command."
    So the actual code was Pascal an Assembler. That just uses pseudo (not even real) Cobol for pseudocode to show the algorithm.

    Again the important quote: "First generation languages worked in more or less in the same way as George Devol's invention. They accessed the robot at a very primitive level and were, therefore, suited to highly repeatable tasks. Most of them were based on existing programming languages that had been developed in the 1950s, such as COBOL, ALGOL or Fortran."

    First languages used were _BASED_ on old languages, but none of them _WAS_ cobol.

    This article talks about IBM PCs and briefly mentions this: "IBM itself is offering a robotics control language (AML, A Manufacturing Language)"
    So again the roboticts stuff is proprietary IBM stuff (AML). No mention of robots and cobol in the same sentence.

    Originally posted by duby229 View Post
    There's more, a lot more. Believe me there are still a whole shitload of IBM XT's still running ancient machines.
    IBM XT is a personal computer!? How's that relevant in the robotics context? Nobody denies that COBOL was heavily used in other areas, but robotics is not one of them.

    Comment


    • #22
      Originally posted by droste View Post

      This just shows an OPC interface FROM controllers (for example from robots) TO a linux machine running business code (COBOL) and databases. The controller shown is a controllogix which is the US equivalent of siemens and uses proprietary programming languages.

      Quote from this document: "The software was written in Pascal with some inline sections in assembler. The pseudocode was written in pseudo Cobol due to appreciation of Cobol's PERFORM command."
      So the actual code was Pascal an Assembler. That just uses pseudo (not even real) Cobol for pseudocode to show the algorithm.

      Again the important quote: "First generation languages worked in more or less in the same way as George Devol's invention. They accessed the robot at a very primitive level and were, therefore, suited to highly repeatable tasks. Most of them were based on existing programming languages that had been developed in the 1950s, such as COBOL, ALGOL or Fortran."

      First languages used were _BASED_ on old languages, but none of them _WAS_ cobol.

      This article talks about IBM PCs and briefly mentions this: "IBM itself is offering a robotics control language (AML, A Manufacturing Language)"
      So again the roboticts stuff is proprietary IBM stuff (AML). No mention of robots and cobol in the same sentence.

      IBM XT is a personal computer!? How's that relevant in the robotics context? Nobody denies that COBOL was heavily used in other areas, but robotics is not one of them.
      Almost every robotics I've ever seen personally was attached via a serial board to a PC. Robots are literally mechanical. Almost no robotics have the computational hardware integrated. I never claimed to be an expert, I simply responded to an obvious troll post.

      Comment


      • #23
        While it is true that especially the first robots were connected to standard pcs it's not true that they used the same environment as the rest of the pc world.
        Robotics was and is still a highly proprietary field. There are some movements to being more open and having standards, but this is a real problem. There's a lot of vendor lock in etc.

        "I simply responded to an obvious troll post." <-- Don't do that

        And btw. banking is the sector with a too high usage of cobol with too few people actually knowing cobol anymore: http://www.bankingtech.com/375941/cobol-bank-it/

        Comment


        • #24
          Originally posted by gufide View Post
          I've look into the header. It's pretty well thought. They carefully made it to not induce any overhead. The only thing someone could complain about it is that they didn't use the raii idom, so you still have to clean memory yourself. But again, it's so easy to add a raii wrapper that it's not a big deal.
          They should use the RAII idiom and thus fix such an outstanding deficiency!

          Comment


          • #25
            Who cares about COBOL ? It should have died years ago !!

            P.S. The company I'm working with still use COBOL :P

            Comment


            • #26
              Originally posted by plonoma View Post

              They should use the RAII idiom and thus fix such an outstanding deficiency!
              I'm certain that was done on purpose. A lot of the applications that will want to use this will have a custom memory management scheme they'll want to plugin and use.

              Comment


              • #27
                Originally posted by duby229 View Post
                Almost no robotics have the computational hardware integrated.
                Another great troll post.

                Comment


                • #28
                  Originally posted by droste View Post
                  "I simply responded to an obvious troll post." <-- Don't do that
                  He meant that my post wasn't enough troll and he wanted to fix that.

                  Comment


                  • #29
                    Originally posted by smitty3268 View Post

                    I'm certain that was done on purpose. A lot of the applications that will want to use this will have a custom memory management scheme they'll want to plugin and use.
                    Good point, but the design should be as RAII friendly as possible and practical for those who do use RAII idioms.

                    Comment


                    • #30
                      Originally posted by plonoma View Post

                      Good point, but the design should be as RAII friendly as possible and practical for those who do use RAII idioms.
                      Not sure how to do that without introducing a lot of black template magic related to destructors and/or liberation functions. And even that would not be as efficient as explicit resource cleanup.

                      RAII in vulkan sounds pretty strange - considering that one of the point of the vulkan API is to give you back the power to handle memory as you want to handle it. If you want RAII in your vulkan game/app, you'll have to add it by yourself - in your code. Which is good because you control all resources in your code too

                      Comment

                      Working...
                      X