the hot new programming language

Maybe we should just stop using software until someone figures it out? How about if we make all computers analog? Yeah, that has got to work better, right? The digital stuff is boring and easy, even if no one seems to be able to do it right. I guess the whole world is just stupid...

As I said, I don't really know Ada, so I defer to your knowledge.

Again, I don't have first hand knowledge of compiler efficiency, but I have discussed this with others who do and they tell me compilers are every bit as good as hand coded assembly most of the time. That is no surprise to me as this is a problem that has been worked on for a long time. So forgive me if I don't defer to your opinion on this one.

Do you have any examples?

Closed mouth? When it went public? Was this in the early 70's? Fig forth was freely available in the 70's. Who was closed mouth about it? I remember attending a conference on Forth early in my career, about

I'm currently using a Forth that runs on the target processor of a TI Stellaris Cortex M3 MCU, not even a high end one.

On Thu, 02 Jul 2015 17:54:35 -0700, John Larkin Gave us:

John Larkin in rare form tonight... NOPE, this *stupid* s*it behavior from him is his *norm*.

He blathers on about civil behavior ALL THE TIME.

How much you wanna bet that he completely ignored my tale about when I saved a part at a company I once worked for?

It was in response to his "I caught a hot iron once." remark, and I didn't cuss even once.

From John... crickets.

Only so long as Cobol programmers are in short supply. These things run in cycles.

The problem is in maintaining code which is critical to the banks core clearing operations (as opposed to the snazzy trader floor stuff).

They don't spend much on the legacy systems and they do tend to have spectacular MFUs from time to time. Some banks more than others.

If you want to sell your soul for maximum financial gain then destabilising the global stock trading systems with sophisticated high frequency trading algorithms is definitely the way to go.

One guy in the UK in his parents bedroom can allegedly do this:

People seem to get upset if you are too good at it!

I don't often defend Johns comments but on this he does have a point. For most home and office kit these days the CPU power available is so huge that efficiency literally does not matter in end user code.

The notable exceptions are video editing and 3D gaming which really do push the performance envelope. Word processing and general stuff you can trade a few percent of speed for safety without any problems.

Fast CPUs are cheap and getting cheaper in line with Moore's law whereas good software engineers are rare, expensive and getting more so.

TBH I am amazed that Moore's law has held good for as long as it has.

To be fair here, there are very few* operating systems written in COBOL. It was developed to solve other types of real problems.

I would compare it more to SNOBOL or PL/1.

• but not zero!
  formatting link

He has a part of a point, but at the time that C was taking off big time most machines were pretty short of resources and C was a distinct improvement over its predecessors like B and BCPL.

They are not all cowboys. MacConnell's Code Complete published by Microsoft is quite a good introduction to defensive programming. It is just a shame that they don't always practice what they preach.

The problem stems from their sheer complexity and the fact that the customer tends not to really know what they want at the outset.

They do care. Academia dumps their rejects into the software industry.

I am somewhat annoyed that in the UK our professional body is far too supine about expressing disgust when government software projects go haywire - almost inevitably due to some combination of inadequate specifications, bad management, budget overrun and mission creep.

The Royal Society for Chemistry is a heck of a lot better at PR.

Sadly I have to concede that you have a point there.

OS/2 was a lot more robust but IBM made a total mess of selling it!

The problem is that modern management views time to market as the priority to get sales bonuses. It is only software after all and you can sell "support" to the poor suckers or maybe a years free updates.

No-one would dream of doing it for physical hardware with product recalls, messy patch wires and oudles of conformal coating.

There are static analysis tools that can find latent bugs in a codebase without executing it by using dataflow analysis. Looking for any paths through the code where variables are used before first being assigned a value or where a nul pointer could be dereferenced.

Such bugs can lurk for a long time along seldom executed paths (often but not always the error recovery for some critical system failure).

Ada was too big and complicated for it's own good. Modula2 wasn't bad for a minimalist hard realtime language with separate compilation of modules and provision for low level system operations by design.

All the mainframe compilers in that era apart from the most expensive high end FORTRAN had pretty lousy optimisers.

