|
I used to write on coding sheets & send them off to be punched.
Then we got a Holorith(sp?) manual card punch. PROGRESS!
Then we got keyboard-driven card punches. PROGRESS!
Then we got a teletype terminal with thermal paper. PROGRESS!
Then we got a VDU. PROGRESS!
Then we got a text editor. PROGRESS!
Then we got the ability to send a job to compile ourselves. PROGRESS!
Then we got local compilers. PROGRESS!
Then we got an IDE. PROGRESS!
Then we got colour screens. PROGRESS!
Then we got PCs. PROGRESS!
Then we got new OO languages. PROGRESS!
Then we got Visual Studio 2010. F***!
|
|
|
|
|
I experienced everything you mentioned and agree for the most part, but how can you knock Visual Studio ?
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
pkfox wrote: how can you knock Visual Studio ?
Experience shows that a big sh*tty stick gives the most satisfaction
|
|
|
|
|
Yeah. And that's why Eclipse is mostly used for Java, the stick isn't that satisfying when you can't hold it from all the dirt.
OT: Didn't knew you are on FarceBook.
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
|
|
|
|
|
I prefer Netbeans, for some stupid reason. But then all IDE's have gone down hill since forever.
|
|
|
|
|
I wish Eclipse was only used for Java. Texas Instrument's C/C++ development environment for their DSP's (Code Composer Studio) is Eclipse based. I like embedded and DSP programming but really dislike the Eclipse environment.
|
|
|
|
|
Chris Maunder wrote: What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
Let's see. Because the database manager was an idiot, my manager and I had to create a skunk-works project to hide how we were doing things so it didn't take a week per table to write the update, insert, delete, select operations. I kid you not.
Rewrote the "Application Coordinator" that this guy had put together taking up most of a year of his time. I rewrote it in a weekend, to the wrath of said developer and the envy of everyone else that had to use said developer's pile of dung. Needless to say, my team ditched this guy's code immediately, and we went on to be a productive, on time and on budget team.
Along those lines, getting my team's app to work meant finding the right people, smart people, not dogmatic "design pattern" nincompoops that were running around the hallways touting Java and exclaiming "ooh, did you read about the Visitor Pattern?"
On a personal note, getting my C++ apps to work meant realizing that "base class" was the top of the abstraction, not the foundation (and therefore the derived class) in a class hierarchy. I had to remove the "base of the pyramid" image from my understanding of OO.
And lastly, solid architecture. And what that meant was, architecture that logged every keystroke, every mouse click, every button press, so I could tell the mostly good, honest, but sloppy people in the QA department, no, you didn't click on "Save", you clicked on "Cancel" to refute their claim that the app failed to save their document.
Marc
|
|
|
|
|
I still do that for early releases
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Marc Clifton wrote: And lastly, solid architecture. And what that meant was, architecture that logged every keystroke, every mouse click, every button press, so I could tell the mostly good, honest, but sloppy people in the QA department, no, you didn't click on "Save", you clicked on "Cancel" to refute their claim that the app failed to save their document.
Ooh, good idea. I was figuring on using the C# version of UnhandledExceptionFilterHandler for ultimate deniability error-catching, and that's a good addition as well.
Now I just need to work around C#'s "if anything but the main thread has an unhandled exception, terminate the thread and ignore it" methodology...
|
|
|
|
|
SortaCore wrote: if anything but the main thread has an unhandled exception, terminate the thread and ignore it" methodology...
Well, you could put try-catch's in your threads! And there is Application.ThreadException[^] as well.
Marc
|
|
|
|
|
POKE 53280,0
POKE 53281,0
|
|
|
|
|
Not use local stack space for anything bigger than a pointer or integer
(16-bit Windows)
|
|
|
|
|
I have created a really complex and dynamic organizational chart using pure HTML Tables like a Boss! 
A giant table with crazy amount of pre-calculated rowspan and colspan, with even crazy amount of coding in picking the cell border colors (black or white). so that that whole madness will look like this[^] with really tiny scroll bars.
It was in Classic ASP, and the only real alternative (that might not work everywhere) was to create an ActiveX control or Flash control and draw the whole thing.
It was a network marketing company (like Amway) where members can see their complete network tree (people they have successfully infected/brainwashed).
I am still proud of it. 
|
|
|
|
|
Using Tables? OK, that's kinda cool.
cheers
Chris Maunder
|
|
|
|
|
First Programmer: Back in the day, we didn't have Windows. A command-line was our only interface to the machine.
Second Programmer: Command-line?!? You had a command-line?!? All we had was punch cards to input all of our code.
First: Punch cards?!? You had punch cards?!? All we had was paper tape.
Second: Paper tape?!? You had paper tape?!? We had to hand toggle switches on the front of the machine and hand assemble all of our code.
First: Toggle switches?!? You had toggle switches?!? We had to wire wrap our 0's and 1's directly into the logic of the computer.
Second: 1's?!? You had 1's?!?
|
|
|
|
|
|
Going back to the 90's I learned to program using a 16bit compiler for DOS which meant I had to deal with memory segmentation and near/far pointers.
Needing to use pointers to have more than 64k of data (and when I was working with multiple 64,000 byte screen buffers this was inevitable) forced me to actually learn how to use pointers for things beyond the textbook standard linked list, etc.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Long time ago...... programming a PDP 11/45 via the front console. Load an address and insert the octal instruction 014747. Then start running from the address you loaded the instruction (single stepping the execution is more fun!)
The "program", a single instruction, will cause the computer to run "backwards" and fill memory backwards from the starting point with 014747 until it gives a hardware trap (address error.)
|
|
|
|
|
The idle loop on RSTS would make the console lights cycle in a clockwise direction. You could tell how busy the CPU was by watching to see how often and how long the idle loop display was interrupted. Once the system was down for a hardware failure, so we wrote and toggled in our own "idle loop", except it cycled the console lights in a counter-clockwise direction. We waited as other developers came into the computer room to see why they couldn't log on. Only one developer figured out there was a problem by simply seeing the console lights cycling backwards. The rest asked us if there was a problem.
|
|
|
|
|
Giving away my age ... I started wiring boards for EAM (look it up) equipment. The trays of cards (80 characters each) were diagonally marked (magic marker) in case the cards were dropped...ugh. When I graduated to an 8k 1401, the 80 character boot strap area (programs loaded from cards - no OS) was hard wired to the card reader and the next 132 characters were hard wired to the printer. It made for interesting issues when additional code was required in the middle of run: code had to be interspersed with data cards. To top that off, I worked in a large display window on Madison Ave, since IBM liked to show off their equipment.
The first communications project I worked on used punched card readers for remote input and IBM Selectric typewriters as output devices. It ran on a dedicated 360/40 256k mainframe with 24k of OS and 3-28 mbyte disk drives. You had to watch the register lights on the console to "see" if the system was in a tight loop.
Using current IDEs (VS2013 and Eclipse) and targeting various device types, I don't miss the "Good Old Days" at all. The most agile activity back then was trying not to trip on cables.
Abbott Fleur
|
|
|
|
|
I worked on an IBM 360/40 with 256k core memory. There were a few disks, but a majority of our work was done with tape. Do you remember how to do a master file update with the master on one tape drive and the updates on another tape drive with the new master going to a third tape drive? Needless to say, I preferred the PDP-11/20 I mentioned in another post.
|
|
|
|
|
I left off that I was a 7094 tape jockey (in the same window). That was a 32k machine with a card reader the size of a very large generator and 14 tape drives. It billed out @ $700/hr. The OS (IBSYS) was on 1 tape. IBM did all their 360 simulations on the 7094. To make life a little easier we had a utility program (on 1 card) that rewound all the tapes at once so we didn't have to walk around and do it by hand.
|
|
|
|
|
Let's see, I've never done embedded programming so my limitations weren't too bad. On the PDP-11/20 running RSTS with BASIC-Plus, you had an 8KB address space for your program and data. Since it was interpreted, code comments took up space and thus were discouraged. Variable names weren't a space issue since they were limited to upper case letters A-Z, optionally followed by a digit, optionally followed by a type indicator: No type indicator was a floating point number, a type indicator of '%' was a 16 bit integer, and a type indicator of '$' was a string.
Given the address space limitations, most programs were broken into one or more data entry programs which interacted with the user, did limited data validation, wrote the input data into a temporary file, and then passed control to another program, using the "CHAIN" keyword, that did additional validations, including file-based validations, and if everything was OK, updated the actual production data files. If there was a data problem, the program would CHAIN back to the data entry program with a link to a temporary file that had information about what was wrong with the data.
The file system was equally primitive. You read and wrote 512 byte blocks of data from/to the disk. The rest was up to the developer. Some people wrote indexes which lived in separate files and sped up access. I wrote a hash-based lookup with collision detection and handling.
|
|
|
|
|
Chris Maunder wrote: What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
Boot Windows with NUMCPUS=1 on an early dual core machine so our video recording software would continue to work when we stopped recording the audio. Oh, and the OS happily ignored the directive and ran itself and our software on both CPU cores anyway, but only with NUMCPUS=1 did our software run correctly.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Also related to very early days in Web programming. I remember we had a Sun Web Server that had to interact with some legacy system and we lacked connectivity libraries to it; however there was a command line tool that could process simple queries and dump them to the screen. We used a CGI C executable that piped and redirected the screen output of the command line tool. We had to parse the screen-based report to extract the data fields, but eventually managed to provide exactly what the customer was asking for. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
