Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Is Hard (2007)

gamearchitect.net

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Software Is Hard (2007)

#31

Post by noir_lord »

otakucode wrote: post #19

The way I have thought about software's necessary complexity for a long time is by considering what software IS. Software, no matter what it does or how it is written, boils down to instructions and data that operate on transistor gates in a computers processor and memory. We must write code which orchestrates the flipping of millions or billions of switches, millions or billions of times a second, in exact perfect s…

> and we are definitely past the point at which one person can even reasonably understand the entire stack from transistors all the way up through OS, compiler, language, etc. We must accept this fact of complexity and formulate ways to deal with it, to contain it and reduce it when we can, but it will always be with us.

Beautifully put and we definitely are, I think the trick now is knowing which bits of the layers underneath you need to know to interact with things well (in terms of your goal), I came up on computers in the 80's and used C and Pascal, those early experiences have been useful for 30 odd years because often I have a 'feel' for what the computer is doing underneath that younger (and really capable!) devs lack.

Often when performance is really critical I'll go look in the source code for the tool to get a feel for what it is really doing (even though I haven't written C in a long time) which is regarded as voodoo.

On the flip side of course is I can build things in an afternoon or a day or two that simply wouldn't have been possible with months or years of work and a dev team of dozens back then.

My next side project is a tool for motorcyclists, you drop pins on a map where you are going to be at points in time and it then pulls the complete meterological data for those points and does some calculations (are the roads likely to be wet, icy, show the direction of the wind, show the windchill at 30mph, 40mph, 50mph etc) with the ability to set recurring routes and email you the day before something like "Tomorrow morning, there may be ice on the roads, wind chill will be 5C, feels like temperature at 40mph -2c, Sunny, low winter sun so wear your shades/visor"

The data to do that didn't exist 30 years ago and the GIS tooling (I'm using open street maps) to process the entire UK would have cost millions.

Re: Software Is Hard (2007)

#32

Post by noir_lord »

alkonaut wrote: post #30
euske wrote: post #3

How timely. I was reading the Unicode Standard the other day, and realized how this seemingly simple project of "modelling a character with a number" has become a huge, sprawling behemoth over years because they tried to cover every aspect of human language; I'm sure it's going to be even more convoluted and politicized in future, and it will never be complete. And this brings me two sides of the argument: should sof…

Yes. It will happen whether it’s desireable or not. For example, I think it’s inevitable that the US will use an ISO date format eventually, and further down the line I think many Asian scripts will be replaced with western etc.

> I think it’s inevitable that the US will use an ISO date format eventually

About half the programmers I know (including myself) already write dates as 2019-10-27 even when using a pen, it really is a more convenient format.

Re: Software Is Hard (2007)

#33

Post by jffhn »

There is a Dunning-Kruger-esque quote on painting, that applies maybe even better (*) to software:

"Painting is easy when you don't know how, but very difficult when you do." (E. Degas)

(or for a more literal translation: "Painting, that's very easy when you don't know how to do. When you do know, it's very difficult.")

(*) (Although Ecce Homo by E. G. Martinez is a good image of what can happen to the software you're working on when management adds someone to help you out ;).

Re: Software Is Hard (2007)

#34

Post by amelius »

twblalock wrote: post #15
zzo38computer wrote: post #14

Earlier quoted context omitted.

Unicode is terrible. They can use Chinese character coding when writing in Chinese on the computer (perhaps cangjie encoding), and use ASCII when dealing with computer codes which are based on ASCII.

Unicode was invented to avoid the kind of thing you are suggesting, and that's why it is popular. ASCII doesn't even cover all of the characters and symbols that are normally used by English speakers.

> ASCII doesn't even cover all of the characters and symbols that are normally used by English speakers.

Such as?

Re: Software Is Hard (2007)

#35

Post by amelius »

tannhaeuser wrote: post #28
euske wrote: post #3

How timely. I was reading the Unicode Standard the other day, and realized how this seemingly simple project of "modelling a character with a number" has become a huge, sprawling behemoth over years because they tried to cover every aspect of human language; I'm sure it's going to be even more convoluted and politicized in future, and it will never be complete. And this brings me two sides of the argument: should sof…

Unicode (ISO/IEC 10646) is without doubt a hugely successful project. But like every huge project, it keeps nurturing itself ad infinitum, and is becoming absurd in the process (for example, Unicode has also captured emojis). As Unicode is covering more and more symbols all the time, it becomes less and less useful for its original purpose to communicate the character set encoding standard used in a document. Eg a ba…

> Unicode has also captured emojis

Yes and a huge downside of this is that we're now stuck with an incomplete set of them.

Re: Software Is Hard (2007)

#36

Post by thethirdone »

alkonaut wrote: post #29

Simple software is simple. Complex software is hard. In the choice between simple (and cheap and correct) vs complex (and expensive and buggy) customers and stakeholders with very few exceptions go for the latter . Our software is exactly as buggy as we want it to be - a decision we make with the tradeoff of cost and complexity.

> 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 heapsort.

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.

Not having correct behavior in the 1% of cases is unacceptable because that introduces security problems. And not speeding up webpages as much as possible will make web browsing very unpleasant.

I think if we got a fresh start, we could redefine what a browser needs to do and make it simple and faster, but supporting the web as it exists today requires complexity.

Re: Software Is Hard (2007)

#37

Post by dri_ft »

> Encyclopedias are well-designed software. They're loosely-coupled--entries tend to not make calls into other entries[...]

Spoken like a man who has never lost an afternoon to Wikipedia.

Re: Software Is Hard (2007)

#38

Post by dri_ft »

amelius wrote: post #34
twblalock wrote: post #15

Earlier quoted context omitted.

Unicode was invented to avoid the kind of thing you are suggesting, and that's why it is popular. ASCII doesn't even cover all of the characters and symbols that are normally used by English speakers.

> ASCII doesn't even cover all of the characters and symbols that are normally used by English speakers. Such as?

Forward and backward quote marks. Different kinds of dash - the en-dash and em-dash.

Re: Software Is Hard (2007)

#39

Post by clarry »

thethirdone wrote: post #36
alkonaut wrote: post #29

Simple software is simple. Complex software is hard. In the choice between simple (and cheap and correct) vs complex (and expensive and buggy) customers and stakeholders with very few exceptions go for the latter . Our software is exactly as buggy as we want it to be - a decision we make with the tradeoff of cost and complexity.

> 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 even more features.

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.

Re: Software Is Hard (2007)

#40

Post by nchelluri »

jffhn wrote: post #33

There is a Dunning-Kruger-esque quote on painting, that applies maybe even better (*) to software: "Painting is easy when you don't know how, but very difficult when you do." (E. Degas) (or for a more literal translation: "Painting, that's very easy when you don't know how to do. When you do know, it's very difficult.") (*) (Although Ecce Homo by E. G. Martinez is a good image of what can happen to the softwa…

well said!

I think about this sometimes. When I was 15, and just learning to program, I thought I could code anything. And if you look at history, I was perhaps right.

Now, as a seasoned professional software developer, all I see is pitfalls everywhere...

Post reply on HN