Future reuse of code

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Peter E.C. Dashwood

    Re: Future reuse of code


    "Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
    news:3F39F703.5 9068DA0@gascad. at...[color=blue]
    >
    >
    > "Peter E.C. Dashwood" wrote:[color=green]
    > >
    > > To answer your very fair question (... and replaced by what?), I believe
    > > that new methodologies for system development will arise in response to[/color][/color]
    the[color=blue][color=green]
    > > pressure from the Marketplace. I have already seen interesting[/color][/color]
    departures[color=blue][color=green]
    > > from traditional methods that achieved much faster results and were much
    > > more flexible. The key to these approaches is a more RAD like process[/color][/color]
    with[color=blue][color=green]
    > > iteration and interaction by users. Currently, we have programmers and
    > > "Quick Build" tools in the loop, but it is only a matter of time before
    > > smarter software will take on these functions. Eventually, end-users[/color][/color]
    will[color=blue][color=green]
    > > interact with smart software to achieve what they want, and there will[/color][/color]
    be no[color=blue][color=green]
    > > programmer in the loop at all.
    > >
    > > There is far too much on this to go into here (sorry, I know that sounds
    > > like a cop out, but I have been writing on this subject for some years[/color][/color]
    now[color=blue][color=green]
    > > and have been using alternative approaches in the real world in industry
    > > with results that are very encouraging.), but I will close by saying[/color][/color]
    that[color=blue][color=green]
    > > everything I am saying is simply extrapolation from what is happening[/color][/color]
    NOW. I[color=blue][color=green]
    > > claim no psychic powers, just good observation and a lifetime of[/color][/color]
    experience[color=blue][color=green]
    > > in IT.[/color]
    >
    > Do you have some links on that subject?[/color]

    Here are just two articles which give some insight into the technology which
    I believe will enable the Future I have been describing:

    https://www.aboutlegacycoding.com/Ar.../V3/V30501.asp (This is about what's wrong
    with what we do now, in terms of development methodology...I t was the
    attempt to break out of this way of working which suggested to me how things
    might work in the future.)

    https://www.aboutlegacycoding.com/Ar.../V3/V30201.asp (This is about the
    direction I see programming technology going in. The emerging component
    based systems will provide the basis for the User interaction I have been
    postulating. Components are platform independent, small, with encapsulated
    functionality and consistent and robust interfaces. These attributes are
    just what is needed to respond to rapid change and provide flexibility.)

    I'm sorry, these are links to just two of the articles I have written which
    are pertinent. I don't normally promote my own work, but you did ask for
    some links and these will at least give you an idea of where I'm coming
    from.

    [color=blue]
    > I am personally interested in that subject. As you say: the old,[/color]
    traditional[color=blue]
    > textual representations of procedural programming is something which[/color]
    requires[color=blue]
    > skills, skills we cannot expect from ordinary users. I have thought about
    > some sort of graphical programming. The problem seems to be: It is[/color]
    relatively[color=blue]
    > easy to come up with such a thing for a specific topic (eg. image[/color]
    manipulation),[color=blue]
    > but as I see it, it is hard to generalize this to general programming.
    >[/color]
    Yes, that's right. There are models where we can achieve a general result if
    we use a Human in the loop. (Basically, the Human is providing the
    intelligence and discernment to decide whether a given proposed result is
    acceptable or not.) By the key processes of ITERATION and INTERACTION, a
    better and better solution can be arrived at. (If you like, the solution is
    "evolved" towards...this varies markedly from the "traditiona l" IT approach
    where the solution is "designed" from scratch, then built.)

    Consider this...

    Small Businessman goes to the "computer shop" and purchases a "small
    business computer".

    (Let's assume he is a very competent Businessman and knows his trade
    extremely well, but he isn't big on computer technology, apart from the
    basic "computer literacy" that children are growing up with today...).

    He gets home, unpacks the computer, uses an interactive DVD (or similar) to
    connect everything up, and switches on.

    B'man: "Print me an invoice."
    Computer: "What's an invoice?".
    (This is a contrived example because the machine would certainly "know" what
    an invoice is...but bear with me a little longer...)
    B'man: "An invoice is a document that records the details of a sale
    transaction."
    Computer: "Ah, I know about Sales. That is a transaction where a CUSTOMER
    purchases a PRODUCT."
    (The machine comes equipped with the "concept" of a CUSTOMER and a PRODUCT,
    among others. It also recognises the transactions we would expect to be
    associated with a small business.)
    Computer: "So you will want details of the CUSTOMER and the PRODUCT on
    this INVOICE?"
    B'Man: "Yes."
    Computer: "Like this...?"
    (It produces a document...)
    B'Man: "Yes, but I need to see how many and what the unit price was.
    Then calculate the total and add Sales Tax."
    Computer: "How's this...?"
    B'Man: "That's right. Put the totals for each product in a separate
    column. And move the name and address details to here." (He indicates on the
    screen with his finger or a pointing device.) "Print the overall total
    payable in blue."
    Computer: "Like this..?"
    B'Man: "Yes, exactly like that."

    There are some assumptions in the above whimsy (the computer has certain
    inbuilt "concepts" - [you could think of this as a set of components with
    all the attributes and Methods of a CUSTOMER, for instance], a natural
    language interface, a "test" database for each of its concepts, however, all
    of these things are possible with today's technology, and what is currently
    "bleeding edge" will be passe in 15 years...), but I don't think anyone with
    a programming background would say it was "impossible " or "infeasible ".

    Of course this demonstrates a solution to just one class of problem. There
    are many others. But there are many other solutions also...

    The bottom line is that "general" solutions ARE obtainable (note that in the
    example above, we never know what particular "business" our "Businessma n" is
    in...the solution works for ALL small businesses, or can be "tailored"
    easily to accommodate exceptions to the "norm".)

    The keys to success in this are Interaction and Iteration. The Human
    provides the "intelligence". (It is really "discernment".. .)

    But a time will come when the software will be capable of evaluating its own
    results, matching them against stated requirements, rebuilding an entire
    system in seconds to ensure that what is required is delivered. (Then doing
    it all again, without complaint, when the User changes his mind <G>).

    "Evolved" systems show every indication of being at least as good as
    designed ones.

    And they don't require computer skills on the part of the User.

    Pete.


    Comment

    • Peter E.C. Dashwood

      Re: Future reuse of code


      <docdwarf@panix .com> wrote in message news:bhdhsl$a60 $1@panix1.panix .com...[color=blue]
      > In article <3f3a398d_5@new s.athenanews.co m>,
      > Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:
      >
      > [snip]
      >[color=green]
      > >(The fundamental goal of commercial computing has been to have computers
      > >that are capable of "understand ing" Business needs and meeting them, in a
      > >manner that would enable a Business User (or Users) to identify and[/color][/color]
      design[color=blue][color=green]
      > >the system and "explain" what is needed to the computer, in as simple a
      > >manner as possible, without need for in depth technical skills.[/color]
      >
      > This, to me, screams for the implementation for the DWIM (Do What I Mean)
      > command.
      >[/color]

      <G> It certainly would, Doc, were it not for the Interaction and Iteration
      which is fundamental to achieving it.
      (note the inclusion of the word "explain"...thi s is an iterative and
      interactive process, rather than a "Do what I want/mean" process...)

      Pete.


      Comment

      • Karl Heinz Buchegger

        Re: Future reuse of code



        "Peter E.C. Dashwood" wrote:[color=blue]
        >[color=green]
        > > Do you have some links on that subject?[/color]
        >
        > https://www.aboutlegacycoding.com/Ar.../V3/V30501.asp
        > https://www.aboutlegacycoding.com/Ar.../V3/V30201.asp
        >
        > I'm sorry, these are links to just two of the articles I have written which
        > are pertinent. I don't normally promote my own work, but you did ask for
        > some links and these will at least give you an idea of where I'm coming
        > from.[/color]

        No problem.
        The links are fine.
        [color=blue]
        >[/color]
        [snip example][color=blue]
        >
        > There are some assumptions in the above whimsy (the computer has certain
        > inbuilt "concepts" - [you could think of this as a set of components with
        > all the attributes and Methods of a CUSTOMER, for instance], a natural
        > language interface, a "test" database for each of its concepts, however, all
        > of these things are possible with today's technology, and what is currently
        > "bleeding edge" will be passe in 15 years...), but I don't think anyone with
        > a programming background would say it was "impossible " or "infeasible ".[/color]

        That reminds me on 'SHRDLU' :-)
        [color=blue]
        >
        > Of course this demonstrates a solution to just one class of problem. There
        > are many others. But there are many other solutions also...[/color]

        Ever read D.Hoffstadter - Goedel, Escher, Bach (I guess you did)
        The augumented semantical network and its size seems to be one of the
        big problems with this.

        Anyway: We have wandered way off topic, but you gave me a hint to leave
        my small little programming world (which concentrates around 3D graphics)
        and start looking over the fence again.

        Thanks for sharing your thoughts.

        --
        Karl Heinz Buchegger
        kbuchegg@gascad .at

        Comment

        • goose

          Re: Future reuse of code

          Joe Zitzelberger <joe_zitzelberg er@nospam.com> wrote in message news:<joe_zitze lberger-0267F5.07571512 082003@corp.sup ernews.com>...[color=blue]
          > In article <ff82ae1b.03081 20009.43157fcf@ posting.google. com>,
          > ruse@webmail.co .za (goose) wrote:
          >[color=green]
          > > and yet creating a std C program would not only get you that, it would also
          > > get you a fairly snappy application *and* leave you open in the future
          > > to be able to support those people who have machines that are not
          > > capable of running java (certain designer palmtop-types) to *also*
          > > interface with the campus machines.
          > >
          > > java doesn't *buy* you anything extra in terms of portability.
          > > The only relatively *portable* way I can think of is when writing
          > > applets for web-pages (note: /relatively/). as long as the browser
          > > has a java runtime environment, of course.
          > >
          > > Java does have its advantages. Portability isn't one of them.[/color]
          >
          > ???Huh???
          >
          > Which sort of Java isn't portable? I get binary compatibility on all
          > desktop/server/enterprise machines and many embedded as well.[/color]

          a couple of things:
          1. my std C programs has portability on *ALL* the platforms
          that java has *AND* *MORE*.
          2. name the embedded devices.

          C compilers are available for all the platforms that java runs on,
          but java is only available for platforms that are big enough to run
          it.

          bottom line: code written in java runs on less platforms than code
          written in C.

          next time, try thinking *before* you post !
          [color=blue]
          > If that
          > fails (it never has) I get source level compatibilily (the compiler is
          > written in java after all...) across all the platforms.[/color]

          no you dont, you only got a few platforms. you can count the number
          of java platforms without going into a 4 digit number ... miniscule.
          C is ubiquitous enough to assume that if you got a digital machine,
          you can get a C compiler for it.

          if all you have is java experience, you have to look at each machine
          and decide whether or not to use it for your project *before* you
          even decide if it meets your *other* requirements.
          [color=blue]
          >
          > Now it might not make any sense for me to try and open a dialog box on a
          > stoplight, and the stoplight manufacturer might well leave those
          > libraries out, but that hardly makes it non-portable.[/color]

          tell me, how does one get as stupid as you did ?
          write me a crc8 algorithm *in* *java* that I can reuse for the
          stoplight!!!

          I can write the same thing in C and use it on everything from
          a stoplight to a cray.
          [color=blue]
          >
          > All of this talks of applications, not applets which were a cute, but
          > useless toy.[/color]

          sigh.
          [color=blue]
          >
          > Have you ever actually tried porting an application to another
          > hardware/os using std C?[/color]

          not only have I *done* (not "try") this before, I found that the
          number of changes /needed/ to be done to get it going on the new platform
          were few.

          now, if you wanted to run java code on one of the many platforms that
          cannot run java, you have to rewrite.
          [color=blue]
          > It is not just a recompile, there are plenty
          > of issues the original programmers must have planned for -- and they
          > usually don't.[/color]

          so you *assume* they dont ???

          your answer to me pointing out that java is rather limited
          is "C programmers usually write badly" ???

          you might double your IQ if you grew a second brain cell

          goose,
          insulting? surely you're too stupid to notice?

          Comment

          • Thomas Gagné

            Re: Future reuse of code

            Just to split English hairs...

            goose wrote:
            [color=blue]
            ><snip>
            >
            >C compilers are available for all the platforms that java runs on,
            >but java is only available for platforms that are big enough to run
            >it.
            >
            >bottom line: code written in java runs on less platforms than code
            >written in C.
            >[/color]
            Because of its demands, Java runs on /fewer/ platforms than code written
            in C. Because of C's lower requirements it can run on lessor platforms
            (less CPU and memory).

            I think my 12th grade English teacher would be proud. ;-)
            [color=blue]
            >
            >[/color]

            --
            ..tom
            remove email address' dashes for replies
            opensource middleware at <http://isectd.sourcefo rge.net>



            Comment

            • Bat Guano

              Re: Future reuse of code

              goose wrote:[color=blue]
              >
              > but java is only available for platforms that are big enough to run
              > it.
              >[/color]

              big like my mobile phone?

              Comment

              • William M. Klein

                Re: Future reuse of code

                One of the comments that I have frequently made in response to Peter's posts
                in comp.lang.cobol (and which I will now share with the other newsgroups on
                this list) is that IF (and I have mixed opinions on this) the "future" of
                business (particularly) computer programming moves more and more into
                "component - mix-and-build / drag-and-drop type" end user application design
                and DEVELOPMENT, that it will STILL require "someone" at the other end of
                the new (and improved) tools doing the "lower-level" programming that
                provides such tools (and components and libraries).

                I can well imagine the current "trend" away from every medium-to-large
                shop/business/company from having their own (semi-)large programming staff
                to using a combination of off-the-shelf (but customizable) applications and
                end-user available "tools". However, both of these require SOMEONE
                somewhere designing/programming the tools themselves.

                Whether this programming is done in OO, "procedural ", waterfall, or whatever
                type environments, is not something that my "crystal ball" tells me (yet).

                If anything, my GUESS is that the "end users" of such tools will be LESS
                tolerant of "iterative find a mistake and fix it" applications than users of
                in-house developed applications. This means that I can see the "return" of
                more strictly enforced "sign-off" of design, testing, development phases of
                the TOOLS and components that are delivered to "purchasers ".

                --
                Bill Klein
                wmklein <at> ix.netcom.com
                "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
                news:3f397a8a_3 @news.athenanew s.com...[color=blue]
                > Marco,
                >
                > a good and fair response.
                >[/color]
                <much snippage>


                Comment

                • Alistair Maclean

                  Re: Future reuse of code

                  In message <bhdhsl$a60$1@p anix1.panix.com >, docdwarf@panix. com writes[color=blue]
                  >In article <3f3a398d_5@new s.athenanews.co m>,
                  >Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:
                  >
                  >[snip]
                  >[color=green]
                  >>(The fundamental goal of commercial computing has been to have computers
                  >>that are capable of "understand ing" Business needs and meeting them, in a
                  >>manner that would enable a Business User (or Users) to identify and design
                  >>the system and "explain" what is needed to the computer, in as simple a
                  >>manner as possible, without need for in depth technical skills.[/color]
                  >
                  >This, to me, screams for the implementation for the DWIM (Do What I Mean)
                  >command.
                  >
                  >DD[/color]

                  Unfortunately Doc, the DWIM command would not be adequate. I have worked
                  for users where they complained about what they were given because,
                  although it met their stated requirements and was exactly as they had
                  asked, it was not what they needed to do their jobs. How about a GWIN
                  command (gimme wot i need)?

                  --
                  Alistair Maclean

                  Comment

                  • Marco van de Voort

                    Re: Future reuse of code

                    In article <vjl1mqp4n28d4f @corp.supernews .com>, Bat Guano wrote:[color=blue]
                    > goose wrote:[color=green]
                    >>
                    >> but java is only available for platforms that are big enough to run
                    >> it.[/color][/color]

                    Or that have hardware support
                    [color=blue]
                    > big like my mobile phone?[/color]

                    Is it 1 Mhz with 2k RAM?

                    Comment

                    • Bat Guano

                      Re: Future reuse of code

                      Marco van de Voort wrote:[color=blue]
                      > In article <vjl1mqp4n28d4f @corp.supernews .com>, Bat Guano wrote:
                      >[color=green]
                      >>goose wrote:
                      >>[color=darkred]
                      >>>but java is only available for platforms that are big enough to run
                      >>>it.[/color][/color]
                      >
                      >
                      > Or that have hardware support
                      >
                      >[color=green]
                      >>big like my mobile phone?[/color]
                      >
                      >
                      > Is it 1 Mhz with 2k RAM?[/color]

                      I dont know, but it slips into my pocket easily

                      Comment

                      • docdwarf@panix.com

                        Re: Future reuse of code

                        In article <3f3a4f52_3@new s.athenanews.co m>,
                        Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:[color=blue]
                        >
                        ><docdwarf@pani x.com> wrote in message news:bhdhsl$a60 $1@panix1.panix .com...[color=green]
                        >> In article <3f3a398d_5@new s.athenanews.co m>,
                        >> Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:
                        >>
                        >> [snip]
                        >>[color=darkred]
                        >> >(The fundamental goal of commercial computing has been to have computers
                        >> >that are capable of "understand ing" Business needs and meeting them, in a
                        >> >manner that would enable a Business User (or Users) to identify and design
                        >> >the system and "explain" what is needed to the computer, in as simple a
                        >> >manner as possible, without need for in depth technical skills.[/color]
                        >>
                        >> This, to me, screams for the implementation for the DWIM (Do What I Mean)
                        >> command.
                        >>[/color]
                        >
                        ><G> It certainly would, Doc, were it not for the Interaction and Iteration
                        >which is fundamental to achieving it.
                        >(note the inclusion of the word "explain"...thi s is an iterative and
                        >interactive process, rather than a "Do what I want/mean" process...)[/color]

                        It would appear that if Meaning could be translated into action by a
                        single, simple DWIM command then that single command would constitute the
                        Interaction and no further Iterations would be necessary as what was Meant
                        would be Done.

                        DD

                        Comment

                        • William M. Klein

                          Re: Future reuse of code

                          <docdwarf@panix .com> wrote in message news:bhe5lf$a74 $1@panix1.panix .com...[color=blue]
                          > In article <3f3a4f52_3@new s.athenanews.co m>,[/color]
                          <snip>[color=blue][color=green]
                          > ><G> It certainly would, Doc, were it not for the Interaction and[/color][/color]
                          Iteration[color=blue][color=green]
                          > >which is fundamental to achieving it.
                          > >(note the inclusion of the word "explain"...thi s is an iterative and
                          > >interactive process, rather than a "Do what I want/mean" process...)[/color]
                          >
                          > It would appear that if Meaning could be translated into action by a
                          > single, simple DWIM command then that single command would constitute the
                          > Interaction and no further Iterations would be necessary as what was Meant
                          > would be Done.
                          >
                          > DD
                          >[/color]

                          And on the 8th day, it was said,

                          "Let there be profits,
                          and lo,

                          all the business were profitable,
                          and all the applications worked as desired,
                          and all the user support personnel were helpful
                          and ..."

                          --
                          Bill Klein
                          wmklein <at> ix.netcom.com


                          Comment

                          • Richard Plinston

                            Re: Future reuse of code

                            [color=blue]
                            > In article <vjl1mqp4n28d4f @corp.supernews .com>, Bat Guano wrote:[color=green]
                            >> goose wrote:[color=darkred]
                            >>>
                            >>> but java is only available for platforms that are big enough to run
                            >>> it.[/color][/color][/color]

                            There is Waba which is a JVM for smaller machines such as Palm and CE PDAs.
                            There is even a version for MS-DOS, one for GameBoy, and a version for TI
                            Calculators.

                            (see http://www.wabasoft.com )

                            Comment

                            • Peter E.C. Dashwood

                              Re: Future reuse of code


                              "William M. Klein" <wmklein@nospam .netcom.com> wrote in message
                              news:pvw_a.1758 2$vo2.15788@new sread1.news.atl .earthlink.net. ..[color=blue]
                              > One of the comments that I have frequently made in response to Peter's[/color]
                              posts[color=blue]
                              > in comp.lang.cobol (and which I will now share with the other newsgroups[/color]
                              on[color=blue]
                              > this list) is that IF (and I have mixed opinions on this) the "future" of
                              > business (particularly) computer programming moves more and more into
                              > "component - mix-and-build / drag-and-drop type" end user application[/color]
                              design[color=blue]
                              > and DEVELOPMENT, that it will STILL require "someone" at the other end of
                              > the new (and improved) tools doing the "lower-level" programming that
                              > provides such tools (and components and libraries).
                              >[/color]

                              It is normal and natural for programmers to see things from a programming
                              perspective.

                              What I am suggesting is bigger than that.

                              I foresee a time when there will be no need for the "lower level"
                              programming you are talking about, Bill.

                              The job of building the tools will be complete. And "smart software" will do
                              the enhancements to it.

                              There are already specialised tools and wizards to do specific jobs.
                              (Network management, for instance). Programmers are not redeveloping these
                              tools; you could argue that they are "complete". They work and do the job
                              they are designed for. In fact, it would not be desirable to have
                              programmers "fiddling" with them.

                              One of the points often overlooked about component based systems is that
                              these components encapsulate EXPERTISE as well as functionality. I have
                              purchased components to provide specific functionality, initially to save me
                              the time of writing it myself, then found that the component provided
                              Methods I would never have dreamed of (in addition to the ones I needed),
                              because the programmer who wrote it had many years of EXPERTISE in that
                              particular area and was aware of things I couldn't be aware of unless I had
                              also spent years in a particular niche.

                              I only have one lifetime and I cannot be an expert in everything. Sooner or
                              later it is necessary to trust someone else's experience.

                              Your assumption that there will ALWAYS be a requirement for "low level"
                              programmers to keep maintaining tools is, at best, arguable, at worst, just
                              dead wrong.

                              [color=blue]
                              > I can well imagine the current "trend" away from every medium-to-large
                              > shop/business/company from having their own (semi-)large programming staff
                              > to using a combination of off-the-shelf (but customizable) applications[/color]
                              and[color=blue]
                              > end-user available "tools". However, both of these require SOMEONE
                              > somewhere designing/programming the tools themselves.
                              >[/color]

                              But not INDEFINITELY.
                              [color=blue]
                              > Whether this programming is done in OO, "procedural ", waterfall, or[/color]
                              whatever[color=blue]
                              > type environments, is not something that my "crystal ball" tells me (yet).
                              >[/color]

                              It really doesn't matter. Sooner or later, the job will be "done"...
                              [color=blue]
                              > If anything, my GUESS is that the "end users" of such tools will be LESS
                              > tolerant of "iterative find a mistake and fix it" applications than users[/color]
                              of[color=blue]
                              > in-house developed applications. This means that I can see the "return"[/color]
                              of[color=blue]
                              > more strictly enforced "sign-off" of design, testing, development phases[/color]
                              of[color=blue]
                              > the TOOLS and components that are delivered to "purchasers ".
                              >[/color]

                              Well, your guess is wide of the mark, Bill. The iteration is required to get
                              closer to the goals, within the time allocated to do so (timebox). These ARE
                              "in-house developed applications". I have managed projects where we did this
                              (no guessing involved). It is foreign to the way you may have been used to
                              working, but it is VERY successful, PARTICULARLY with end users. (Why
                              wouldn't it be? They are involved in the process throughout and feel that it
                              is as much theirs as ITs. Users and IT people work together to achieve
                              specific goals within a specified time period. Programmers write code (or
                              select and drop components) towards the achievement of the common goal.
                              Users can see something taking shape as the process unfolds, and they are
                              able to ensure it meets CURRENT (today's) business requirements and balance
                              the priorities according to the Business needs.

                              On such a project, users and programmers discuss requirements together and
                              the programmers cut code. It is not such a big leap to have smart software
                              cut the code. I believe that is what will happen within the next 15 years.
                              It is just too expensive to maintain "multi-lingual" programming departments
                              in-house. Smart software will take on this role. Even if it isn't
                              "intelligen t", this lack can be compensated for by keeping Humans in the
                              loop. These Humans will be end Users, not technicians.

                              Pete.


                              Comment

                              • Peter E.C. Dashwood

                                Re: Future reuse of code


                                "Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
                                news:3F3A61EC.6 0CDF2E@gascad.a t...[color=blue]
                                >
                                >
                                > "Peter E.C. Dashwood" wrote:[color=green]
                                > >[color=darkred]
                                > > > Do you have some links on that subject?[/color]
                                > >
                                > > https://www.aboutlegacycoding.com/Ar.../V3/V30501.asp
                                > > https://www.aboutlegacycoding.com/Ar.../V3/V30201.asp
                                > >
                                > > I'm sorry, these are links to just two of the articles I have written[/color][/color]
                                which[color=blue][color=green]
                                > > are pertinent. I don't normally promote my own work, but you did ask for
                                > > some links and these will at least give you an idea of where I'm coming
                                > > from.[/color]
                                >
                                > No problem.
                                > The links are fine.
                                >[color=green]
                                > >[/color]
                                > [snip example][color=green]
                                > >
                                > > There are some assumptions in the above whimsy (the computer has certain
                                > > inbuilt "concepts" - [you could think of this as a set of components[/color][/color]
                                with[color=blue][color=green]
                                > > all the attributes and Methods of a CUSTOMER, for instance], a natural
                                > > language interface, a "test" database for each of its concepts, however,[/color][/color]
                                all[color=blue][color=green]
                                > > of these things are possible with today's technology, and what is[/color][/color]
                                currently[color=blue][color=green]
                                > > "bleeding edge" will be passe in 15 years...), but I don't think anyone[/color][/color]
                                with[color=blue][color=green]
                                > > a programming background would say it was "impossible " or "infeasible ".[/color]
                                >
                                > That reminds me on 'SHRDLU' :-)
                                >[/color]

                                Sorry, you lost me ..."SHRDLU"?
                                [color=blue][color=green]
                                > >
                                > > Of course this demonstrates a solution to just one class of problem.[/color][/color]
                                There[color=blue][color=green]
                                > > are many others. But there are many other solutions also...[/color]
                                >
                                > Ever read D.Hoffstadter - Goedel, Escher, Bach (I guess you did)[/color]

                                Nope, none of the above.

                                Everything I know, I learned on the shop floor. (In 38 years, even if I was
                                a slow learner (which I'm not...<G>), I'd have to pick up SOMETHING,
                                wouldn't I?)

                                I realise that there is a wealth of excellent work available now and I would
                                encourage young people to read it. (It's a bit late for me...<G>).

                                Try and understand that in 1965 not a lot was known about the theory of
                                computing, and what was known was not proliferated because it could mean
                                competitive advantage. Try to imagine a world WITHOUT standard "best
                                practices", installation standards, computing science courses, standard
                                algorithms even... We did things and got programs working. Next time we
                                wrote a program, we tried to make it "better" than the last one we wrote. (I
                                still do that to this day, but I realise there are thngs I could do better
                                that I am not going to change now...).
                                [color=blue]
                                > The augumented semantical network and its size seems to be one of the
                                > big problems with this.
                                >[/color]
                                [color=blue]
                                > Anyway: We have wandered way off topic, but you gave me a hint to leave
                                > my small little programming world (which concentrates around 3D graphics)
                                > and start looking over the fence again.
                                >
                                > Thanks for sharing your thoughts.
                                >[/color]

                                It is always a pleasure, and thank you for being interested.

                                Pete.


                                Comment

                                Working...