Software is stupid, programmers are overpaid poets.

[dryjoints]

... well that's what I think. Now read this:

https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Get ready for self-crashing cars & self-employing robots. 

[Brumby]

The programmer(s) were certainly the creator of the problem - but the responsibility lays with whoever signed it off as "production ready".


I could go on about systems design, review, coding, testing, etc....  but I won't - or I'll be here all week.

[Richard Crowley]

Welcome to the 20th century (and beyond).
Electrocution was unknown until the 20th century.
Just another cost of doing business in the modern age. 

[HalFET]

Could have been solved if they had only done more unit testing, added more abstraction layers, and introduced that fancy new framework!

[Brumby]

...or they could have asked someone how many calls come in - rather than using a blind guess.

[dmills]

and introduced that fancy new framework!

Ah, you work with "web programmers" too .

Funny how the frigging web site on an embedded device ends up using more code space then the program that does whatever the thing was really intended to do (And how when you point out that the result needs an I7 with modern gamer graphics to render properly, they cannot explain where the time goes).

Regards, Dan.

[Berni]

Could have been solved if they had only done more unit testing, added more abstraction layers, and introduced that fancy new framework!

That is exactly why i don't like where programing is going these days.

Everything is buried under so many layers that nobody really even understands exactly what is going on anymore and then something you did at the top layer causes something unexpected to happen 4 layers down the software stack. The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.

EDIT: Oh and yes how the thing now suddenly needs 60MB of RAM to run on some small embedded system because of all the junk the lower layers are hauling with it and certain operations in the top layer are so slow that they start affecting the UI responsiveness even tho there is a big ass multicore 2GHz ARM CPU running it all

[dmills]

Oh yes, the PC (And Web) programmers view that RAM is infinite, and that only crashing once a month is reliable  .

I also love that javascript (Spit!) does not let you do proper networking, in particular it seems you cannot listen to a UDP port, and multicast is 'interesting' very annoying when you have something like audio metering data that you want on a devices web page. Would generating arbitrary TCP packets really have been too much to ask?

Everyone should start by being required to write "Elite" on an 8 bit 1MHz 6502 with 48kB of RAM (Including the frame buffer).

Regards, Dan.

[llkiwi2006]

The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.

How is that a problem? Often the first step to locating a bug is when it occurs and what changes will cause it to not occur. There are people who understand the lower layers, so communicate with them and they will help you with your issue. Isn't it the same thing true in hardware? Do you understand the design decisions in an ic that might be causing you problems?

Although I do agree there is too much complexity and abstractions quite a lot of software, especially things using "web technologies" (looking at you electron).

[llkiwi2006]

only crashing once a month is reliable

Hey crashing for 45 minutes every month is still 99.9% reliability. /s

[dmills]

Hey crashing for 45 minutes every month is still 99.9% reliability. /s

Quite!

Regards, Dan.

[Rerouter]

Ok, this seems like a dumb question, but if the TLA+ they keep praising fixes many fundamental issues, and they seem to imply it is only acceptance by programmers that is preventing it wider access.

Why is it a java backbone,
And if I had to climb the hill that would be using Eclipse IDE, could TLA+ toolbox be used with something like an embedded micro controller, spitting out firmware, or is this locked away to the likes of computer programming,

[Berni]

The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.

How is that a problem? Often the first step to locating a bug is when it occurs and what changes will cause it to not occur. There are people who understand the lower layers, so communicate with them and they will help you with your issue. Isn't it the same thing true in hardware? Do you understand the design decisions in an ic that might be causing you problems?

Although I do agree there is too much complexity and abstractions quite a lot of software, especially things using "web technologies" (looking at you electron).

Yes but i mean the nonsense bugs that you have no idea why they happen and the documentation doesn't say anything about it and the layers underneath are not in your control.

For example i had a case where i was using the .NET chart control in C# and came across a bug where the whole program would suddenly crash inside of the paint calls to the controls. The debugger doesn't really give you any details where it happened, just tells you what form window the event handler crashed on, but i knew it was the chart controls fault as it only happened when i did stuff to it. If it had the source code for that control then it would likely point you into it and where the crash happened. Normally the this chart control has some safeguards inside it that draw a big red X mark across the control when it gets too confused or misconfigured to draw something reasonable. Well they forgot to safeguard against this overflow that happens if your charts Y axis has values above about 1 million and you zoom into a small part of the chart. Okay so then il just wrap a error handler around it to catch it so that my program doesn't crash on the spot but just shows an error text or something. Well... the mechanism that calls events is deeper down in .NET so i can't just wrap a Try statement around it, nor can i wrap the code that's causing it in a Try statement since i don't have the source code to the chart control. Consulting the documentation says that it should display a red X when it encounters an error. Don't think anyone at microsoft would be willing to help me with the problem, but if enough people complain they will probably fix it in the next version of the .NET Framework.

I guess it is a bit similar in hardware, but the layers underneath tend to be simpler than these massive software stacks that modern code runs on. So its easier to properly document them and debug them. Tho when writing hardware drivers i do run into cases where something is just plain broken. For example on TIs OMAP processors the SD card controllers buffer full flag was always zero, it supposedly worked for DMA transfers but manually reading it doesn't. The fault was not yet documented in the PDFs but the solution was to instead wait for the buffer empty flag(that worked fine) and fill the buffer with how ever many bytes the buffer is supposed to be able to hold.

[janoc]

