Part II

In more detail, I had to pick an operating system I would use as the main one for my work -- I picked Windows. Then I had to pick a compiled language -- I picked Visual Basic .NET (VB).

Then to develop VB code I discovered that actually the VB compiler is in file VBC.EXE. Then if install .NET Framework 2.0, 3.0, 3.5, 4.0, etc., in each of them is just one file, VBC.EXE, and it IS the VB compiler. To run it, just RUN it by having a simple script give the full tree name on a 'command line'. The options needed are minimal. The compiler seems to be fast and to generate small EXE files. I find the error messages to be good. So far I've found no bugs at all. It's easy to suppress many sources of problems with just the source code statements

Option Strict On

Option Explicit On

Works fine. For MY work, I don't see that an IDE could be much better.

For interactive debugging? So far I've not needed it and have not looked at what is available.

Why VB? Because it has very little 'idiosyncratic syntax' and more generally is easy to read on the page, and it offers essentially full access to .NET and its ASP.NET for Web site development and ADO.NET for relational data base access. Its 'object model' based heavily on 'interfaces' is SIMPLE but powerful enough. Its 'managed memory' can be a big help. The complier is fast. The complied code is plenty efficient. Good enough. Decision done.

For an IDE, I've seen several of them. Each is a complicated new tool to learn with a lot of time and effort for the learning. Generally the documentation just SUCKS: E.g., I never could find any clear statement of what Microsoft meant by a 'dockable' window or why I should care, and I very much did NOT want to figure it out.

Then there is the issue of how to write macros for the IDE and/or how to script the work, and I've so far never seen how to do that or any reasonably clear documentation for how. Then there's the issue of what the heck is the IDE doing for (to!) me -- I don't know, and won't know. And when what it does for me no longer works, guess who gets to diagnose and fix the problem? So I would be depending on something complicated I don't understand and, then, have to fix it, when I don't understand it. Then in the first few trials I saw that just for a program "Hello World" the IDE created a big subdirectory tree with maybe 50 MB of who knows what the heck; when things didn't work, I'd have to work with all that glop, gorp, and goop -- NO THANKS.

Uh, long ago I discovered that the key to 'ease of use' is not some tool doing a lot for (to) me but just a tool that is reliable, well documented, easy to 'script', and easy to understand. Thus, I don't want an IDE! Uh, in my kitchen, I REALLY like my 10" classic French chef's knife and various cutting boards, and I want no Rube Goldberg contraption just for cutting onions, another just for slicing carrots, another just for shredding cabbage. Similarly for software tools.

The matrix omitted some of what I do consider crucial in programming:

First, in the work, what is most important is the significant 'meaning'. There is, so far on this planet, exactly one way to record and communicate meaning -- a natural language, and of these, now, the most important is also my native language, English. So, I want the important 'meaning' to be recorded and communicated in English. Math? Actually, when done well, e.g., by P. Halmos, it is written in complete sentences. Same for mathematical physics. The symbols? They don't mean anything until carefully described in the natural language and, then, remain essentially as just abbreviations for the natural language definitions, descriptions, explanations, and examples. To be more clear, the symbols and the source code, without the English, mean NOTHING, mean zip, zilch, zero. Don't fool yourself into thinking otherwise. I don't say this because I like English literature (I HATE it) or hate math (my field is really applied math, and I do like it); I say this because it is what I have concluded is true. Knuth's old idea of 'literate programming' may be close.

So, some of the best examples of how to communicate 'meaning', ESPECIALLY about technical material, in English are in good college texts in, say, math or mathematical physics.

That's where we have to start on 'meaning'.

Second the work of software is to create 'systems' that have useful 'meaning'. So, this meaning needs to be recorded and communicated, for both developers and users, in English. There is NO substitute: Here are software techniques that are sometimes helpful -- long, mnemonic symbol names; pretty printing of source code; software 'objects'; IDE GUI 'panels'; software 'functions' and/or 'functional programming'; 'declarative' programming; desktop GUI UI 'icons' and 'windows' -- but none of these has meaning or is a substitute for English for recording and communicating meaning. Sorry 'bout that.

In particular, to me source code should read much like a good college text in math or mathematical physics. So, the English is in the source code 'comments'. On first reading the source code file, read just the comments. The code itself has no meaning. Even 'object oriented' code with long, mnemonic symbol names has no meaning. The meaning depends heavily on the English in the comments. In well written software, between the code and the comments, far and away the comments are the more important.

Commonly well written technical material has references that provide support for smaller details. Good. So source code should have such references, and mine does: My code is awash in file system tree names of files of documentation, mine or otherwise usually an HTM file of a Web page. For my source code in my favorite programmable editor, one keystroke displays a reference.

All the crucial issues, e.g., checking the inputs, the 'edge cases', issues of 'memory leaks' and threads, should be discussed in English in the comments with explanations of how the issues have been handled.

Yes, more important than code with English comments can be 'external' documentation all in English with no code at all! Then, of course, in appropriate places the code comments will reference the external documentation.

Net, by far the most important typing in software is the English documentation, NOT the 'code'.

For 'source code control systems', I can believe that in some projects, although maybe ones a bit too large to be effective, such tools could be useful. However I've been on significant software projects with eight or so people, and we did well with no such tools at all.

For my work now, everything particular to some one 'version' of the software is in a file system directory subtree. Then for a new version of that software, I start by just making a copy of that subtree; then I document, right, in English, the purpose of the copy and go to work on the copy. Works well.

Next, to me the most important lesson in work that needs software is to be clear on what the work is and what contribution the software is to make to the work.

Next, for the software, the most important need is to describe what, in terms of the real work, the software is to do.

Next, within the software, the most important step is to use 'divide and conquer': At one point in Rome in the Middle Ages, there was a big project to move a large, stone monolith some dozens of feet in a plaza. Big project. Complicated. Expensive. Famous.

But, before getting too impressed, how the heck did that rock get there in the first place? Over 1000 years earlier, Caligula's slaves cut the rock as one piece somewhere in the headwaters of the Nile, floated it down the Nile, across the Mediterranean, and to Rome and put it in place.

How'd they do that? They used 'divide and conquer', that is, broke the whole project into pieces, broken into pieces, etc., until each of the pieces was doable. What else? Summon spirits from the vastly deep?

Same for software: Break the work into doable pieces. Hopefully each piece is easy to understand, document, code, test, and modify and likely changes in what the software is to do need affect only a few pieces. That's it.

Next, for getting people productive in programming, my experience is that someone, maybe the project leader, needs to have cut through the millions of acres of swamp of glop, gorp, and goop and gotten the work and the tools all simple, clear, and easy to understand. Then can take a bright, well motivated person with no background in programming at all and in a few hours of instruction get them quite productive. The person needs to know how to read with understanding, learn, analyze, and create meaning by writing English.

So, in interviewing, I want such a person. 'Dynamic programming' and Knuth's 'Sorting and Searching' or 'functional programming'? I don't care.

How 'bout that!