I think that is a somewhat jaundiced view of the situation (although I am not a particular fan of Ada). Algol68 had similar speed complexity tradeoffs in a previous era. Fortran compiler could run rings around it performance wise but for algorithm development it was still very useful.

I think you will have to elaborate on that point. Offhand I can't see anything in the Ada language specification apart from its immense size and the enormous validation suite that forced Ada compilers to be clumsy and emit slow code. I will concede that in the era where C was in the ascendency a great deal more effort was expended on its code optimiser than on any other language apart from Fortran.

I don't disagree that most of the powerful languages started out as someone's pet project that gained momentum locally and then globally.

That isn't true any more with profile directed optimising compilers. The compiler can often beat all but the very best handpicked assembler practitioners. Register colouring, speculative execution and pipeline stalls mean that most people cannot see the wood for the trees now. The compiler (with the right CPU optimising flags set) does it seemlessly.

A surprising number of modern compilers will reduce common loop constructs to almost identical canonical code. Certain constructs are faster on some Intel CPUs than on others so it chooses the right one.

I don't remember it being all that closed mouthed. It was in relatively wide use in the late 1970's for telescope control and I thought the magnetic tapes were circulating fairly freely in that community.

There was even a Forth for the venerable BBC micro in about 1983.

Den fredag den 3. juli 2015 kl. 00.03.35 UTC+2 skrev John Larkin:

up to a point, haven't you been wishing for a faster ltspice? if is was as easy as buying a faster cpu why don't you?

-Lasse

Envision trillion dollar bugs. I suspect it happens all the time, and they just clean up afterwards.

Yeah, a good fraction of MIT grads get sucked up for that.

Terrifying instability.

Den fredag den 3. juli 2015 kl. 12.52.52 UTC+2 skrev Martin Brown:

yeh, you have to be a member of "the money sucking parasite club" to manipulate prices and steal money like that

-Lasse

Maybe ricky runs a lot of 3D EM simulations. Or maybe he games a lot.

I only notice CPU runtime rarely, in Spice sims of oscillators and switchers. Most Spice sims run in zero subjective time. And they are giving me a new PC soon, 5x or so faster than what I have. Most people run Facebook and Twitter and texting, so a small ARM in the corner of a chip is plenty of compute power.

I run ATLC once in a great while, which is compute intensive, but I doubt that I've totaled four hours computing in the last year, and I can always do something else, clean my office maybe, while it's running. Upgrading my PC will take me more time that I might ever get back.

Intel must appreciate that the water-cooled gigaflop desktop biz can't be the future. They just canned a bunch of top management.

So it makes sense to trade runtime efficiency (as in, Python type things) for program quality and security.

The wall isn't too far away. EUV is still in doubt. Maybe the Moore's law feature-size progression will die from lack of demand, rather than lack of supply. If all you need is a hundred million transistors on a chip, there's no economic upside to doing that with 7 nm features and insane mask costs. About the only app that benefits from extreme resolution is memory.

Amen!

It's impressive that the software industry is able to evade legal liability for the damage they do.

Burroughs wrote their OS and their Algol compilers entirely in Algol. Apparently a couple of guys read the Algol source code of the first compiler and hand-compiled that to machine code, as the bootstrap.

A small tax on transactions, like 0.1%, would have a remarkable damping effect. Maybe we can get that soon, after the next monster worldwide crash.

What I want is a 1000x speed improvement, so I can move sliders and see waveforms change instantly, just like a breadboard with pots and a scope. N-dimensional iteration at 5 minutes per trial is not intuitive, but then 1 minute isn't either.

I did that kilovolt switcher design recently, and it was running 4 minutes per pass, until I removed the leakage inductance and got it down below 1 minute. Still, I got the design done in a few hours. Since I'll breadboard it anyhow, I didn't really need Spice.

My new Dell, due soon, will be maybe 5x faster. Spice will then probably be hard drive limited rather than compute bound. It shows up at about 50% CPU utilization on my old HP.

Spice on a GPU might make sense for some people, with ramdisk for the .raw files, but I don't really need that.

Some FPGA compiles are slow, but again probably hard drive limited. Or bloatware limited.

On Fri, 03 Jul 2015 09:17:48 -0700, John Larkin Gave us:

Did you post the fixed final design?