The Vent and Rant Thread

[Katsunami]

Originally Posted by Hitch

The simpler the UI, the more complex the back end. Period.

Hitch

That could be true; I don't know. What I do know is that I often write very simple code to get a machine to do something:

- Get a box from there.
- Move jars along this track.
- Push the jars into the box.
- Keep moving and pushing until the box is full.
- Move the box.
- Put a lid on it.
- Move the box onto a pallet machine.
- Done.
- Restart....

Something like that takes me about a day or two days to write, and it works perfectly every time (if the machine itself is OK).

Then I spend 2 months writing all the error handling. What if the box isn't picked up correctly? What if there is no box to pick up? What if the track doesn't move? What if the pusher fails or jams? What if someone stops the machine mid-movement? What if the lid gets put on askew (your pallet will be wacky and unstable)? What if the machine making the pallets is not ready? And so on....

And all of that has to be remedied by two things: An error message, and a button called "Reset" which needs to fix the problem without messing with the rest of the machine.

Writing the actual process is mostly easy. Writing the error handling of all the five million things that can go wrong, and do it in such a way that the entire process doesn't need to be restarted, can be *** hard.

[Wearever]

Originally Posted by cromag

The plow made its long awaited second pass last night. Now the plowed path is wide enough for two cars to pass ... carefully.

But all that dense, heavy, ice slush had to go somewhere and the plow driver apparently decided that a good place to put it would be directly in front of my mailbox. The pile is more than 4 feet high, extends ten feet into the street, and is frozen solid.

I don't remember ever doing anything to p*ss him off!

You have my sympathies Cromag ! I hope it warms up soon for you & this will all be in your past memories. I still have PTS from last years endless Bermuda Triangle of Blizzards. Every time it snows now.

[Hitch]

Originally Posted by Katsunami

That could be true; I don't know. What I do know is that I often write very simple code to get a machine to do something:

{whole bunch of cool stuff here snipped for space}

Something like that takes me about a day or two days to write, and it works perfectly every time (if the machine itself is OK).

Then I spend 2 months writing all the error handling. What if the box isn't picked up correctly? What if there is no box to pick up? What if the track doesn't move? What if the pusher fails or jams? What if someone stops the machine mid-movement? What if the lid gets put on askew (your pallet will be wacky and unstable)? What if the machine making the pallets is not ready? And so on....

And all of that has to be remedied by two things: An error message, and a button called "Reset" which needs to fix the problem without messing with the rest of the machine.

Writing the actual process is mostly easy. Writing the error handling of all the five million things that can go wrong, and do it in such a way that the entire process doesn't need to be restarted, can be *** hard.

Uhhunh. Seems like telling a machine to do X, if X is a single operation, is no problem. Even X+Y, as long as it's logical. But, lo! Look what happens when it has to sort through various possibilities for X going wrong...and then, you involve humans. So, one compused (confused computer) and one human. Hell, you might write a million lines just to deal with that!

Hitch (who is often compused).

[Katsunami]

Originally Posted by Hitch

Uhhunh. Seems like telling a machine to do X, if X is a single operation, is no problem. Even X+Y, as long as it's logical. But, lo! Look what happens when it has to sort through various possibilities for X going wrong...and then, you involve humans. So, one compused (confused computer) and one human. Hell, you might write a million lines just to deal with that!

That's indeed the case. Most people only see the simple process, and forget all of the possibilities of something going wrong. Each one has to be caught and fixed ASAP, or the entire line of machines will grind to a halt.

[Freeshadow]

@Katsunami: to support you with a very simple example: back when I was a kid and storage was precious I wrote (with Pascal) a simple equivalent to 'du -h <drive>' for DOS for my own use, just for not to have to juggle with bytes when I crammed my stuff in as little floppies as possible.
But I wanted to do it RIGHT. Thus I thought about all the "what ifs" a user could pass as command line argument. Gave them exit codes and proper error descriptions. The code to do the task was 3 lines. The code to catch all the shit which might hit the fan - the rest of an A4 page. It was a little shitty prog. But I was damn proud of it because I did it error proof. Is this somehow along with what you had in mind? If so then you might like the following answer when a user asks what the fuss is all about: To tell the computer what to do is just the beginning; the real fun starts when you are telling what to do if shit hits the fan. Because you have to anticipate every direction and angle it might come from.

