must-read book Brotopia: Breaking Up the Boys' Club of Silicon Valley

pia

enough people

s,

st to

at

ve a complete

ed at

e

You

are

interesting challenge.

h
l
e

r understanding of the condition.

Yup. But who is the expert on the thinking of autistics, autistics themselv es who are privy to every thought they ever have or people that really don' t think like them? There's too much of that kind of stupidity in psych.

NT

Reply to
tabbypurr
Loading thread data ...

They've moved past OOP to an extent. Functional's always been around ( and is being ... extended, shall we say? ). I've stopped arguing about generics for a long time now.

And frankly, the "abstract" part seems to be mostly puffery. Save five seconds typing with some template-element-thingy that provides acres of obfuscation:)

The thing we're talking about really is something hardware guys know well - how *deterministic* is your stuff? Most of us softies rarely get around to that.

--
Les Cargill
Reply to
Les Cargill

SO you don't think FSM can work like that? See below....

It scales *just fine*. You write out message sequence charts, people go code to that, then you integrate.

And 20-30 programmers is a lot of cat-herding. Pity the poor management...

--
Les Cargill
Reply to
Les Cargill

In a large project like that, programmers shouldn't be making changes to *ANY* state machines. That's the what the architect(s) do. The programmers implement, they don't design. Chip designers don't change the architecture of a processor, either. They implement the architect's design. That's probably why there is so much shit software out there. Too many cooks.

Reply to
krw

I tried the "Hungry Man" dinner once...incomplete, unbalanced and inadequate (not to mention expensive). One can do far better with veggies (pick combo you like today), steak (pick type: t-bone, rib, flank, etc) and potatoes (white, russet, yam, etc), add onions and/or garlic etc; build from scratch. Broil, bake, fry, etc as you choose.

Reply to
Robert Baer

Time is money. Hungry Man knows it as well as McD's.

Reply to
krw

When Mo is out of town, I can catch up on guy food. BBQ ribs, ham, frozen chicken pot pies, cheese and crackers, stuff you can eat over the sink.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

NO veggies, just a dinky chunk of meat and little else. If the price was 1/3 what one sees,it might be of decent value but still crap WRT any kind of balanced meal.

Reply to
Robert Baer

ALL far better in value...

Reply to
Robert Baer

So don't buy them. You're not their target market. What's so difficult to understand about that? OTOH, they're obviously profitable.

Reply to
krw

That's called "waterfall design" and has been passe in the software world for I'd guess 30 years or so. It's brittle, inflexible, too "top-down", there is no one "architect" or small group of architects who have a complete God's-eye picture of every single "state" or function or branch of code in a 100 million-line codebase.

Processor design is a different animal it takes years and years to bring a new architecture from concept to finalized design, the software world is working under much tighter deadlines and customers _expect_ major changes to be possible for most of the development cycle.

Giving a client this "the design is finalized and being implemented according to God's plan by the code monkeys and it cannot be touched" stuff would be a way to find yourself rapidly out of business

Reply to
bitrex

So has defect-free software. There is a reason Win* is such shit.

No, it's exactly the same thing. One group believes in the quality of their work.

So you think the race to the bottom is a good thing. I could have guessed that.

Reply to
krw

There are many reasons why Windoze is shit, but this isn't one of them.

Waterfall is passe because it implied that the design is complete, unambiguous and accurate. If that was true, then it is also

*compilable*, i.e. it only needs a machine to execute it.

We have a word for such a compilable design: we call it code. When you insist on design-up-front, you're just writing the code in design phase, and that has all the same problems of any coding. It's an infinite regress.

Clifford Heath.

Reply to
Clifford Heath

So far as I can tell they have calling something "waterfall", re-lableling the same beans, stirring the pot and calling something else that's essentially the same with the latest buzzword for over

30 years.

The customers don't know what is a major change and what isn't.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

There's a lot of lousy code out there, but there's also more great code out there than there's ever been in history. Well-designed and implemented software using "modern" practices is not at all hard to find. Flawed hardware designed top-down is not at all hard to find, e.g. Spectre, Meltdown.

