Why is software inherently shit? Why is spaghetti code, memory leaks, segfaults, etc the STANDARD in programming?

suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. After the introductions are made, you are invited to come up with some new ideas, but you don’t have any because you’re a propulsion engineer and don’t know anything about bridges.

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.

The absolute state of software:

Removing 90% of the bugs costs X, removing 99% costs 10X, removing 99.9% costs 100X.

For most software it's not worth getting it perfect.

I agree with this post and would like to add that with software there is a limited lifetime it will be good and secure and it takes nothing but huge man hours to create.

Programers who can actually get anything fucking done on a professional level are in HUGE demand right now, they can easily earn $100 or more per hour. Given that any program worth having takes thousands and thousands of hours to code and will only last a finite time and you can see why it's a tough business.

Attached: 1533776204381.png (1080x720, 1.23M)

>muh spaghetti code
Literally hasn't been a thing since the 80s when people used procedural BASIC.

Broken gets fixed.
Flakey gets worked around.

XKCD thread?

Attached: SASDAD.png (376x555, 67K)

what is going on here? They are all dreaming that they are all dreaming the same thing?

Fully electronic voting is dangerous because it gives all the power to the person that made the machines.
They can change the results and never be caught.
The entire reason America is a republic is to NOT do this.

good thing with paper ballots the same can't be said for whoever you let count the fucking paper ballots dumbass

>boomer who retired decades ago and never had to deal with Java codebases with a thousand singletons communicating in two thousand directions.

>one person counts paper ballots
>what is machine counting

this. normies and office politics ruin everything
yeah I used to believe this but over the years am starting to feel its just an excuse

how is a machine counting the ballots not the same as a machine recording the votes in software?

C++

fpbp

>Why is spaghetti code, memory leaks, segfaults, etc the STANDARD
Because C is the standard.

Then you should be able to give an example of non-buggy software right?

no, they think themselves superior, then have a second thought that maybe others have the same perpective.

any program made in any language other than C/C++ is non-buggy compared to any program made in C/C++

There is a reason why Java and C# dominate enterprise programming, because they are statically typed and garbage collected. Unfortunately these languages run on a VM and so are slow and bloated. But we have new compiled languages like Swift, Go, Rust, etc to take there place

ballots leave the voting places directly to centrals with observers from several rival parties and other ppl.
some ppl can defraud some ballot baxes sometimes, a federal mafia would be unlikely to plant collaborators in a significant portion of the transporter teams.
now with computers ill assume its self evident

patch(1) works so reliably that the entire history of version control software relies on it.

I'm no expert, but I suspect that a lot of software is shit precisely because at the end of the day, it's not going to kill people if it fails. At least, not directly - it might lose people money and they might die because of that, etc. - but it's not going to kill people the way a badly constructed bridge or aircraft might kill people. Because of this, software is often written in such a fashion that the developers, even if they are good, don't get enough time to actually construct a sound, strong piece of code. Is it good enough that the client will be satisfied and it won't go berserk and lose the client a bunch of money? Great, ship it! "But it's ugly and brittle..." Fuck that, we can't afford to make it beautiful and fundamentally sound, ship the shit!
My professional experience is limited (3 years), so I could of course be wrong though...

Because even a low end system is still more than good enough to cope with it.

Having more than 1MB of RAM was a mistake.

Relevant article from security perspective

medium.com/message/everything-is-broken-81e5f33a24e1

>My professional experience is limited (3 years), so I could of course be wrong though...
yeah, youre extremely wrong. embedded systems that control machinery and equipment that humans use have to go through an extremely rigorous testing and validation process

I think those fall into the category of "might kill people if the code sucks". Maybe you didn't understand what I wrote?

If that's true then why is old software written much better, and uses far less resources, then newer software?

what you wrote was stupid, I would have to be stupid myself to understand it

What he said is true for most other applications of software though. It's precisely that: lack of good engineering is what makes most software shit.

