Yes, unfortunately it is and the way we handle this isn't exclusive to SF. Google Andrew Yang NYC homeless. Everyone is avoiding the elephant in the room and refusing to touch this issue.
I don’t know if it’s unpopular or not but it’s certainly not as simple as “you force them to get the psychiatric help that they need.” That’s not how it works at all. You can’t force people to heal or get better — they have to want it themselves. When people make these types of sweeping statements, it makes me really question if they’ve ever been in a situation where a loved one has been resisting getting help for years.
In Our Time is a wonderful podcast, always interesting content! Also, as an American, the pace of the show and way of speaking is itself interesting to me.
That's funny, although it's missing the one of the best bits about Radio 4: the Shipping Forecast. For some reason, I find the late (0040) and early morning (0520) shipping forcasts immensely familiar and comforting. It's been a part of my life since I was a small child getting up very early for school when I had no idea what Dogger, Forties, Cromarty and Rockall meant.
This brings back thoughts I've had that we should be working with normalized data in code, rather than thick objects. I think the main reason we don't is because there's a lack of tooling around it in our languages. I think a system/language/library designed around this could solve some of the problems in the article as well. First class support for having only one value for a given domain specific id, relations, declaratively describing constraints, and strong querying seem like they would be very helpful to lots of programming problems in complex apps.
This is the right answer and I wish more languages would make this dramatically more ergonomic to do. Store the most basic normalized truth and query/derive what you need.
But how will you decide which is worth knowing if you never look? I get why you may want to take it in at a slower pace than a social media feed, but it seems like there's no way to tell what's worth knowing if you "stop consuming news".
If it matters to my work I’ll find out about it through industry channels or coworkers. If it matters to my family/community/area I’ll hear about it from local interactions.
Why is the medium of acquisition of news important here, seems like an irrelevant distinction. How can one be 'Ignorant of current events' if he is acquiring said current events through coworkers/locals.
This is precisely what I was referring to in my original comment. Not everyone has the privilege to leave safety of their family to random happenstance local interactions. eg: My wife's grand parents are on greencard and unenrolled themselves from one govt service based on recent news about being a public charge. Some ppl are constantly on the edge to leave it to 'local interactions'
> if it matters to my family/community/area I’ll hear about it from local interactions.
If it affects your life, you’ll become aware of it eventually. By definition.
It’s surely possible that something could occur that has repercussions for your life, to where you would have preferred to be aware of it ahead of time. But I can only think of 1 time in my 40 years when that’s happened with any significance. Hardly worth making myself an anxious wreck trying to constantly “be informed”. No matter how diligent one tried to keep pace, you’d never be certain of catching everything anyway.
Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b?
His point is that Maybe a should be composed of all the values of a, plus one more value, nil. A value of type a is a member of the set (nil + a). Why should having a more specific value reduce the things you can do with it? It breaks composition, fundamentally. It's like saying (+) works on integers, but not on 3. I'm saying this someone who really enjoys type systems, including haskell.
> His point is that Maybe a should be composed of all the values of a, plus one more value, nil
No, that's a simple union type. There are very good reasons for Maybe to be different than unions (Maybe can nest meaningfully, simple unions can't.)
Maybe Maybe a is valid, and often useful, type.
Of course, if you have a function of type a -> b and find out you need a more general Maybe a -> b, instead of a breaking change, you just write a wrapper function that produces the correct result for Nothing and delegates to the existing function for Some(a) and you're done without breaking existing clients.
(Now, I suppose, if you're u had something like Scala implicits available, having an implicit a -> Maybe a conversion might sometimes be useful, though it does make code less clear.)
I agree that there are reasons for Maybe a to be a different type from (a | nil) but there are also good reasons to prefer (a | nil). Like most things, it's a set of tradeoffs. What I appreciated about this talk was that he went into the benefits of thinking about types in this way. It's (relatively) common to see the benefits of Maybe a explained, but more rare to see the benefits of full union types explained.
My problem is that I don't know when to expect nil from a call because in Java null is part of every type and you can happily receive a null from anything, the compiler won't give you a warning. In OCaml I know what to expect because Some x | None is super simple to reason about. I can never receive a null a nil or other things that somehow satisfy the type requirements. Clojure is great with untyped programming everything is an Object after all but I still would like to see a reasonable thing like Erlang's {:ok,x} | {:error, error} or OCaml's Some x | None. It is not an accident that many languages that like reliability implemented it like that.
Yes, the default of a lot of languages, (Java, C, etc) where nil is implicitly a member of every other type is a bad default. But that's a separate question.
> Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b?
Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b.
You could imagine some function from Nothing -> b that could rescue us. But since it only handles one case of the Maybe type, it is partial (meaning it could give undefined as an answer). There is basically two total functions that we could change it to:
* Maybe a -> b in which case we are back where we started.
* Unit -> b which essentially is just b, which can be summed up as meaning we need some kind of default value to be available at all times.
So to be able to call Maybe a -> b as a -> b you would need some default value available at all the call sites for a -> b
Now this is only "illogical" because we don't postulate a value of type b to be used as this default.
> It's like saying (+) works on integers, but not on 3
No, it's like saying (+) must work on all integers AND a special value nil that is not like any other integers, but somehow included in them and all other data types. We can't do anything with this nil value since it doesn't carry any data, so in the case of (+) we would essentially have to treat it as an identity element.
This is good though, since (+) has 0 as an identity element, so we can just treat nil as a 0 when we encounter (+). However, when we want to define multiplication we still need to treat nil as an identity element (since it still doesnt carry any data), except the identity element for multiplication is 1. This would be repeated for every new function that deals with integers.
So by mashing together Maybe and Integer we have managed to get a frankenstein data type with an extra element nil which sometimes means 0 and sometimes means 1.
Why not just decompose them into Maybe and Integer and supply the default argument with a simple convertion function like fromMaybe?
(FWIW, I actually agree with Hickey that using Maybe in api design is problematic and I've encountered what he's talking about. But while that might be an argument for where he wants to take Clojure, it's not an argument for dismissing type theory the way he does.)
Yeah, you're right, I got confused when interpreting the parent comment. Thanks for pointing it out!
I guess I overlooked it because the other way is so logically trivial, since it basically boils down to A -> B => (A || Nothing) -> B, which is just an or-introduction. So if you wanna implement Maybe generically the "work" lies on the other side.
But since Hickey's argument sort of is that we shouldn't implement Maybe generically, I guess my argument here becomes circular. (Begging the question maybe?)
> I guess I overlooked it because the other way is so logically trivial, since it basically boils down
Yeah, that's (part of) Hickey's point. That the "best" type systems fail this test, and require manual programmer work to solve this problem. Again, I'm saying this as someone who really appreciates Haskell.
- "Zero evidence of any of that" is a completely ridiculous thing to say. Get out of your bubble. Try to see the world from the other POV, there are many pieces of evidence that point in this direction. If you step back from moment-to-moment politics and try to look at what's already publicly known, from a historical perspective, it's already an unbelievable scandal.
- I don't think he consciously wants to be a fascist dictator, but it's again completely ridiculous for you to say there's "zero evidence of that sort of behavior". He does many things that point in that direction, if only you look. And, concretely, he's destroying norms that keep us not-fascist, barriers are being torn down right now. That degrades our system and populace and will make it easier for future people to transgress further.
- I don't know enough about what regulations he's rolled back. But dropping out of the Paris agreement and simply not taking action for the next four years have a significant impact.
This would be a reasonable opinion if the far right reacted to this event by giving credit to WaPo--if their genuine interest was in the truth and good reporting. Unfortunately truth and good reporting is not their goal, and this entire story will be presented in a very different light on far right sites.
I've been thinking a lot about nearly these exact same things. We desperately need better ways to deal with derived textual data. Why do we make the programmer guess which data structure will work best for a particular task, when we could easily try it each way and record the performance, and pick the best? A big part of the reason must be that we have no good strategy for storing that data and making that choice in an ongoing and living way, inside of a code repository. We suck at dealing with derived data on the meta layer above our programming languages.
Email me at glmitchell[at]gmail if you want to chat more about this.
