λ - programming

Because most software is rushed to meet deadlines.

All Software is like kicking dead whales down the beach (tm)

>>11076
Because the vast majority of people who create it don't know soykaf or don't care, and they hate doing it.
The remaining few who love to and are brilliant are spread so thin that they often fall flat of their dreams and potentials whilst being forced to whore their minds elsewhere just to make ends meet.

what "software" do you use that you dont like?

>>11076
That is a small question with a large answer.
Part of it is because making software is big work now. Some people get paid by how much software they write and not how well they write it.
Appealing to people who don't want to learn is why web browsers and televisions can be used to order pizza and all other sorts of ridiculous things.
I would also cite language choice as part of the reason for this. Compatibility and legacy uses help keep bad languages, made to make the programmer fungible and restricted, alive well past their expiration date and make what is one line in one language tens (or sometimes even hundreds) of lines in the languages most people actually use.
It's a big mess and even some standards are pretty gross, like the www. It's pretty telling about a "standard" if only a handful of giant organizations are able to implement it somewhat completely.
Fortunately, you can help by implementing programs yourself for your own needs. It's great fun and the level of control you get is amazing to feel.

>>11081
I hate my web browser, firefox. It's the only program I use full of ridiculously exploitable security holes and it crashes constantly on OpenBSD, usually dozens of times a day.

Something that may be interesting is to collect ideas about what drives software to be bad. What do you like and dislike in your programs? To start off: I'd much rather a program slow down instead of crashing. Both should be avoided if possible, but slow down is understandable at times. Firefox does both.

>>11106
large software sucking like firefox could be a problem at the organizational and management level of the group. lack of communication between developers and all of that.

>>11106
> It's the only program I use full of ridiculously exploitable security holes and it crashes constantly on OpenBSD, usually dozens of times a day.
You use encryption only in firefox? I doubt it. Therefore, you use something like OpenSSL, therefore, you use another big software with security holes. Same goes for your various firmware etc. But nitpick aside:

>>11108
>large software sucking like firefox could be a problem at the organizational and management level of the group. lack of communication between developers and all of that.
yeah i'm sure it's a size/org problem.
1. Many people working together
2. People are imperfect
3. soykaf happens
4. Software is like kicking dead whales down the beach in some places
I doubt you can avoid it. You can strife to do it, though. Best keep every piece of software you create as small and simple as possible, but put great effort into various testing that should cover both correctness and usability.

Working with software is not easy, because it's workings are effectively invisible when it's used, and terribly inscrutable when examined. They require multiple layers of abstraction working together, hiding details, just to keep the entire thing somewhat manageable for a user or a programmer. It's like to trying to sculpt thin air itself.

A fine pocketwatch is also a complex machine, with many moving parts and layers, but all of it's parts are tangible, and it only really has to serve one purpose, unlike most applications made these days. You could conceivably take off the back cover and examine the way it works "as it runs". You can't easily do the same with most software.

As if software weren't inherently complex enough, you also have to factor in all the external pressures added on top of actually making software. Time pressures and requirements, and communication between team members and whatnot. Then consider that every piece of software has to work with at least some other piece of software in order to run.

So, is it any wonder that mistakes are made?

>>11133
This is why I brought up the language used in an earlier post.

Languages with excellent error-handling should be used to build programs to be used by other people and not simply run by another program, like a cron job. PL/I and Common Lisp both have excellent error-handling, both programmable and interactive.

>>11106
>Part of it is because making software is big work now. Some people get paid by how much software they write and not how well they write it.
Strange. Why not let programming be run by priorities?


>I would also cite language choice as part of the reason for this. Compatibility and legacy uses help keep bad languages, made to make the programmer fungible and restricted, alive well past their expiration date and make what is one line in one language tens (or sometimes even hundreds) of lines in the languages most people actually use.
And who decides when a language is obsolete? Consider COBOL. First released in 1959. Few updates. But do what it's supposed to do really good.

On the other hand we have C. First released in 1972. Lots of updates and deratives. If I get this right, it's a language where you can go almost as close to the hardware as you can with Assembly.

The reason that I mention these languages is because it's the only two I know, sorta. Two examples for comparision:

COBOL:

DISPLAY "What's your name?".
ACCEPT Name.
DISPLAY "Hello, " Name "!".

C:

printf("What's your name?\n");
scanf("%c", &Name);
printf("Hello, %c!", Name);

As you all can see, COBOL has a far more straightfoward way to accept data. It's also easy to define the exact length of a variable. As a matter of fact, it's mandatory. Name would look something like this:

01 Name PIC X(10).

And this mandatory precision is because COBOL is made for number crunching and report writing.

The most obvious difference between C and COBOL is that you can have multiple commands on a line as long as they end with a semicolon. This allows you to do more elegant code. Also obfuscated code.

With that said I must say that the question about what language is the best is a moot point. Both serve their purposes. Both are old but not obsolete.

>>11133
>So, is it any wonder that mistakes are made?
None of these problems are unique to software and the internals of software are easier to view than the internals of any physical system. Software is broken because of apathy and laziness.
https://events.linuxfoundation.org/sites/events/files/slides/klf15_kryabitsev.pdf

Possible explaination:

http://geometrian.com/programming/tutorials/testing/test-first.php

>>11202
tests are a middle ground approach for the actual problem mentioned in >>11182
>Software is broken because of apathy and laziness.

>>11076
because c/c++

First of all, I wholeheartedly agree with OP. It's saddening.

>>11239
You can make a lot of change with relatively low effort even with C/C++.

>>11182
That seems to be the case to me. I mean, it's like developers like pain. The whole bunch of them. Us.

I constantly find areas where existing solutions are just bad, or missing entirely. Only from time to time someone optimistic with some free time hacks together something going roughly in the right direction.

Software development shouldn't be as hard as it is now. But no one dares to make the tools to make it simpler!

I want to be able to quickly glue together applications. Build myself a nice file manager! Write a solid hexeditor! Text editor! Somehow, this requires some arcane overcomplicated bull soykaf stuff on Linux. And probably elsewhere, too.

All the languages with proper tools are soykaf . C, C++, Java. (.Net I actually think is pretty fine but quite platform-bound)

Just...

Writting software is "easy", you only need a computer and you can hack a solution until it does what you want.
It's not like in any other engineering field where you have to plan what you're going to do and have a detailed instructions of how to do it like in Civil or Mechanical Engineering.
So the engineering part is always forgotten in the software world, here's an example: http://www.darkcoding.net/software/facebooks-code-quality-problem/
People don't care about software engineering and architecture, and obviously any software that wasn't correctly designed is doomed to fail