Windows isn't shitty because of the techniques used to develop modern software, it's mostly because it is and always has been a slave to the past and backwards compatibility. It's always needed a ground-up rewrite since about 1990 which it never got.

I remember watching a 133 MHz PC running BeOS display 32 full-motion videos in windows on its desktop while you could simultaneously edit a document in the word processor with no hiccups or lag at all. In 1997. Win 95 would choke and crash under a tenth of that workload. But BeOS couldn't run 10 year old DOS productivity software. BeOS is gone with the snows of yesteryear.

Reply to
bitrex

What an asinine statement. First, of course there is decent code out there and even more than ever. Dumbshit, there is a *lot* more code every day. Almost all shit. Compared to stuff like the Shuttle OBS and S/360, almost all is shit. Some is man-rated, so one hopes it's somewhat better but it's certainly not done in an ad-hoc, throw-it-together, uncontrolled process as you suggest. It's not the code we see every day.

Wrong. Stack overflows are precisely due to the way code is developed today. There is no excuse for such things.

Change of subject again.

Reply to
krw

Right, you don't really gain anything by shifting all the design work to the God-guy "architect", it just means you're implicitly bottlenecking yourself thru having one guy write all the code instead of ten.

You don't hire a team of software engineers to be data-entry people to bring Great Visionary Architect Howard Roark's perfect design into being, that's not how it works. If you want to hire typists hire typists.

Reply to
bitrex

lol you have a weird idea how software is developed in practice. Even the Space Shuttle GPC software was not developed purely top-down by the methods you're talking about. They solicited feature and modification requests from everybody under the sun all the way down to maintenance techs and the ground crew. In the early 1980s the team at IBM was processing 30 or 40 change/feature requests a week. Clearly they were not all implemented but they were all taken seriously.

What made it so reliable was not the "design philosophy", it had a huge "ad-hoc" component to it, but it was extensively, extensively, extensively bug checked and tested, and enormous amounts of money was thrown at that process.

The majority of code out there in 2018 runs on virtual machines in browsers or the JVM there is no hardware stack to overflow. And in compiled languages it's just the reverse; stack overflows are primarily a consequence of how "legacy" languages from the 1970s and 1980s manage memory which is full of undefined behavior and stupid unintuitive gotchas that even the best programmers have trouble reasoning about effectively.

Reply to
bitrex

No. But getting paid for work done is rather important. The customer is always right (even when he is wrong). I give mine the opportunity not to make stupid mistakes but if they fail to take my advice they sign in blood that they understand what they are asking for will cost them.

Spectre and Metldown are security exploits of correctly working but deterministic hardware. The cache engineering was sound in terms of achieving faster execution. FDIV bug and incorrectly accepted invalid OPCODES were genuine CPU hardware design mistakes.

I'd guess it was about 50:50 without having done a detailed survey. You hear about the big stuff that goes horribly wrong - you don't hear about the small successes like ABS brakes, mobile phones etc which just work.

I wouldn't use Shuttle code as an example - there was a known synch issue with the multiple processor voting implementation that could freeze the launch and wasn't worth going in to fix. They also had schedule induced process issues that made it into comp.risks

formatting link

As for OS/360 I always loved Fortran G1's lack of confidence when it reported "NO DIAGNOSTICS GENERATED?". The "?" being a trailing NUL byte which IBM change management procedures made too difficult to correct. (it was after all a cosmetic bug)

Your IBM terminal concentrators were unmitigated crap. Phoenix ran a vastly larger number of simultaneous terminal sessions using DEC PDP11 hardware to link them. NIOP could run rings round original IBM code.

Parrot - a TCAM replacement by Hazel & Stonely is actually online free these days.

formatting link

Although I agree that there is no excuse for it today but the worst bugs are mostly a side effect of the ubiquitous C nul terminated string.

We have never had better tools for static code analysis and runtime defensive testing but sadly they are not deployed very widely :(

--
Regards, 
Martin Brown
Reply to
Martin Brown

snip

This one eats good...

formatting link

Reply to
Long Hair

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.