>It's precisely that: lack of good engineering is what makes most software shit.
which is stupid and says nothing

>why does old software use less resources than newer software
>what is moore's law
>what is survivorship bias

Attached: 1511414778288.gif (322x364, 9K)

Machine time is cheaper than programmer time. The buggy, shitty programs from back then didn't survive.

Sure, for a pajeet like you it does.

I know XKCD is reserved for only the most autistic and smarmy of fags, but I had to fix this one.

Seriously though I fucking hate xkcd, and 99% of webcomics. Fucking reddit-tier normie humor.

Attached: fixed.png (602x606, 76K)

>>what is moore's law
Irrelevant to what I said.
>>what is survivorship bias
That doesn't mean what you think it means.

you're invoking moore's law where it's completely irrelevant

not so much anymore; a lag of up to seconds between click and response is now the norm for me. layers of frameworks, probably a JS interpreter on top of another interpreter, multiple garbage collectors making a sweep, are all churning away so that [application name here] can accomplish the simplest fucking thing.

i find that things that are written in C today tend to be better quality because of a higher relative barrier to entry

it's odd that people will deny software bloating or justify it by saying "software is more advanced today". how much more advanced is the latest MS office over office 97? not much. the system requirements have certainly advanced though, and the user experience has degraded.

Attached: 10931432_770279959729435_3388272894245396955_n.png (650x506, 208K)

I mean, the comic is basically referencing safety/security use, and it's just not really a good argument to make.
Planes can be hijacked and/or tampered with and taken down, creating a tragedy.
Elevators can also be tampered with so it doesn't function as it should.
But in neither instance is such a thing considered a "normal" or "regular" thing to happen.

With software, however, people attempting to break it, break into it and sabotage it is not only a very real threat, it's actually expected to happen. Further, even if, somehow, the software is completely and entirely bulletproof, it's still subject to a fallacy that it's really only as secure as the hardware it's running on.
And if it's something that someone could have a lot to gain from, it's assured that someone is going to try to do it.

Basically, in other fields of engineering you're preventing something from breaking on its own and from very predictable use conditions.
In programming you not only have to accomplish that, you also have to attempt to prevent external unknown threats and tampering, which isn't very feasible in the vast majority of situations.

>Irrelevant to what I said.
No, it's completely relevant. Older software that uses 64 MB of ram seems light today, but absolutely was considered bloated back in the day. You only think that "older software uses less resources" because of Moore's law.

>That doesn't mean what you think it means.
No, I used it correctly. You think older software was written much better because only the useful, usable and functional software from that time is what you use today. Only the well-written projects survived because they didn't accrue technical debt. You are ignoring thousands of projects that got abandoned and tossed in the trash due to shittiness.

Older software is garbage. The fact that you could still grep through codebases for gets() vulnerabilities as recently as 2000 is proof enough.

Its not the fault of programming languages that there is bloat unless youre using a VM language like Java or C#. It is still possible to make extremly light weight software. The reason that software has become bloated is inefficient OS windowing systems and overuse of external libraries.

i didn't even say it's the fault of programming languages

>overuse of external libraries
yes, exactly. things like electron especially are really bloating things to farcical levels

older software uses less resources IN ABSOLUTE TERMS. bloat = requirements / functionality

Attached: 12243465_979107185513377_2311378918379572503_n.jpg (500x500, 22K)

Going in absolute terms is a bullshit argument though when actual older software was a case of having to completely reboot a system into that software to run it.

christ what sort of fucking argument is this

i was talking above about office 97 as one example. do you have to fucking boot into that? no.

>older software uses less resources IN ABSOLUTE TERMS.
Because it has less functionality and was designed at a time when resources were a bottleneck? Again, you only think older software is "less bloated" because of Moore's law.

At the time, a lot of the software you're claiming isn't bloated was definitely considered bloatware.

Office 97 has less functionality than modern word.

i like spaghetti user

>Because it has less functionality
possibly, but not necessarily

