Software Is Hard (2007) • Hacker News Board

Re: Software Is Hard (2007)

#51

Post by TeMPOraL » Sun, Oct 27, 2019, 9:22 PM UTC

clarry wrote: post #39

thethirdone wrote: post #36

Earlier quoted context omitted.

> In the choice between simple (and cheap and correct) vs complex (and expensive and buggy) Often simple is not correct. In much of the code I have worked on there is simple code for 99% of cases, but correctly handling the other 1% can be much more complex. Also, simple is often not fast. An implementation of bubble, insertion, or selection sort is almost always simpler than quicksort, mergesort or especially heapso…

> Web browsers are a really good example that some software needs to be complex to do its job. Web pages can do pretty much anything so web browsers have to support that which requires a bunch of code off the bat. The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and…

> And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need.

I think you can see evidence against your point and for the GP's point if you look for "Falsehoods programmers believe about X" articles. Whenever software interacts with the real world, corner cases abound.

Re: Software Is Hard (2007)

#52

Post by clarry » Mon, Oct 28, 2019, 3:05 PM UTC

milesvp wrote: post #49

clarry wrote: post #39

Earlier quoted context omitted.

> Web browsers are a really good example that some software needs to be complex to do its job. Web pages can do pretty much anything so web browsers have to support that which requires a bunch of code off the bat. The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and…

I think op is referring to something you’re ignoring. Simple algorithms can often become quite gnarly if you can’t ignore some base assumption. I’ve seen some really elegant mathematics represented in a single equation turn into thousands of lines of code simply because reality means we can run out of stack space. Similarly, I can tell you that dealing with ill formatted feed data, parsing any given value can be triv…

> Similarly, I can tell you that dealing with ill formatted feed data, parsing any given value can be trivial, until you find some random example of data that abuses some seperator. Then suddenly you need to do thing like try seperating on X and see if you get data that looks right, else seperate on Y.

Yes, if you accept complexity, this is where you end up. The other alternative is to reject complexity. Stop accepting and trying to make sense of broken data.

At this point, we get back to my point because you'll say that someone (a stakeholder) demands that the program works with existing legacy/broken/misguided systems/users. Sometimes that is genuinely the only reasonable option, but all too often I see people introducing more and more features and complexity instead of figuring out whether it's really necessary or whether the intended end result can be achieved with less.

Re: Software Is Hard (2007)

#53

Post by clarry » Mon, Oct 28, 2019, 3:14 PM UTC

TeMPOraL wrote: post #51

clarry wrote: post #39

Earlier quoted context omitted.

> Web browsers are a really good example that some software needs to be complex to do its job. Web pages can do pretty much anything so web browsers have to support that which requires a bunch of code off the bat. The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and…

> And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need. I think you can see evidence against your point and for the GP's point if you look for "Falsehoods programmers believe about X" articles. Whenever software interacts with the real world, corner cases abound.

Just as often, the problem is that the programmer had introduced assumptions (and complexity and problems) where none were required. Did they do it just for the heck of it? Or did a stakeholder ask them to add feature X because it "would be nice to have" (maybe they just think it would be nice to have, without realizing that it is unnecessary or that they could achieve what they want in a different manner using a different, less complex feature Y)?

I'm well aware of those corner cases. And, at work, I'm dealing with.. well, not corner cases, but "real world" stuff right now, related to dates and timezones. None of what I'm doing right now would be necessary if people had the guts to decide that internally and in logs, everything is always going to be in a single format such as Unix time. Unfortunately, people made bad decisions and there are stakeholders so I'm adding complexity to the software.

If it were my software, I would outright reject this complexity. It is not needed for the software to do what its core purpose is.

People like to argue that the real world is absolute and software is strictly inferior if it cannot deal with all the complex cases people in the real world attempt to shove into the software world.

My argument is that a good engineer can look at a (seemingly) gnarly real world issue and finds a way to make it simple. Not all complexity is inherent.

Using OpenBSD after Linux is quite illuminating in this regard. At points it might seem like it's lacking features, but on the other hand you find lots of cases where it achieves exactly what you could achieve on Linux in a simpler manner and with fewer features & less complexity because they took a simpler approach to it, and in doing so, made a bunch of features a Linux user would look for simply unnecessary.

Re: Software Is Hard (2007)

#54

Post by j88439h84 » Tue, Oct 29, 2019, 5:00 AM UTC

zzo38computer wrote: post #25

j88439h84 wrote: post #24

Earlier quoted context omitted.

Duocode seems to be a javascript compiler, not alternative to unicode.

That is something else with the same name, and is not the same as the Duocode I saw mentioned on IRC.

Can you link to the thing you're talking about?