The value of a CS education

=46ull accounting systems, databases including the base of IDMS.

?-/

by

about.

years

the

e.g.,

time.

and

Well sthi. I am better educated now, thranx.

?-)

What was the reliability of semiconductor diodes in the 1940's ?

According to reports from that time, the semiconductor diodes were more unreliable than tubes.

Anyway, it would be interesting to design an HP35 style scientific serial calculator or even Sinclair Cambridge (reprogrammed BCD machine) using tubes (like 5965/6211/6463) and modern, reliable diodes:-).

According to Grace Hopper, Cobol was designed to be used by accountants. In reality, this goal was reached with spreadsheets in the early 1980's.

Anyway, ISAM (Indexed Sequential Access Method) files were built into the Cobol language, making it possible to make databases quite easily.

I'm not sure. They definitely were easier to pack and to power than tubes--more like miniature relay circuit densities, but with the speed of tubes. (Gosh.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

Hi Martin,

Division is potentially dangerous -- you might divide by zero, etc. Running with scissors is potentially dangerous. Guns are potentially dangerous. Etc.

Know how to use them. Use them wisely.

I rely on pointers heavily. E.g., my latest memory management system parameterizes the various mechanisms used in managing the free list, selecting the "appropriate" memory fragment to allocate, determining *how* it is allocated, etc.

Sure, I could represent each option with magic constants/enums. And, embed lots of switch'es in the code.

Or, create sets of appropriate functions -- functions that implement selection algorithms, functions that implement allocation mechanisms, etc. -- and then pass pointers to the functions of interest for this particular invocation to the routine (i.e., AS IF they were magical constants). This allows me to extend/modify the functionality without having to recompile *this* module.

I think much of Windows' applications suffer from black box syndrome. People using classes/libraries/etc. without completely understanding their limitations, etc.

To write good/robust code, you need to be very disciplined. Compilers can't catch all your mistakes. Nor prevent you from doing things incorrectly.

I've opted for variable precision decimal arithmetic in some of the newer projects I'm working on (for features presented to users). Less efficient but more predictable (by folks who aren't skilled in data representations).

E.g., find the roots of the polynomial: y = (x - 1234567890123456789012344)(x - 1234567890123456789012345) (silly example but obvious as to why traditional packages would fail)

No such solution exists. If it works for him, then it works for him. :> I;m not a religious zealot when it comes to tools, languages, technologies, etc. -- "Use what works (for you)".

Or, an ineffective test bench! Are you sure you are measuring the code in question and nothing else? Do both use the same hooks to the OS (e.g., for I/O)? etc.

Profiling code under an OS can be a tricky undertaking. I only look at differences in algorithms on bare (non-PC) iron so I know *exactly* what is executing.

Exactly. The "team" -- code for "we don't want to be dependent on individual(s)". (We'd prefer to have a crappier product that costs more to develop and maintain!) :>

Working *with* drones (in *any* field) is depressing. There's no fire or excitement or inspiration. The emphasis is on not rocking the boat, not doing anything *obviously* wrong, etc. OTOH, working with a group of truly talented *individuals* makes each day a terrific learning adventure! It's really *cool* when someone shows/teaches you something new -- esp as you get older and have fewer opportunities for surprises :-/

And, the quality of the back-ends has improved dramatically! I've stopped looking at assembly output as it was too humbling :< A mechanical approach to generating code with oodles of details about the actual efficiencies of particular instructions and instruction combinations, awareness of how NOT to stall the prefetch queue, how to organize things on cache-line boundaries, etc. is *way* too impressive to compete with (and usually not a good use of neurons)!

Hi Phil,

OK. Limbo has typed channels that you create as needed. E.g., (apologies if any typos creep in, here -- error checking omitted):

# create a channel named "inbound" to accept tuples from # tuple consists of first names of both parents, their shared last # name and a list of their offspring -- each accompanied by their age inbound := chan of (string, string, string, list of (string, age));

...

(mom, dad, lastname, offspring) => *thought* he was dealing with "a number" only to discover that

I recall a "dot" notation (?) and colons (?)

But, it uses far less syntactic sugar than, e.g., C (or, worse, Limbo!). And, IIRC, the symbols used could be easily replaced with different representations (e.g., "**" --> '^'). This is a bit more tedious in e.g., limbo (just too many damn combinations of punctuation marks with different interpretations)

OK. So what might some input and corresponding output look like?

Dunno. The problem could be local to my end just as easily. I noticed that the glyphs look perfect when greatly enlarged (so, the "defect" isn't part of the underlying representation). It could just be a display artifact that appears when rendered at a particular scale. (but it is very repeatable, here! *Every* D, T, Z, etc. shows the same defects in the same places.

But this just reinforces my assertion -- *reuse* is a key part of doing things in C++. Creating a class that is used in a single application carries significantly more overhead than a classless (or, "C with classes"-style) approach.

Java, IME, is even less efficient in this regard. I think much of Java's appeal is for the endless number of VERY SIMILAR web pages and applets where reuse can be a big part of the job.

Exactly. My applications are significantly varied. I don't reuse code as much as I reuse *designs*.

And, as I've said before, C++ hides too much from me (I suspect that I could pick up the skills to better visualize those hidden activities) so I can too easily write sloppy code and not know it. (by contrast, I can feel what C *should* be doing with my source)

Understood.

One could nearly stand in front of a microphone belching "one" and "Ot" at faster "bit rates" than those ran at. (of course its exaggerated, it's a joke).

Does that mean you were at UBC, Vancouver? CO molecular lines or something.

I am teasing a bit, but their compilers were a bit pedestrian. FortranQ had a bit more zip to it if the optimiser was used with care.

We tended to use Waterloo FORTRAN (WATFOR) for teaching because the diagnostic error messages were much easier for students to understand.

One thing I do recall from that era is that we always learnt something from porting our software to new hardware or compiler. Most compilers had their little quirks and with no reserved words FORTRAN could be made extremely obfuscated if you put your mind to it (a bad idea).

A very unkind one to kill some compilers was including a line that declared a statement function something along the lines of:

FORMAT(A4) = A4+1.0

Subject to memory errors. It is a long time since I last used FORTRAN.

Mainly that it wasn't Fortran77 which we had on the VAX by then.

Cheers, Martin Brown

Hmm, looks like a cross between C and LISP--obviously designed by a pure computer scientist who crossed over to the dark side. ;)

(Both fine languages and all that, but not all the offspring are fertile.) ;)

True, I forgot those. A colon is what tells you that a reference to a function name is a definition and not a call. Otherwise it isn't used.

For stem variables, you need a dot between stem and suffix. REXX stems are associative arrays, which are very powerful but can also be like a combination pistol and shoehorn--the suffixes are strings, and if you give a suffx a value, the value is what gets used, e.g.

foo.bar = "handsome" foo.1 = "sailor"

say "Hello," foo.bar ]Hello, handsome

bar = 1

say "Hello," foo.bar ]Hello, sailor

