Correctness – A paradigm for sustainable software development • Hacker News Board

Re: Correctness – A paradigm for sustainable software development

#121

Post by paulddraper » Sat, Apr 06, 2019, 12:18 AM UTC

gambler wrote: post #65

beders wrote: post #41

Earlier quoted context omitted.

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furtherm…

Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages…

> OOP != Java

What is OOP language?

Re: Correctness – A paradigm for sustainable software development

#122

Post by OneWordSoln » Sat, Apr 06, 2019, 12:22 AM UTC

rglover wrote: post #6

The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the work. Simply saying "this is hard, it will take some time" makes focusing on correctness a hell of a lot easier. In no uncertain terms: don't be a pushover. If it can't be done well in the amount of time you suggest, don't say that it can be. You're just diggin…

The problem is that every new software project requires defining and solving a brand-new problem, and that "communication and setting expectations" part is really the problem of, first, specifying the problem and then, second, guessing how long it will take to solve the problem. Insert the old joke about "multiply by three and add five".

Within corporate environments, the ultimate problem is that the people who allocate the resources are usually the least knowledgeable about the costs of "digging a hole" (i.e. technical debt).

Of course, there is a great deal of blame to be placed on our -- the developers' -- shoulders, but guesstimating software delivery is difficult enough without non-technical people setting ridiculous timelines. I'd say the solution to the problem is to have managers select competent, driven developers who care about quality, and then for those managers to trust the technical teams to get the job done right. For such a team to work, each piece must work well and work hard.

Re: Correctness – A paradigm for sustainable software development

#123

Post by nickpsecurity » Sat, Apr 06, 2019, 12:33 AM UTC

dual_basis wrote: post #96

gambler wrote: post #71

Earlier quoted context omitted.

Too late for editing. Here is what I wanted to add: Low-level code correctness is overrated. With some experience it's trivial to achieve even in a crappy language like Java. Nothing except horrible syntax stops you from writing "functional" code in Java (and even that became easier in Java 8). This is what I and all sensible engineers I know are doing. In my experience, this "weak" version of FP plus a few tests is…

I don't have the experience to assess your comments regarding the classes of errors you have seen in practice, but I'm interested in the other argument I have often heard of in favor of FP, that it is substantially better for concurrent coding.

Here's an answer to that:

https://www.quora.com/Why-is-functional-programming-suited-f...

Functional programming is also easier to mathematically verify than imperative:

https://semantic-domain.blogspot.com/2018/04/are-functional-...

While you might not do proof, languages and methods that are easier for proof are often easier for automated analyses that look for problems, too. There's tools out there that can check code for concurrency problems that are extremely hard to spot with just testing. They might be easier to build or get more results if the program was functional/stateful instead of heavily stateful.

Re: Correctness – A paradigm for sustainable software development

#124

Post by OneWordSoln » Sat, Apr 06, 2019, 12:35 AM UTC

iamleppert wrote: post #80

I just got off a job where my boss was under the impression that bugs are because of incompetence or laziness. He literally expected the code I produced to be of perfect quality, or else, using his words “you don’t know what you’re doing”. I told him about how most major companies have QA teams and engineers spend a lot of time fixing bugs and reviewing others’ work. My (now former) boss was non-technical. Wondering…

Software is still very much a craft, as opposed to an engineering discipline. As such, we each have to learn, over time, how to produce defect-free code. For the capable, concerned and intelligent developer, this means that each new bug leads to new ways to ensure that such bugs will not happen again in the future.

So, no, like life itself, we all make mistakes in our systems. The important thing is that we don't make the same ones over and over again. In software development, that means adjusting our development methology to make such bugs less likely in the future. That is why software development is both the most challenging and most rewarding of careers. Of course, I may be a bit biased ;-)

As far as encountering crappy managers, I'll just say that I can count the good managers I've had on one hand and still have a couple of fingers left over. As to your former manager's particular flavor of belligerence, I haven't had that one specifically, but there are very much uglier variants, my friend. My understanding is that one cannot be made a manager unless the person is willing to prioritize money over human beings and it doesn't take a biblical scholar to see how that is causing so many problems in the small and large across the world. In the small, that attitude manifests itself in many ugly personality traits, while being the foundation of the entire structure and intention of the for-profit corporation where the vast majority of us are forced to find our work.

Re: Correctness – A paradigm for sustainable software development

#125

Post by dope99 » Sat, Apr 06, 2019, 12:35 AM UTC

mlthoughts2018 wrote: post #112

dope99 wrote: post #110

Earlier quoted context omitted.

I think most bugs are that kind that the compiler can catch. But yes absolutely a program can compile and be dead wrong. I’m writing a regex engine and lol at types saving me from all the mistakes I can make with building and transforming finite automata. I’d still much rather have a slightly slow compilation than verify types in my head every time I’m in that area of code, or writing unit tests for every configurati…

