Live data from Hacker News

Software crisis: the next generation (2016)

habitatchronicles.com

21–30 of 66 posts

Re: Software crisis: the next generation (2016)

#21
post #5

> Anybody who’s seen the systems inside a major tech company knows this is true. Or a minor tech company. Or the insides of any product with a software component. Anybody who's seen the sun rising east and setting west knows that this is true: the Sun rotates around the Earth. The other, less-obvious alternative, is that software is NOT crap, we just like to complain a lot. And it's just so easy & fun to blame everyt…

Oh no no.

Most software we use daily is barely running, filled with holes, in fact crap. Developed by multiple contractors, barely maintained.

Re: Software crisis: the next generation (2016)

#22
More precise understanding of faults and how to deal with them can go a long way before suggesting formal verification. Bug is not a fault, but it may cause faults though. You can try to find this bug beforehand or you can deal with the faults at runtime. In practice not just bugs cause faults, but also hardware failures, natural disasters, human mistakes and so on, so you kind of have to deal with faults either way.

> But we can certainly arrange to radically limit the scope of damage available to any particular piece of crap, which should vastly reduce systemic crappiness.

Now, this is the big idea behind supervision trees. Where you split everything into the smallest possible isolated processes and supervisors that watch over them, so that in the event of any process failing it can just get restarted, limiting the scope of the problem to only that one tiny process for the shortest possible time. This idea might even reduce the cost of software development compared to some more popular software development practices. But it does require an easy to use actor model in the language.

Re: Software crisis: the next generation (2016)

#23

Earlier quoted context omitted.

When you talk about static typing as providing some form of formal verification, you really can only talk about languages with advanced type systems like Haskell. Type systems like those in Java and C# give you very little formal verification (and I say this as someone who programs daily in C# for work and Python and Common Lisp for fun). What Java-like type systems give you is confidence in refactoring, which is not…

I work with C# full-time and it's type system constantly helps me. Of course, it's not Haskell or Rust, but it is still so much better than my Javascript experience. Anonymous types, generic containers and interfaces are usually enough for my needs. Can you please go into some detail about heterogenous tuples in Python? I've never used it to build big long-lasting systems so I be not aware of some of it's type capabi…

Tuples are just two or more values with separate types lumped together, i.e. (Int, String).

For example, in Haskell, to get the elements of a map, there's this function:

    assocs :: Map k v -> [(k, v)]
which gives you an array of tuples, the first element of which is of type k (the map key type) and the second element being of type v (the map value type.)

Re: Software crisis: the next generation (2016)

#24
post #4

We have some formal verification, it's called typed systems. Very limited, I know. But some people are still praising dynamically typed languages for their "speed" and "lack of compiler errors".

>We have some formal verification, it's called typed systems. Very limited, I know.

Very limited.

In my many years of experience doing software professionally, the serious bugs, that is, the ones that took us more than one day of debugging (after such a bug was able to be reproduced), were the ones that had nothing to do with types but with

* bad understanding of the business rules

* bad fundamental implementation of the problem domain

* misuse / incorrect use of an API or libraries

* API/library behaviour different from what the documentation says.

No type system will save you from them. Type systems don't verify how the code does the correct thing. They only verify that the types moved between functions/modules satisfy certain conditions. Big deal.

Where code reusability implies that your functions should apply to the widest type of circumstances (and thus increasing the scope in which they can be reused), type systems go fundamentally against to this goal, enforcing your functions to go very specific on what they're able to accept and return.

Dynamically typed systems allow for faster coding, and also allow for interactive development which allows for faster, easier testing of individual components as they are developed. Also, the very best dynamically typed systems also allow for redefining / uploading updated function definitions while the code is running, which greatly increases development & testing speed (emphasis added.)

This is not just a claim, this is my personal experience after about 23 years of programming where 90% of those years were spent using statically typed systems.

As for speed, for highly optimized code Java, Haskell, and F# are basically in the same ballpark. Which is, very good speed. Well, Common Lisp (dynamically typed language) is not only in the same ballpark, but faster than them in some cases.

You know what i'm going to choose.

Or, different take on this: If i was going for absolute speed i'd be hacking in C, where no Hindley-Milner type checker gets in the way of clever tricks for gaining that extra bit of performance you need on that tight loop.

Re: Software crisis: the next generation (2016)

#26
This is cultural. The Walmart-ification of the worlds products. Planned Obsolescence. The short term profits to get the stock prices up by the end of the quarter mentality. The credit card mindset.

How fast society moves, and how cutthroat capitalism is becoming...its all about short term gain because the future feels chaotic and unstable to most of the world.

I personally think its the fact the money is getting more an more difficult to obtain because more and more is being hoarded in the upper strata of society. So short term mindsets on financial gain take over because financial opportunities don't come easily.

This is reflected in software development.

Re: Software crisis: the next generation (2016)

#27
post #6

“The reason this stuff is crap is far more basic. It’s because better-than-crap costs a lot more, and crap is usually sufficient. ... ... ... Every dollar put into making software less crappy can’t be spent on other things we might also want, the list of which is basically endless.“ Software is crap because humans on the whole have an extremely difficult time reasoning through all the possible logic flows. Software i…

> I understand now why Keith Wesolowski ditched computers and went to work on a ranch

Ha ha! Can't help but think of the Roman emperor Diocletian, who after two decades of a "moderately successful career" decided to leave the office and move to a ranch to grow divine cabbages

Re: Software crisis: the next generation (2016)

#28
post #5

> Anybody who’s seen the systems inside a major tech company knows this is true. Or a minor tech company. Or the insides of any product with a software component. Anybody who's seen the sun rising east and setting west knows that this is true: the Sun rotates around the Earth. The other, less-obvious alternative, is that software is NOT crap, we just like to complain a lot. And it's just so easy & fun to blame everyt…

Most software actually is crap.

Re: Software crisis: the next generation (2016)

#29
post #23

Earlier quoted context omitted.

I work with C# full-time and it's type system constantly helps me. Of course, it's not Haskell or Rust, but it is still so much better than my Javascript experience. Anonymous types, generic containers and interfaces are usually enough for my needs. Can you please go into some detail about heterogenous tuples in Python? I've never used it to build big long-lasting systems so I be not aware of some of it's type capabi…

Tuples are just two or more values with separate types lumped together, i.e. (Int, String). For example, in Haskell, to get the elements of a map, there's this function: assocs :: Map k v -> [(k, v)] which gives you an array of tuples, the first element of which is of type k (the map key type) and the second element being of type v (the map value type.)

I asked a question because I assumed that I might not know something about it, since C# has Tuple generic class just for that and if it would be just that, Python would have nothing on C# in that regard. But your comment is exactly what I was thinking about.

So, is there something else in Python that is not present in C#?

Re: Software crisis: the next generation (2016)

#30
post #6

“The reason this stuff is crap is far more basic. It’s because better-than-crap costs a lot more, and crap is usually sufficient. ... ... ... Every dollar put into making software less crappy can’t be spent on other things we might also want, the list of which is basically endless.“ Software is crap because humans on the whole have an extremely difficult time reasoning through all the possible logic flows. Software i…

Other industries, for example the automobile industry? Have a look at https://en.wikipedia.org/wiki/Ford_Pinto . And have your received a recall notice for your airbag yet?
Post reply on HN