Beginning programming question

Well, I took about the same route -- Generic CADD, CADKey, (then DesignCAD, a couple of other architectural CAD programs, and Ashlar Vellum, which was my client), and then Rhino 3D. Rhino 3D is more than a modeller now, although I don't know if I'd use it to produce files for CAM. Some people do but I haven't kept up with the professional uses of it.

Anyway, yeah, computer power to the people. I could use some more computer power myself, come to think of it...

(...)

I use Rhino3D to produce .DXFs that I export to another package to create Gcode for my mill. This week, I made a motor adapter plate to help my friend resurrect his old drill press. Half inch CRS, 8 holes drilled for 3/8-16. It Worked A Treat.

I dabbled a little with MadCAM which is a 3D CAM plugin for Rhino. Perhaps it is much better now. :)

Couldn't we all. :)

--Winston

AutoCAD did indeed have a very steep learning curve. But once the keyboard commands are learned, it is incredibly fast to use for a competent typist. I once saw an experienced operator "build" a small commercial building (in 3D) in about 10 minutes. He didn't use the mouse much! His 3D model included HVAC, plumbing, wiring, doors, windows, and a walkthru. That was with a DX486-66 with maybe 512 meg of RAM. I think it might have been about circa R12 or R14.

I still like and use ACAD (R14) fairly regularly, but if I wasn't facile with it I'm sure I wouldn't invest the time to learn it now.

(...)

Yup. Remembering all the command mnemonics was impossible for me.

Whoa!

The thought makes my head hurt. :)

--Winston

Did you try Fortran V. It had some good optimising.

One of the support people was working on a benchmark, from a potential customer, (10,000) lines of code. He compiled it, ran it. He had the results, from other machines, all > 60 secs. The program printed k=123, time=0. He asked me, to have the customer call him, re: time=0, because something wasn't right.

I mentioned this the next time I talked to them. The reply was "REALLY????". Some one had put in a lot of time, writing a program that did nothing.

When I looked at the generated code, it was obvious what the compiler had done.

EAI was across the street from Interdata, wasn't it?

A little tidbit, most people don't know: The original intent of Interdata, was a low cost way to teach people to program 360s.

That is interesting. My first 360 class was at a community college. That wa= s pretty cheap.

Another tidbit: My very first programming class used a Monroe Monrobot desk= computer. 1k of 32 bit drum memory. I-O was a typewrite and paper tape. Al= l programming was machine language. The instruction set almost identical to= the IBM 360 several years later. Made the 360 much easier to comprehend.

Paul

S? Never heard of it. ;-P

Cheers! Rich

pretty cheap. Well, that finally explains why the Interdata instruction set looked just like the IBM 360.

Jon

They eventually leased a building across the street. They started in a little two story building on Lewis Street in Eatontown.

Messrs. B&S left EAI long before I got there. The way I heard the story-

EAI needed a digital and two engineers were assigned the task of design. Superior digital was designed. The design was dutifully trotted up to management, who decided that digital was a passing fad. If EAI wanted a digital they would just buy a digital computer company (they did). Engineers decide to start their own computer company.

It was the stuff of engineering dreams. For years, there would be lunchtime conspiracies; we would plot among ourselves to leave management behind and build the Red Hot Machine.

I remember a quote from Don K., one of the casual conspirators.

"Yea, I know some people with money. They're gonna keep it, too."

As an aside, one of the last things I worked on at EAI was a floating point format converter to convert SEL floating point to Intel (IEEE) floating point. Hardware brute force conversion with a board of 82S100 FPLAs.

Kevin Gallimore

Been there -- done that. :-)

