jadero

For me, Unison is basically inscrutable. I know that part of it is that functional programming is 100% completely brand new to me, so there is just too much to take in all at once.

One of my retirement projects is to learn functional programming. I'm hoping that will be enough to get me far enough along to be able to figure out the other parts.

I found that starting with a "critical path" analysis was very useful. Basically, identify which components or activities need to be at least somewhat functional in order to deal with a different component or activity.

This gives you a list of problems you have to solve in the order they need to be solved. That is, there is no point spending time on writing to disk until you've figured out what you're writing to disk and how your going to collect whatever needs to be written.

Virtually every critical path will have some easy stuff on it that needs to be in place before the hard stuff. That gets you (or at least me!) in the right frame of mind and builds momentum towards the goal. I've often found that doing the work leading up to the hard part made the hard part easier, at least partly because there is now a concrete problem ready to solve instead of a nebulous wondering how to approach it.

Note that if you try this approach, make sure that you avoid the common practice of building "placeholder" stubs for anything other than components further along the critical path than your current position. Even with that, I found little value in stubbing something in before I was actually getting close to the point of needing it in order to continue working.

Note that this process doesn't mean it's not appropriate to go ahead and identify where the dragons are and check to see if you have what it takes to slay them. Back to my example of writing to disk, if you've never written anything to disk before and it looks scary, it might be a good idea to create a completely unrelated toy project to learn and practice that specific skill. After all, if it turns out to be impossible to write to disk, there is no point starting a project that requires it. I find that these toy projects are simple in the sense that there is only one thing to worry about, so you're already doing the easiest thing available.

The left side (linear) looks like the code I write while I'm trying to figure out whether I understand the problem or I'm not quite sure what all I need to do prove that I can (or cannot!) solve the problem.

The code on the right, with all the "abstractions" looks like the code I end up with after I've got everything sorted out and want to make things easier to read, find, and maintain.

I actually find the code on the right easier to read. I treat it like a well written technical manual. For me, understanding starts with time spent on the table of contents just to get a sense of the domain. That is followed by reading the opening and closing sections of each chapter, and finally digging into the details. I stop at any level that meets my needs, including just picking and choosing based on the table of contents if there is no clear need to understand the entire domain in order to accomplish my goal.

I've preferred code written in that "abstracted" style since discovering the joy of GOSUB and JSR on my VIC-20.

Do these people know something I don't? I can't imagine how the mutterings of the mob can be valuable beyond providing a place for us to connect.

And for those intending to use this to improve customer service, I can't imagine how putting yet more barriers between the decision makers and the customers will help anyone other than the decision makers.

Ok, thanks! That looks like a good start for me.

We're getting closer to winter. I've got most of those preparations done. "Just" have to finish building the heater for my shop. My programming based project list is coming together: learn me some Rust, contribute some documentation to a project I'm following, look deeper into the potential of the Accessibility tree. That should keep me busy for a while!

Looks kind of simple to me at first glance...

Well, it has been a decade since I've done anything other than dig holes (literally), drive school buses, and work in my shop. :)

Thanks for the jump start. I'll add this to my ever growing list of tech stuff I'd like to tackle in my retirement.

Nice! That Vlab software looks very interesting. Way back when, I built some primitive tools to help me play with L-systems, but I'd never have dreamed of taking it that far.

Have fun!

Thanks. This is the first I've heard of the Accessibility tree. A quick look kind of spooked me, but I'll dig deeper.

Track down a copy of "The Algorithmic Beauty of Plants". The last time I looked, it was available as a free PDF, too. I think it's a great introduction to L-systems.

I got it when it was first released and spent way too much time poring over it and generating imagery on my decrepit old computers.

I've never looked at plants the same since.

Old fart warning!

Presentation is left to the reader's client. Do you want dark mode? Get a markdown editor/reader that supports it. Do you want serif font? Again, that's client's choice and not part of the document.

I remember when that is how the web worked. All that markup was to define the structure of the document and the client rendered it as set by the user.

Some clients were better than others. My favourite was the default browser in OS/2 Warp, which allowed me to easily set the display characteristics of every tag. The end result was that every site looked (approximately) the same, which made browsing so much nicer, in my opinion.

Then someone decided that website creation should be part of the desktop publishing class (at least at the school I taught at). The world (wide web) has never recovered.

That was a good read. One thing not explicitly addressed is that this failure is not just about duplicate waypoint names, but about converting between sparse and dense data. In this case the problem was in converting dense (higher resolution) to sparse (lower resolution).

Knowing nothing about the systems involved and not really following the proposed solution, I can only ask a question: Is the dense data fully available and understood by the engineers doing the conversion?

If so, the conversion software can start by identifying the entry and exit points in the source (dense) data. (Start at beginning and look for the first "UK" entry to get the entry point. Start at the end and look for the first "UK" entry to get the exit point.) If there is no match in the destination (sparse) data, search outward for matches. When matches are found, these represent the actual entry/exit points within the limitations of the sparse data. (Perhaps this is exactly what the proposed solution is doing!)

If, as I understand, there are no duplicate identifiers within a region's span of control, that should be the heart of a general solution that then "digs deeper" to check for fragmentation (flight plans that enter and exit regional control multiple times).

Or maybe I understood less than I thought and am completely out to lunch. :)

The paradox is that people don't actually implement agile methodologies but rather try to shoehorn them into their waterfall mindset.

After several decades and several methodologies in a number of fields, I've concluded that very few actually think methodologies are useful. It's always pick and choose or mix and match the various elements. This is all driven by the belief that my business is a special little flower and needs it's own custom little process that only I can invent.