Re: Duplicate identifiers in a single namespace

Is that an electronics subject?

Jeroen Belleman

What language was it written in?

You have a tendency to be misunderstood when you start a new thread. Do you have any exaples?

I notice two files one called "C:\Users\Asministrator\Desktop\desktop.ini" and the other called "C:\Users\Public\Desktop\desktop.ini"

What's a ""Desktop" namespace" ?

Is there some way to retreive those files from that namespace by name?

Microsoft making an ambiguous user inteface is neither surprising nor interesting to me.

Two icons at the top have the same writing under them, but that writing is not their name, it's only a partial representation. their actual names on the desktop are their screen co-ordinates.

I'm not convinced that it even exists, desktop icons have coordinates and a keyboard navigation order, I'm not a aware of any way to reference by "name".

Suppose that in your class there are two people called "Mohammad Wong". what are you going to do? Are we even still talking about name spaces?

This is not a Windows question. It is a language question. C C is weird. Some identifiers can be declared multiply as forward. You can have the same name sometimes for things that are of different type. Not to speak of macro's

Pascal If you declare multiple identifiers in the same namespace you are hit on the head. You can have nested namespaces and there is no conflict, the inner namespace counts.

Forth You can use the same name for multiple objects. The name last defined counts. You get at most a warning.

Groetjes Albert

Look into C/C++ Namespaces. That explains things reasonably well.

Pascal is compiled in a single pass through the source code, so everything must be defied before it is first used. Unlike C/C++, which has a multipass compiler and linker. This was done because Pascal was intended for teaching programming, and the load in the university's computers was from compiling buggy student homework code time and time again, while C was intended to replace assembly in the Unix operating system.

Forth is interpreted, and is a pure pushdown language, like a HP calculator using RPN.

Joe Gwinn

I once had the suicidal job of choosing which language to write a large mass of code in. When my name was made public, the phone immediately blew off the hook with special pleaders for the two candidates, Pascal and plain K&R C. I'm doomed - no matter which is chosen, there will be war. And blood.

We had performed something like six prior benchmarks studies that showed that compiled C code was 1.5 times faster than compiled Pascal code, and Pascal had all sorts of awkward limitation when used to implement large systems, in this case hundreds of thousands of lines of code.

That didn't settle the issue, because the Ada mafia saw Pascal as the stepping stone to Ada nirvana, and C as the devil incarnate.

I was still scratching my head about why Pascal was so different than C, so I looked for the original intent of the founders. Which I found in the Introductions in the Pascal Report and K&R C: Pascal was intended for teaching Computer Science students their first programming language, while C was intended for implementing large systems, like the Unix kernel.

Prior operating systems were all written in assembly code, and so were not portable between vendors, so Unix needed to be written in something that could be ported, and yet was sufficient to implement a OS kernel. Nor can one write an OS in Pascal.

This did work - only something like 4% of Unix had to be written in assembly, and it was simply rewritten for each new family of computers.

So the Pascal crowd fell silent, and C was chosen and successfully used.

The Ada Mandate was rescinded maybe ten years later. The ISO-OSI mandate fell a year or so later, slain by TCP/IP.

Joe Gwinn

Well, we had the developers we had, and the team was large enough that they cannot all be superstars in any language.

Integration soon beats that out of them.

Because computers were quite expensive then (circa 1982), and so Pascal was optimized to eliminate as much of the compiler task as possible, given that teaching languages are used to solve toy problems's, the focus being learning to program, not to deliver efficient working code for something industrial-scale in nature.

Yes, lots. They were generally written in assembler, and it was estimated that about 20% of the code would have to be in assembly if Pascal were used, based on a prior project that had done just that a few years earlier.

The target computers were pretty spare, multiple Motorola 68000 single-board computers in a VME crate or the like. I recall that a one megahertz instruction rate was considered really fast then.

Much was made by the Pascal folk of the cost of software maintenance, but on the scale of a radar, maintenance was dominated by the hardware, and software maintenance was a roundoff error on the total cost of ownership. The electric bill was also larger.