Which can get a bit confusing when it happens by accident down in the guts of a program. The mildly warty but complete solution to these name collisions is to give literal suffixes names that aren't legal variable names, e.g.

foo.7bar = "handsome" foo.1 = "sailor"

say "Hello," foo.bar ]Hello, handsome

7bar = 1 (Syntax error--variable names can't start with digits)

Lots of folks would use 'foo.0bar', but I standardized on 7 since to my eye it's the digit that looks the least like any letter.

REXX functions can optionally have local variables, with fine-grained control over what outer scope variables are visible locally.

There are also lots of options regarding what constitutes an error. For instance, by default an uninitialized variable has a value equal to the variable name translated to uppercase, i.e.

/* Example */

say foo ]FOO

foo = "" say foo ]

In small programs, the sort you knock out in a couple of minutes to automate some repetitive task, that's a win, but not in larger ones. You can make uninitialized variables an error by saying

SIGNAL ON NOVALUE

and can optionally specify a signal handler function. There are a bunch of possible SIGNAL conditions. (None of this has to be uppercase, but I like SIGNAL statements to make themselves obvious.)

Rexx doesn't have an exponentiation operator ,so ** doesn't do anything. Lack of even slightly higher math functions is one of my beefs about it--I think OORexx fixed that, and there are math libraries floating around (both REXX source and extension DLLs). I just coded my own in REXX long ago, and have used them ever since.

There are some simple examples in the manual. They're from early in the cycle (about version 0.6) so they don't use the full capabilities by a lot, and they only have monochrome pictures. (Fixing them up is a wishlist item. If I had a marketing department, they'd have my head.)

For-real things that I've done with it include 5- to 8-parameter optimizations of antenna-coupled tunnel junction devices on SOI waveguides, free-space antennas for infrared pixels, aberration-free tapered grating couplers (with the aberration coefficients included in the grating generator function, in REXX), and the modulus of the complex-valued mode match between the actual and desired output angular spectrum being the merit function. Generating objects such as gratings and antennas from arbitrary parameterized mathematical descriptions is one of the more powerful features.

It's not as glitzy or as bug-free as a good-quality commercial package, but it works very nicely for me. (I don't do enough regression testing, for instance--seldom-used features sometimes get broken by extensions.)

We're in violent agreement there, except that I'd add maintenance as one of the reasons to use a well-designed class hierarchy.

C with classes plus a few templates is my usual C++ style, because I mostly do things that OO models very well. I use templates sometimes, mostly in numerical stuff, but I've never felt a need to go all out for generic programming.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

Yes, that's right! Do you know him? He was a great guy to work for. The project was doing Monte Carlo simulations of nonequilibrium radiative transfer in CO emission lines from interstellar giant molecular clouds, starting from a buggy program listing from some guy in (iirc) Denmark or Sweden. As I say, I didn't understand how it worked in any great detail, which made debugging extra fun, but I sure learned a lot.

They were just getting rid of the last of the card-handling equipment, but I managed to have the last remaining keypunch girl do the data entry, which helped a lot since I couldn't touch-type back then either.