[badgoodDeb]

Yup. "You can't make anything idiot proof because idiots are so ingenious."

[Katsunami]

Originally Posted by Freeshadow

@Katsunami:... Is this somehow along with what you had in mind?

Yeah, it is. The procedure to get this machine to do what it needs to do is somewhere around 75 to 100 lines or so. It has code like this (not actual code, but to give an idea):

(* This task will keep running, even if boxes are being placed and filled *)
IF (InputBuffer.Count < (NUMBER_OF_JARS_SET_BY_UI + EXTRA_BUFFER))
    AND (JarInputTrack.Status = STATUS_READY)
    AND (TASK_Get_Batch_Of_Jars = TASK_IDLE)
THEN
    TASK_Get_Batch_Of_Jars := TASK_RUN;
END_IF

IF (BoxPickupArm.Status = STATUS_READY)
    AND (BoxPlatform.Status = STATUS_EMPTY)
THEN
    TASK_Place_Box := TASK_RUN;
END_IF

IF (BoxPlatforum.Status = STATUS_BOX_PLACED)
    AND (JarPusher.Status = STATUS_READY)
    AND (InputBuffer.Count >= NUMBER_OF_JARS_SET_BY_UI)
THEN
    TASK_Fill_Box := TASK_RUN;
END_IF

Rinse/repeat conditions and kicking tasks on and off. At some point, the full box will be moved off the platform, so it becomes empty, and the placement task will start again. Everybody understands this and it's easy to write (I prefer to use types and/or enumerations where-ever possible, to avoid magic numbers and strings scattered through the code.)

Then you start to read the tasks themselves, which have a fairly simple code as well; it's comparable to the code above, but only for one part of the machine. Each task also detects errors, which is fairly obvious code as well.

Then you start reading the error handling, (re)initialization procedures and communication with the main user interface to disable/enable buttons while the program runs.... and you'll probably want to kill yourself before you finish, because in there, you'll find stuff describing what needs to happen if handling the fail actually fails itself.

** ERROR **
*box was crushed*
Action: Retract box placement arm, then remove crushed b....
** ERROR **
*Retract of box placement arm failed*
Action: Shutdown this part of the machine, wait for manual removal of the box, restart, re-initialize box placement arm....

Then try to place a new box... while the REST of the machine (input of jars, output of already finished boxes) keeps running.

You not fast enough removing that box?

** ERROR **
*Input buffer overflow*
Action: Stop input track.
Result: Preceding machine will be stopped as well.
* chain reaction of stopped machines *

Have a nice day reading code if you didn't write such a program yourself.

[HomeInMyShoes]

Sometimes subdivision of process is not really useful.

[Katsunami]

In cases where 3-10 processes run simultaneously to get one main process done, it is.

[HomeInMyShoes]

Oh I completely agree, but we have to be open to what the consequences might be.

[Cinisajoy]

Originally Posted by Katsunami

Yeah, it is. The procedure to get this machine to do what it needs to do is somewhere around 75 to 100 lines or so. It has code like (not actual code, but to give an idea):

(* This task will keep running, even if boxes are being placed and filled *)
IF (InputBuffer.Count < (NUMBER_OF_JARS_SET_BY_UI + EXTRA_BUFFER))
    AND (JarInputTrack.Status = STATUS_READY)
    AND (TASK_Get_Batch_Of_Jars = TASK_IDLE)
THEN
    TASK_Get_Batch_Of_Jars := TASK_RUN;
END_IF

IF (BoxPickupArm.Status = STATUS_READY)
    AND (BoxPlatform.Status = STATUS_EMPTY)
THEN
    TASK_Place_Box := TASK_RUN;
END_IF

IF (BoxPlatforum.Status = STATUS_BOX_PLACED)
    AND (JarPusher.Status = STATUS_READY)
    AND (InputBuffer.Count >= NUMBER_OF_JARS_SET_BY_UI)
THEN
    TASK_Fill_Box := TASK_RUN;
END_IF

