ABOUT ME

Steve Hollister, SNAME, IEEE (Life Member), ACM

I wrote my first program in 1972 at UConn using cards. In 1973, I transferred to Michigan Engineering and used the famous Michigan Terminal System (MTS) and Integrated Graphics (*IG) package in computer graphics classes with Bert Herzog and Dick Phillips. We wrote "interactive" graphics programs in FORTRAN for Tektronix terminals and Calcomp plotters. I graduated in 1978 with two separate master's degrees in Naval Architecture and Marine Engineering (NAME), and Computer, Information, and Control Engineering (CICE). I was one of the first to have formal computer engineering and subject matter expertise.

Then came the PC era with computers that had nothing. I wrote graphics drivers in assembly for devices like the CGA, EGA, and VGA displays and the Hercules card and Epson printer and  programmed everything from Bresenham's algorithm up through the display of points, curves, and surfaces, hidden line renderings, 3D viewing transforms, to a full graphics user interface where there were separate text and graphics modes. I wrote and still write general CAD software and software for boat and ship design and analysis. One of my programs is a general 3D CAD program that uses NURB surfaces (see www.pilot3d.com and www.newavesys.com) See also my top-searched paper called "The Dirty Little Secrets of NURBS."

In the mid-80s I taught college math and computer science full time during the height of Turbo Pascal. I connected it to my graphics drivers for my computer graphics course. Those were also the years of emergence for C and then C++. After many years developing code at all levels for programs in DOS, Windows came in the 90s. Most all of my code had to be thrown out and only that which was commercially viable was updated. I still have valuable DOS code that does not justify the cost of conversion. I have valuable old mainframe code that's never been recreated for new technology.

What was the new programming environment? Microsoft Foundation Classes (MFC). Now, years later, that's old and going away. Next are web-based apps and SaaS and we now have JavaScript, Python, Full Stack Agile Programming, WebAssemby and more. Which do you learn and use? What justifies conversion time and cost? How can subject matter experts ever learn to create web apps on a SaaS website? How can they collaborate and connect code without making it open source and free?

I've written over a million lines of code over 50 years and a lot of it has been thrown out. Even though calculations might be coded into libraries, the cost of building new apps is prohibitive. I'm a subject matter expert programmer who has spent much of my career writing UI and data file conversion code - again and again as technology changed - losing code and market opportunities along the way.

When will change, learning curves, and programming objects be properly encapsulated and externalized from programming languages and operating systems? The universal web browser finally opens that door.

However, there are still the problems of no automation of separate calculations and the problems of different "neutral" data file formats and schema unification. TriSplit is my solution to all of those problems. It's the story of and result of my career and what I needed 25 years ago. It's been in development for eight years where I've given six technical papers and created three working versions on the desktop. I've given short courses, had expo booths, and talked with hundreds of colleagues. This is not a product looking for a market. It's a product waiting for a web implementation.

The traditional "app" user model of program architecture has to change. Industries and data engineers have to work together to take back control of their data and SME users must become creators. Methods have to be split from data definitions and an agile bottom-up and collaborative process defined to unify data horizontally, vertically, and longitudinally using external data-driven programming with plug-and-play base components. 

An internal top-down DevOps and a single app mentality cannot coexist in an increasingly interdependent, outsourced, automated, and collaborative world of separate programs, SME developers, and data. The traditional OOP internal encapsulation of data and methods into programming language-centric classes will not work. TriSplit splits data and methods but allows for grouping to create external classes if needed. (Xclass)
​
The web has created an amazing digital interstate highway for the world, but what happens at the exits has to be isolated from "civil engineering" web programmers. Civil engineers are not required to build stores and malls at the exits of highways, but it's not that way yet for the web. TriSplit will make that happen.

We are circling back to a world where the WWW "mainframe" allows everyone to share data and code and collaborate with common tools.

If you have any questions, you can contact me directly by email here.

TriSplit can "wrap" multiple separate Code Engines to create a combined single Code Engine that can be launched by a standard user interface - UIF. The sequenced Code Engines above search for an optimum solution and this wrapping was done without writing a line of new code, and each Code Engine can be located anywhere on the web. The sequence above combines a ship hull shape variation Code Engine with a hydrostatics Code Engine and followed by a ship resistance Code Engine that I wrote. These Code Engine batch programs were created and validated separately, can be used separately, can be combined with no programming, and they can be written in any programming language. This is the Holy Grail of engineering and all analysis fields: automatic data variation to search for an optimum result using many separate and potentially complex  calculations. This can't be done with traditional separate interactive apps. TriSplit offers this automation and plug-and-play collaboration.

These batch Code Engines were wrapped together to create one Code Engine to use with a standard open macro source UIF spreadsheet. I gave a technical paper on this working solution at the 2016 annual conference of SNAME. This solution is not possible unless calculations are separated from user interfaces. This is an updated recreation of my work described in a paper I gave in 1996 (25 years ago!) that accomplished the same task, but all calculation and user interface code had to be combined into one app and tested. TriSplit completely eliminates that need. This is extremely important for all areas of software development. The alternative is complex and very costly custom programming - by programming experts, not users.

TriSplit gives subject matter experts the tools to take back full creative control over their work - and their markets!