list the office 97 features the positively necessitate the insane bloating of office over the years.

>Office 97 has less functionality than modern word.
as above

in fact we can look at any bloated piece of software trying to find what new features justify its bloatedness over past versions, we will be left empty handed

Because there are always more possibilities than you can possibly account for during the development process.

Office 97 objectively has less features than Office 2016

You can argue about the necessity or usefulness of those features, but that's largely subjective and a matter of personal opinion.

You're conflating "functionality" with "my personal use for features"

list the office 97 features that positively necessitate the insane bloating of office over the years.

Your question is nonsensical.

Reminder that "just" one megabyte is space for at least 262,144 x86 instructions. There are no excuses for the level of bloat we see in modern software.

you're saying sofware is so incredibly inefficient today because it has more features than past versions. i want you to enumerate some of the features that demonstrate this causative relationship, otherwise your argument is based on nothing more than supposition.

i think you know, deep down, that bloating is because of shitty practices like using ever-growing towers of frameworks and pulling in massive libraries as shared objects (therefore precluding any dead code elimination, let's just ship this software with a dozen 100MB external library .dlls even though we use very little of the libraries in total, right guys). it's not because of an expanded feature set.

And the entirety of War and Peace is 3MB.

You said
>list the office 97 features that positively necessitate the insane bloating of office over the years.

Did you mean
>list the office 2016 features that positively necessitate the insane bloating of office over the years.
?

>Why is software inherently shit?
The same reason machine translations are shit. You're trying to convert your thoughts into logical statements and then trying to write them with a language. A language that you haven't perfectly memorized the grammar rules for, and might have multiple dialects for certain things (implementation specific). And then it's automatically translated into another language.

oh, yes. office 97 being the thing to compare it to.

Just go look at Office 2016 features compared to 97.

The "usefulness" of those features is subjective and varies depending on your use case

i'm not seeing any features that necessitate this jump in requirements:

97:
Intel 486
16 MB RAM
60 MB of available disk space

2016:
1 GHz processor (but by which measurement? pentium 4? core 2? certainly not 486)
2 GB RAM.
3 GB of available disk space
You will also need .NET 4 or 4.5 CLR (yet more gigabytes)

I bet it's also because some software is written by people who are chemists, physicists, etc.
I know because I am of those.

I have friends who work as consultants. They're pretty much always hired to do the absolute minimum. Obviously they would prefer to produce high quality code, but that's up to the client.

the reason that happens is due to feature bloat
most software is a product and the people selling it want to sell it to the most people, so they'll try to accommodate everybody to get maximum sales

Software engineering is still evolving. 10 years ago, the OS, compilers, code language, etc. were all shit. 20 years ago it was even worse. 30 years ago perhaps none-existant and everybody had to do shit by terminal. 40 years ago fucking punch cards.
If somebody hands you a shit pen and shit paper, nobody is going to blame you for shit work. However, over time, we're polishing this shitness so shit works a little easier, less problems, more flexibility and scalability.

t. electron and node.js user

OSes were better to use 10 years ago, even more so 20 years ago

It's a retarded edit of an XKCD comic that originally made sense turned into something 'smarter'.

There's a strange lack of continuity in software engineering. Technologies are dropped based on trends and then picked up again (with a different name) decades later.

Because it's possible to do things very quickly, unlike other forms of engineering. So you are competing to do things in the fastest possible way, rather than the safest, most solid way.

Because it is fucking difficult.

When we build something like a car, a house, or a chair, we can see what we have created. We can use our natural senses of sight, touch, etc. to guage the quality of the final product based on our innate understanding of the environment that we have spent every moment of our life in.

When we write software, we rely on audiovisual outputs that are only as good as the platform we are writing for. We can't see the underlying transistors to guage whether we have built a masterpiece or a ticking time bomb. We can't see a scratch on the surface, or a misaligned part. We can't feel a wobbly leg or a loose screw.

Don't try and argue that you understand the platform, because there is no possible way that you have seen and understand every single line of code and input, every single operation and data stream of the platform you are using.

We go in blind, and come out blind with a pile of shit that does what we want it to, but we don't understand.

Nice autism.

This is just plain wrong if you're not a total webshit

Sup randall

because you're not using openbsd, and you're not contributing to the openbsd project

>Linux people do what they do because they hate Microsoft. We do what we do because we love Unix.
>It's terrible, everyone is using it, and they don't realize how bad it is. And the Linux people will just stick with it and add to it rather than stepping back and saying, 'This is garbage and we should fix it.' on the quality of the code of the Linux kernel
>Low code quality keeps haunting our entire industry. That, and sloppy programmers who don't understand the frameworks they work within. They're like plumbers high on glue.
>The world doesn't live off jam and fancy perfumes - it lives off bread and meat and potatoes. Nothing changes. All the big fancy stuff is sloppy stuff that crashes. I don't need dancing baloney - I need stuff that works. That's not as pretty, and just as hard.
>Our solutions provide something that is 100% right, all the time. That is the idea. The cobbled together gunk never does [...] It's unfortunate the application-level people are all caught up in cobble, cobble, cobble and just never learn how to evolve.

it was made relevant, you salty normie

>Current UI libraries are fucking shit, and hard af to use
>Along comes Electron, letting you use tried and tested, easy as fuck to write, HTML in a local environment
>Anons get mad because it's easier than what they've been doing the entire time until that point

Believe me, you do not want me and people on my level to contribute to any open source project.

>Believe me, you do not want me and people on my level to contribute to any open source project.
?

It's not if you actually have a QA process.

Even if your designing a car it's going to have a development build to begin with that goes through tests before large scale manufacturing. Even then you can have the odd lemon in that model.

But with software it's different because we can always rollback the current build or push bug fixes into a production system while a car would need a mass recall so they have mor pressuee to get it right the first time.

There is a very high demand for software which creates opportunities for even sub-par programmers, back in the day the demand was much lower so most software was produced by relatively good programmers. And modern devices such as JS allow for very bad programmers to produce results

electron is fucking horrible to use

How does this voting system works in the USA ?

Holy shit is that Aphex?

Software is abstract and people don't fucking understand it.

Show a manager a shit engineer who builds a shit bridge in 2 months
Show a manager a great engineer who builds a great bridge in 6 months

Manager will clearly be able to see the cheap shitty engineer did a bodge dangerous job and if not when it will get rejected by stringent safety standards checks, because he has to be professionally accredited.

Show a manager a shit developer who builds shit software in 2 months
Show a manager a great developer who builds great software in 6 months

Manager will be like
>"I like this other guy, he did the job in only 2 months for half the price."
>"What's the problem, it works doesn't it?"
>"I'm going to hire the cheaper guy again, he's much faster"
>"What do you mean you can't maintain his code, all you have to do is add feature X. He says he got 50% of the way there on feature X already, he already showed me a working prototype"
>"I'm going to promote shit guy, he rolls up his sleeves and gets results, I like his can-do attitude."

foobar is the pinnacle of good programming.
I'm impressed every time I use it.
I sometimes run it through wine, just to get the foobar feeling back
None of the music players I've tried on linux can compare to it.
Closest being Audacious which atleast supports LADSPA effects (like VSTs for foobar)

Attached: 1533742617661.jpg (1280x960, 90K)

yeah

Attached: 10985860_874942012596562_5796523369975443320_n.jpg (462x424, 23K)

That comic is misleading.

Notice how in the first two cases it's explicitly about SAFETY.
In the final case it's about SECURITY, though.
Two completely different things.
Also, computer voting is fucking retarded, and that's a completely different matter than what you are trying to talk about.

Because most software has a code monkey behind it, not an engineer.

Software Engineer is a meme.

>It's also intrinsically harder.
lmao

Based user. I like your metaphor, pretty much sums it all

nice

>hemorrhaging-edge
K E K