[om-list] Fw: The TomP Software Design -- Re: Current Tasks...

[Tom and other Packers]

Mark et alia

    Any comments on Mike's comments below:

tomp

----- Original Message ----- 
From: Mike Jones 
To: Curtis Harrison ; 'Thomas Packer' 
Cc: Daniel R (w) Cook ; Thomas L (h) Packer ; Mike Jones 
Sent: Wednesday, September 05, 2001 6:40 AM
Subject: RE: The TomP Software Design -- Re: Current Tasks...


Here are my two cents...

I agree that the current system is far from perfect and could use many improvements.  However I think it is quite remarkable we have the current suite of tools and yet Thoughtform has  NO fulltime programmers.  Wow, a software company with no fulltime programmers....  Anyway, one very common and potentially dangerous thing is to see problems with a system and want to completely rework it thinking the new system will be the 'silver bullet'.  Sometimes this is necessary, but more times than not, it can cause as much or more grief than trying to adjust the current system where it falls short. In the real world this is called 'the grass is greener' philosophy

I agree with Curtis that this new approach would take lots of time and would need lots of up-front planning.  Believe me, scripting languages are nice and have there place but they also have problems.  Here are just a couple that could turn out to be serious downfalls with a script based system:

1) Debugging a script can be a nightmare.  Would we write a script debugger also that would inspect/modify variables, step over lines of code, view outputs, etc?
2) Scripts are notoriously slow since they are interpretive in nature.  If we are complaining about slow processing now, it will become much much slower if it were script based. 

I personally have worked with many extendible software systems and the best one I have seen is both .dll and script based.  Most of the extensions are .dll's but it also has a powerful scripting language.

