Loading ...
Sorry, an error occurred while loading the content.

Re: Which programming language should I try to learn?

Expand Messages
  • Tom
    ... You are right about C and C++. Java has always been a language where the compiler managed the heap for you (see note below). Objective-C has evolved. In
    Message 1 of 7 , Jun 25, 2013
    • 0 Attachment
      --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@...> wrote:
      >
      > On 24 Jun 2013 at 12:00, Tom wrote:
      > >
      > > A major characteristic of genealogical software is the need to have
      > > persistence of objects in the programs. That is, you need to be able to create
      > > a software object to represent some genealogical concept (e.g., person,
      > > family) and you need that object to continue being alive within your program.
      > > It has to have a lifetime beyond the individual software modules that create
      > > them, or display them or compute with them. Objects like these are called heap
      > > objects, meaning they exist in a largish, originally unstructured area of
      > > computer memory. The heap is carved up into smaller units of memory, to hold
      > > your objects, as the program proceeds. Because of this you need to use a
      > > programming language that helps you manage the heap. The popular
      > > "object-oriented" languages provide you with the support you need. These
      > > languages are Java, Objective-C, C++ and C#. All four of them actually manage
      > > to hide almost all issues of heap use and heap management from you. Note that
      > > C is not on the list. C is not object-oriented, and C does has only a very
      > > simple interface to the heap. C can be used in an object-oriented manner by
      > > how you structure your code, and the heap interface of C (the malloc and free
      > > system calls) can be encapsulated in a higher layer abstraction in C, but
      > > using C in this manner is not for the beginner.
      >
      > The way I understood it is that C and C++ allow (require) the programmer to
      > manage memory, whereas in most of the others this is handled automatically by
      > the compiler.
      >
      > And isn't the kind of information you refer to as objects ultimately stird on
      > disk in a database, called from there and stored there again once it has been
      > interrogated or manipulated?

      You are right about C and C++. Java has always been a language where the compiler
      managed the heap for you (see note below). Objective-C has evolved. In Objective-C
      you used to manage the heap using reference counting that you did by making
      calls to retain, release and autorelease. The latest version of Objective-C has a feature
      called ARC (automatic reference counting) which essentially makes Objective-C
      equivalent to Java in terms of heap management. Basically the compiler inserts all
      the right heap management calls at the right places. I have shifted over to using ARC
      in all my development and it is wonderful.

      The proviso (the note below) is that programmers can still be stupid and the
      compilers can't help that. Heap management means creating new objects when
      needed and returning objects when no longer needed. Smart compilers are smart by
      figuring out when an object will never be referred to again and then getting rid of it
      automatically. The compiler does this by inserting code that keeps track of how many
      times a heap object is referred to. When this drops to zero the object is removed.
      But, programmers can (and often do) write code in which objects are still referred to but
      will never be used. A classic situation occurs when one object refers to another, and
      that other object refers back to the first object, but no other references to either
      object exists. Most compilers are not smart enough to recognize this case and the
      two objects persist for the life of the program, essentially as leaked memory. There
      are "garbage collection" algorithms that can find these leaks, but they are expensive
      to run and usually cause your programs to suddenly pause. Good monitoring tools
      used during development can find these problems for you.

      Tom
    • Tom
      ... Forgot to respond to the above. Yes, most objects of interest in a genealogical program will be stored in a database. Issues boil down to the format of the
      Message 2 of 7 , Jun 25, 2013
      • 0 Attachment
        > And isn't the kind of information you refer to as objects ultimately stird on
        > disk in a database, called from there and stored there again once it has been
        > interrogated or manipulated?

        Forgot to respond to the above. Yes, most objects of interest in a genealogical program
        will be stored in a database. Issues boil down to the format of the data in a persistent
        database versus the format of an object in a running computer program. When going
        in either direction a transformation must occur. In a relational database, the on-disk
        format are all in "tables" and there may be many tables involved in storing the information
        about a single person (the names will be in one table, the birth info in another, the source
        references
        in another, and so on and so on and so on). To bring a person into a program's memory
        so it can be computed with, database access code must be written to read all those
        tables and to construct an internal objects out of the information found in all those tables.

        In most non-sql databases, the objects are not stored in tables but in structures that
        can exactly mimic the structure that the objects should have when being processed
        in a program. Moving objects to and from one of these databases is trivial as no
        transformations are required. This is definitely the trend into the future.

        Tom
      Your message has been successfully submitted and would be delivered to recipients shortly.