3 ms·

I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static defi

by yarg 6y ago

I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static definition of good. But things like: - don't copy, paste and tweak a piece of code when additional parameters are a better option, - don't grossly overload a definition with parameters instead of breaking up a function. There's nuance there, and the question of what amount of technical complexity is reasonable for a given problem - but if I start thinking about that I'll never stop digressing. I have dealt with an entire office of people who seemed to code purely in bug-filled technical debt: you could tell when they clocked on because the build broke an hour later. As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.

User23 6y ago
> As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is. FP isn't necessary for mathematically provable programing. Dijkstra and Scholten did a ton of work in this area that conclusively demonstrated that. I can't do them justice in a post here, but to a first approximation the trick is that you reason about imperative programs as transformations on a state space, which is to say you think about functions. A simple example: We want the predicate x = 3 to hold for all preconditions. The code "x := 3" establishes that predicate everywhere in the state space. That is to say, no matter what x was before the assignment, afterwards the predicate holds. While plenty of bytes have been spent on discussing why this is totally impracticable for real programs, whatever that means, we also have buzzwords like "defensive programming" that follow the same philosophy: we should write code such that when it has executed no matter what the state of the system was initially, afterwards it satisfies some specification.
- yarg 6y ago
  Cool.

by yarg 6y ago

User23 6y ago

> As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is. FP isn't necessary for mathematically provable programing. Dijkstra and Scholten did a ton of work in this area that conclusively demonstrated that. I can't do them justice in a post here, but to a first approximation the trick is that you reason about imperative programs as transformations on a state space, which is to say you think about functions. A simple example: We want the predicate x = 3 to hold for all preconditions. The code "x := 3" establishes that predicate everywhere in the state space. That is to say, no matter what x was before the assignment, afterwards the predicate holds. While plenty of bytes have been spent on discussing why this is totally impracticable for real programs, whatever that means, we also have buzzwords like "defensive programming" that follow the same philosophy: we should write code such that when it has executed no matter what the state of the system was initially, afterwards it satisfies some specification.

yarg 6y ago
Cool.