DEV Community: Mike Nakis

Why do you prefer using a scripting language?

Mike Nakis — Sun, 27 Nov 2022 10:46:57 +0000

Scripting languages have seen tremendous growth in recent years. CodingNomads ran some stats on job postings on Linkedin (see cover image) and found that from the top-10 programming languages in highest demand in 2022, six of them are scripting languages.

Why do you choose to program in a scripting language rather than in a real programming language?

Please tell us your reasons.

To help you get started, here are some ready-made options:

It is easier to learn.
It is easier to be productive.
It gives fewer errors.
I do not want to have to wait for it to compile.
It does not require an IDE, I can just use a text editor.
I do not need type safety, because I do testing.
There exist lots of libraries for it.
I can modify my program as it is running.
It is the only option on the browser.
It is easy to find a job doing it.
I have not learned any real programming language.

Are there any tools for visual software design and automatic deployment?

Mike Nakis — Thu, 25 Aug 2022 12:25:00 +0000

I really hope that the collective intelligence of dev.to has answers, because this is the type of question that you cannot ask on stackoverflow.

The question is exactly as the title says. The following text provides context, but if you already understand what I am after, you can skip it.

In 1992, when we saw Visio for the first time, and we were hoping that one day we would be able to use it for creating software design documents visually, and then deploying them with the press of a button. Visio is a general-purpose diagram-drawing application, so it cannot do that, but it has always supported linking and embedding, so in theory it could be used for this purpose by a specialized software design tool. However, I have never head of any such tool.

In 1993 Microsoft announced the successor to their Microsoft C/C++ compiler, and the name of the new product was going to be Microsoft Visual C++. The term "visual" in the product title got our hopes up that it would include some visual design tools, but when we finally got our hands on it, we realized that it is just another command-line toolset, and the title was just marketing deceit.

In 1997 Microsoft announced its first Integrated Development Environment, and the name of the product was going to be Microsoft Visual Studio. We had been hoping that it would have Visio embedded in it for use in visual software design, but nothing of that sort happened.

In 2000 Microsoft bought Visio, but instead of integrating it into Visual Studio they made it part of Microsoft Office, so apparently Microsoft is moving in directions unrelated to visual software design.

In the mean time, various "Visual Programming Languages" have been created, such as Snap!, EduBlocks, Blockly and Scratch, which are cute, but what they facilitate is visual programming, not visual design.

Since 1996 UML has been trying to standardize the notation used in software designs, but notation has been the least of our problems. Some UML tools are allegedly capable of bridging the gap between design and implementation, but as far as I know they do it by means of skeleton code generation, which is almost always a very bad idea. (The "all design up-front" doctrine has been dead for decades now.)

Recently we have been seeing some visualization tools such as Lucidscale by Lucidchart, but they deal with a specialized domain (cloud environments) they only work at a very high level of abstraction (cloud components, not software components) and they tend to only be usable for visualization, exploration, and documentation of existing systems rather than design and deployment of new systems, or even modification of existing systems.

So, are there any specialized tools for visual software design that would allow us to visually compose a software design consisting of predefined software components, and then have that design deployed with the press of a button?

Note that "deployment" does not necessarily imply cloud environments and the like; deployment could also be the uploading of a binary image into an embedded device. So, I am talking about software systems of any complexity and scale.

Historical Question about Visio

Mike Nakis — Sat, 13 Aug 2022 16:27:30 +0000

According to the Wikipedia entry about Visio, at some unspecified time before 1992, a pre-release version 0.92 of Visio was distributed free on a floppy disk along with a Microsoft Windows systems readiness evaluation utility.

No other information is available about that floppy disk.

There are several mentions of this on the interwebz, but they all seem to be copies of the exact same text found on Wikipedia.

I was wondering if anyone could confirm that this was in fact a floppy disk created by, and distributed by, Microsoft.

The Mother of All Bugs

Mike Nakis — Sat, 13 Aug 2022 15:52:00 +0000

Summary: This is a story about the most elusive and sinister software bug I ever came across in my decades-long career as a programmer.

The Mother of All Bugs

At some point early in my career I was working for a company that was developing a hand-held computer for the area of Home Health Care. It was called InfoTouch™. The job involved daily interaction with the guys in the hardware department, which was actually quite a joy, despite the incessant "It's a software problem!" -- "No, it's a hardware problem!" arguments, because these arguments were being made by well-meant engineers from both camps, who were all in search of the truth, without egoisms, vested interests, or illusions of infallibility. That is, in true engineering tradition.

During the development of the InfoTouch, for more than a year, possibly two, the device would randomly die for no apparent reason. Sometimes it would die once a day, other times weeks would pass without a problem. On some rare occasions it would die while someone was using it, but more often it would die while sleeping, or while charging. So, the problem seemed to be completely random, and no matter how hard we tried we could not find a sequence of steps that would reproduce it.

When the machine died, the only thing we could do was to give it to the hardware guys, who would open it up, throw an oscilloscope at it, and try to determine whether it was dead due to a hardware or a software malfunction. And since we software guys were not terribly familiar with oscilloscopes, we had to trust what the hardware guys said.

Luckily, the hardware guys would never say with absolute certainty that it was a software problem. At worst, they would say that it was "most probably" a software problem. What did not help at all was that one out of every dozen times that they went through the drill, they found that it did in fact appear to be a hardware problem: the machine was just dead; there was no clock, no interrupts, no electronic magic of the kind that makes software run. But what was happening the rest of the times was still under debate.

This situation was going on for a long time, and we had no way of dealing with it other than hoping that one day someone either from the software department or the hardware department would stumble upon the solution by chance. The result was a vague sense of helplessness and low overall morale, which was the last thing needed in that little startup company which was struggling to survive due to many other reasons having to do with funding, partnerships, competitors, etc.

Then one day as I was working on some C code somewhere in our code base, I stumbled by pure chance upon a function which was declaring a local variable of pointer type and proceeding to write to the memory location pointed by it without first initializing it. This is a silly little bug which is almost guaranteed to cause a malfunction, possibly a crash.

To this day still I do not know (or do not remember) whether that early version of Microsoft C did not yet support warnings for this type of mistake, or whether the people responsible for our build configuration had such hubris as to believe that "we don't need no stinkin' warnings".

I quickly fixed the bug, and I was about to proceed with my daily work, when it occurred to me to take a minute and check precisely what were the consequences and ramifications of the bug before the fix.

First of all, I checked to see whether the function was ever being called, and it turned out that it was; however, the InfoTouch was running fine for 99.9% of the time, so obviously, due to some coincidence, the garbage that the pointer was initialized with was such, that writing to the memory address represented by that garbage did not seem to cause any problems.

Or did it?

I decided to see exactly what was the garbage that the pointer was being initialized with. To my astonishment, I discovered the following:

Function afunc() was invoking bfunc() and then cfunc().

In cfunc(), the uninitialized pointer was in the 5th word of the stack.

In bfunc(), the 5th word in the stack had been used to hold a... date-time variable!

So, the uninitialized pointer contained a bit pattern that represented a date and time. This resulted in random memory corruption during different hours of the day and different days of the month. The function was not being invoked very frequently, so the memory corruption was building up slowly, until some vital memory location would be affected and the software would crash. It is amazing that the machine ever worked at all.

After this bugfix the InfoTouch never again experienced any problems of a similar kind.

What do we learn from this? Warnings are your friend. Enable as many warnings as you can, and use the "treat warnings as errors" option to ensure that not a single warning goes unnoticed.

The original post on my blog: https://blog.michael.gr/2015/10/the-mother-of-all-bugs.html