My experience has been the opposite. Compilers are not just a little slow, but introduce a significant slowdown for every read-edit-test loop, which adds up to such huge productivity losses that any small gains from the compiler catching typo-style / wrong arguments sorts of bugs is totally erased.

I’m not arguing here but honestly don’t know: how can interpretation be faster than the checking step of compilation? Maybe code generation takes more time, but Rust has ‘cargo check’ which only typechecks.

Parsing is basically a wash between compilation and interpretation. Dynamic types still need to be resolved for the tests to run. So why would interpretation be faster?

I’m working through a compiler book and would love to know.

Re: Correctness – A paradigm for sustainable software development

#126

Post by keepmesmall » Sat, Apr 06, 2019, 1:05 AM UTC

If you notice bugs, you should do more maths and get tweaking. Wait... something's not quite right there.

On a more serious note: the biggest barrier to correctness I've encountered is doing things I don't understand. I also care less and less for being paid to understand particular things, it's so much worse than just being paid to do work.

Re: Correctness – A paradigm for sustainable software development

#127

Post by julius_set » Sat, Apr 06, 2019, 1:37 AM UTC

I disagree, based on this articles logic everyone should strive for a perfect codebase which is impossible.

You will always run into issues because code just like matter decays to entropy.

Re: Correctness – A paradigm for sustainable software development

#128

Post by beders » Sat, Apr 06, 2019, 1:41 AM UTC

gambler wrote: post #65

beders wrote: post #41

Earlier quoted context omitted.

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furtherm…

Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages…

You arguments are all nice and dandy - but who uses OOP like this? And you still have the state being all over the place problem.

I think I made it clear that OOP is fine if you can afford to live in that space. In practice you often can't.

Re the boundary problem: Sending objects over wire doesn't solve it at all, it makes it worse. Object identity for once and incompatible classes between client/server. Hiding data in magic objects just doesn't work. It's the reason CORBA failed, it's the reason RMI is a nightmare, it's the reason we have data-oriented wire protocols.

Re: Correctness – A paradigm for sustainable software development

#129

Post by jes5199 » Sat, Apr 06, 2019, 1:52 AM UTC

nickpsecurity wrote: post #123

dual_basis wrote: post #96

Earlier quoted context omitted.

I don't have the experience to assess your comments regarding the classes of errors you have seen in practice, but I'm interested in the other argument I have often heard of in favor of FP, that it is substantially better for concurrent coding.

Here's an answer to that: https://www.quora.com/Why-is-functional-programming-suited-f... Functional programming is also easier to mathematically verify than imperative: https://semantic-domain.blogspot.com/2018/04/are-functional-... While you might not do proof, languages and methods that are easier for proof are often easier for automated analyses that look for problems, too. There's tools out there that can check…

this is how you end up with darcs as your version control system. It’s provably correct, but about 1 in 10 times it hangs forever and never terminates. Also it doesn’t implement branching because that’s out of scope for the model.

Re: Correctness – A paradigm for sustainable software development

#130

Post by ghettoimp » Sat, Apr 06, 2019, 1:52 AM UTC

dope99 wrote: post #125

mlthoughts2018 wrote: post #112

Earlier quoted context omitted.

My experience has been the opposite. Compilers are not just a little slow, but introduce a significant slowdown for every read-edit-test loop, which adds up to such huge productivity losses that any small gains from the compiler catching typo-style / wrong arguments sorts of bugs is totally erased.

I’m not arguing here but honestly don’t know: how can interpretation be faster than the checking step of compilation? Maybe code generation takes more time, but Rust has ‘cargo check’ which only typechecks. Parsing is basically a wash between compilation and interpretation. Dynamic types still need to be resolved for the tests to run. So why would interpretation be faster? I’m working through a compiler book and woul…

I think mlthoughts2018 may be saying that he finds the advantages of a good "read-edit-test loop" to be more valuable than a compiler that catches type errors?

It is certainly valuable. A good REPL is completely fantastic for prototyping and debugging. Being able to change how your program works while it's still running and has all its data loaded is great compared to a classic edit-compile-run cycle where you've got to get your program's data re-loaded each time.

But I don't see that this has much to do with compilers versus interpreters, or even really dynamic versus static type checking...

- There are REPL-based environments with integrated compilers, and there are compiled languages with REPLs bolted on top.

- Good REPL support is surely more challenging for languages with strong static typing. After all: what does it mean to redefine a type? what happens to the functions that are using the old definitions? what happens to the instances of that type that are already alive in your program? But these problems all exist in dynamic languages too, it's just easy there to sweep them under the rug by treating them as yet more run-time errors.