Not sure if anyone realized that the 1802 was a CMOS implementation of a TTL design. The 1802 wound up in a lot of embedded designs including silicon-on-saphire implementation.

The modularity reminds me of modded Volkswagen dune buggies. Making a platform that can be upgrade, modded and even repairalble will spawn a lot of third party jobs especially if the numbers grow. Someone might even make a body that looks like a Cyber Truck.

A better question is why convert from COBOL at all. COBOL is far from dead and getting programmers costs one thing: money. Any decent programmer can learn to code in almost any language. The harder part here is working with existing code and trying to define what will work with other systems including the internet. This is already being done so why this big push to change it? Is there some wonderful feature that a new coding language will bring to the table. Likewise, what are they planning on coding in? C? Talk about archaic languages. The massive job and short timeline is a sure fire way to totally mess up the system which is probably the real reason for doing this.

If it was an interest bearing account they should at least get the interest for a few minutes.

Ada/SPARK are ahead of C++ in this area by a significant margin. Rust is more focused on memory management but is woth examining as well. The hard part is incorporating any of those language features into C++ within the constraints of backward compatability. C and C++ still put too much dependency on the competance of the programmer requiring expertise to maintain quality even across functions and libraries. Any additions to C++ should improve a progammers ability to both specify their own code's functionality and understand what other's code does.

Where is my Pause and Mute button. I often want to stop the audio using pause and these days I tend to mute ads.

Ada is not slower than C or C++ and lots of Ada applications are designed to run on bare-metal. SPARK is even better as many of the checks that Ada might need at runtime can be eliminated if contracts are employed since the compiler can determine what values might be assigned at compile time rather than runtime.

I remember those times well and started with coax and modems. I am still debating about buying the book though as it is only hard copy, no ebook version and these days I have sworn off dead tree versions whenever possible. Given the topic, it is disappointing as LAN parties were part of the movement to virtual content. Hopefully a rendition will be made available as an EPUB but, in the meantime, here is hoping that a copy makes it to my library where I tend to pick up those physical incarnations.

It seems that the tools one uses is indicative of what they are used to. Post-it type notes are a standard feature of most decent computer-based readers and they are searchable. Can't do that with a post-it. Actually post-it notes are a limited tool even on a computer but it is easy to understand.

Actually they exist and it makes a lot more sense to put the recognition and recording in a smartphone that can be easily changed than in the source. It also means the same binocular can be used with different apps for different identification purposes.

"Your battery needs to be replaced but your built-in battery is cannot be replaced. Sorry, you cannot trade in a phone that does not work."

self-driving delivery. Of maybe a drop off via a drone. And a self-driving car can take itself to Amazon's service center and come home once service is complete.

In-person and remote work usually have the same goal in mind: to get the job done. Of course, there are typically a lot of things involved with the "job" such as teaching new colleagues and collaborating. Not having the right tools and environment can make this harder. The "open office" is really more of a cheap way of setting up an office than one that is conducive to work or training as it is rare that everyone in speaking distance wants to hear an extended conversation about training or chatter about sports.

Collaboration and training takes interaction and that is something that needs to initiated on a regular, not necessarily scheduled, basis. Remote workers often need to be reminded or have a regular way of initiating conversations which is often overlooked versus a "watercooler" discussion.

Tools like Zoom make a big difference. Take it from someone who grew up with telephones and modems. Still, you need to remember to turn on your camera and keep your group interaction small if you are looking for one-on-one interactions. It is surprising these days the number of people that keep their camera off and their microphone muted when they don't have to. I am not talking about the large one-way training sessions but the more intimate discussions of two or so people. The excuses are numerous but like being in person but sitting on the other side of a cube's wall. Think etiquette.

I find a lot to agree with in your comment. I suggest those interested in a better C investigate Ada in addition to C++. It is amazing how many are trying to create a better C and overlook the fact that the alternatives already exist. They are just not as popular because "they are not new".

I also find it interesting that many of those involved in designing these new solutions have not done a better job of learning about these existing alternatives to understand the features and implications that they are trying to incorporate into their new language.

I also wonder about the many excuses for not using a particular language are common regardless of which you choose compared to your current one such as a different syntax, need to learn a whole new language, etc. The article, 11 Myths about Ada, highlights some of these issues with respect to Ada.

Rust is the darling because of some good features but also because it is new and shiny. It is also going through improvements at a significant rate. On the other hand, SPARK/Ada has a long track record and has commercial support and a few things that Rust does not including contracts that are worth investigating if you don't know what they are. SPARK is the statically provable version of Ada that would go a very long way to improving the reliability and security of Linux by putting more of the detailed checking that is done by people into the compiler. Linux is massive and the relationships between components is equally taxing to developers trying to ensure that the system is bug free. Contracts are only one aspect of Ada that makes it a good programming language but that alone should make it a consideration.