Sanding our assholes with 150 grit. Slowly. Lovingly.

Verbs I would like

to be expressed in a computer language include:

Because
Should
Never (as in Should Never Equal)
Permalink Simon Lucy 
March 10th, 2005
How would you use each of them? How would you expect them to be implemented?
Permalink muppet 
March 10th, 2005
The only uses for Because I can imagine are already handled by If.
Permalink muppet 
March 10th, 2005
This is a bit tongue in cheek maybe?

But Never (and Always) are already present in C family languages in the form of the assert() macro.
Permalink Ian Boys 
March 10th, 2005
it has always seemed to me as though assert( ) is a backup plan for shitty programmers. :)
Permalink muppet 
March 10th, 2005
And a poor backup plan at best.
Permalink Crazy Old Guy 
March 10th, 2005
A = A + 1 BECAUSE (A != A + 1)

=D
Permalink Eric Debois 
March 10th, 2005
Whoa!

Maybe I'm missing the mark completely regarding the assert comments.. maybe they are really in jest.

Assert is one of the most useful ways to catch bugs at an early stage. They're comments that are enforced, invariants that are automatically validated, and more.

And it can *never* have anything to do with a command like Never or Always because an assert statement only shows up in a DEBUG release. Therefore, doing any kind of assignment in assert expression is suicide.

I think I just don't get what the joke is. Nope, still don't get it.
Permalink Zorg 
March 10th, 2005
People working on formal specifications are trying to do stuff like 'Never' and 'Should'. Preconditions, postconditions, invariants, all that crap.

The only practical example of 'Never' and 'Should' that I can think of are in things like unit tests. It'd be cool if there were tools that'd take specs written in OCL (or some other spec language) and convert them to unit tests. I think the transformation is pretty mechanical. Maybe this already exists.
Permalink John V. 
March 10th, 2005
Since I consider "Should" to be one of the most dangerous words in requirements documents, I'd hate to see it in a computer language. I suppose it's not likely, because it has built-in ambiguity.

If something "should" happen, how bad is it if it doesn't? Terrible? Not bad at all? Who knows? What "should" we do about it? Crash the program? Issue an error message? Update a log? Roll-back a transaction?

It's dangerous because people use "Should" as a shortcut word for ALL of these conditions. Consequently, you get agreements that blow up in your face when you try to implement them. Party A and Party B both "agreed" what "should" happen -- they just disagree strongly on the implementation. Gah.

And I've found "assert()" to be very badly taught. When I first stumbled over it in live code, I thought "WTF is THIS doing here?! Crash the program if ONE LITTLE ASSERTION is bad? Who thought THAT was a good idea?"

Once I read Plum's "Reliable Data Structures in C", I found it's ONLY supposed to be active during Debugging, and he came up with a more meaningfull error log to make the assert() useful.

Yet still, you have a line of code that DOES NOTHING in operation, can CRASH THE PROGRAM if not used EXACTLY RIGHT, merely to hold your hand a little during early debugging. I see its purpose, and I still am not fond of it.
Permalink AllanL5 
March 10th, 2005
It should 'crash' the program, because asserts are used to validate constraints. When those constraints don't hold the program may fubar afterwards, but you don't know if it will or when.

When you have an assert that checks whether you access an array out of its bounds then I want the program to break, and a correctly placed assert does exactly that.

How on earth can that be a bad thing? Asserts are an ideal tool for verifying preconditions, postconditions and invariants. MFC uses asserts everywhere, and it works well. If I pass an invalid combination of flags to a function I get an assert failure. Even when you don't check for return values you're still notified of the problem.

Asserts are A Good Thing TM.
Permalink Zorg 
March 10th, 2005
It can be A Bad Thing because I don't WANT the only error behavior of an assert to be to CRASH THE PROGRAM. I want control over how my program behaves.

As I said, this comes from BAD TEACHING, not anything evil in asserts themselves. I've seen error checking in programs I've had to maintain where asserts were spread around to error check every little thing. Did a file not open? Assert crash. Did a 'malloc' return null? Assert crash. Did a function call return a good value that the original programmer hadn't thought about? Yes? Assert crash.

Troubleshooting these 'crashes' can be extremely difficult. And you SAY they're only supposed to be in the Debug version -- but my clever predecessor enabled them in production code. So I'm a little prejudiced.

