CONTACTS 
0201 - Dynamic Alternatives
020101 - Mr. Garold L. Johnson;

SUBJECTS
Default Null Subject Account for Blank Record

0403 -
0403 -    ..
0404 - Summary/Objective
0405 -
040501 - Follow up ref SDS 10 0000. ref SDS 9 0000.
040502 -
040503 -
040504 -
040505 -
040507 -  ..
0406 -
0407 -
0408 - Progress
0409 -
040901 - On 081114 met with Morris to review progress on Medit for SDS using
040902 - Java development tools. ref SDS 8 YD64
040904 -  ..
040905 - In later discusison with Gary, there was consideration of deviating
040906 - from prior success using assembly language which has been effective
040907 - for nearly 30 years, shown in the record meeting with Morris on
040908 - 081104. ref SDS 6 VO3P
040910 -  ..
040911 - On 081120, received a letter from Gary following up on discussions
040912 - with Morris about deviating from prior pattern and practice for Medit
040913 - development. ref SDS 9 KD7J
040915 -  ..
040916 - On 081122, received a copy of a letter from Morris responding to
040917 - Gary's letter on 081120, ref SDS 10 YX7N, and in which Morris says in
040918 - part...
040919 -
040920 -    1.  I agree Rod started out with a good intent with the line
040921 -        numbers, but they are now a mess.  He has moved to indentation
040922 -        to add structure in his records which is easy to recognize
040923 -        visually, but is a real problem for a computer to understand.
040924 -        (Take a look at some of his tables), ref SDS 10 NX9V
040926 -         ..
040927 -    2.  A real issue is "syntax".  If computer parsing is to be useful,
040928 -        then the record must have unambiguous syntax.  The commas and
040929 -        other items are part of the syntax.  I challenge you to take
040930 -        Rod's records and parse them with any BNF style parser. (I have
040931 -        tried and failed), ref SDS 10 NX4R
040933 -  ..
040934 - Today, received a copy of Gary's letter responding to Morris' letter
040935 - on 081122, and saying...
040936 -
040937 -    1.  Subject: Re: Issues Affecting Software Longevity
040938 -        Date: Sun, 23 Nov 2008 11:35:15 -0800
040946 -         ..
040947 -    2.  Updated Record
040949 -         ..
040950 -        I updated the record on the web
040951 -
040952 -             http://www.welchco.com/sd/08/GLJDY/02/08/11/20/062144.HTM
040954 -         ..
040955 -    3.  Regular Syntax for SDS Records
040956 -
040957 -        a.  I agree with wanting a cleaner syntax for SDS records.  The
040958 -            only way I know to do the job better is to build an
040959 -            outliner rather than an editor as a basis for the program.
040960 -            The leading indentation would thus be regular and
040961 -            controlled rather than left to the whim of the user.
040963 -             ..
040964 -        b.  Line numbers work in SDS only because the program handles
040965 -            everything concerning them.  The only reason to edit them
040966 -            is when you screw them up somehow.  I think the same would
040967 -            be true of a true outline structure.
040969 -  ..
040970 - Gary discussed line numbers in his record on 081120 at line 051503
040971 - which was reviewed on 081120. ref SDS 9 5O67
040973 -  ..
040974 - Gary's letter continues...
040975 -
040976 -        c.  I haven't gone so far as to recommend something like the
040977 -            text markup languages used to generate HTML.  They are
040978 -            simple for simple things but break down at tables.  Using
040979 -            simple tags to delimit sections could make record handling
040980 -            a lot easier without needing line numbers for structure.
040982 -         ..
040983 -    4.  Build What Exists
040984 -
040985 -        a.  Having said that, I think there is merit in the idea of
040986 -            building a modern SDS that does what the current one does
040987 -            without trying to understand it all that much.
040989 -  ..
040990 - This aligns with planning on 070907 to develop 64-bit version of SDS
040991 - with C, ref SDS 1 V35O, and implementation beginning on 081104 using
040992 - Java. ref SDS 6 2W6I
040994 -  ..
040995 - Gary's letter today further aligns with his letter transmitting his
040996 - record on 080422 noting that SDS assembly language platform enables
040997 - huge work product stretching over decades [30 years] -- a feat matched
040998 - by no other known efforts. 080422, ref SDS 4 KH8L
041000 -  ..
041001 - Review on 081104 Morris showed progress on developing an updated Medit
041002 - program to run SDS on 64-bit microprocessor technology. ref SDS 6 2W6I
041003 - Review at that time cited Morris' successful experience building an
041004 - editor with assembly tools that enables development of effective
041005 - knowledge management technology. ref SDS 6 VO3P
041007 -  ..
041008 - On 081120 telecon with Gary discussed professional presentation on
041009 - advantages using assembly language to continue successful work
041010 - history. ref SDS 9 KD6H  Gary's SDS record on 081120 cites
041011 - disadvantages using assembly language, and no advantages, based on
041012 - "zero chance" other popular software programs are created in with
041013 - assembly. ref SDS 9 KD6O
041015 -  ..
041016 - On 081114 Morris discussed challenges developing the Medit editor for
041017 - SDS support using Java development technology. ref SDS 8 YD64
041018 -
041019 -               [On 081123 Morris reports progress developing new Medit
041020 -               editor with Java and notes challenges using this method
041021 -               meeting requirements for SDS macro code, and difficulty
041022 -               avoiding "redoing" a bunch of SDS code. ref SDS 12 RO4X
041024 -                ..
041025 -               [On 081130 Gary's letter cites disadvantages using
041026 -               assembly lanaguge and no advantages of assembly language
041027 -               for the editor to support what already exists for SDS,
041028 -               ref SDS 13 IK5H, as previously proposed on 081123.
041029 -               ref SDS 11 V29Y
041031 -  ..
041032 - Gary's letter continues...
041033 -
041034 -        b.  By improving on the macro language or even exposing enough
041035 -            of the internals to support scripting in Groovy, we could
041036 -            have an experimental environment that would allow us to try
041037 -            ideas much more readily than presently, actually deliver
041038 -            the product, and migrate functionality into the core as it
041039 -            makes sense.
041041 -             ..
041042 -        c.  I can (and have) thought about many ways of improving SDS.
041043 -            It would be easier to do if it were in an environment where
041044 -            evolution were facilitated. A Java version of MEdit with no
041045 -            more warts than absolutely needed would be a great place to
041046 -            start.  Systematic migration of the SDS macro code base
041047 -            would eventually give us either a much improved scripting
041048 -            environment or a full Java implementation.
041050 -         ..
041051 -    5.  Redeployment Required
041052 -
041053 -        a.  You noted "A program will require redeployment every few
041054 -            decades in the best of conditions", and I agree.
041056 -  ..
041057 - Gary seems to reference Morris' letter yesterday on 081122.
041058 - ref SDS 10 NX4X
041060 -  ..
041061 - On 080422 Gary noted that SDS assembly language platform enables huge
041062 - work product stretching over decades [30 years] -- a feat matched by
041063 - no other known efforts. 080422, ref SDS 4 KH8L
041065 -  ..
041066 - Gary's letter to Morris continues...
041067 -
041068 -        b.  What makes that easier is regularized structure, using text
041069 -            rather than binary for data, and documenting the program
041070 -            itself. All of this is relatively standard software
041071 -            engineering.
041073 -         ..
041074 -    6.  32-bit Characters
041075 -
041076 -        a.  It does seem that Unicode will eventually move to 32-bit
041077 -            characters as you suggest.
041079 -  ..
041080 - Morris discussed 32-bit characters in his letter on 081122.
041081 - ref SDS 10 NX5S
041083 -  ..
041084 - Gary's letter to Morris continues...
041085 -
041086 -        b.  Once "plain text" becomes 32-bit, we can stop fooling with
041087 -            it.
041089 -  ..
041090 - How does this relate to Morris' concern on 081114 of finding a font
041091 - that supports SDS line draw features? ref SDS 8 PS6O
041093 -  ..
041094 - Gary's letter to Morris continues...
041095 -
041096 -        c.  More and more software is becoming Unicode-aware.
041097 -            Microsoft, of course, never found a standard it didn't want
041098 -            to pervert.
041100 -         ..
041101 -    7.  Protection From Internals
041102 -
041103 -        a.  You said "One of the things I like about Java is that the
041104 -            code can't get at physical things such as parts of a
041105 -            number, so I can't write the code in a manner that depends
041106 -            on things like byte ordering, integer size, etc."
041108 -  ..
041109 - Gary cites Morris' letter on 081122. ref SDS 10 NX6W
041111 -  ..
041112 - Gary's letter to Morris continues...
041113 -
041114 -        b.  This is the point I have made about control vs.
041115 -            productivity.  By relying on the language system to protect
041116 -            us from details, we lose some degree of control -- we are
041117 -            dependent on the Java community to keep Java current, but
041118 -            we gain a great deal of freedom in the process.
041120 -  ..
041121 - This should be expanded with examples to evaluate trade-offs between
041122 - control and productivity.  Often increased "control" is the path to
041123 - better productivity.  Here Gary seems to present a conflict.
041125 -  ..
041126 - Gary's letter to Morris continues...
041127 -
041128 -    8.  Controlled Java Subset
041129 -
041130 -        a.  I haven't looked at Java, and it may not have this problem
041131 -            to the extent that, say, C++ does, but it is often
041132 -            worthwhile to restrict use to a subset of a language.  I
041133 -            doubt that the problem is as severe in the Java language as
041134 -            it is in C++ (that *would* be hard to imagine), but we may
041135 -            have a similar situation with respect to Java libraries.
041137 -             ..
041138 -        b.  The number of components and component types simply drives
041139 -            me nuts.  Do you know of a reference that provides an
041140 -            inventory of what is available, where each thing fits, and
041141 -            how they interact?
041143 -             ..
041144 -        c.  It seem clear that learning Java isn't going to be the
041145 -            problem, but choosing among all the various libraries
041146 -            certainly could be.
041148 -         ..
041149 -    9.  Proprietary Formats
041150 -
041151 -        1.  DMOZ has a good listing of documents relating to the idea
041152 -            of Open Standards, and Open Formats that make the case for
041153 -            open, non-binary, standard (or at least documented) data
041154 -            formats.
041155 -
041156 -                 http://www.dmoz.org/Computers/Data_Formats/Open_Standards/
041158 -             ..
041159 -        2.  While I am not suggesting we adopt any of the standards,
041160 -            the arguments for the nature of data formats are well
041161 -            taken.
041163 -             ..
041164 -        3.  They provide a base for redeployment of software as needed.
041165 -            Insuring that it is always possible to build software to
041166 -            handle and possibly upgrade data formats is one aspect of
041167 -            software longevity.
041169 -         ..
041170 -   10.  Polyglot Programming
041171 -
041172 -        1.  I mention the concept of "polyglot programming" in the
041173 -            record
041174 -
041175 -                 http://www.welchco.com/sd/08/GLJDY/02/08/11/20/062144.HTM#PB5K
041177 -  ..
041178 - Gary refers to his record 081120, cited his letter the same day.
041179 - ref SDS 9 KD7J
041181 -             ..
041182 -        2.  Their results for Jython vs. Raw Java are enough to give
041183 -            one pause. The theory sounds really good, but may not work
041184 -            all that well in practice.
041186 -             ..
041187 -        3.  Do you know anything about Groovy?  Since it was designed
041188 -            to be Java rather than being "bolted on" it might not have
041189 -            the performance penalties.
041191 -         ..
041192 -   11.  Exposing Program Internals
041193 -
041194 -        1.  The question of what of the editor external to expose and
041195 -            how is a thorny one. I have considered that in Delphi, for
041196 -            example, "actions" are used internally as a package that
041197 -            can be tied to invocation, menu items, buttons, or
041198 -            commands. Scripting languages require an exposed
041199 -            interfaced, and so doe OLE (or whatever the name is today).
041200 -            I wonder if it would be possible to abstract the concept so
041201 -            that an action could be developed as an atomic item and
041202 -            used in all the ways mentioned above. If we could do
041203 -            something similar for the SDS macro language and some sort
041204 -            of scripting language, it would be great.
041206 -             ..
041207 -        2.  I would love to see a plugin technology, eventually, so
041208 -            that the core system could be extended without having to
041209 -            interfere with the central code.
041211 -         ..
041212 -   12.  End Babble
041213 -
041214 -        a.  I tend to run on.
041216 -             ..
041217 -        b.  Later.
041218 -
041225 -
041226 -
041227 -
041228 -
041229 -
041230 -
041231 -
041232 -
041233 -
041234 -
041235 -
041236 -
041237 -
041238 -
041239 -
0413 -