The conclusion was to use C: It was designed for the implementation of large realtime systems, while Pascal was designed as a teaching language, and is somewhat slow and awkward for realtime systems, forcing the use of various sidesteps, and much assembly code. Speed and the ability to drive hardware directly are the dominant issues controlling that part of development cost and risk that is sensitive to choice of implementation language.

Hidden complexity is still complexity, with complex failure modes rendered incomprehensible and random-looking to those unaware of what's going on behind the pretty facade.

I prefer to eliminate such complexity. And not to confuse the programmers, or treat them like children.

War story from the days of Fortran, when I was the operating system expert: I had just these debates with the top application software guy, who claimed that all you needed was the top-level design of the software to debug the code.

He had been struggling with a mysterious bug, where the code would crash soon after launch, every time. Code inspection and path tracing had all failed, for months. He challenged me to figure it out. I figured it out in ten minutes, by using OS-level tools, which provide access to a world completely unknown to the application software folk. The problem was how the compiler handled subroutines referenced in one module but not provided to the linker. Long story, but the resulting actual execution path was unrelated to the design of application the software, and one had to see things in assembly to understand what was happening.

(This war story has been repeated in one form or another many time over the following years. Have kernel debugger, will travel.)

Pascal uses this exact approach. The absence of true pointers is crippling for hardware control, which is a big part of the reason that C prevailed.

I assume that RMI is Remote Module or Method Invocation. These are inherently synchronous (like Ada rendezvous) and are crippling for realtime software of any complexity - the software soon ends up deadlocked, with everybody waiting for everybody else to do something.

This is driven by the fact that the real world has uncorrelated events, capable of happening in any order, so no program that requires that event be ordered can survive.

There is a benchmark for message-passing in realtime software where there is ring of threads or processes passing message around the ring any number of times. This is modeled on the central structure of many kinds of radar. Even one remote invocation will cause it to jam. As will sending a message to oneself. Only asynchronous message passing will work.

Joe Gwinn

It's a little bit deeper than that. Startups can afford to have a large fraction of superstars (so long as they like each other) because the need for spear carriers is minimal in that world.

But for industrial scale, there are lots of simpler and more boring jobs that must also be done, thus diluting the superstars.

War story: I used to run an Operating System Section, and one thing we needed to develop was hardware memory test programs for use in the factory. We had a hell of a lot of trouble getting this done because our programmers point-blank refused to do such test programs.

One fine day, it occurred to me that the problem was that we were trying to use race horses to pull plows. So I went out to get the human equivalent of a plow horse, one that was a tad autistic and so would not be bored. This worked quite well. Fit the tool to the job.

I graduated in 1969, and there were no computer courses on offer near me except Basic programming, which I took.

Ten years later, I got a night-school masters degree in Computer Science.

Those were the days. Our computers did integer arithmetic only, because floating-point was done only in software and was dog slow.

And we needed multi-precision integer arithmetic for many things, using scaled binary to handle the needed precision and dynamic range.

A realtime system can definitely consume a goodly fraction of the computers.

In the 1970s, there was no such thing as such an appliance.

Nor did appliances like stoves and toasters possess a computer.

Yes, a bullet dodged:

Well, current radar systems (and all manner of commercial products) contain many millions of lines of code. Fitting this into a few brains is kinda achieved using layered abstractions.

This falls apart in the integration lab, when that which is hidden turns on its creators. Progress is paced by having some people who do know how it really works, despite the abstractions, visible and hidden.

There are people who do know these things.

Yes. Actually it's always. And they don't know what they don't know, the unknown unknowns.

Remote meaning accessed via a comms link or LAN is not done using RMIs in my world - too slow and too asynchronous. Round-trip transit delay would kill you. Also, not all messages need guaranteed delivery, and it's expensive to provide that guarantee, so there need to be distinctions.

Object-Oriented stuff had its own set of problems, especially as originally implemented. My first encounter ended badly for the proposed system, as it turned out that the OO overhead was so high that the context switches between objects (tracks in this case) would over consume the computers, leaving not enough time to complete a horizon scan, never mind do anything useful. But that's a story for another day.

At the time, RMI was implemented synchronously only, and it did not matter if a response was required, you would always stall at that call until it completed. Meaning that you could not respond to the random arrival of an unrelated event.

