Programming and Such

[Atomic]

Ported over from the How Dangerous 2012-10-09 thread which wandered far afield, fell over, sank into the swamp, and then burned.
So, it was rebuilt.

=====

Understanding Array structures (tables, etc) and the use of Rational Expressions pointed my way to everything from simplifying program structures and understanding database design.

Could you be more specific about the book title?

My bad -- I meant to say Regular Expressions. The O'Reily series has it covered, for example, and I'm sure there are plenty of online resources to poke at.

The point is, once you understand that an array can represent any arbitrary organization of arbitrary data, the question becomes how to arrange it for minimal (preferably no) duplication (3NF at least), and how to access it (rational expressions). SQL, et al, is simply a styled manifestation of this concept, providing both the array (database) and the access tools (SQL coding). Drupal, for example, is an example of the box in a box in a box (Outside In programming) for web pages. You establish a hierarchy of containers (think CSS name= attribute), set them in a database, establish layout with item locations, then finally populate the containers with whatever you like. Want to change a price? Poke the database, not re-write the whole page. Lather, rinse, repeat.

Glad you found Starting Forth online. That's the book I was referring to. Granted, it's tailored for the Forth language, but the concepts are what counts. Learn what tools can do, then learn to apply the specific tool to meet your needs. That's why you really need a handle on Algebra and the various math operators in any decent spreadsheet program to build good Regular Expressions!

Happy coding!

P.S. -- Geez are we off topic here! Probably should have relocated this stuff to the Pub somewhere, eh?

[Atomic]

Likewise, relocated as above.

=====

Ah, Turbo PASCAL. Good times. Completely useless, but good times.

Was PASCAL the language where every program was actually a subroutine?

Basically, yes, which was a break from GOTO programming by line numbers. GOSUB programming always intended a return, forcing you to consider handlers for them. By quitting the line number structure, you could build by function and not fuss about lines at all. Stylistically, you really need to keep a Subroutine down to 100 lines or less if you can, because it makes for easier documentation and maintenance. Also, if forces you to look for common code, which you can then generalize and make one Sub with 20 calls instead of 20 variations of the nearly same function scattered through the program.

If you were really good, you could basically flowchart your entire program, then code from the chart. Say some, anyway!

[Fairportfan]

For those who do SQL - this guy has been a friend of mine since 1972. (Though i haven't seen him in ten or twelve years.)

Either he's had laser surgery or he's even vainer than i remember him being. Remembering how bad his eyes always were (measles in his teens), i vote for the vanity.