Rinse/repeat conditions and kicking tasks on and off. At some point, the full box will be moved off the platform, so it becomes empty, and the placement task will start again. Everybody understands this and it's easy to write (I prefer to use types and/or enumerations where-ever possible, to avoid magic numbers and strings scattered through the code.)

Then you start to read the tasks themselves, which have a fairly simple code as well; it's comparable to the code above, but only for one part of the machine. Each task also detects errors, which is fairly obvious code as well.

Then you start reading the error handling, (re)initialization procedures and communication with the main user interface to disable/enable buttons while the program runs.... and you'll probably want to kill yourself before you finish, because in there, you'll find stuff describing what needs to happen if handling the fail actually fails itself.

** ERROR **
*box was crushed*
Action: Retract box placement arm, then remove crushed b....
** ERROR **
*Retract of box placement arm failed*
Action: Shutdown this part of the machine, wait for manual removal of the box, restart, re-initialize box placement arm....

Then try to place a new box... while the REST of the machine (input of jars, output of already finished boxes) keeps running.

You not fast enough removing that box?

** ERROR **
*Input buffer overflow*
Action: Stop input track.
Result: Preceding machine will be stopped as well.
* chain reaction of stopped machines *

Have a nice day reading code if you didn't write such a program yourself.

This post made me dizzy.

[Katsunami]

Originally Posted by Cinisajoy

This post made me dizzy.

Heh. Sorry

Imagine what the real code looks like.

Still, there are many who can understand code like this, and some are even able to write a half-decent to good Word or Excel macro. That doesn't make one a software engineer though. Building a nice doghouse is not the same as building a small mansion either

[Cinisajoy]

Originally Posted by Katsunami

Heh. Sorry

Imagine what the real code looks like.

Still, there are many who can understand code like this, and some are even able to write a half-decent to good Word or Excel macro. That doesn't make one a software engineer though. Building a nice doghouse is not the same as building a small mansion either

I understood it. It just seems circular but I know it has to be. Thanks but no thanks on writing code.
Must ask on your jars and boxes, do you have a code for human behavior?
There is a show here called "Dirty Jobs" and I could see the host messing up the box loading.
I did once write a program in BASIC. It was a strobe light. Does that make me an engineer??? Please know I am just kidding on the engineer part.

My thought would be plumbing and electrical are two different skills. And just because one can turn on a faucet does not make them a plumber nor does flipping a switch make them an electrician.

[Katsunami]

Originally Posted by Cinisajoy

I understood it. It just seems circular but I know it has to be.

Good observation It is indeed circular. It doesn't run from top to bottom, but in a circle, and everything runs all the time. The code itself is rarely complex. It actually is very easy most of the time. The circular part and having everything run all at once is what makes it difficult.

Must ask on your jars and boxes, do you have a code for human behavior?
There is a show here called "Dirty Jobs" and I could see the host messing up the box loading.

I know the series. They had some jobs in there I didn't even know existed :X

I did once write a program in BASIC. It was a strobe light. Does that make me an engineer??? Please know I am just kidding on the engineer part.

Everybody starts out like this My first "program" was a menu to start games. (Press 1 to start Arcade F1. Press 2 to start Prince of Persia.) The fracking menu actually took more space and memory than some of the games

One of my earliest real programs from 1990 or 1991 was a front-end for pkzip/unzip. It basically had one (1) useful line of code: the one that executed the command-line to actually zip or unzip something. The rest of the program was the front-end, and error handling. I used it for years, until I switched to OS/2 and later Windows NT, and it worked well.

I found it 10 years ago during a cleanout, and took a look at the code before throwing out those 15 year old floppies. I really wanted to have a look at the extreme smartness of my past self.

This is the closest approximation, as it's impossible to describe:



I'm still amazed it actually worked at all

[Cinisajoy]

Let's see if I remember the program.
1 COLOR 1
2 COLOR 0
3 COLOR 1
4 GO TO 1
RUN.
Note the double Color 1 worked better than just one color one.
I can't remember if 1 was black or white. I want to say it was black and 0 was white.
That was in 1982 so excuse failing memory.
It was also originally my younger brother's computer. He gave it to me when it did not have enough memory for him to do anything on it.
It was a TRS-80.