Back in my day…

A discussion in the U2 forum got me thinking. When Pick people talk about how great Pick is, what’s really happening is that they’re holding on dearly to simpler times in the face of the onslaught of the modern world. Our generation is no different than those that came before us. It’s kinda fun to see it play out.

Snipped from David Jordan in thread “Reliability doesn’t raise enough issues to keep the list busy”:

80% of my code is in UniBasic and 20% in .Net… I agree we should not do everything in U2, but I wish some of the other environments kept it simple too. … with .Net, suddenly I hit strange problems …. Hence I spend a lot of time on .Net forums seeking solutions that I just don’t need to do with U2. Buggy may have been a bit harsh, but there is an issue of consistency and dependability of development.

Postioning a character in a 80×24 screen where the input is synchronous requires nothing more than a CRT and INPUT statement. 20 years ago that’s all people wanted. Today, yes, it does take much more knowledge, code, time, and money to render a GUI and accept input in an event-driven, asynchronous, software-drive client over a multi-tier topology that we often don’t control. That has nothing to do with the data storage which still ultimately happens with READ and WRITE statements.

What David describes, and what a Lot of people describe in similar words, is increased complexity and related challenges necessitated by user demands. What I’m hearing is the lament of a developer (like most of us) who was spoiled with primitive technology, the CUI (Character User Interface), that few people want to see in modern times. This is evolution in our field of choice. Despite claims of being easy, none of the modern stuff is or ever will be. It’s not the fault of the technology, that’s just life, man. Every generation complains about this. As anything gets more complex, the problems increase commensurately with the features. But that doesn’t mean the technology is “buggy”, just that the number of “anomalies” is higher. I don’t use “anomalies” as a way of avoiding the word “bug” but as a way of encompassing all of the things that we need to deal with.

I think the incidence of such anomalies may not be unusually high as a ratio when compared with the size of the supporting code set and the features that the code supports. In other words, if 10 lines of Pick code does X and we have 1 anomaly caused by 1 line of code, the ratio is 1:10. If we have 10 thousand lines of object-oriented code in a multi-tier framework supporting a multitude of functions, and there is 1 anomaly, we’re still doing pretty well, because that code set is relatively, and by necessity huge. The anomaly might still be in 1 line of code, but of course finding it takes a Lot longer.

Let’s further clarify that it’s not just .NET, which seems to be the popular poster child whenever people talk about complex modern development and related problems. The same applies to Java, PHP, Ruby, related frameworks (for which there is no consistency and never-ending instability) and all of the various databases as well.

It’s also interesting that Pick people are still complaining about the modern world in the year 2011. This world has existed in it’s current incarnation for about 15 years. An entire generation of developers has no idea how easy it was to use BASIC or even Fortran or COBOL. Instead of adapting early and leading this pack, Pick people are moving grudgingly and continue to get pulled forward. (Yes, “forward” can be argued, but let’s go with it for now.) Similarly, while the world has turned upside down in terms of the UI and connectivity, the MV DBMS model at the core remains largely unchanged over decades. I think most of the MV DBMS vendors have wasted a couple decades of lead time. The Pick model should have evolved at the core to remain as cutting edge as in the heyday (when there was virtually no competition), but everyone has remained content with the status quo – until our lunch started to get eaten by the other guys, and then we gripe about how complex everything is.

Referring back to David’s quote, I agree with the 80/20 rule, and in fact, over the last decade I’ve learned that it’s best to try to keep that ratio, even though I happen to sell modern tools and development services. I believe part of my value-add offering is educating my clients about when NOT to use all of these technologies that I like to discuss. In other words, working “with” the modern world doesn’t mean we need to use mainstream tools exclusively – we can still be modern, mainstream developers as long as we understand all of the tools and make judicious use of them. (My “right tools for the job mantra”.)

It’s time for an on-topic humor break. A crochety old guy speaking…

Back in my day telephones had wires. Ya couldn’t lose um. They didn’t have an operating system that required updates. And ya couldn’t brick um by hacking to root. Why, back in my day ‘root’ was something under a plant and a brick was in the wall. I didn’t need to go to a store to get a headset for my phone because I could just pick up the blasted thing and hold it to my ear. If we wanted to know the weather forecast, we didn’t load some “app”, we’d look out the window or wait for the evening news. And then we’d sit around the tube and Talk like a real family, instead of “texting” the weather report from one side of the room to the other. And if we needed a phone number we’d open the Yellow Pages — yeah sonny, I said it, we’d crack pages and read a book!

Well folks, that’s us. And anyone who denies being that guy on the outside is probably still a little like that on the inside. As always, my motto is “lead, follow, or get out of the way”. If we’re going to continue to support our families over the coming decades, we need to roll with the rest of the world. Just because the world is more complex doesn’t mean it’s more broken or that what we have is better. And even if it is more broken and what we have is better, get over it, we still need to work with the rest of the world.

So, is anyone doing anything cool with MV in combination with other tools lately? I think I am. But you’ve heard enough from me for today. 😉

Tags :

4 thoughts on “Back in my day…

    • Back in my day there were 3 compelling reasons to choose pick. It was so efficient you could have multiple users on an AT class PC. The development was hassle free, no data types to trip you up, easy file I/O. Code was easily portable between licensees. Today efficiency counts for little unless you’re the NHS or Amazon doing millions of transactions a day. You won’t be coding in DataBasic for the web stuff so hassle is back. Different methods of interfacing for .Net and Java mean portability is gone. Remind me, why choose Pick today?

    • Thanks for taking the time to register and post your comments!

      I disagree with “You won’t be coding in DataBasic for the web stuff”. What I’ve learned from creating MANY web interfaces is that we really don’t want the business rules in the client or the middle tier. We want those rules and the database manipulation back on the server where it’s always been. Sure, there are some things we can do off-server to save net transit time. But when it comes to heavy reading, writing, and processing data, I choose not to do this in a cool middle-tier framework that supports CRUD and other fancy features. I keep the UI and middle tier as thin as possible and pass just about everything to the server for processing. The CRUD tools and class generators have their place, but as usual they are not universal solutions.

      For multi-tier development sometimes a decision needs to be made about where to put a code segment. For example, do I pass field X and Y to the server to test them, or do I test them in the client or middle-tier? Do I pass X to the server so that it can read and test with Y, or do I pull Y from the server, save the burden of passing in X, then test X and Y in the middle tier? Those sorts of questions are on the fringe. Most complex operations are a no-brainer for the server. We’ve got a great engine and we should use it.

      THAT is why I personally choose Pick today.

    • 80×24? I use 240×78 on my desktop, 160×60 on my laptop, and code to accommodate any geometry.

    • Gaius, I was just using that as recognized short-hand for “character interface”. Thanks for your comment.

Leave a Reply