The Lounge - CodeProject

kalberts9-Nov-18 2:34

9-Nov-18 2:34

As a general rule, people showing the kind of hashness as you do, toward one tool (or standard, or whatever) tend to have a poor understanding of how to use it. Or they consider it out of its intended scope of usage.

A number of years ago, I switched jobs, from a Solaris environment to a non-*nix-environment: I really never made friends with Solaris. Nor with the company standard editor emacs. I made both crash quite regularly. More than once, I demonstrated to my colleauges what I had been doing. They looked over my shoulder, and screamed out: Hey, you mustn't do THAT! What the h** did you do that for? Well, I did it to show you how I made Solaris crash (or emacs)... This happened several times, and every time they made me the cruel sinner who didn't know to behave, and ruined their concept of Solaris as the worlds most rock solid OS. Well, it was - as long as you didn't do anything that could make it crash...

In my new job, they were running a different OS (this was before Windows became the only alternative; it was in mincomputer/supermini area), which crashed several times a day. The Unix educated sysops did everything to make Sintran III appear as if it were Unix. I happened to know Sintran III well, so, as a left hand job, I became sort of sysops supervisor, telling them the proper way to maintain a Sintran III machine. I spent a week or two cleaning up the procedures. Three months later, some people were still complaining about the frequent crashes, and I had to drag them over to show them the system logs: The system hadn't had a single stop for three months.

Systems, languages, methods ... may be severely misused, abused, used in inappropriate ways or for inappropriate purposes. That doesn't mean the poor abused thing is evil, despisable or even bad. What you could say is that "X is not suitable for application Y, because it lacks a suitable way of doing A, B and C" (maybe it does have a provision, but for reasons 1, 2 and 3, that provision does not fulfill our requirements).

Any system, language or method that is widely used, is well suited for a certain class of tasks. Otherwise it wouldn't have been widely used. There may be other tools that would also be satisfactory. If you went into those environments using the tool you hate, presenting your arguments, you might learn that you hate reasons are not valid there.

E.g. lots of software people argue for open source, but lots of tool users would never ever consider looking at the source code of the tool. Or cost: You may save a thousand dollars on not paying for Visual Studio but sticking to emacs: How many man days saved does it take to pay for the software? Will the software save that many man days? (For VS, it has paid its price many times, compared to emacs, in my case.) Adaptation to established procedures: I have rejected a good handful of tools because the UI did not communicate in established professional terms and/or didn't support established work procedures or standards. The software developers just made their best guess.

To illustrate this with an experience of my own: In the old days when we had needle matrix printers with an ink ribbon, I was teaching a week long course, introducing computers to office workers who had never seen any more advanced tool than an IBM Selectric before. I taught them on screen editing, automatic text justifation, chapter numbering and TOC generating - all the things that we, as developers, were proud of. The last hour was reserved for reactions and comments to the course. The first thing that came up, and the only thing that all the participants agreed about, was the color of the printer ribbon! The black was almost bluish - cold, unfriendly. Would it be possible to get a more brownish ribbon, to give their correspondance a warmer, more friendly impression?

That was an essential point for the acceptance of our office automation system! Lots of systems succeeds because they e.g. provide (high quality) translations of the UI. That they use the right terms. That the end users understand what's going on.

I never used VB, so I can't tell why it has been so successful. I guess many of the reasons are non-technical. Then again I could say the same about other system that is used within the software business, such as the Internet protocols: They certainly didn't succeed becase they were the best designs, but 99% for non-technical reasons. Then entire "C class" of languages: The same. You won't be able to point out technical merits that can explain why the "C class" came to dominate the programming world. Then it is not fair to condemn VB purely on its technical merits (or lack thereof).

Welcome to the Lounge