Live data from Hacker News

Gettiers in software engineering (2019)

jsomers.net

221–222 of 222 posts

Re: Gettiers in software engineering (2019)

#221
post #72

Earlier quoted context omitted.

Hmm. That seems like a better example of the problem than either of the examples at https://en.wikipedia.org/wiki/Gettier_problem . The cases cited in the article don't seem to raise any interesting issues at all, in fact. The observer who sees the dark cloud and 'knows' there is a fire is simply wrong, because the cloud can serve as evidence of either insects or a fire and he lacks the additional evidence needed to…

It’s not super clear there, but those are examples of a pre- Gettier type of argument that originally motivated strengthening, and externalizing, the J in JTB knowledge— just like you’re doing! Gettier’s contribution — the examples with Smith — sharpens it to a point by making the “knowledge” a logical proposition — in one example a conjunction, in one a disjunction — such that we can assert that Smith’s belief in th…

> But it’s also a bit quaint, these days. To your typical 21st century epistemologist, that’s just not a very terrifying dilemma. One can even keep buying original recipe JTB [...]

Sorry, naive questions: what is a terrifying dilemma to 21st century epistemologist? What is the "modern" recipe?

Re: Gettiers in software engineering (2019)

#222
post #19
post #10

Earlier quoted context omitted.

This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just a dark forest of hidden horrors. When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.

The surest way to get yourself into a mess like this is to assume that a sufficiently complex codebase can be deeply understood in the first place. By all means you can gain a lot by making things easier to understand, but only in service of shortcuts while developing or debugging. But this kind of understanding is not the foundation your application can safely stand on. You need detailed visibility into what the sys…

Yeah, if you get over a thousand lines of code you need to be building and documenting it in a way that makes it intelligible in a modular way.

FP can be good for that but I often find that people get so carried away with the pure notion of functional code that they forget to make it obvious in its design. Way, way too much “clever” functional code out there.

The data structures are the key for many things, but a lot of software is all about handling side effects, where basically everything you touch is an input or an output with real world, interrelated global state.

That’s where correctly compartmentalising those state relationships and ample asserts or fail-soft/safe code practices become key. And properly descriptive variable names and naming conventions, with sparse but deep comments where it wasn’t possible to write the code to be self documented by its obvious nature.

Post reply on HN