Reviews for BASIC, fundamental concepts

The average rating for BASIC, fundamental concepts based on 2 reviews is 5 stars.

Review # 1 was written on 2016-02-05 00:00:00 Christina Colby A top-notch program requires a top-notch algorithm. Most of the books I’ve read on programming were for individuals; the older ones were for students who had access to university computers, and the more recent—circa 1978 or later—for hobbyists with their own personal computer. This guide to programming style is written for the employee of an organization. The introduction is from Harlan D. Mills of IBM (Federal Systems Division). Copious documentation throughout the programming process is essential, and “an efficient secretarial staff” will help with the maintenance of daily documentation. And emphasis is laid on discipline rather than creativity. In programming, it is not enough to be inventive and ingenious. One also needs to be disciplined and controlled in order not to become entangled in one’s own complexities. Looking back, even with the simple programs of the time the goals seem impossible. The time has come for programmers to write programs that work correctly the first time. Planning is emphasized to the point that almost seems like it would result in paralysis. It is senseless to start programming until there is a complete understanding of the problem and a complete general plan of attack. Today, at least, and my sense is the same was true then, this is impossible; if you wait until you have a complete understanding, you’ll either write trivial programs or never start important ones. Many of our best tools came because we did not understand the problem but wrote the program anyway. Then scrapped the program and focused on what it illuminated. But this is probably also a reflection of the bureaucratic mindset: It is much easier to discard poor thoughts than poor programs. This is more true of bureaucracies than of individuals. I have probably abandoned more programs than I’m currently using. But bad ideas do seem to live on in bureaucracies. The biggest insight in the book comes in the Foreword, which was not written by the authors. Mills writes: Back in 1900 it was possible to foresee cars going 70 miles an hour, but the drivers were imagined as daredevils rather than grandmothers. The moral is that in any new human activity one generation hardly scratches the surface of its capabilities. So it will be in programming as well. That’s extraordinarily true, but isn’t in any way what this book is about. Interesting in hindsight are the authors’ repeated complaints about focusing too much on writing fast and efficient programs. They call these “microefficiences”, trying to wring out every bit of speed and memory from the computers. With the development of inexpensive fast storage and larger memory systems, the preoccupation with the size and speed of machine code would seem to have been dealt a death blow. Not so! Old habits remain. Whoever wrote this didn’t read their Foreword: every advancement in speed and memory brought with it new uses that expanded what we expected of computers, whether it meant sticking a computer into every phone or running more than one program at a time on home computers. It was well after 1978 that we stopped caring about how much memory of computer program used, or how fast it ran. Even now, speed is still an issue because we’re running programs over networks, and memory an issue because we’re serving the same code to an audience of billions. So that we still complain about the time it takes web pages to display data. But it is undoubtedly true that “microefficiences” made programs harder to read. The authors recommend avoiding tricky code in favor of code with real-world correspondence: We will say that a program is “straightforward” or “natural” or “not tricky” if each step in the computer algorithm has a simple correspondence to a step in the real world algorithm that a person would use to solve the problem. And they provide examples of how straightforward code is easier to extend than tricky code, for example, using a form of checksum to find the one missing card in a deck rather than simply looking for the missing card might be a lot faster, but it means that you can’t alter the algorithm to find two missing cards in a deck. GOTOs came under special scrutiny as well, for obvious reasons; the authors list four valid uses for GOTOs, to handle clearly-defined loops and conditionals. The third was opaque to me until I realized it was a way of handling an ELSE in a language without ELSE. Interestingly, they also discourage flowcharts, and for what seem to be reasonable reasons. Flowcharts, they write, are sequential in nature, and so tend to discourage the use of “procedures and subprograms”. When they write: Good code alone seems to be sufficient for the detailed understanding needed for program maintenance. What they mean is not good code without documentation is better than bad code with documentation, but that good code beats a good flowchart; flowcharts are seldom used after good code is written: programmers seem to find it easier to follow code flow by looking at good code than by looking at the flowchart. And flowcharts don’t seem to help understand bad code. It seems, however, a clumsy way of saying it in a book where variable names by necessity are one letter long and subroutines have no names at all. They even recommend against GOSUBbing to the REM line that has the subroutine’s name, and instead using the line number of the first line of code, for reasons I don’t understand and which seems to go against the rest of their advice. Remember, never assume that the computer assumes anything.

Review # 2 was written on 2017-09-28 00:00:00 Doreen Accatino Not bad I'm a big 50