War story: Some years later, in the late 1980s, I was asked to assess an academic operating system called Alpha for possible use in realtime applications. It was strictly synchronous. Turned out that if you made a typing mistake or the like, one could not stop the stream of error message without doing a full reboot. There was a Control-Z command, but it could not be processed because the OS was otherwise occupied with an endless loop. Oops. End of assessment.

When I developed the message-passing ring test, it was to flush out systems that were synchronous at the core, regardless of marketing bafflegab.

Well, the alternative is to use a different paradigm entirely, where for every event type there is a dedicated responder, which takes the appropriate course of action. Mostly this does not involve any other action type, but if necessary it is handled here. Typically, the overall architecture of this approach is a Finite State Machine.

Or, more commonly, be statistically uncorrelated random. Like airplanes flying into coverage as weather patterns drift by as flocks of geese flap on by as ...

True, but what's the point? It is general for that class of problems, when the intent is to eliminate operating systems that cannot work for a realtime system. There are also tests for how the thread scheduler works, to see if one can respond immediately to an event, or must wait until the scheduler makes a pass (waiting is forbidden). There are many perfectly fine operating system that will flunk these tests, and yet are widely used. But not for realtime.

Joe Gwinn

Nor could you convince them. They wanted to do things that were hard, important, and interesting. And look good on a resume.

Actually, the customers often *required* us to inject faults to prove that our spiffy fault-detection logic actually worked. It's a lot harder than it looks.

I was doing Fortran on cards as well.

Real men used teletype machines, which required two real men to lift. I remember them well.

BTDT, though we fitted other curves to approximate such as trig functions.

Well, in the radar world, the signal and data processors would be fixed-task, but they were neither small nor simple.

Yep. So don't do that. Just ride the metal.

No. The problem is again that those pretty abstractions always hide at least one ugly truth, and someone has to know what's inside that facade. to fix many otherwise intractable problems.

Yep. We do layers a lot, basically for portability and reusability. But at least a few people must know the truth.

Shouldn't this be written in COBOL running on an IBM mainframe running CICS (Customer Information Control System, a general-purpose transaction processing subsystem for the z/OS operating system)? This is where the heavy lifting is done in such as payroll generation systems.

.

Maybe so, but conceptual clarity does not pay the rent or meet the payroll. Gotta get to the church on time. Every time.

Actually, that is not what "realtime" means in real-world practice.

The whole fetish about deadlines and deadline scheduling is an academic fantasy. The problem is that such systems are quite fragile

- if a deadline is missed, even slightly, the system collapses. Which is intolerable in practice, so there was always a path to handle the occasional overrun gracefully.

Restart? If you are implementing a defense against incoming supersonic missiles, you just died. RIP.

This is how some early OO systems worked, and the time to switch contexts between processes was quite long, so long that it was unable to scan the horizon for incoming missiles fast enough to matter.

Hmm. I think that Jensen's Alpha is the one in the war story. We were tipped off about Alpha's problem with runaway blather by one of Jensen's competitors.

And thus not suitable for essentially all realtime application.

One can design for such things, if needed. It's called fault tolerance (random breakage) or damage tolerance (also known as battle damage). But it's done in bespoke application code.

True, but not suited for many realtime applications.

Yes for molding plastic, but what about the above described use cases, where one cannot make any such assumption?

The word "realtime" is wonderfully elastic, especially as used by marketers.

A better approach is by use cases.

Classic test case. Ownship is being approached by some number of cruise missiles approaching at two or three time the speed of sound. The ship is unaware of those missiles until they emerge from the horizon. By the way, it will take a Mach 3 missile about thirty seconds from detection to impact. Now what?

Again, it's not quite that simple, as many RTOSs are not preemptive, but they are dedicated and quite fast. But preemptive is common these days.

An OS can be deterministic, and still be unsuitable. Many big compute engine boxes have a scheduler that makes sweep once a second, and their definition of RT is to sweep ten times a second. Which is lethal in many RT applications. So use a more suitable OS.

I've done that too.

How would this handle a cruise missile? One can ask it to back up and try again, but it's unclear that the missile is listening.

Yeah. I think we are solving very different problems, so it's time to stop.

Joe Gwinn