Oh yes, the PC (And Web) programmers view that RAM is infinite, and that only crashing once a month is reliable  .

I also love that javascript (Spit!) does not let you do proper networking, in particular it seems you cannot listen to a UDP port, and multicast is 'interesting' very annoying when you have something like audio metering data that you want on a devices web page. Would generating arbitrary TCP packets really have been too much to ask?

Everyone should start by being required to write "Elite" on an 8 bit 1MHz 6502 with 48kB of RAM (Including the frame buffer).

Regards, Dan.

Yes, it would be a serious problem. Javascript in a browser is designed to run in a sandbox, if you let it open arbitrary network connections and generate random packets, you will have the largest DDOS botnet in the world - just pay a few bucks to an ad network to deliver your code as ads on some high profile websites.

And this is not a theoretical attack - it has been done. There are websites that abuse your browser for cryptocurrency mining, for DDOS, etc.

Before you complain about such limitation, try to think a bit outside of your problem "box" why that limitation is actually there.

If you are writing stuff like that in Javascript, you are most likely doing it wrong.

[chris_leyson]

I guess it is a bit similar in hardware, but the layers underneath tend to be simpler than these massive software stacks that modern code runs on

I think some hardware is starting to go that way, one example is control loops in SMPS controllers. The traditional analogue opamps and comparators are being replaced by digital control loops so you can't use traditional control theory anymore to model you power supply. The digital control loops aren't even properly documented so they just become some abstract hidden layer of hardware which you end up having to second guess. Power Integrations and Dialog Semiconductor are just two companies I can think of with ON Semi and maybe TI working on similar designs. To be fair Dialog Semi at least give you a simulator.

[Jeroen3]

UncleBob Expecting Professionalism (Kuppelsalen, Copenhagen)
Watch 1:07:37 to 1:12:45-ish. And maybe the rest of it as well.
Uncle Bob: "Half the programmers in the world have less than 5 years experience."

[dmills]

you will have the largest DDOS botnet in the world - just pay a few bucks to an ad network to deliver your code as ads on some high profile websites.

That surely is what firewall rules exist to prevent?

End of the day I don't really care what the JS does within its sandbox, but there are more appropriate places to filter network frames then at the edge of the sandbox, and those places are generally more usefully configurable.

I would get less annoyed by this sort of thing if I was not always being told by our web devs that web based 'apps' were the future, when they clearly cannot do basic things that I would expect of a general purpose machine.

regards, Dan.

[dryjoints]

Additionally, I find the term "programmer" to be somewhat of an ego massage, considering how many layers of software goop are underneath the layer that the "programmer" is copy/pasting templates into; unlike ASM, I very much doubt, if not almost GUARANTEE, that the "programmer" doesn't know, and never did know, the ASM instructions for the silicon upon which those many layers of software goop are piled.

Then, we have the hilarity that is some of them calling themselves "Software Engineers"

[lundmar]

http://programming-motherfucker.com

[Vtile]

There should be more serious use of coding languages like Grafcet seriously, instead of C derivatives or even Wirthian lingos..

[GeorgeOfTheJungle]

I also love that javascript (Spit!) does not let you do proper networking, in particular it seems you cannot listen to a UDP port, and multicast is 'interesting' very annoying when you have something like audio metering data that you want on a devices web page. Would generating arbitrary TCP packets really have been too much to ask?

You're confusing Javascript and the DOM, it's a common mistake. And imagine if any web page could arbitrarily generate any TCP packets it wanted... as in freely mess with your network.

[bd139]

I’m not a programmer, I’m a unicorn shit shoveller.

Reality https://www.stilldrinking.org/programming-sucks

[GeorgeOfTheJungle]

End of the day I don't really care what the JS does within its sandbox, but there are more appropriate places to filter network frames then at the edge of the sandbox, and those places are generally more usefully configurable.

I would get less annoyed by this sort of thing if I was not always being told by our web devs that web based 'apps' were the future, when they clearly cannot do basic things that I would expect of a general purpose machine.

Yes, you can do that 100% in javascript, but don't expect the browser to do it because a browser is designed  to run programs coming from any web page you visit and therefore must have severe privilege limitations. Many apps are written in .js and can do anything you want without the limitations of a browser, because they don't run in a browser.

[tggzzz]

Additionally, I find the term "programmer" to be somewhat of an ego massage, considering how many layers of software goop are underneath the layer that the "programmer" is copy/pasting templates into; unlike ASM, I very much doubt, if not almost GUARANTEE, that the "programmer" doesn't know, and never did know, the ASM instructions for the silicon upon which those many layers of software goop are piled.

I'd be content if they could give a very rough pseudocode explanation of what happens during a function call.

[Kjelt]

Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin.

SW has become massive the last decade. Many HW eng's have no clue how many locs are written and that it is virtually impossible to prevent all possible conditions, test all forks and all possible outcomes.
Very expensive software, tests the code and tries to find all unhandled situations and reports issues.
We once had five sw engineers work three months to get rid of all the possible issues that came from two months coding, it can be that complex.
than most modern code use open source third party stacks what is in those, or do you think those are perfect? Do they really behave as documented under all conditions. Can they handle gracefully all input parameters?

When I started 20+ years ago we had 3x more HW engineers than emb. SW engineers, we now have 20x more SW engineers than HW engineers, do you really think that is because the Company does not care? Or does it want all the latest and greatest "features" that clients can think of in their product?