scientists as superstars

Do you compile, run, test, and debug at each iteration? If not, why iterate? Just write the whole thing.

On a sunny day (Wed, 12 Aug 2020 11:02:17 -0700) it happened John Larkin wrote in :

I am not talking about iteration, something you and Elon seem to be into. Iteration comes when you have no grasp of what you want to do :-) I mentioned *incremental*, one part at the time, test it, next part. Like put on one ski on one foot, make sure it is OK, then the other on the other foot? Write part of your idea in code, test it. Then the next part. I must say that over all the years I hardly have encountered any structural (if you want to call it that way) issues (idea wrong, never). Once I start coding I know exactly what I want the thing to do. It is silly to start coding (or building anything) if you have no clue what you want, costly too.

I was wondering .. how long it will be .. before we see a computah language with the but first statement

I simply do not see the problems you guys have, try doing some embedded in asm.

Freaking ... I do not even use a debugger, neither do I use the Microchip tools, man I even wrote the PIC programmer. And in C use printf(), what has the world come to?

First, the entire Win32 API was a petri dish for pathology. They pointerized parameters that didn't even need to be pointerized.

Second, for a long time all that crudity extended the natural life of installed systems. Linux still doesn't properly do "multimedia" without considerable value-added work.

Not so much any more. Not so much for quite some time now.

Lousy metaphor, really. Lousy when ESR coined it and even less so now :)

In software, architecture won't save you.

OK, you code, let the compiler find the spelling and syntax and typing errors, run it, test it, debug it, and then when it looks OK, add more source code and repeat.

That's standard operating procdure in the world of software. If we did that in hardware design, we'd never ship a product. We have to get the entire thing right first time, before we apply power.

Some people, probably you, have native talent to get it right. But such people are a minority, and the world needs a lot of code, and most of it is bad and buggy. A hard embedded system is a nice tight single-person programming challenge, too. One person owns every line of code, and there are mere thousands of lines of code.

I'm competing with an organization that does design that way. I could have shipped in 4 or 5 months from "go." Their policy is incremental design. They scheduled two big teams for two years. The latest schedule calls for a final design (ready to qualify!) in 3.5 years from start, but I doubt they will make that. Their sunk cost is gigantic now.

Certainly not. Snap into skis. Get on the chair lift. Ascend 1800 feet. At the top, unload and ski straight down. That's the test.

On a sunny day (Thu, 13 Aug 2020 07:46:05 -0700) it happened snipped-for-privacy@highlandsniptechnology.com wrote in :

I do not mind saying you are right, for 100$ I will say it once and give you a discount

I do not start coding unless I know how to tell the thing to solve the problem. A big advantage of open source is that zillions of people have solved zillions of problems and you can learn from their code and use their libraries if you want. Add you own solutions to the public space...

Capitalism is out to extract the maximum money out of 'things'. You see that with many projects, military, and often the taxpayer pays. Once you could go to the moon, all that happened after that was driving around the block at a cost of trillions for the taxpayer and human life. Job creation program. There was Obamacare project, in a weekend some students made the website..

Every year trains come back here from Switzerland with people in casts.. broken things... You left that part out. But in cars airbags are required by law I think. Even the mars landers used airbags! Get smart :-) Anyways pointless to argue, let's agree on eh... taste of chocolate being good? It is so hot here my chocolates melted.

You folk are good at horizontal things. Vertical, not so much :P

CH

They do mud really well though. You have to give them that.

Cheers

Phil Hobbs

(Who used to spend time in New Mexico, where they specialize in dirt and rocks.)

When I was a kid, we knew that rocks came in barges from rock factories. We had geology classes and didn't believe any of it.

Mozzlla seems to have dumped at least some of the Rust team:

It perhaps should not be niche, but it is.

There are high reliability methologies where you exhaustively account for all the invariants ( things that must be true for correct operation ).

It's not a well-known methodology. During the CASE tool era, there were several; just do that without the CASE tool. You can do it in Haskell with the Actor pattern.

It's not that far from thinking like an FPGA designer.

Green Hills has really tight memory protection built into its products. It's ... bad, but not that bad. Kluncky.

Because the licensing prevents it. The political economy of software is very, very bent. Correctness is simply not a consideration unless you can make it a billable thing, like the testing done in avionics.

You can translate known models ( frequently state machine like ones ) directly into code. There will be minimal knuckle-busting and the remaining defects are then all hard cases ( timing, race conditions, the like ). After a span of time, you stop making hard cases too.

Then that null better be there.

There was something akin to a gold rush in PC software and IBM never had their head in the game. Remember that this was when EDS was one of IBM's biggest VARs, and IBM themselves were trying to embrace a service model.

I personally saw lots of PS2 machines installed.

Eh. It's all a game of constraints. Kids just aren't taught; the emphasis is on getting butts in seats as fast as possible. The kids are struggling, too. Lots of "impostor syndrome" and the like.

And getting faster.

More than a few; it's moving mainstream. Visual Studio now has LLVM as an option.

:) I've fixed sooooo many hardware problems in software...

IBM wasn't actually interested in it. It's something that happened *to* them.

It's not even accounted for, nor is it an actual cost in the usual sense of the word - nobody's trying to make this actually less expensive.

That's what "managed languages" like Java or C# do. It's all bytecode in a VM.

And there you have it. That's next.

Sort of like UCSD Pascal, circa 1975. ;)

Not in our shop. We just had an 8-day phone/net/cell outage on account of a dippy little 50kt storm that blew through in three hours (Isaias). I was having to wardrive to find a place with enough cell bars that I could use my phone's hotspot, so eventually I just started working from home again, where there was still cell service.

And then there's the data security problem.

Cheers

Phil Hobbs

I doubt they will remain unemployed. Rust is gaining traction in wider settings.

Linus Torvalds is vociferously and famously opposed to having C++ anywhere near the Linux kernel (good taste IMNSHO). He has given a big hint he wouldn't oppose Rust, by stating that if it is there it should be enabled by default.

It also goes lower than that. The processor internally decomposes x86 ISA instructions into sequences of simpler micro operations that are invisible externally. Yup, microcode :)

... the triumphant reinvention of bureaux timesharing systems.

Greybeards remember the collective sighs of relief when users realised PCs enabled them to finally get hold of and own their own data

Have you ever looked at the errata lists associated with modern processors?

SPARK/Ada is well known and well developed and used. It was originated by one of my university lecturers, Bernard Carre.

There are many useful design methods. They all have two fundamental problems: - stuff that is outside the methodology, e.g. runtimes and libraries - incorrect/unproven specifications

I doubt that, since if that was the case then other engineering disciplines would use the same technique!

I'm waiting to see how the legal system deals with machine learning systems in terms of - baked in illegal biases, where nobody knows why "the computer" made a decision - accident liability, e.g. with cars

Consequential damages would be a starting point.

In high school, we got a gravel track, with imported crushed rock. From which I harvested a bunch of semiconductor crystals (iron pyrite). But, aside from riverbeds, the soils were all sand and clay.

It is said that in parts of Kansas, every rock you find is...a meteorite. Ditto some ice fields in Antarctica.

On a sunny day (Fri, 14 Aug 2020 09:46:09 +1000) it happened Clifford Heath wrote in :

Yes, we only got one small hill in the south, the rest is flat, much even below sea level, protected by dikes and pumps. Amsterdam is about 2 meters or so below sea level. We can swim! ;-)