work, life

One *advantage* of not using a cell phone is people can't EXPECT you to be "by the phone" (people ASSUME you've got a phone wired to your left nut and should be JUMPING to answer it each time it rings!)

There's the rub -- if you want what they are offering, you have to meet their terms/expectations.

I keep wacky hours. So, there has never been a time when it's been "safe" to call me. I finally got tired of friends and clients "waking me up in the middle of the day" :< and moved everyone to email. Call me and you can be *sure* I will go to lengths to NOT respond! :>

The other HUGE advantage has ben that both parties now have an incontrovertible record of the "converation"! Previously, I would type up notes for every client contact. So, I have to invest my time on the call (no, I really don't care what the weather is like, there!)

And, arguing later about that content ("Um, did *you* take notes? No? Well, *I* did...").

The email approach forces each party to make an investment in the conversation, documentation, etc. Sure cuts down on the "exploratory calls" -- where you are asked for an off the cuff estimate -- "I won't hold you to it+ --that inevitably comes back prefaced with, "But I thought you said it would cost..."

(sigh)

Ha! Too funny!

e.g.,

counting

Seems

float, any

pointers are

That is not true, Ada does have pointers. Pointers are a necessary component of linked lists an many other programming tools that Ada supports. Ada has pointers that are not part of structures as well. What is does not have is untyped pointers.

?-)

line numbers.

language.

you

write flat

global.

Interesting, have you ever considered designing your code as multiple interacting state machines? I have seen that idea implemented frequently in design of GPIB, PCI, PCIE, firewire, SPI and other interfaces.

?-)

Sort of, but code is still procedural, whereas in a real synchronous state machine everything is clocked at once.

We do program a lot of embedded applications where there is one main loop that just executes a list of state machines, with some ISRs running sort of in background. But I don't generally do that in Windows engineering apps... they aren't realtime.

ADA has subscripts, which are declared, bounded, and checked. I don't think it has c-type pointers that can point at anything or anywhere. PB has subscripts, and you get a choice of runtime bounds checking or not.

Ada has "access" types (fancy name for pointer).

It took me a while to figure out which (Ada) text had this quote: "Playing with pointers is like playing with fire. Fire is perhaps the MOST IMPORTANT TOOL KNOWN TO MAN. Carefully used, fire brings ENORMOUS BENEFITS; but when fire gets out of control, disaster strikes. Pointers have similar characteristics but are well tamed in the form of access types in Ada." -- Barnes, _Programming in Ada 95_ [emphasis mine]

People who don't know how to use pointers shouldn't use them! People who don't know division by zero is undefined shouldn't divide! People who don't know how to use guns shouldn't use those, either!

"Outlawing" either (which is what some languages try to do) is an overly paternalistic approach. (would you favor a language that didn't support division to protect against folks who fail to test for zero divisors?)

Serpentine is a good stone for crystal meditation and is said to be valuable in opening psychic abilities. It can be used to clear clouded areas of all the Chakra.

Heh, QB has pointers, in that you can find VARSEG and VARPTR(variable) (ah yes, segmented memory..). But there, you're just PEEKing and POKEing and you have to know the data formats, or make them up yourself. You can't typecast, so it's as good as (and just as dangerous as) a void.

In those situations, I said "fuggit" and CALL ABSOLUTE'd my own assembly...

Tim

That is actually quite risky allowing floating point ranges and steps - counting up between exact integer values in float 0.1 intervals may well get you round the loop one time more than you are expecting.

Pointers are not evil in them selves. Many forms of structured data rely on linked lists that can most efficiently be done with pointers.

The lethal weakness is being able to cast any random integer as a pointer to a whatever you like with no sanity checks whatsoever.

C programmers excel at overrunning array bounds with zero terminated strings which is why many buffer overrun exploits are so successful. These days the OS loads modules in random location order to make such attacks slightly harder. Data execute prevention no longer stops the latest most advanced malware :( Things will get much much worse when MS support for XP ends and the world is overrun with hostile botnets.

The difference is that in Ada you cannot have a pointer to a God only knows what object and then cast it to point to something else entirely. Windows is riddled with such monstrosities which is why it is so dodgy.

Which are exactly what one needs for physical I/O (hardware registers are known by address, not name, and don't necessarily act like memory), and for implementation of messaging software (you cannot know what's coming till it comes), and so on.

In a prior life, I was building what would now be called middleware allowing Ada83 programs to do all those neat, fast things that C could do with pointers. And to implement a "volatile" directive that really worked.

The resulting middleware was fully asynchronous and literally ten times faster than rendezvous-based communications. The speedup was accomplished by doing all those evil pointer tricks in a few specialized Ada-callable subroutines that were written in assembly code. The use of subroutines was essential to keep the Ada optimizer from screwing up.

Ada95 arrived far too late to save Ada from being swamped by C.

Joe Gwinn

Chrysotile is even more effective than that, especially when ground to a powder and inhaled. Of course it's more dangerous for your body, but much safer for your sanity. ;)

Cheers

Phil Hobbs

Recently, I have been working with the Propeller chip from Parallax on a small contract. It basically has eight processors that can operate semi-independently, so you can run seven processes with a processor dedicated to each one, and then a main supervisory process. Interesting for running different interfaces. You can have one processor running your base interface, and another feeding it data from a third processor that is getting all your data...

Charlie

That's cool, but it has potentials for logic races that you wouldn't have with a single CPU. Are there explicit synchronizing provisions?

There have been, by now, millions of bugs costing billions of dollars, in all sorts of programs, because c allows pointers (including the stack pointer) to point at anything, and doesn't separate code, data, and stack spaces. Many security exploits use stack and buffer overflows, and unassigned pointers, to get in. Things that continually allow such bugs and exploits *should* be outlawed.

Dividing by zero should produce "infinity" or should trap and kill the process. It shouldn't allow a spambot to install malware on a few million PCs.

In situations where it's risky, you have the option to not do it.

Thay are unreliable in real life, as used by the vast majority of c programmers.

Yep.

You can throw it at cats, too.

We'd better outlaw assembly language too then.

BASIC mutilates the mind. (Thank you E.G. Dijkstra.) Of course, BASIC today is very different from what it once was. In the absence of a standard, it's possible to call any language BASIC.

I like C. It's just the right mix of unfettered low-level stuff and high-level constructs to make it useful for hardware work. I started off in Algol-60, Pascal and Modula-2. I had some brush with BASIC and a random bunch of other languages. All of them were awkward in one way or another. C is far from perfect, but it was just what I needed in 1983. I never looked back. In the end, it's just what you're used to.

Jeroen Belleman

Dijkstra didn't program and didn't "have regular access to a computer".

Of

Sure, but too many people write bad c code, creating bugs and enabling exploits.

Perhaps the best computer language of all time was COBOL. "Real programmers" of course hate it, because they prefer playing with computing constructs to the mundane world of programming actual, reliable applications.

The trend now is for interpreters, which can at least, in theory, protect the population from the average programmer.

c is now about 40 years old.

Yes, the basic between process comms are through shared memory, which each processor gets to access in turn. You do have to be careful sometimes on things like arrays of data, since one process can be updating the array while the other is reading a different part...

To be honest, my part has basically been maintanance programming an existing system, adding and fixing features. I haven't really gotten down into the nitty-gritty yet.

Charlie