The point of make is that it relies on a clock to form a sequence. Your point is perfectly correct, and I have also experienced it, too. But if the clock is not backtracking (eg slowed down), then make will be happy.
Make can also get slammed if more than one clock is involved: eg parallel compiling on different computers.
That the 24 hour day is an Egyptian invention, based on a decimaldivision of the "day" + morning + twilight + the rising of 12 of their 36 signs. The 36 signs relate to their 10 day week.
The division into 60 is a Sumerian system, but their native system is to divide the day into powers of 60.
The uniform hours divided by base 60 is a Greek invention. The Romans divided the hour into 12 uncia. [The romans used weight-fractions: the unit = 1 libra: therefore a scruple of time is 12 1/2 seconds = 1/288 hour]
The metric system was meant to replace the angle and the length with a decimally divided quadrant: so it would be appropriate to divide the quarter day likewise. It makes some sense to do it like this.
Of course, you can consistantly divide the circle, day, and circumference into any system. Eg I use a circle divided into powers of 120, a nautical system of a marinal (9120 ft) of 120 segments (76 ft). This is the 'minute' and 'second' of the base 120 system. The day is divided into 12 hours of 120 min of 120 seconds
You can use other divisions as well, eg a decimally divided circle.
One thing I keep in mind is the clock division. In our clock, the hours use the major markings, which serve as multiples of the minute. So you could, in something like base 14, use a day divided into 16 hours of 56 minutes a peice. The clock is divided into hour-octants, each of sevenths.
Because 120 is 12 by 10. While 12 divides 60, it is like using scores with decimal: ie a right pain. Also, a lot of fractions come out with shorter periods in base 120, eg:
base 120 base 60
1/ 7 0:17.17.17 cf 0:08.34.17...
1/11 0:10.V9.10 cf 0:05.27.16.21.49...
1/13 0:09.27.83 cf 0:04.36.55.23...
1/17 0:07.07.07 cf 0:03.31.45.52.56.28.14.07
This means that periods for many multiples of 7, eg 42, 84, 224, all come out with a one-place period: eg
1/10! 0:00 00 00 57 17 17 17 17
1/12! 0:00 00 00 00 51 E3 91 E3 91
I use base 120 quite often, and have done so since 1976: base sixty is *much* harder.
The decimal day (10 hrs of 100 minutes of 100 seconds), does not work well with the metric system. The km/h and m/s would be respectively too slow and too fast.
The system was actually a division of the world circumference into 400, eg 40,000 km. Dividing the day into 40 kilohesits, each of 1000 hesits wuld make 1 km/kh = 1 m/h, etc.
If the plan had been to base a system on decimal divisions of the circle/day/earth circumference, then a unit of 4 km, divided into 10000 units of 400 m/m, would be more appropriate: 1 mph = 1 eps.
But why bother with decimal time, when there is base 120?
Where I come from, a cowboy is the boy who milks the station's cow, and do other odd chores around the station buildings.
A station is similar to what the US types call a ranch, although ranches are very small. Jackeroos (and Jilleroos) go out and round up the cattle or sheep in the paddocks.
Given that the americans come over here to see the real bush, as opposed to those market gardens and spelling pens you call "ranches", they should move their national day to something more appropriate, like 26 Jan.
Make only uses the timestamp to provide sequencing of dependancies. All "make" requires that all times come from the same clock, not that all clocks be accurate.
And since make is using file-stamps, this condition would be pretty much met by the clock that controls the fs where the data is stored. If there is more than one clock involved, then this becomes an issue.
The idea of synchronising clocks is that by being accurate, they will be "in step" with once another.
Someone compiling things on a computer where the standalone clock is used for both the fs and the system clocks.
The purpose of laws is to provide checks and balances that are not provided naturally. In this light, it functions like a dam wall, where the surrounding hills do most of the holding of water.
With the advent of computers, the main check and balance (the cost of copying and distribution) for things like privacy, copyright, etc, is no longer there.
So what happens, is that to print off a copy of a book or record, I'd need to invest in a suitable press (and such activity is not easy to hide), for copying music now, all I need is a program and a computer, both of which are elsewhise legitimate.
A train, or a car, or even an aeroplane, is in essence, a fast mode of transport. It is still a thing on the road, it just moves quicker. Of course, there are law modifications to adjust for this. In some cases, we give them new roads.
The internet, etc, is something fundementally new, in that the laws are based on the assumption that copying and collecting and analysing data is a fairly expensive activity. Nothing is now further from the truth.
Until we find a way to deal with this issue, we will have any number of problems.
It appears to have been standard practice or common practice with LP's in the sixties, to distribute them with a blank second side.
This refers to advance copies made available for reviewers. Normal retail copies were always double-sided. One of the reviews of the LP refer to these blank sides.
I'm not sure when Cage's peice came out.
The peice came out in 1952. None of this 1960's practice, or Lennon's 1969 peice were challenged, even though this has been pointed out on a number of occasions.
On the other hand, Lennon's 1969 song "Come Together" was challenged for copyright infringement. Lennon put Ya-Ya on the LP Walls and Bridges as part of the settlement.
John Lennon and Yoko Ono did a "Two Minutes Silence" on the 1969 LP Life with the Lions. I read somewhere at that point about the possibility of copyright etc. but forget what the outcome was.
I'm not sure when Cage's peice came out.
It appears to have been standard practice or common practice with LP's in the sixties, to distribute them with a blank second side. The LP Life with the Lions was compared unfavourably with this. It is an avant guarde LP.
I am not a lawyer, but I think there is established prior art on silence, and the only new peice that one could suggest is that if the silence is "intended for" some rememberence or some other significance. That is, the a given significance of the silence might be copyrightable, not the silence itslef.
Copying. Under computers, it is easy to create copies of data, and fork them down different paths. So your every action can be legitimately recorded, and then illegitimately passed onto unknowing third parties.
Analysis. grep is a faster tool than vgrep. I can pull out data from millions of line of data from with script.
Cost. With the digital age, and the connection of computers, I do not even have to pay for crunching time to do this. Most spam is duplicated at someone else's expense.
Overzealousness. Now we get to the stage that/any/ comment can be overheard. People simply do not do act this controlled.
What can be done.
Until we get some sort of protection from this sort of digital snooping, nothing really. Like, who obeys the good manners and law associated with spamming.
We can hide for a while, but why should we?
Sometimes being different or incognito is perfectly legitimate. But you neigh must be a technical wizard to make this happen...
Windows 2K has a number of Windows NT 3.1 bugs in the command prompt.
eg passing parameters to a script in the form works, but closes the window.
rexx mycalc.cmd 2+2 fails
mycalc.cmd 2+2 works
Running a pipe under cmd.exe usually closes the session window. This is documented in technet under NT 3.1. Pipes work as expected under the DOS session.
The DOS session looks like it's about to crash+burn. This gives a similar appreciation to Windows NT in general.
You can run OS/2 1.3 rexx under NT, either under 4OS2 2.50 or OS/2 1.3 cmd.exe.
I'm aware that NT derives from OS/2. What no-one says is that it's version 1.3, ie 16-bit stuff. OS/2 is up to version 4.5.1 now. Like Posix, the OS2 subsystem is hopelessly crippled tick-list feature [yes we run OS/2 and Posix programs]. Most OS/2 stuff is 32-bit stuff, not the 16-bit stuff.
Windows 2K does not support multiboot with non-MS operating systems, unless service pack 2, (and its series of bugs) is installed.
4NT reports WinXP as 5.01, not 5.1. That a vendor can put a different version on the box is not supprising. PCDOS 6.10 reports itself as 6.00.
Any version of Windows is legacy software in the making. It's only because of people's reaction and the antitrust thing that Microsoft's plan for NT4 were brought to heal.
IBM continue to support vers 3, 4 and 4.5, vers 3 is up to fix-pack 43, and still benefits from driver extentions. v 4.0 fixpack brings it up to the 4.5 codebase.
MS should have forked NTFS into a new partition type, instead of pretending it's HPFS. Don't these guys have *any* imagination???
I've had NT systems locked up from scrambled passwords as well.
Well, all it needs is a text file to crash windows. I've even had OS/2 crash...
I'm not a big fan on 2k, since it has all sorts of serious Win3.1 bugs and IE bugs kicking around in it. I have managed to wedge it a few times. You see, the kernel should be fixed by now, but there's still other parts of it that play up, such as the loosing IE interface, and the dozens of different ways to open a program bugs.
Not sure about XP, but it's a 0.01 downgrade on 2K (ie WinXP = NT 5.01, 2K = NT 5.00).
On the other hand, I have had systems crash, and not crash the fs. Even DOS and Win98.
The success or failure of a program has more to do with its interface, and not the code.
Code that has a good interface, and buggy code will still appeal more than one with poor interface and good code, just as we fondly remember good movies from older times, even if the quality of the acting and filming leaves a lot to be desired.
Programs are expected to do a lot more than appliances, and operate effectively in wildly variable conditions. When robustness is required, there are efforts made to reduce the variable conditions, and the range of expectations. Some programs run on dedicated boxes that do nothing but run that program.
User expectations and knowledge is a moving target. In part, this is the fault of the vendors, who change the interface quite often. Where in the world of DOS, enter adds data to a field, in Windows, it accepts and closes the dialog. Control-Alt-Delete is another bugbear.
Were the manufacturers of cars to lay out the controls to suit their own design, there would be pandamonium, when the left foot activates the break here, the accelerator there.
If we're going to have a common interface, we should get it designed and use it unfailingly.
Command lines are not imune. In fact the command session can be regarded as a computer inside a computer. One would be wholy upset if some program started to uninvitingly leak data into another program's space. Even command line options are becoming standard: how many of us look for help with a/? or -? option?
We need words to have singular meanings: for example, the word 'cancel' should back out of a dialog box. A dialog box that has a large amount of data entry should have some sort of 'save' option. Activating a button or control with F1 should bring up relevant help.
Software will continue to suck, as long as people have to change from one activity to another very often, and have to use different keystrokes for the same command.
It will continue to suck while it decides to do something different with your data than what you thought it was supposed to be doing. This is rather hard to get around. In essence, the program should communicate what it is going to do, and do what it said it was going to do, and *no more*. [Spyware does a few extra things:(]
You don't have to be one of the big guys to get a good product out: JPSoftware's replacement for cmd.exe and command.com is a much cherished product. JPSoftware is not a huge company, but it has a huge following of loyal customers who speak highly of its products.
Just getting the bugs out of the code is not enough. You have to work on the interface as well.
My experiences and observations with Windows, is that you don't need to go through the back door: the front door is good enough.
For instance, you hear of drives being shared on the internet.
A lot of those email viruses run on fairly valid code. Just a matter of doing them properly.
Still, getting into the back door, Windows, Linux or whatever, is a matter of getting the appropriate access. You know, many of these crackers are not pouring over linux code, but just trying tricks they read in some chat room or mailing list.
And, code compiled from source in your posession is clearly safer than someone's hidden stuff. You can take control of it, debug it, analyse it, do what you want.
This is more a case of getting a different variety through monoculture. The main reason for going for "old" is that you manage to cut out the bulk of ghee-whizz script-kiddies. But some of the kids may have cut their tooth on your system, and then will be quite conversant with its innards.
What it does not stop is those who live off hand-me-downs. My experience with a pentium 200 is that it's not much fun browsing the web with it.
The rule of affordance states that locks are meant to be picked.
Pseudocode is OK. Especially if it can be made into real code.
In fact, the concepts of bubble-programming and literate programming are based on pseudocode. All it means, is that you write the calls to the subroutines before the subroutine appears...
So a program like:
/*rexx */
call begin
call loops
call endme
exit
is a perfect pseudocode, that becomes a valid rexx script when the bits are filled in. It's also a neat block-breaker.
Often the pseudocode for something becomes with a little debugging, the alpha-code.
To say the same thing, there is no theory in 99% of designing and building bridges as well. In both case it's pretty much applying stock formulae to each case.
I mean, what's the difference in cut-and-paste and kit-assembled homes. The bulk of the work is done elsewhere.
Sorting routines are pretty much thrown at people. I do not deny this. So is bridge design. But this is not the point.
On the other hand, a careful study of where things go in a program, and considering alternate options for the program, resulted in massive speed increases (here hundred or thousand-fold type), in some of the programs I wrote and rewrote. Yet the first program I wrote was recycled to do an entirely different task, where it was much more effective.
There's no "magic wall" between theory and practice. It's more a matter of how far you stand back and see the scheme of things.
I never said you should not make mistakes, or that you can't learn from mistakes.
None the same, theory is valuable, not all the time, but as often as it is in engineering. Debugging is fairly theoretical task. The more you move up the front, the less you have to debug and rewrite.
Yes, the average programming does benefit from a fair bit of design. In essence, if you can plan for things aforehand, then you can avoid these pitfalls. A big program in an area wher you can't lock away variables, or needs a tight squeeze of space, does well with a bit of foreplanning.
And, besides, what's the difference between "SORT" "ORDER BY", and cutting and pasting a standard sort routine.:)
I may not know how to do quicksort, but the program runs faster with it than, say, bubblesort. Most of the time I use the "sort" command, and structure output to make its life easier. It's only when I need an inline sort that I dig out the code.
I mean, I wanted some code for matrix determinate and inverses, so I took some stock code, and made my programs use the right variables. It's not that much different to doing the same in an spreadsheet.
There's nothing wrong with a spot of idealism, and I assure you, it's not a new thing with computers.
As far as programming goes, the first thing I show people is things like how to write filters in rexx, and shell programming. Both of these are dirt-easy, and immediately appliable.
For example, consider the sorting algorithms. There are several different methods of sorting a series. Some of them, like quicksort, are generally better than others, like bubblesort. But in Knuth, we find a system where bubble sort is the most efficient method.
The idea that different methods "cost" different amounts, and doing these calculations can speed up programs greatly, is also not to be missed.
There is also "design philosopy", which is about how the parts fit together, and are built. The shift from the hard-coded jumps and gotos of assembler and basic to the structured programs of c, rexx &c is the application of a theoretical discovery. The unix pipe is built around the idea of task segments.
Like bridge design, program design is a case of learnt skills. And if you don't periodically look objectively with some theory at the design process, the design of both the bridge and the program may be sadly lacking and unnecessarily expensive.
And yes, you CAN learn bad habits. Programs like basic teach you bad habits in the sense that all values can be called from anywhere, and the use of "GOTO"'s.
Flow charts are generally a bad idea, since they force you into excessive codes. Better to let things wait and ride.
Computer languages, like real languages, give you the power to say things. Learning a foreign language or C++ isn't going to get you to say intelligent things.
Because computers are so literal, you need to think out the fine details of the process as well.
This is where the cardboard comes in. In essence, you assume the program works, and manually work through the data.
You need to be conversant with your target enough to deal with all of the possibilities. To get an idea of this, read some of the bug-lists and history files of shareware.
The other thing to do is to design the thing so that the user knows what to expect. Spreadsheets were there before computers [Stationers carry books of x or y columns].
Once you do this, sit down with your material, and start with this program:
You break the program down into parts, and then address each part. Each part should do a clearly defined activity. This may not be just "one thing". Each routine must leave the global variables in a clearly defined state,
More importantly, each of the controls (be they buttons or command switches) must do logical things. You can draw on your user's expectations. Putting a function at menu|F|X will draw the ire of people who use this sequence to shut the program down.
There are of course excellent books out there. The one by Hackel [I forget the name.... will post it tonigth:)] is good, as is Knuth's "Literate Programming". Jon Bentley's comment in there is worth considering as well.
If because the wires are busy, you can get only 20k of traffic, your modem runs at 20k. That's why the net slows down when it's busy.
On the other hand, if you can get 100k of traffic, you get to download it at 56k
The idea is that you save the unessential downloads to when you can pull them at full speed, not at half speed.
The same works with electricity. The generators can only pump out x kW. But if you can use some electricity at otherwise low loads, you even the loads out. This is called "saving".
Slashdot Mirror
Make can also get slammed if more than one clock is involved: eg parallel compiling on different computers.
Or AEST. At least the important parts of the world would have correct time. Who *cares* if the Americans work from midnight to 8 am?
A similar system was flaunted in one of the 19th Century Pyramid books. It had a system based on base 50, with some of the 2's removed ^_^.
The division into 60 is a Sumerian system, but their native system is to divide the day into powers of 60.
The uniform hours divided by base 60 is a Greek invention. The Romans divided the hour into 12 uncia. [The romans used weight-fractions: the unit = 1 libra: therefore a scruple of time is 12 1/2 seconds = 1/288 hour]
The metric system was meant to replace the angle and the length with a decimally divided quadrant: so it would be appropriate to divide the quarter day likewise. It makes some sense to do it like this.
Of course, you can consistantly divide the circle, day, and circumference into any system. Eg I use a circle divided into powers of 120, a nautical system of a marinal (9120 ft) of 120 segments (76 ft). This is the 'minute' and 'second' of the base 120 system. The day is divided into 12 hours of 120 min of 120 seconds
You can use other divisions as well, eg a decimally divided circle.
One thing I keep in mind is the clock division. In our clock, the hours use the major markings, which serve as multiples of the minute. So you could, in something like base 14, use a day divided into 16 hours of 56 minutes a peice. The clock is divided into hour-octants, each of sevenths.
Because 120 is 12 by 10. While 12 divides 60, it is like using scores with decimal: ie a right pain. Also, a lot of fractions come out with shorter periods in base 120, eg:
base 120 base 60
1/ 7 0:17.17.17 cf 0:08.34.17...
1/11 0:10.V9.10 cf 0:05.27.16.21.49...
1/13 0:09.27.83 cf 0:04.36.55.23...
1/17 0:07.07.07 cf 0:03.31.45.52.56.28.14.07
This means that periods for many multiples of 7, eg 42, 84, 224, all come out with a one-place period: eg
1/10! 0:00 00 00 57 17 17 17 17
1/12! 0:00 00 00 00 51 E3 91 E3 91
I use base 120 quite often, and have done so since 1976: base sixty is *much* harder.
The system was actually a division of the world circumference into 400, eg 40,000 km. Dividing the day into 40 kilohesits, each of 1000 hesits wuld make 1 km/kh = 1 m/h, etc.
If the plan had been to base a system on decimal divisions of the circle/day/earth circumference, then a unit of 4 km, divided into 10000 units of 400 m/m, would be more appropriate: 1 mph = 1 eps.
But why bother with decimal time, when there is base 120?
A station is similar to what the US types call a ranch, although ranches are very small. Jackeroos (and Jilleroos) go out and round up the cattle or sheep in the paddocks.
Given that the americans come over here to see the real bush, as opposed to those market gardens and spelling pens you call "ranches", they should move their national day to something more appropriate, like 26 Jan.
And since make is using file-stamps, this condition would be pretty much met by the clock that controls the fs where the data is stored. If there is more than one clock involved, then this becomes an issue.
The idea of synchronising clocks is that by being accurate, they will be "in step" with once another.
Someone compiling things on a computer where the standalone clock is used for both the fs and the system clocks.
The purpose of laws is to provide checks and balances that are not provided naturally. In this light, it functions like a dam wall, where the surrounding hills do most of the holding of water.
With the advent of computers, the main check and balance (the cost of copying and distribution) for things like privacy, copyright, etc, is no longer there.
So what happens, is that to print off a copy of a book or record, I'd need to invest in a suitable press (and such activity is not easy to hide), for copying music now, all I need is a program and a computer, both of which are elsewhise legitimate.
A train, or a car, or even an aeroplane, is in essence, a fast mode of transport. It is still a thing on the road, it just moves quicker. Of course, there are law modifications to adjust for this. In some cases, we give them new roads.
The internet, etc, is something fundementally new, in that the laws are based on the assumption that copying and collecting and analysing data is a fairly expensive activity. Nothing is now further from the truth.
Until we find a way to deal with this issue, we will have any number of problems.
This refers to advance copies made available for reviewers. Normal retail copies were always double-sided. One of the reviews of the LP refer to these blank sides.
I'm not sure when Cage's peice came out.
The peice came out in 1952. None of this 1960's practice, or Lennon's 1969 peice were challenged, even though this has been pointed out on a number of occasions.
On the other hand, Lennon's 1969 song "Come Together" was challenged for copyright infringement. Lennon put Ya-Ya on the LP Walls and Bridges as part of the settlement.
Paul McCartney is in there somewhere as well. It's a track promised for the LP "Cold Cuts"
I'm not sure when Cage's peice came out.
It appears to have been standard practice or common practice with LP's in the sixties, to distribute them with a blank second side. The LP Life with the Lions was compared unfavourably with this. It is an avant guarde LP.
I am not a lawyer, but I think there is established prior art on silence, and the only new peice that one could suggest is that if the silence is "intended for" some rememberence or some other significance. That is, the a given significance of the silence might be copyrightable, not the silence itslef.
Analysis. grep is a faster tool than vgrep. I can pull out data from millions of line of data from with script.
Cost. With the digital age, and the connection of computers, I do not even have to pay for crunching time to do this. Most spam is duplicated at someone else's expense.
Overzealousness. Now we get to the stage that /any/ comment can be overheard. People simply do not do act this controlled.
What can be done.
Until we get some sort of protection from this sort of digital snooping, nothing really. Like, who obeys the good manners and law associated with spamming.
We can hide for a while, but why should we?
Sometimes being different or incognito is perfectly legitimate. But you neigh must be a technical wizard to make this happen...
Windows 2K has a number of Windows NT 3.1 bugs in the command prompt.
eg passing parameters to a script in the form works, but closes the window.
rexx mycalc.cmd 2+2 fails
mycalc.cmd 2+2 works
Running a pipe under cmd.exe usually closes the session window. This is documented in technet under NT 3.1. Pipes work as expected under the DOS session.
The DOS session looks like it's about to crash+burn. This gives a similar appreciation to Windows NT in general.
You can run OS/2 1.3 rexx under NT, either under 4OS2 2.50 or OS/2 1.3 cmd.exe.
I'm aware that NT derives from OS/2. What no-one says is that it's version 1.3, ie 16-bit stuff. OS/2 is up to version 4.5.1 now. Like Posix, the OS2 subsystem is hopelessly crippled tick-list feature [yes we run OS/2 and Posix programs]. Most OS/2 stuff is 32-bit stuff, not the 16-bit stuff.
Windows 2K does not support multiboot with non-MS operating systems, unless service pack 2, (and its series of bugs) is installed.
4NT reports WinXP as 5.01, not 5.1. That a vendor can put a different version on the box is not supprising. PCDOS 6.10 reports itself as 6.00.
Any version of Windows is legacy software in the making. It's only because of people's reaction and the antitrust thing that Microsoft's plan for NT4 were brought to heal.
IBM continue to support vers 3, 4 and 4.5, vers 3 is up to fix-pack 43, and still benefits from driver extentions. v 4.0 fixpack brings it up to the 4.5 codebase.
MS should have forked NTFS into a new partition type, instead of pretending it's HPFS. Don't these guys have *any* imagination???
I've had NT systems locked up from scrambled passwords as well.
I'm not a big fan on 2k, since it has all sorts of serious Win3.1 bugs and IE bugs kicking around in it. I have managed to wedge it a few times. You see, the kernel should be fixed by now, but there's still other parts of it that play up, such as the loosing IE interface, and the dozens of different ways to open a program bugs.
Not sure about XP, but it's a 0.01 downgrade on 2K (ie WinXP = NT 5.01, 2K = NT 5.00).
On the other hand, I have had systems crash, and not crash the fs. Even DOS and Win98.
Code that has a good interface, and buggy code will still appeal more than one with poor interface and good code, just as we fondly remember good movies from older times, even if the quality of the acting and filming leaves a lot to be desired.
Programs are expected to do a lot more than appliances, and operate effectively in wildly variable conditions. When robustness is required, there are efforts made to reduce the variable conditions, and the range of expectations. Some programs run on dedicated boxes that do nothing but run that program.
User expectations and knowledge is a moving target. In part, this is the fault of the vendors, who change the interface quite often. Where in the world of DOS, enter adds data to a field, in Windows, it accepts and closes the dialog. Control-Alt-Delete is another bugbear.
Were the manufacturers of cars to lay out the controls to suit their own design, there would be pandamonium, when the left foot activates the break here, the accelerator there.
If we're going to have a common interface, we should get it designed and use it unfailingly.
Command lines are not imune. In fact the command session can be regarded as a computer inside a computer. One would be wholy upset if some program started to uninvitingly leak data into another program's space. Even command line options are becoming standard: how many of us look for help with a /? or -? option?
We need words to have singular meanings: for example, the word 'cancel' should back out of a dialog box. A dialog box that has a large amount of data entry should have some sort of 'save' option. Activating a button or control with F1 should bring up relevant help.
Software will continue to suck, as long as people have to change from one activity to another very often, and have to use different keystrokes for the same command.
It will continue to suck while it decides to do something different with your data than what you thought it was supposed to be doing. This is rather hard to get around. In essence, the program should communicate what it is going to do, and do what it said it was going to do, and *no more*. [Spyware does a few extra things :(]
You don't have to be one of the big guys to get a good product out: JPSoftware's replacement for cmd.exe and command.com is a much cherished product. JPSoftware is not a huge company, but it has a huge following of loyal customers who speak highly of its products.
Just getting the bugs out of the code is not enough. You have to work on the interface as well.
For instance, you hear of drives being shared on the internet.
A lot of those email viruses run on fairly valid code. Just a matter of doing them properly.
Still, getting into the back door, Windows, Linux or whatever, is a matter of getting the appropriate access. You know, many of these crackers are not pouring over linux code, but just trying tricks they read in some chat room or mailing list.
And, code compiled from source in your posession is clearly safer than someone's hidden stuff. You can take control of it, debug it, analyse it, do what you want.
What it does not stop is those who live off hand-me-downs. My experience with a pentium 200 is that it's not much fun browsing the web with it.
The rule of affordance states that locks are meant to be picked.
The book by Heckel is "The elements of friendly software design".
In fact, the concepts of bubble-programming and literate programming are based on pseudocode. All it means, is that you write the calls to the subroutines before the subroutine appears...
So a program like:
call begin
call loops
call endme
exit
is a perfect pseudocode, that becomes a valid rexx script when the bits are filled in. It's also a neat block-breaker.
Often the pseudocode for something becomes with a little debugging, the alpha-code.
I mean, what's the difference in cut-and-paste and kit-assembled homes. The bulk of the work is done elsewhere.
Sorting routines are pretty much thrown at people. I do not deny this. So is bridge design. But this is not the point.
On the other hand, a careful study of where things go in a program, and considering alternate options for the program, resulted in massive speed increases (here hundred or thousand-fold type), in some of the programs I wrote and rewrote. Yet the first program I wrote was recycled to do an entirely different task, where it was much more effective.
There's no "magic wall" between theory and practice. It's more a matter of how far you stand back and see the scheme of things.
None the same, theory is valuable, not all the time, but as often as it is in engineering. Debugging is fairly theoretical task. The more you move up the front, the less you have to debug and rewrite.
Yes, the average programming does benefit from a fair bit of design. In essence, if you can plan for things aforehand, then you can avoid these pitfalls. A big program in an area wher you can't lock away variables, or needs a tight squeeze of space, does well with a bit of foreplanning.
And, besides, what's the difference between "SORT" "ORDER BY", and cutting and pasting a standard sort routine. :)
I may not know how to do quicksort, but the program runs faster with it than, say, bubblesort. Most of the time I use the "sort" command, and structure output to make its life easier. It's only when I need an inline sort that I dig out the code.
I mean, I wanted some code for matrix determinate and inverses, so I took some stock code, and made my programs use the right variables. It's not that much different to doing the same in an spreadsheet.
There's nothing wrong with a spot of idealism, and I assure you, it's not a new thing with computers.
As far as programming goes, the first thing I show people is things like how to write filters in rexx, and shell programming. Both of these are dirt-easy, and immediately appliable.
For example, consider the sorting algorithms. There are several different methods of sorting a series. Some of them, like quicksort, are generally better than others, like bubblesort. But in Knuth, we find a system where bubble sort is the most efficient method.
The idea that different methods "cost" different amounts, and doing these calculations can speed up programs greatly, is also not to be missed.
There is also "design philosopy", which is about how the parts fit together, and are built. The shift from the hard-coded jumps and gotos of assembler and basic to the structured programs of c, rexx &c is the application of a theoretical discovery. The unix pipe is built around the idea of task segments.
Like bridge design, program design is a case of learnt skills. And if you don't periodically look objectively with some theory at the design process, the design of both the bridge and the program may be sadly lacking and unnecessarily expensive.
And yes, you CAN learn bad habits. Programs like basic teach you bad habits in the sense that all values can be called from anywhere, and the use of "GOTO"'s.
Flow charts are generally a bad idea, since they force you into excessive codes. Better to let things wait and ride.
Because computers are so literal, you need to think out the fine details of the process as well. This is where the cardboard comes in. In essence, you assume the program works, and manually work through the data.
You need to be conversant with your target enough to deal with all of the possibilities. To get an idea of this, read some of the bug-lists and history files of shareware.
The other thing to do is to design the thing so that the user knows what to expect. Spreadsheets were there before computers [Stationers carry books of x or y columns].
Once you do this, sit down with your material, and start with this program:
call startup
call looping
call closure
exit
You break the program down into parts, and then address each part. Each part should do a clearly defined activity. This may not be just "one thing". Each routine must leave the global variables in a clearly defined state,
More importantly, each of the controls (be they buttons or command switches) must do logical things. You can draw on your user's expectations. Putting a function at menu|F|X will draw the ire of people who use this sequence to shut the program down.
There are of course excellent books out there. The one by Hackel [I forget the name .... will post it tonigth :)] is good, as is Knuth's "Literate Programming". Jon Bentley's comment in there is worth considering as well.
If because the wires are busy, you can get only 20k of traffic, your modem runs at 20k. That's why the net slows down when it's busy.
On the other hand, if you can get 100k of traffic, you get to download it at 56k
The idea is that you save the unessential downloads to when you can pull them at full speed, not at half speed.
The same works with electricity. The generators can only pump out x kW. But if you can use some electricity at otherwise low loads, you even the loads out. This is called "saving".