They have their place. Personally, I'm not fond of them. By all means, I believe in predicate based programming, and asserts make that much easier, so go for it.
Permalink AllanL5 
March 10th, 2005
Asserts are meant to catch coding errors, not problems due to external factors or random bit flips due to gamma ray strikes.

If you can put asserts all through your code and have them never go off when your program is abused in every way possible by a room full of trained gorillas, then you can have some increased confidence that you have robust code.

That is what asserts are for. And asserts don't "crash" the program. They log a message and stop the program, hopefully at the point where you can readily discover what went wrong with the program logic.
Permalink Ian Boys 
March 10th, 2005
Uhm, I haven't gotten Ruby's "unless" under my skin yet.
But we could always find use for Intercal's "please".
Permalink Alex 
March 10th, 2005
Uhm, I'm not such a big C/C++ guy, but I'd hazard a wager that assert() is used for far more than debugging. Much like 'On Error' is used in VB/VBA for more than it should be too. The actual intended use of assert() is beyond my knowledge. Always seemed clunky to me, even though the C flavors aren't my primaries.
Permalink I am Jack's assert() assertion 
March 10th, 2005
Exactly Ian, that's how I think they're meant to be used.

Any errors generated either by
a) users
b) lack of system resources
c) windows being unpredictable

should be elegantly handled with exceptions. Or possibly by checking a function's return value, but that's often not practical.

Asserts are for LOGIC errors, exceptions are for everything else. There's not much more to it.

And yeah Alan, I can imagine you hate them if people abuse them like that. However, shouldn't you also be hating the entire programming language and/or the platform the program is designed for?
Permalink Zorg 
March 10th, 2005
According to the requirements i get, the most important words are "probably", "maybe", "sometimes" and possibly.

for example ...

Me: "Does the system have to handle stuff like .. blah blah"
Functional Expert: "Um, maybe. Probably not, so I shouldn't worry about it"
Me: "But if the case does arise"
Expert: "Oh, I don't think that's likely, that's why we didn't put it in the specification"
Me: "So we don't need to code to make allowance for it then, Good".
Expert: "Well obviously if it does happen then the system will definately have to deal with it"
Me: *twang* as my eyeballs roll hard enough to hit the stops
Permalink David Aldridge 
March 10th, 2005
Reminds me of a computer language we thought of in high school - it was Base 9 - true, false, and seven shades of indecision.

For example:
if (testValue probably should be 5)
{
  resultValue will almost definitely be 8
}

Philo
Permalink Philo 
March 10th, 2005
Ok so we are looking for the magic "Grey Logic" computers that verious research grants are working on.

I still like the requirements that contain the phrase "Most of the Time".
Permalink Douglas 
March 10th, 2005
Philo: Isn't that called fuzzy logic? ;-)
Permalink Ian Boys 
March 10th, 2005
Zorg: No, I figure there's nothing wrong with the language or the platform that a little informed instruction to the programmer won't take care of.

For that matter, a little informed instruction would take care of people's mis-using 'assert()', also.
Permalink AllanL5 
March 10th, 2005
Ok, I admit it was slightly tongue in cheek but only slightly.

SHOULD and NEVER would be useful as excetion mechanisms and I agree ASSERT is for 'the hand brake is broken and we are going over a cliff'.

BECAUSE though would be useful as a condition set within called function. Imagine you have some kind of state and then you're going to perform some action based upon that state but that there are multiple paths to getting that state and that it would be useful to know that 'REASON' at other times (I know there are other ways to manage this).

Then you get something like this:

BECAUSE (condition) function(parameters...)
{
stements....
}

And then in the called function you get:

REASON = (condition)


And this implies that there is some meta definition stored at runtime of the condition.
Permalink Simon Lucy 
March 11th, 2005
NEVER looks like it's almost aspect oriented. In which case I'd like to add WHENEVER <condition> <code> that'll run when a condition occurs.

I've recently had a number of conversations with people who've done things like the above expert. It's damn annoying. Especially when you find out six months later that "never" actually means "not very often..."
Permalink Katie Lucas 
March 11th, 2005
Having re-read what I wrote just above I'm wondering if I'm becoming aphasic or otherwise evincing symptoms of early onset senility. Or perhaps I just wasn't awake.

I like WHENEVER.
Permalink Simon Lucy 
March 11th, 2005
Back in my assembly code days I ached for CAME_FROM ...
Permalink sgf 
March 11th, 2005
Ah yes.
Permalink Simon Lucy 
March 12th, 2005

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: March, 2005 Other topics: March, 2005 Recent topics Recent topics