And -- it is a good systems programming language -- it allows programming down to almost the "bare silicon", which makes it a good tool for writing and implementing an OS. Only a tiny amount of the OS needs to be written in assembly language for the processor in question. Everything else is in C. It makes a very efficient implementation. (Of course, when implementing the OS, you can't depend on the support of the OS for library routines, so you need to write that to be embedded in the OS, too.

You can do a lot of that in library routines anyway -- including hiding details of data handling. I used this when I wrote a suite of membership database programs. The application programs had no idea how the data was structured -- it called library routines to do everything

-- including the initial construction of the empty database.

This meant that once I had the library code working, I did not have to worry about a mistake in the applications corrupting the database structure -- at worst damaging the data in a single entry at a time.

And no -- I was not a professional programmer -- I wrote this in support of a non-profit organization in which my wife and I were trading off the job of membership chair. And I used a unix system at home for this, and ported it to newer unix systems as I got them.

Enjoy, DoN.

I would not have thought of that for math intensive applications. It is an interesting language, and happens to be used for implementing the monitor ROM (called (OBP -- Open Boot Prom) in Sun SPARC and UltraSPARC based workstations and servers. Gives it a lot of diagnostics power.

It was originally written by an astronomer, improved as he went from observatory to observatory. It started as a fourth-generation language -- and he hit a site where the significant characters in a file name were limited to five, so the 'u' had to go. :-)

It is good for implementing on just about any computer hardware.

But it certainly is not an easy language to learn. :-)

Hmm ... I've not encountered that book (or set of books?). I do have the first three volumes of Knuth's books.

Enjoy, DoN.

The history of this will all be written in a language we don't understand by "people" that don't exist in our current reality.

Point and Laugh..............

I was not recommending it for Ed's son. Just surprised with all the people talking about various programming languages, no one had mentioned it.

=A0But " Software Engineering

It is a book more about what works when writing programs. ( hint, the programmers are more important than the language or tools ). And thoughts about when it is reasonable to write software. Sometimes the answer is not to use computers.

By far the best return on time spent customizing autocad was creating your own command aliases in acad.pgp. Acad.pgp is simply a text file with a list of commands and associated aliases. I haven't used acad for 10 or 12 years, but I still occasionally hit ZA (my alias for zoom all) while working in Solidworks.

Yup. Generic CADD and Visual CAD both supported 'ZA' (as well as Zoom Window). It took me a long time to unlearn those commands because they aren't supported in Rhino3D.

--Winston

The Model 1 console looked like a 360. Also the hardware, it had a multiplexer channel, and eventually a selector channel. But not as sophisticated as IBMs, no channel programs.

I used to refer to Interdata, as a computer erector set. I could build any thing with the hardware they had, and did, all it took was money.

One of my 4 processor systems, made a cameo appearance in the movie "Top Gun".

Yes, indeed. Inadvertent practical joke from the 1970s: One of the engineers in the lab dropped a cigarette into a trashcan filled with wirewrap wire clippings. Turns out that the cigarette was still burning, slowly, and so soon the lab had the faint wiff of burning insulation, triggering a mad search for the fried wire (in the company of 100,000 other wires in that rat's nest). No fried wire was found, and we eventually figured out what had happened. Nobody noticed tobacco smoke in those days, because it was always present.

Joe Gwinn

Fortran V was in the future. In the early days of the transition, there were lots of marketing claims that Fortran was only 10% slower than handcoded assembly language. Well, not really, unless one used only student programmers for the assembly code, and used toy problems for the benchmark.

Where assembly code shone was that there was most often a machine instruction that was just perfect for the purpose at hand, and so one designed one's code around that often oddball instruction. Now, this is easy for an experienced programmer to do, but impossible for a compiler to do. No matter how good the optimizer, the compiler was not going to design and code your program for you.

The classic SEL 32/55 example of the just-perfect machine instruction is the combination of the indexed execute remote instruction and how operant addresses were encoded. To make a long story short, if one arranged things correctly, one could do a triple-indexed execution access through a 3D table of instructions (including subroutine invocation) in a single machine instruction. While we used 3D, there was in fact no limit other than the number of available index registers, which was 8 or 16 (I don't recall which).

The optimizer saw that the code was pointless, and elided it. We always inspected the generated code to ensure that things like this didn't happen.

Joe Gwinn