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.
Disagree on much of this, unless I've misunderstood you. No interactive debugging? I can't imagine adding print/log lines for every imaginable variable in a scenario. I love being able to drop a breakie and inspect an object from the inside out.
Ditto for source control. It's fantastic to have a complete history of changes with date and blame attached, along with comments for explanation. It's like an automatic logbook for the code, with free unlimited "undos" to boot. I can't imagine working without it, even in a one-developer project.
Perhaps I'm just spoiled -- AKA "Kids these days can't lance a pimple without an automatic vibrating scalpel with drain and suture" -- but these are the tools that make me more productive. I can do more better in less time.
I'm not a fan of English docs either; they fall out of date very quickly. I'd much rather have readable code, with things like sensible variable names and readable conditionals like if(noUser || userIsBusy) instead of if(user==nil || [userObject state]==kStateWaiting). I realize that readable code doesn't mean no docs, but I'd rather my colleagues spend an hour coding than a half on coding and a half on docs. I've seen too much code where the comments are flat-out wrong.
On interactive debugging, it's terrific stuff when it's needed. I've done a LOT of programming, and a few times I've used interactive debugging: When I needed it, it was terrific.
Net, I just haven't needed it very much. On my current project, I haven't needed it at all yet. I believe that I've written the challenging code, and I had no problems with debugging.
For some of the trickiest parts of the code, I just coded the operations twice, once a simple, slow way and once the faster, trickery way I wanted in the final version; then I had the code compare the results. I ran enough test cases to have good confidence that the two versions give the same, and correct, results. If the results were not the same, then to find the difference, instead of interactive debugging, I would have just 'desk checked' the code carefully. I find such desk checking terrific stuff -- each little possibility for a problem has to be checked, and sometimes more than one error is found. With interactive debugging, I can be tempted to quit checking when the first error is diagnosed for just that one test case -- not so good.
Or, "Joe, there's a bug in here somewhere. Find it with desk checking."! Or, "Mary, Joe says that this code is correct. Here's $1000: If you find an error, then you get the $1000; else Joe does."!
I wouldn't have coded just the tricky version and then tried to use interactive debugging to be sure the version was correct: My test cases were too extensive for checking 'interactively'.
For "I can't imagine adding print/log lines for every imaginable variable in a scenario.". I don't do that either or need to. Occasionally a few print or log file writes, in a small part of the code, say, where I just added some code and something doesn't work, have been enough.
Generally, though, any reasonably complex system should be able to report, at levels of detail requested in real time, what it is doing, and a lot of print or log statements are a start. In my most important code, I have such statements controlled by a variable that specifies 'message level', that is, the 'level' of detail of the messages. My intention is later to use Microsoft's code instrumentation infrastructure to send the contents of such statements to some 'system management' platform. So, generally I like 'messages' from code.
And, actually, in my testing, I have lots of such print statements executing. The output of a small test case can be some thousands of lines, and I explore them with the capabilities of my text editor; I wouldn't want to do that work with interactive debugging.
E.g., recently I had to reinstall the Microsoft software on my boot drive (grim story) so wanted to be sure my code would compile and run as before. So, for each directory of code, I made a copy of the directory and in the copy again ran the relevant scripts to compile the code and to run it on the test cases. Then I took the output, with its thousands of lines, and used a simple editor macro to do a line by line comparison of the new and old output files. Some lines were different because of time and date stamps or reports of allocated memory addresses. A few editor commands removed those lines, and then the old and new output compared perfectly. I can't see any easier or better way to do such a test; I want the print statements and don't want interactive debugging as a substitute there.
To me so far interactive debugging is so unimportant I haven't even taken the time see what is available with VB. I believe that somewhere I saw that VB has interactive debugging also via command lines; if so, then that should be the most I would want. But I haven't even looked.
Here are my 'source control' tools!
First, if I am making any change at all in an old program or any significant change in a program still under development, then I start with a new file. So, if the last version of the program was PROG013.VB, then the next version is PROG014.VB; that is, I copy file PROG013.VB to file PROG014.VB, put some explanatory documentation at the top of the file, and start making changes.
I don't don't even see the "014" -- I have an editor macro find that for me! My editor gives me a directory listing, and one keystroke sorts the files in descending order on time, and then PROG014.VB is right at the top of the list ready for work!
You mentioned "undos" -- that's PROG013.VB! Of course another source of 'undos' are the daily incremental disk backups! And another souce is just my text editor.
Second, for making changes in a program, typically I slap a time and date stamp on the change. So my editor does that, e.g.,
Modified at 01:32:46 on Wednesday, December 1st, 2010.
For source code files, the editor puts this line in as a comment, choosing the comment syntax based on the file extension.
So, I get time and date stamps, and that's close enough for me for a "logbook" of changes!
For "comments for explanation", I'm big on those!
For "I'm not a fan of English docs either":
Well, fundamentally there's no alternative: Again, as I wrote:
"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."
Fundamentally, that statement is just true. Sure, with enough detective work, decoding, etc., people commonly guess at the meaning given much less than what I described.
Other aids to understanding the meaning include mnemonic symbol names, pretty printing, and your "readable" code. Still, at least fundamentally, these aids cannot replace English as the source of meaning.
You wrote
if(noUser || userIsBusy)
Okay. For using English documentation, I gave as examples college texts in math and mathematical physics. In such books, the symbols are carefully defined and maybe also motivated, discussed, and illustrated. Then commonly the exposition can continue with some 20 lines of algebraic derivations without additional English. Your statement 'if' can be seen as parallel.
For your symbols
noUser userIsBusy
likely somewhere you specify the data 'type' of these as 'logical' or some such, and then your code can be plenty clear.
Yes, keeping the English documentation up with the code is a pain:
For an on-going development project, it can be tempting to rely on the fact that the team does know the code and delay a lot of documentation. But if the project goes on for many months, then staff can leave and leave the project short on what parts of the code 'mean', and new staff can arrive and be lost and nearly useless.
Further, at some point development slows and the software becomes an 'asset' of the company. For continuing value, there needs to be enough documentation so that a new team could with reasonable efficiency take over and 'maintain' the code. So, that new team needs, typically, quite a lot of good English documentation, both as comments in the code and as an external paper. So, before the original development team goes on to other work, it can be important to take one more pass over the code documentation and get it up to date and clear. Sorry 'bout that.
Generally on code and its internal documentation, Knuth's work on 'literate programming' is one polished way to proceed.
In particular, for the code I wrote a year ago, without reasonably good documentation I wouldn't know what the heck the code does or what I was thinking about.
Here's a related point on IDEs: Of course, can use SQL Server Management Studio to 'define' a database, that is, say what the tables are and for each table what the columns are. Yup, can do that! But I refuse to!
Instead I define the database using the T-SQL statements in a text file, and here's why: The text file has about as many blank lines just for 'readability' as T-SQL lines. Then the comments are about five times as many lines as the sum of the blank lines and T-SQL lines. These comments explain what the heck I had in mind for that database 'schema' (in the traditional sense, not really in the sense of SQL Server 2005 and later). So, when a table has a clustered key and also a separate index, the comments explain why. Etc.
So, that 'schema' with its documentation is a rock solid part of my project; as I write code to manipulate the database, all the code writing draws from the ONE, SAME documentation of the database as the code should.
If I typed the schema into the SQL Server Management Studio IDE, then I'd miss out on the documentation and the primary source of crucial 'meaning'.
GUIs have often been praised with "What you see is what you get", but there is a perceptive old response, "What you see is all you've got.".
Or, using SQL Server Management Studio to type symbol names into text boxes just does NOT create the crucially important meaning.
Sure, one way to be sure that English documentation is not "flat out wrong" is to omit all the English documentation! But I suspect that if you were to maintain code written by someone else, then you'd rather have more English documentation, possibly with some errors, than less.
Yes, important, undocumented code can be a form of job security! But for my 'job security' I want the code well documented because in two years the code may need some changes and I may be the person who has to make them.
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!