It's fun to see package management improvements move full circle—lessons from Ruby package management contributed to Rust, Rust is helping improve package management for Python, and now Python package management is inspiring improvements for Ruby!
I kinda miss the fun days of using addresses to physical memory. (Maybe I'm wrong but I've always assumed that explicit use of handles went out of fashion because virtual address lookup is, in effect, a handle.)
Just to be clear, this content isn't from Stanford per se, the Stanford Encyclopedia of Philosophy is an academic publication that's hosted by Stanford (and was started by and continues to be run by Stanford faculty, but is mostly written by academics elsewhere and has some form of peer-review).
Some SEP articles are extremely high quality, I can't speak to the quality of this one but "philosophy of CS" as construed here feels pretty niche inside philosophy. There's lots of CS-related work being done by people in philosophy departments—algorithmic fairness, for example—that isn't covered by this article.
I would add that independent of quality, any article on the SEP is closer to a literature review than a comprehensive, rigorous treatment of the topic at hand.
Just to be clear, it isn't that people though justification (which, yes, can be probabilistic/non-deductive) invariable leads to knowledge, and these aren't supposed to be cases of believing the right thing for the wrong reasons.
Suppose you grant that justification is probabilistic. What's the extra condition that makes justified belief count as knowledge? Pre-Gettier, one might have been inclined to say that it's that your justified belief is actually right—what you believe is true. Gettier's point is that this can't be the full explanation of the difference between merely justified belief and knowledge.
Similarly, suppose you grant that one can have true belief that falls short of knowledge because one lacks "right reasons". Well, "right reasons" is a tricky notion, but suppose this means something like good evidence, or more generally, the sorts of reasons that we take to show your reasoning in a responsible way. Again, Gettier's point is that good evidence or responsible belief (assuming this isn't limited to deduction from things that you're certain about) isn't sufficient to make true belief into knowledge.
(Fwiw, Gettier wasn't the first person to point this out, but he did it in an especially vivid way which got a lot of people thinking hard about what else you needed to say if you were going to explain the difference between mere justified true belief and knowledge.)
> Suppose you grant that justification is probabilistic. What's the extra condition that makes justified belief count as knowledge? Pre-Gettier, one might have been inclined to say that it's that your justified belief is actually right—what you believe is true.
I would say that what makes it count as knowledge is the quality of the justification. If Jones had seen a written job offer to Smith rather than just hearsay that he would get the job, his belief that Smith would get the job would probably count as 'knowledge.'
Requiring that what you believe be actually true to count as knowledge is begging the question, since that requires either already having 'knowledge' that it's true, or having direct access to objective reality that no one has.
If "quality" means something like strength of the evidence, then couldn't you still have Gettier-like cases, so long as the evidence doesn't entail the truth of the belief? (suppose the HR department printed the wrong name on the offer letter, etc.)
If "quality" doesn't mean this... then the worry is that you've just labeled what you were trying to explain, because "quality of justification" might mean something like "that thing, whatever it is, which makes a belief count as knowledge".
About truth as a condition for knowledge... there's a lot of subtlety here. The claim isn't that you have to first know that P is true in order for you to know that P, or that you have to provide the truth of P as one of the reasons why you know P, or anything like that. It's more of a logical claim about what it means when we say "S knows that P"... knowledge is "factive" in that you can't know P if P is false. At least, that's how philosophers use the word "know", and it's at least one of the common ways that ordinary folk use the word.
(For what it's worth, there's a lot of discussion amongst philosophers about whether anyone who knows that P also has to know that they know that P... plenty of philosophers deny this.)
> If "quality" means something like strength of the evidence, then couldn't you still have Gettier-like cases, so long as the evidence doesn't entail the truth of the belief? (suppose the HR department printed the wrong name on the offer letter, etc.)
It would entail Gettier-like cases if you require knowledge to be true in some absolute sense. But I'm discarding the "true" condition as a requirement of a knowledge. Outside of a few domains like math, knowledge of this kind doesn't exist. Knowledge is always subject to revision.
Often we might think we know something and later conclude that we were wrong... but in this case, it's common to say "I thought I knew such-and-such, but I didn't". Also, for what it's worth, most people don't think that knowing that P requires that you're certain that P.
At least, that's one way of using the word "know". So if we're trying to give an analysis of this thing, we can't just decide to discard truth as a requirement of knowledge... the goal is to give an analysis of this thing that people talk about, not replace it with something else.
That said, it sounds like you're sympathetic to a line of thought on which this so-called "traditional" conception of knowledge isn't very useful, and we should focus on the sorts of things that Bayesian epistemology focuses on... something like degrees of confidence.
> Often we might think we know something and later conclude that we were wrong... but in this case, it's common to say "I thought I knew such-and-such, but I didn't". ... At least, that's one way of using the word "know". So if we're trying to give an analysis of this thing, we can't just decide to discard truth as a requirement of knowledge... the goal is to give an analysis of this thing that people talk about, not replace it with something else.
Let's consider a case like that. A student receives a graded history test, and says "I thought I knew that James Madison was the 3rd president of the United States, but I didn't."
Under the "justified true belief" one might say that their knowledge was undermined because they learned it wasn' true. But their teacher, born (say) circa 1970, has no more direct access to the truth of who was the 3rd U.S. President than their students.
So we might say instead that the student changed their mind about their knowledge because a rather flimsy justification for believing that Madison was the 3rd president ("I studied really hard") was kicked out from under them by a somewhat sturdier justification for a contradictory belief ("My teacher says that Jefferson was the 3rd President, and she knows a lot about history.")
> That said, it sounds like you're sympathetic to a line of thought on which this so-called "traditional" conception of knowledge isn't very useful, and we should focus on the sorts of things that Bayesian epistemology focuses on... something like degrees of confidence.
> Under the "justified true belief" one might say that their knowledge was undermined because they learned it wasn't true. But their teacher, born (say) circa 1970, has no more direct access to the truth of who was the 3rd U.S. President than their students.
I'm not quite sure what you mean and I think a bit more precision is helpful here. If one adopts a JTB conception of knowledge, then one wouldn't say that the knowledge of undermined because the student didn't have knowledge. Yes, it's also true that the (weak) justification for believing Madison was the 3rd president was outweighed by the (new and stronger) evidence that he wasn't... but that's about the justification, not the knowledge per se.
(Quick note: philosophers tend to use "undermined" for when something removes the evidential force, rather than countering the force. For instance, suppose I see someone who looks exactly like you in the library. Ordinarily that's pretty good evidence that you were in the library, and it would be reasonable for me to believe you were in the library. However, if I found out that you had an identical twin, this would undermine the evidence, and assuming this is all the evidence I had, it would not be rational for me to believe you were in the library.)
For what it's worth, the post-Gettier literature (and failure to get much clarify about the concept of knowledge) is one of the things that pushed people towards the more Bayesian approach to epistemology.
(Personally I think the Bayesian approach is avoiding some hard but genuine issues about rationality. Specifically, in Bayesian epistemology everything is relative to your priors. But there are lots of probabilistically coherent priors. Are they all equally good? If so, then there's really not much we can say in general about what's good or bad evidence, what people should or shouldn't believe, it's all pretty relative. I don't think that's right... it seems like one can be irrational yet coherent, otherwise it's hard to say how people like you and me are more rational than people believing massive conspiracy theories. Lots more could be said here, but that's why I and plenty of other folks aren't happy with an "anything goes" view about priors. But then for folks like me who want to say that all coherent priors aren't equally rational, it's hard to say what would make some priors better than other in purely Bayesian terms... so I think we end up back in the realm of traditional epistemology. That said, all this is pretty controversial and this is a pretty quick sketch of an argument, so there's of course lots to be said in response.)
You're right, JTB would say they didn't have knowledge. But why? Is it because it wasn't justified or because it wasn't true? If it's the latter, how can you ever ascertain whether something is or isn't knowledge (i.e. how do you know 'truth')? That's my fundamental problem with this account.
I agree, also, that just defining good knowledge as beliefs based on good priors regresses the problem. I tend to think this regression is unsolvable except in pragmatic terms (what is efficacious when tried against the real world is what is good).
Most folks who do traditional epistemology would say that you could have very good justification yet fail to have knowledge because what you believe isn't true.
And yes, this probably means that in some sense, when you know something, you don't have direct access to the fact that this is knowledge. It's also often the case that you shouldn't be certain that you know. You can't perfectly ascertain whether you have knowledge... though you can have good reason to believe that you know something.
Most philosophers these days deny that knowledge requires either certainty or direct access. For instance, we know lots of things on the basis of testimony and other sorts of non-deductive evidence.
I can understand why the idea of more structured, object-like input and output is appealing, but after using PowerShell for a while, my take is that it's much harder to manipulate objects into a consistent format than it is to manipulate text. For instance, if you want to compare Azure DNS records with DNS records from a Windows server, it's a huge pain because Get-AzDnsRecordSet and Get-DnsServerResourceRecord return objects with different structures. Same problem if you want to pipe output of one util to another which expects slightly different format of input. More generally, text is great for loose coupling; structured objects, less so.
> More generally, text is great for loose coupling; structured objects, less so.
I disagree. Parsing "loose coupled" text and converting it to the format that a different tool expects is a rather non-trivial problem, and one that's often poorly specified to begin with; converting structured outputs is generally straightforward in comparison.
Sure, converting (or interpreting) structured data is easier then unstructured. I doubt anyone is arguing that. I interpret op's statement however in that unstructured data is easier to couple unrelated tools. Tools perhaps which haven't written yet, by teams not knowing of each other and hence are unable to agree on a structure.
I feel like if that were true then you’d have the majority of REST APIs delivering unstructured output instead of structured JSON, XML, CSV, etc. The market has spoken - there is true utility in structured text output.
I think that's why the article proposes adding command line options and alternative APIs to output JSON objects not forcing all things the use objects all the time.
For any serious data retrieving or scripting the light object wrapping will be superior. For quick one off use maybe the plain text option will be quicker to reason about.
I've tried writing a language around this but it's... rusty. You kind of want to pipe Get-AzDnsRecordSet and Get-DnsServerRrsourceRecord to the same interface structure and then build another transform to some other structure from the interface... The program wires together the transforms. So the programming paradigm becomes rather unconventional, you only write transformations of “events”, you address other shell commands by listening to outputs of their “eventspace,” etc. ... You get a sort of strange logic programming language where the pipe operator has to be slightly specialized every time because it always needs to transform a little as it pipes
No seriously, there really are. I appreciate it requires learning a new tool but rather than downvoting me how about those unconvinced ask me questions instead? I’m happy to answer.
While there will always be a need to keep Bash around for comparability, there are a plethora of other tools out there that solve many of the shortcomings of POSIX.
I use murex exclusively. It’s still beta quality so not totally bug free but the bugs are rarely showstoppers and it’s still in active development so fixes are usually just one GitHub issue away.
I don’t use it on servers, I stick with Bash for that. But I do use it as my primary local shell.
As for why murex, that’s a combination of personal preference and simply not being aware of other shells until after I’d already started using murex.
What I like about it is it’s typed and does a lot of the boring stuff automatically in the pipeline based off what type is (JSON, YAML, CSVs etc are all “types”). So working with a JSON file is as natural as working with a flat text file. But also it’s trivial to bypass the clever stuff and use it like a dumb bash shell too. Which is where Powershell and its ilk fall down.