The bottom line is I think we need to identify EXACTLY what the problems are with the current system and what is the best way to address them given the current company resources.  


  -----Original Message-----
  From: Curtis Harrison [mailto:charrison at found.com]
  Sent: Friday, August 31, 2001 6:10 PM
  To: 'Thomas Packer'; Curtis Harrison
  Cc: Daniel R (w) Cook; Thomas L (h) Packer; Mike (HG) Jones
  Subject: RE: The TomP Software Design -- Re: Current Tasks...


  Tom,

  I'm willing to leap, but not for free.  I'd need to get paid the same as I do for regular TForm projects. 

  I think that it may be difficult to get all the functionality to work for all utilities, HOWEVER, I think that if we really spent some time and worked on a good design (I'm talking about MONTHS FULL TIME for design) we could probably come up with something pretty good.

  For example, suppose we had a studio, as we do now, with configurable toolbar buttons and menus.  We could write generic dialogs that get user input.  File names, basic options (overwrite existing file, manually edit file name, show full path, etc) would be shared by all classes (each class would represent what we now have as utilities and could inherit their base functionality from a superclass that would have most of the generic functionality built in).  Some of the functionaility would include .ini file handling, etc.

  Now, when you click on a button (say FindEvents) a dialog will be dynamically created that contains generic components used by FindEvents (input file, output file, progress bar ok, cancel, help buttons, etc) as well as custom controls that are specific to FindEvents.

  The processing would be handled by the FindEvents class (again, inheriting or using other shared classes for most of the work, like parsing TSF files).

  So to create a new 'utility' or class, you would just inherit from the base class, design your class-specific dialog, write the main 'PerformAction()' method, and you're done.

  We also may want to create a new model for the file format and use it ONLY with the new Studio.  Don't make it backwards compatible with anything..

  Unfortunately, all this would cost a lot of MONEY, but I think it is necessary (when we have some money to use on this).

  HOWEVER, LET ME BE CLEAR,  before we do ANY work on this, I think it would be wise to incorporate some QUALITY ASSURANCE principles and processes.  No code should be released unless 2 other programmers have reviewed it.  No code should be written unless at least 2 programmers and the one requesting the code (Dan in most cases) are present for several Requirements and Design sessions.  MUCH OF OUR TIME is wasted because we think that we don't have enough time to sit down and DEEPLY design these utilities before we write them.  Many of our bugs are introduced when NEW FEATURES are added to pre-existing code long after it was originally written.  This causes undesirable side effects in the code that may live for a long time before they are discovered.  Creating and enforcing a few Quality Assurance principles as well as coding standards will GREATLY reduce our bugs and GREATLY reduce our coding time.

  Anyway, in a nutshell, if we want to pursue this, it should be REALLY well thought out before any code is written.  We will need some serious $$$ before TForm will be able to fund this.  The benefits could be great, but ONLY if we take adequate time with all of us sitting down together to design this the RIGHT way.

  That's just my opinion...

  See ya,
  Curtis Harrison
  Technical Lead - Found, Inc.
  charrison at found.com
  (801) 892-3554 (office)
  (801) 673-6397 (cell)
  (801) 892-3501 (fax)
  -----Original Message-----
  From: Thomas Packer [mailto:tomp at thoughtform.com]
  Sent: Friday, August 31, 2001 5:32 PM
  To: Curtis Harrison
  Cc: Daniel R (w) Cook; Thomas L (h) Packer; Mike (HG) Jones
  Subject: The TomP Software Design -- Re: Current Tasks...


  2001-08-31

  Hello Curtis

      There's nothing pressing for you to work on, except maybe using that HASP CD as well as you can.

      ~~~~~~

      If you're desperate for things to work on ...

      I have a personal project you could help with, but it wouldn't pay well yet -- maybe in stock points, if anything, and if I can convince Dan to let me find subcontractors to help me in the personal project he was almost unwilling to pay me even in stock points alone.

      But here it is anyway, since I want Dan and others to know what I intend to do, ultimately:

      I want to recreate the entire TFStudio ensemble of utilities, the protocol engine, and all the utilities we haven't even thought of yet, in a completely new form: I want to make a shell-scripting type environment, using a whole new, high-level knowledge-processing programming language called MPL (Mathetical Programming Language).

      Sound fun?

      The whole idea of individual dialog-box utilities, with all the associated overhead and over-compartmentalisation is really starting to annoy me.  For the long run (which after six-and-a-half years, we are starting to experience), the whole TF paradigm was less than optimal.

      (No offence, Dan.  I do understand that you originally thought we could sell the TFStudio package to laymen, who were not programmers, and who were not familiar with Unix or other text-based OS-es.  So, I'm not complaining or criticising.  I'm pointing out what all 20/20 hind-sight tells us: what we did wrong, and what we might want to consider doing in order to change this less-than-optimal direction, as soon as possible.)

      So ...

      Costly busy work and disconnectivity was designed into TFStudio, and so inefficiency is inherent in every new utility we program, and in every data analysis study we carry out using them.  Development time is longer than it should be for utilities which are so similar to each other -- and will be still, even after we start using Mike's and your re-usable libraries -- though those things will help a lot.  And after the new utility is made, "run-time" is longer than it should be when you boil a study down into its component parts, and realise that you could have written one utility to do the whole thing, instead of running a long string of disjoint processes.

      If we had had the time, money, and/or the foresight, we should have taken the extra time to design a more generalisable approach: A whole waveform processing language, in which we could more easily write basic file-processing functions of all sorts, which we could then recombine in any way we wished, textually, in a matter of hours, which would allow us to then use the whole combination in one operation, also in a matter of hours, with one set of input parameters, and one final output, instead of having to press so many okay buttons, and individually set so many parameters, and use so much hard-drive space in duplicating so many files.

      The protocol engine was our first (and second) attempt at doing this sort of thing -- while we didn't, and still don't, have quite enough commitment or faith to abandon individual dialog box utilities, and start from scratch.

      Well, while TF is using what it has developed at mediocre studies, I intend to start over with a whole new system, from scratch, which could be tried and tested on studies, in parallel with the current TFStudio, until the gap between the two is small enough that we have the faith to make the leap.

      This will probably be part of my senior project at Weber, and my PhD work in graduate school.

      Feel free to take the leap of faith with me. 

      :-)

  Ciao,
  Thomas L. Packer
  ~~~~~~~~~~~~~~~~~~~~~~~
  ph: 801-299-1285
  fax: 801-292-7217
  tomp at ThoughtForm.com
  tomp at NeuroInsight.com
  tomp at BrainResearchInstitute.net
  Omnia aput me mathesis fiunt.
  ~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://six.pairlist.net/pipermail/om-list/attachments/20010905/406bc20e/attachment.html