The fact that the organization is Jewish is stated prominently in the article, but I’m not entirely sure why that’s relevant. Many charities in the US have religious affiliations.
The adult matchmaking etc, that deviates substantially from their advertising.
Anthropomorphizing is likely a mistake, but Daniel Dennett’s idea that the most straightforward (possibly only practical) way to create the external appearance of consciousness is a real internal consciousness does float around in my thoughts.
I haven’t yet seen any convincing appearance of one in an LLM, but I think if skeptical people don’t keep an eye out for the signs, we may be the last to see it.
He also wrote about the idea of the intentional stance: even if you’re quite sure these systems don’t have real conscious intent, viewing them as if they did may give you access to the best part of your own reasoning to understand them.
I was also dissatisfied with existing task tracking apps, and built my own:
t-do.com
There are still many rough edges, but it’s extremely useful. One of the best features that a text file has that very few apps support is unlimited sub-task nesting, and that’s a core feature of T-Do.
I disagree. There are many operators that you’ll never use but if you memorize
(^.), (.~), and (%~), you’re pretty much set for a lot of real-world software development.
Per Kmett’s original talk/video on the subject, I can confirm my brain shifted pretty quickly to look at them like OOP field accessors. And for the three above, the mnemonics are effective:
“^.” is like an upside down “v” for view.
“.~” looks like a backwards “s” for setters.
“~%” has an tilde so it’s a type of setter and “%” has a circle over a circle, so it’s over.
I’ll also add that my experience in recent versions of PureScript things get even nicer: visible type application lets you define record accessors on the fly like:
foo ^. ln@“bar” <<< ln@“baz”
“.” Is unfortunately a restricted character and is not the composition operator like Haskell, but I alias “<<<“ with “..”
The pretty obvious question with the above is: why don’t you just write “foo.bar.baz”. In my case I use a framework that uses passed lenses for IoC, but I think “%~” is always nicer and less repetitive than the built-in alternative.
> We don’t have philosophically satisfying insights into the universe at subatomic scales. We have quantum mechanics: a set of equations that are good at predicting the behavior of elementary particles, but that don’t line up with our intuition about the macroscopic world.
Our analogies and intuitions are based off of our macroscopic experienced reality, this seems to be an entirely emergent phenomenon based on those strange behaviors described by quantum mechanics. If those insights ever do come, I don’t believe they’ll correspond to anything prewired into our brains or experienced in our lives, and will never be remotely satisfying.
There’s a danger for first-time founders buying into this 100% — having special knowledge in a subject gives us a big advantage, we can’t all just hire experts like Levchin and other successful repeat well-funded founders can. We have to be the experts (or team up with them). That expertise is probably coming from either a love of (or at least a familiarity with) a subject.
Point of clarification for readers who aren’t familiar with Haskell:
Haskell doesn’t have operators in the classic sense, since they’re just an alternate syntax (infix) for regular functions; implemented in libraries. The Haskell ecosystem OTOH has a shitton of infix functions, as does Edward Kmett’s lens library. I don’t think there’s any reason to bother memorizing the ones that aren’t useful to you. You can always search them on Hoogle if you encounter one you don’t know. E.g. https://hoogle.haskell.org/?hoogle=%28%5E.%29&scope=set%3Ast...
I use lenses frequently in a large application and have only ever used view, set, and over.
A similar statement could be made about monads. Originally used to implement IO in Haskell because it’s a lazy pure functional language, they’re largely unnecessary in strictly evaluated languages.
Monads are now of course seen by Haskellers as being very useful in many different use cases beyond the original motivation.
IO in PureScript, which I’d describe as strictly evaluated Haskell, is still implemented using monads. The biggest benefit of this (as one might expect) is forcing the separation of pure and impure code, but a cool byproduct is asynchronous IO is also implemented in a monad. Various functions are available to launch async from synchronous IO and lift synchronous functions into async. The ergonomics of mixing sync and async are better than any other language I’ve used.
So theres an interesting question: once you have dot syntax, are there reasons you’d still want lenses? I’ve come up with two.
First, it is nice to use “over” (%~) to avoid specifying a location in a data structure twice (first to read it and apply a function to the read value, second to create a new data structure with the read value replaced with the output of the function. The deeper the data structure, the bigger the benefit.
The second case is writing functions that take lenses as an input and operate generically with larger data structures without knowing where in the larger data structure the values of interest reside ahead of time.
That may have been the judge’s framing, but it seems off from what I typically expect from mainstream US news.