The one thing I miss about those days (besides being better looking than I am now) is the output room. You submitted a card deck or a batch job from a terminal, which was much cheaper than an interactive job. Then you waited awhile and went to the output room to see if your job had run. Often it came out with a thin pile of fanfold paper instead of a fat one, indicating a fatal error, and another debugging iteration.

Very often, though, there was a guru sitting there waiting for his program to run, with nothing better to do than to help me with mine.

I've forgotten so much Fortran that I don't understand the example!

I see. The "Fortran G" I used was F77--I've never programmed in Fortran IV or earlier. (In fact I haven't used andy Fortran from that day to this--at grad school I used HP Basic, and at IBM, C, C++, Octave, and Rexx.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

Heck, I had my own PDP-11 timeshare system, with a fulltime operator, when I was barely out of my teens. The native language was, of course, Basic+.

John

We had a PDP-8 at my high school, but it was installed in the spring of my senior year, so I never actually used it. I'd done some programming on an early HP computer owned by the school board, in what they called "HP Educational BASIC" using #2 pencil on cards, similar to a SAT answer sheet. (Interestingly that technology was first developed early on, about 1955ish.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

I got a reputation as a COBOL authority on campus from helping the business majors when they got their failing runs back. I didn't know COBOL but knew the system error codes. The COBOL listing also had a link map that would map source statements to the memory offset. From that and the dump summary I could point to the source line and give them the error. They could then usually figure it out.

I could also amaze the FORTRAN programmers by looking at the last line of the error output and tell them they went outside of an array bound - without looking at the code to even know they used an array. The error code would be a memory fault and the only way you got that on that system was to try to go outside an array bound.

Didn't know him directly but did a bit of work with millimetre wave guys and the odd bit of observing of OH masers at 30GHz (which was as high a frequency as our baselines and dish figures could stand). The control computer was still running from paper tape at the time. Observational data were moved directly to a more modern computer. A couple of folk from UBC did spend sabbaticals with us and vice versa. There are only a limited number or radio astronomy sites worldwide.

We had to do our own card punching.

Ours was two big IBM chain printers and a big Calcomp plotter in the middle of the room. My friend and I solved a few exotic DEs numerically (we were supposed to sketch them) one of which was very ill disposed to numerical solution. The resulting plot file shook the plotter pen assembly to bits. We only realised what was going on later.

It isn't intended to be understood so much as crash compilers.

100 FORMAT(A4)

Is a statement defining a format of 4 text characters. The ugly thing I wrote defines a statement function that adds one to its argument. eg.

X = FORMAT(1.5)

Leaves X containing 2.5 (if the compiler ever gets that far).

I used it for a while and/or had summer students using it to port a raytracing ion optics program from a mainframe onto a PC.

My favourite language of all time has to be ETH Modula2 a Wirth language that fixed the faults in PASCAL but never gained much recognition outside academia and a very narrow field of safety critical work. Lilith which ran M2 natively as M-code was a formidable workstation machine in its day and supported one of the first PCB design systems (ISTR used to design the second generation).

The world of modern software might well have been a lot more reliable had Wirth been more effective at promoting its merits.

Cheers, Martin

I will jump in here with my usual take on programming skill...

I have seen three levels of programmers, which I refer to as hackers, programmers, and computer engineers. I have worked with all of them!

Assume that you have a new project coming up. You go to the hacker, the programmer, and the CE and ask "Here is the project. How long will it take to get it done."

The hacker will look at it, and say "Oh, about a month, two tops!" He then goes back to his desk and starts typing away at code. Six months later, he finally has something that just about does what you wanted, and doesn't crash that often.

The programmer looks at you, and says "That should take about two months, three tops!" He goes back to his desk, writes up a few of the requirements that he sees, writes some p-code or maybe a flow chart for a week, and starts writing code. In four months, you have completed software that does a good job doing what you expected.

The computer engineer looks at you, thinks about thirty seconds, and says "I will let you know tomorrow." He goes back to his desk, and starts writing down all the requirements that he can see from how you described at the meeting. That evening, he sends you an email detailing these requirements, and asks for your confirmation that this is what you want. You resond with a few small corrections. The next day, he comes into your office, and says "I can do this project, please give me at least three months."

He then goes back to his office, takes those requirements and makes them into a formal requirements document, which two days later he sends to you for approval. He then spendes the next two weeks designing the software architecture, the data structures and interface requirements. He then spends two weeks writing the code to those requirements, and begins formal testing at six weeks. At two months, he presents the finished project (he overbudgetted time to allow for problems) which includes three features that occurred to him while doing the actual design, which he had you approve during the development process.

Yes, at Microsim they did have several software engineers!

Charlie

And Cadence still hasn't caught up ;-) ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
I love to cook with wine.     Sometimes I even put it in the food.

Wouldn't that be Yosemite Sam.

?-)

=20

=20

by

Basic.

=20

Damn, another of a user evil tool. They are really quite rare.

?-(