[GoLUG] re Well, you knew it had to happen

[Steve Litt]

On 2026-06-06 02:53, Steve Litt wrote:
> You probably saw it coming. You knew it had to happen. I'm very slowly
> writing a Rust version of UMENU2.

Do you have any particular bug or feature in mind during your rewrite?

Probably not. In fact, hopefully it will ultimately be constructed to
exactly mimic, feature for feature, bug for bug, the current Python
version of UMENU2.

If things go incredibly well, I might construct a high quality menu
maintainer feature, so the average Joe can easily and quickly
add/change menu items. The addition of this feature would make UMENU2
an excellent and practical piece of free software, instead of the ultra
niche thing that's been used by maybe 10 people.

But if that were easy, it would have been done last century.


What will this opportunity let you pursue?

Sy, you've known me for years, and know I'm a little perverse and a
little crazy. This lets me pursue the following 3 opportunities, none
of which the average person would consider an opportunity at all:

1. Follow a compulsion: I just have to do it.

2. Learn a little more about Rust: Rust seems kind of cool, I'd like to
   get good at it, and I'd like to use it in situations where I used to
   use C. This is not a career opportunity, because at present very few
   jobs have Rust as their one and only requirement.

3. Learn more about UMENU. Now here's where things really go crazy,
   because I'm UMENU's author, authoring the very first one, in Perl,
   in 1999. Since then I've authored it in Python, then Lua, then
   Python again (as UMENU2). Every one of those programs had a
   significantly different design. All were object oriented, and all
   were kind of hard to read and maintain after several months'
   absence. It turns out that a menu program is not the incredibly
   simple thing it initially seems to be.

A few more thing about UMENU...

The first UMENU I ever wrote was a work-for-hire menu program for
Latham & Watkins, a huge law firm that was my client. It ran on MS-DOS,
was single-user single-tasking written in Borland Turbo C.

A few years later I wrote a similar but different work-for-hire menu
program for the now defunct Litigation Sciences Corporation in LA.
Turbo C again.

The April 1998 Troubleshooting Professional Magazine, themed
"Corporationally Incorrect", at
https://troubleshooters.com/tpromag/9804.htm#LINUX , featured yet
another typical Steve Litt boast:

"Don't like Unix commands and shellscripts? Make a menu to run your
machine. Heck, if I get 50 people wanting it, I'll make the menu
program myself."

That boast was made without one second experience with Linux, and
maybe 30 hours of Unix. I got my first Linux (Red Hat 5.0) in October
1998. That month I joined a LUG called ELUG, went to the meeting,
baffled them with my buzzwords, convincing all but one of them that I
was some kind of Linux guru. That one guy was a Unix veteran named
David Billsbrough, who acted like I was a piece of gum stuck to his
shoe.

The March 1999 edition of of Troubleshooters.Com announced the
fulfillment of my 11 month prior boast. I called it UMENU, for
Universal Menu. David Billsbrough began using UMENU, and we discussed
him becoming a UMENU developer (he was a Perl expert). However, when we
actually tried to collaborate, it became problematic because he wanted
to remove my favorite feature (Prompted Argument Substitution), and we
kept rearranging each others brace placement and indentation. Also,
back in the late 1990's my philosophy was "All OOP All The Time"
whereas his was "OOP Over My Dead Body". With every passing year, my
philosophy drifts closer to his, and I'm proud to say more and more
modern languages are also drifting away from gratuitous adherence to
OOP. Simula and Smalltalk were good for certain situations, but in my
opinion they led us on a 50 year detour over a bumpy road.

In 2004 David Billsbrough came to me with a series of desired
enhancements at a LEAP (Linux Enthusiasts and Professionals, GoLUG's
parent). We sat at a table with him on the left dictating specs and my
incorporating them. This led to the following additional keystrokes:

? : List magic keys
: : Refresh screen
= : Go to top level menu
@ : Show Umenu configuration

On 10/13/2004 Umenu 0.7.0 was released with all these features, plus
many big user interface and coding improvements. All this historical
information comes from 
https://www.troubleshooters.com/umenu/progress.htm .

Some time in the mid 00's I gave up on Perl, switched to Python, and
rewrote UMENU in Python but never published it, then quickly wrote and
published a UMENU in Ruby in 2005. In 2011 I rewrote it in Lua, which
in many ways I consider the best language I've ever used (caution: I've
said this about Turbo Pascal, Perl, Python, Ruby, Lua, Clarion, and
then moved on to find something I liked even better).

By 2004, UMENU menu config depended on a tab indented outline written in
a proprietary-to-UMENU language called EMDL (Easy Menu Definition
Language). It was anything but easy, it was tricky, and required
pre compilation through my EMDL-to-mnu program after every EMDL
change, which is a hassle. Also, Derek Konigsberg rightly criticized me
for not having UMENU run directly on the EMDL file, which was
impossible due to the need to parse the whole outline before starting
up the program. David Billsbrough refused to use EMDL, and still
hand-creates his .mnu files (and still uses UMENU1). I decided the
whole EMDL thing was bogus and decided to use a Unix directory tree as
a hierarchical database, because the Linux/Unix/BSD filesystem is
efficient enough to work right off the directory tree without
precompilation, and also much easier to learn than EMDL. In 2016 I
rewrote UMENU to use the directory tree, declaring it UMENU2.

In 2020 I considered rewriting UMENU2 in Cobol while considering being a
Cobol hired gun, but the demand for Cobol programmers to replace the
dying Boomers and Silent Generation quickly dried up. Since then I
considered rewriting it in Harbour (a modern day Clipper substitute)
but decided Harbour had no future.

After my introduction to Rust, I continued liking it more and more over
a year and a few months, and a few days ago decided to rewrite UMENU2
in Rust. After thinking about program design for several hours, I
concluded that I couldn't think of an object oriented way to do it with
Rust, and even a data-centric focus would be challenging for me, given
that my increasingly bad anemia had negatively affected my thinking
ability, so I decided to do it with functional composition. So far, so
good, and I'm learning a lot about Rust.

After finishing the UMENU2 in Rust project, it's possible I'll create a
user friendly UMENU2 menu constructor. If I do that and do it well,
UMENU2 becomes something that many, many people can use.

Long answer for to a very short question :-)

SteveT

Steve Litt 
Featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques