Why does inflation making space expand faster than the speed of light change the constants? No particle or energy travelled faster than light. Just space expanded smoothly such that, over a sufficient distance, the rate of change of that distance exceeded C. Nothing to trouble relativity in that fact: geometry changed, but nothing moved to fast. In fact, it is still the case: if the Hubble expansion is uniform, as it appears to be, at some distance the rate of recession must exceed C; there are objects which we will never see, because light cannot cross the ever-expanding gulf between us.

It is imaginable that a fibre such as you describe could be one of the products which could be made with graphene. But the nanoparticles being described in the articles are dangerous at the cellular level, not at the size of an arm. They are much more like incredibly fine, incredibly hard grit.

It is hardly surprising that graphene can, in some circumstances, be dangerous. Exhaust particulates, which he have known for years are dangerous, contain (now we know what we are looking for) large numbers of graphene nanoparticles, which may well contribute to their damaging effects. Just about every chemical ever tested has bad effects at some scale. What I didn't get from either article was any sense of the scale of the danger. Obviously, it is early days in the research, and one would only expect an order of magnitude estimate. But is is such a danger that we should not allow graphene products into the home lest they spill, or merely one which demands normal safety precautions in the factories for future graphene products? A warning of danger without some idea of the scale of the problem is just sensationalist: it induces fear without giving any idea as to what should be done, if anything,

Wirth's own compiler obviously implemented his language. But that was a university Comp Sci compiler: it had to be good enough for students to hand in assignments. But otherwise, every compiler needed extensions. Which were fairly easy to add, and the language was generally good. I did many years of embedded development, with two RTOSes optimised to Pascal idioms. And I really wanted to follow the Pascal line of development to Ada, but was not able to. I entirely agree that Pascal is a much more elegant language than C and its descendants. But it was written as a teaching language, and C was written as a systems implementation language. And since systems are a much bigger commercial market than teaching. So people wrote and supported C compilers. So we are where we are.

I think C/C++ is twenty years past it best before date. Not that it is a bad language, for its time, but its time should not be now. We should have replaced it, and haven't. And a replacement descended from Pascal would be nicer than one descended from C, though many devotees will damn me for saying so.

It was not bad, it was incomplete. It was a much nicer language than C, which is why I chose it for the projects I was developing, and was the point made several posts up . But, as I recall, it had no features allowing multiple compilations to be linked together - no equivalent of the C header file.Turbo Pascal added this, to make a very usable system. As did several others - incompatibly. This militated against it becoming a widely used systems language, because it was fragmented into different dialects, all incompatible. C, ugly though it was, stayed on the K&R standard, then added the Ansi standard, which was nearly completely upwards compatible, then mutated into C++ which made great efforts to keep compatibility with C. I can switch code between GCC and VisualC with very little effort: I could not switch code between the various Pascal environments in the same way.

It was not "the standard". The standard was the "Pascal User Manual and Report". To my recollection, this contained no mechanism for multi-file compilation. It assumed that every program was a single file - fine for a teaching language, where programs would typically be a hundred or two lines long, but no use for a system language. UCSD added extensions that made it into a perfectly good systems language. So did Turbo Pascal - differently, So did the Oregon Software cross compiler I used - differently again. You could not simply port programs between these various systems, whereas you could port programs written in K&R C. With additions, Pascal was a fine systems language; as I say, I used it for 15 years and wrote many tens of thousands of lines of code in it. But it needed extensions.

Heard about it, tried it out, evaluated the UCSD P-system hardware. But it needed non-standard extensions to work.

I do not deny that Knuth, and Wirth, created other, very cool, programming languages later. But I stand by my statement that Pascal, as originally defined, was not suitable for large projects, a failing that Wirth himself recognised.

No - the driver behind the current generation of scientists and technologist, of whom there are far, far more than there were back in those days. Back then, you only needed the 0.001% of truly deep geeks to keep the technology bandwaggon rolling. Now we need perhaps 2-3% of the population to be fairly geeky to do all the science and technology related jobs created by the explosion those first guys triggered,

I don't think there was a GUI, because the standard interface then was the ASR-33 teletype. That was certainly what I was using in the early 70s. I first came across CRT terminals in about 1979 - though my employer 75-78 was a bit sluggish, so they would have been around before that. But they were stil character oriented displays - 24x80 usually - and it was not until the early 80s I saw genuine pixel mapped displays on which one could have a real GUI.,

No, it just shows habit. C was descended from B, which descended from BCPL. They just did more of the same, instead of going to someone else's syntax.

And, having programmed in Pascal for 15 years. Pascal as defined was not suitable for large projects, whereas C was. Every Pascal compiler had to have some non-standard add-ons to handle modularity. And they were all different. Obviously, the Borland model came to have the status of a de-facto standard, but that was not till some years later. You could not have written Unix in standard Pascal; it was written in standard C. Wirth acknowledged the modularity failings of Pascal in his Modula language family, but by that time he had missed the bus.

Agreed. I have an iPad and an Android smartphone, and I am thinking of dumping the smartphone for the dumbest of dumb phones, which can only make phone calls and send SMS - and only needs to be charged once a week. I already have one of those as a travel emergency phone; I may switch my main number to it.

True - but nothing to do with homeopathy. You are describing herbal medicine which certainly certainly works sometimes - though there are dangers from unknown potencies and interactions with other medicines. Homeopathic medicines are based on something that causes the symptoms they are intended to cure - but diluted so far that not a single atom of the original substance remains. It is sort of an analogy with inoculation - by giving someone a killed or weakened version of a dangerous virus, you protect against the full-blown version of the virus. But we know what is happening in this case - we are pre-loading the immune system. The mechanisms by which we prepare wakened virus are well understood. Homeopathy has a theory that, by means unknown, dilution beyond non-existence somehow infuses the water with a potency to counteract symptoms similar to those caused by the diluted substance. Unfortunately,there is no theoretical or (importantly) experimental backing for this.

But most people who buy and use homeopathic medicines, as opposed to homeopathic practitioners, believe it does. They feel unwell, look for a medicine to make the unwellness go away, and pick a homeopathic remedy off the drugstore shelf. People are buying homeopathic treatments as if they fitted into the standard medical treatment model.

I think they contact lens reference is just hype. The system needs to be powered, and what is essentially an electronic signal, caused by changing conductivity between two layers of graphene, converted to an image the eye can see. I cannot see that being done inside a contact lens: it will always require some kind of a viewer, such as binoculars or a sight. However, it could be much less bulky, and draw much less power, than current IR systems - which would probably make it much cheaper. So I could see it making night vision binoculars for a few hundred dollars weighing a tenth as much as current models, and possibly more capable. Likewise other classes of IR receptor. These are reasonable possibilities. But contact lenses are sheer headline grabbing.