4 ms·

Python takes care of the records pretty well with named tuples (and since it's dynamically typed, not knowing the fields until runtime is expected). It doesn't

by ptx 7y ago

Python takes care of the records pretty well with named tuples (and since it's dynamically typed, not knowing the fields until runtime is expected). It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL?

skissane 7y ago
> It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL? COBOL has built-in support for accessing flat file databases with either sequential or indexed organisation. On many mainframe and minicomputer operating systems, the filesystem provides native support for record-oriented files (with fixed or variable width records) and indexed-key files, and COBOL directly integrates with that. COBOL has syntax for defining nested record structures which was often used to define the data schema for these files. You could store the definitions in a "copybook" (conceptually equivalent to an include file in C/C++) and reuse it in many programs which would manipulate the same files. COBOL itself doesn't directly support "querying", except for the strategies of (1) manually iterating through every record in a sequential file to find matching records or (2) looking up a key-indexed file by its key field. There are commonly implemented extensions to COBOL to access relational databases (SQL), hierarchical databases (e.g. IMS), etc. However, those are not part of the core COBOL language, and comparable facilities are defined for many other languages, so COBOL isn't really unique on that point.
- ptx 7y ago
  Thanks. It doesn't seem to me that having built-in syntax for this is necessarily a big advantage, since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Even Java can do this with Hibernate.
  - skissane 7y ago
    > since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html Python doesn't support accessing mainframe key-indexed files. There is a port of Python to z/OS [1], but the dbm module can't read/write VSAM KSDS files, and I don't believe there exists any other Python module that can either. (Of course, someone could write a Python C extension using the VSAM C interface, or create a module which calls it using ctypes–z/OS adds some functions to stdio like flocate,fupdate,fdelrec for VSAM access–but I don't think anyone has done that so far.) Now of course, if you are porting your app to another platform, this will not be an issue, but if your data is staying on the mainframe, Python doesn't know how to handle it, COBOL does. > If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Mainframe systems tend to use file formats based on plain text records where fields are assigned to fixed ranges of columns. Is there a Python module to do that? Especially in a declarative way, which is what COBOL provides. [1] https://www.rocketsoftware.com/product-categories/mainframe/python-for-zos https://www.rocketsoftware.com/product-categories/mainframe/...
    - ptx 7y ago
      Sorry, I think I was a bit unclear. By "such databases" I meant to refer to your "flat file databases with either sequential or indexed organisation" in general, not the specific format used on mainframes. My question was about the advantages of Cobol's built-in syntax for database access and it seems like, as you said, you could write a Python module for the mainframe database format if desired, and there would then be no particular advantage to Cobol's special syntax. Edit: The J2ME environments used on phones 15 years ago also provided a database (Record Management System) which would be difficult to access from a language other than Java, but that's unrelated to the question of whether the "programming language itself has no clue about database layout".
      - skissane 7y ago
        I don't believe COBOL has any absolute advantage over Python. It can have a relative advantage in certain environments, especially in mainframe environments. In mainframe environments, COBOL has pre-existing interfaces to various operating system and middleware facilities used on mainframes, whereas for Python you'd have to build those interfaces yourself. In terms of data structures, imagine you are working in an environment in which you have hundreds of pre-existing data files defined by COBOL copybooks, which look like the example on this page: https://www.ibm.com/support/knowledgecenter/en/SSMQ4D_3.0.0/documentation/cobol_rcg_examplecopybook.html https://www.ibm.com/support/knowledgecenter/en/SSMQ4D_3.0.0/... Now, in COBOL, you just include that in your program and then you can parse the file. In Java, well Java has no built-in support for that, but IBM has a product called IBM Record Generator for Java which uses COBOL copybooks to generate Java classes. I'm sure someone could write an equivalent tool for Python. But as far as I am aware, no one has, and it would be a non-trivial amount of work to do. > but that's unrelated to the question of whether the "programming language itself has no clue about database layout". Well, that wasn't my statement, that was Animats'. Possibly what Animats was trying to say, is that in a classic COBOL environment, the language you use to define your database schema is built-in to your programming language, and uses the same syntax as you use to define in-memory data structures. That usually isn't true in other programming languages, including Python and Java, in many of their common usage patterns. In Java for example, you could store all your data using serialization, and then it would be much closer to how COBOL does it, but you normally don't do that. Or you use some kind of ORM framework like Hibernate, but then you end up with all these annotations which don't mean anything for in-memory data – or, in older versions of Hibernate, an XML file – which is further away from the classic COBOL model that describing in-memory data and on-disk/tape data is done identically. However, not all COBOL code is "classic COBOL code" in that sense. Rather than storing data in files, many COBOL programs use a relational database, most commonly via the SQL precompiler (EXEC SQL). In that case, COBOL is basically no different than any of the other languages which support embedded SQL – the SQL standard defines embedded SQL support for Ada, C, COBOL, FORTRAN, MUMPS, Pascal, and PL/I (I know in the past Oracle RDBMS supported every one of those languages except for MUMPS, although in newer versions many of the precompilers have been discontinued due to lack of use.) Embedded SQL also exists for Java (SQLJ), although I've never seen anyone use that technology, almost everybody uses JDBC instead. I don't believe Embedded SQL is available for Python, but again, there is no reason why someone couldn't implement that if they wanted.
jquast 7y ago
Since python 3.7, dataclass is probably preferred over namedtuple, which is typed, https://realpython.com/python-data-classes/ https://realpython.com/python-data-classes/
- faizshah 7y ago
  Dataclass is not immutable, for some cases typing.namedtuple should be preferred over dataclass if typing is needed. Deep dive here: https://stackoverflow.com/questions/51671699/data-classes-vs-typing-namedtuple-primary-use-cases https://stackoverflow.com/questions/51671699/data-classes-vs...
  - tasubotadas 7y ago
    That's not really true - you can set frozen=True and you will get an immutable version of the class.
- EamonnMR 7y ago
  We've had great results with Pydantic models. https://pydantic-docs.helpmanual.io/ https://pydantic-docs.helpmanual.io/

by ptx 7y ago

skissane 7y ago

> It doesn't have anything for the query part through, like C# does with LINQ - are you saying that COCOL does? What does this knowledge of database layout look like in COBOL? COBOL has built-in support for accessing flat file databases with either sequential or indexed organisation. On many mainframe and minicomputer operating systems, the filesystem provides native support for record-oriented files (with fixed or variable width records) and indexed-key files, and COBOL directly integrates with that. COBOL has syntax for defining nested record structures which was often used to define the data schema for these files. You could store the definitions in a "copybook" (conceptually equivalent to an include file in C/C++) and reuse it in many programs which would manipulate the same files. COBOL itself doesn't directly support "querying", except for the strategies of (1) manually iterating through every record in a sequential file to find matching records or (2) looking up a key-indexed file by its key field. There are commonly implemented extensions to COBOL to access relational databases (SQL), hierarchical databases (e.g. IMS), etc. However, those are not part of the core COBOL language, and comparable facilities are defined for many other languages, so COBOL isn't really unique on that point.

ptx 7y ago
Thanks. It doesn't seem to me that having built-in syntax for this is necessarily a big advantage, since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Even Java can do this with Hibernate.
- skissane 7y ago
  > since Python can easily and naturally work with such databases using the built-in dbm module in the standard library (and has no need for defining the schema up front): https://docs.python.org/3/library/dbm.html https://docs.python.org/3/library/dbm.html Python doesn't support accessing mainframe key-indexed files. There is a port of Python to z/OS [1], but the dbm module can't read/write VSAM KSDS files, and I don't believe there exists any other Python module that can either. (Of course, someone could write a Python C extension using the VSAM C interface, or create a module which calls it using ctypes–z/OS adds some functions to stdio like flocate,fupdate,fdelrec for VSAM access–but I don't think anyone has done that so far.) Now of course, if you are porting your app to another platform, this will not be an issue, but if your data is staying on the mainframe, Python doesn't know how to handle it, COBOL does. > If you do need to define the database schema in code, there are many third-party libraries that allow you to do this cleanly using classes and fields, e.g. Django. Mainframe systems tend to use file formats based on plain text records where fields are assigned to fixed ranges of columns. Is there a Python module to do that? Especially in a declarative way, which is what COBOL provides. [1] https://www.rocketsoftware.com/product-categories/mainframe/python-for-zos https://www.rocketsoftware.com/product-categories/mainframe/...
  - ptx 7y ago
    Sorry, I think I was a bit unclear. By "such databases" I meant to refer to your "flat file databases with either sequential or indexed organisation" in general, not the specific format used on mainframes. My question was about the advantages of Cobol's built-in syntax for database access and it seems like, as you said, you could write a Python module for the mainframe database format if desired, and there would then be no particular advantage to Cobol's special syntax. Edit: The J2ME environments used on phones 15 years ago also provided a database (Record Management System) which would be difficult to access from a language other than Java, but that's unrelated to the question of whether the "programming language itself has no clue about database layout".
    - skissane 7y ago
      I don't believe COBOL has any absolute advantage over Python. It can have a relative advantage in certain environments, especially in mainframe environments. In mainframe environments, COBOL has pre-existing interfaces to various operating system and middleware facilities used on mainframes, whereas for Python you'd have to build those interfaces yourself. In terms of data structures, imagine you are working in an environment in which you have hundreds of pre-existing data files defined by COBOL copybooks, which look like the example on this page: https://www.ibm.com/support/knowledgecenter/en/SSMQ4D_3.0.0/documentation/cobol_rcg_examplecopybook.html https://www.ibm.com/support/knowledgecenter/en/SSMQ4D_3.0.0/... Now, in COBOL, you just include that in your program and then you can parse the file. In Java, well Java has no built-in support for that, but IBM has a product called IBM Record Generator for Java which uses COBOL copybooks to generate Java classes. I'm sure someone could write an equivalent tool for Python. But as far as I am aware, no one has, and it would be a non-trivial amount of work to do. > but that's unrelated to the question of whether the "programming language itself has no clue about database layout". Well, that wasn't my statement, that was Animats'. Possibly what Animats was trying to say, is that in a classic COBOL environment, the language you use to define your database schema is built-in to your programming language, and uses the same syntax as you use to define in-memory data structures. That usually isn't true in other programming languages, including Python and Java, in many of their common usage patterns. In Java for example, you could store all your data using serialization, and then it would be much closer to how COBOL does it, but you normally don't do that. Or you use some kind of ORM framework like Hibernate, but then you end up with all these annotations which don't mean anything for in-memory data – or, in older versions of Hibernate, an XML file – which is further away from the classic COBOL model that describing in-memory data and on-disk/tape data is done identically. However, not all COBOL code is "classic COBOL code" in that sense. Rather than storing data in files, many COBOL programs use a relational database, most commonly via the SQL precompiler (EXEC SQL). In that case, COBOL is basically no different than any of the other languages which support embedded SQL – the SQL standard defines embedded SQL support for Ada, C, COBOL, FORTRAN, MUMPS, Pascal, and PL/I (I know in the past Oracle RDBMS supported every one of those languages except for MUMPS, although in newer versions many of the precompilers have been discontinued due to lack of use.) Embedded SQL also exists for Java (SQLJ), although I've never seen anyone use that technology, almost everybody uses JDBC instead. I don't believe Embedded SQL is available for Python, but again, there is no reason why someone couldn't implement that if they wanted.

jquast 7y ago

Since python 3.7, dataclass is probably preferred over namedtuple, which is typed, https://realpython.com/python-data-classes/ https://realpython.com/python-data-classes/

faizshah 7y ago
Dataclass is not immutable, for some cases typing.namedtuple should be preferred over dataclass if typing is needed. Deep dive here: https://stackoverflow.com/questions/51671699/data-classes-vs-typing-namedtuple-primary-use-cases https://stackoverflow.com/questions/51671699/data-classes-vs...
- tasubotadas 7y ago
  That's not really true - you can set frozen=True and you will get an immutable version of the class.
EamonnMR 7y ago
We've had great results with Pydantic models. https://pydantic-docs.helpmanual.io/ https://pydantic-docs.helpmanual.io/