HN user
Do you keep trying to whack-a-mole the AI tools for this, or the humans actually making and distributing fake nudes of real people?
Both, obviously. For example, you go after drug distributors and drug producers. Both approaches are effective in different ways, I am not sure why you are having such trouble understanding this.
Arrows are slightly the wrong abstraction because they require an operation arr :: (a -> b) -> (a ~> b)—which requires you to be able to embed Haskell functions in your category, something which is almost never possible.
Yeah, this is such a shame. It would make arrows actually usable.
Tangential, but to people who find this topic interesting I highly recommend the book What is Intelligence [0] by Blaise Agüera y Arcas that views life through the lens of mutating self replicating Turing machines.
In the book he also talks about GoF, but one of the fascinating experiments he did is that a "computronium" of initially random Brainfuck programs (that obviously don't do anything interesting in the beginning) that mutate (by flipping random bits) and merge (by taking two random programs and sticking them together) eventually, after a sudden phase transition, start to self replicate by producing gradually better copies of themselves!
He also argues that symbiogenesis (merging replicators into a whole that does more than its parts) is the main driving force of evolution instead of just random mutations, because the random Brainfuck computronium eventually produces replicators even without the random bit flips.
Same!
The topic was immutability, not Clojure?
But ok, if mutability is always worse, why not use a pure language then? No more cowardly swap! and transient data structures or sending messages back and forth like in Erlang.
But then you get to monads (otherwise you'd end up with Elm and I'd like to see Apple's payment backend written in Elm), monad transformers, arrows and the like and coincidentally that's when many Clojure programmers start whining about "jumping through unnecessary hoops" :D
Anyway, this was just a private observation I've reached after being an FP zealot for a decade, all is good, no need to convert me, Clojure is cool :)
If there was a language that didn't require pure and impure code to look different but still tracked mutability at the type level like the ST monad (so you can't call an impure function from a pure one) - so not Clojure - then that'd be perfect.
But as it stands immutability often feels like jumping through unnecessary hoops for little gain really.
immutability in Clojure doesn't mean inefficiency.
You are still doing a gazillion allocations compared to:
for (let i = 0; i < data.length; i++) { hist[data[i]]++; }
Would you say that there was a single consciousness that both bodies shared, but that it suddenly split once the meteorite hit?
I agree, this is super weird. In a sense this seems to be the difference between viewing consciousness from the first person vs the third person. But until we understand how (if at all) matter generates felt experience the latter view can not, by definition, be about consciousness itself.
I guess this kind of perspective commits one to viewing first person experience in the way we understand abstract concepts - it is nonsensical to ask what the difference between this "1" here and that other "1" over there is. Well, you can say, they are at different positions and written in different materials etc, but those are not properties of the concept "1" anymore.
So yes, coming back to the thought experiment, one of the consequences of that would have to be that both bodies share the same consciousness and the moment something diverges the consciousnesses do too.
The point about time is interesting, and also directly related to AI. If at some point machines become conscious (leaving aside the question if that's possible at all and how we would know without solving the aforementioned hard problem), they would presumably have to generate quanta at discrete steps. But is that so strange? The nothingness in between would not be felt (kind of like going to sleep and waking up "the next moment").
But maybe this idea can be applied to dynamical continuous systems as well, like the brain.
(Btw this conversation was super interesting, thank you!)
I'm sensing redness here and now, so the sensation of redness exists very clearly tied to a particular point in spacetime. In what sense is the qualia of redness not firmly anchored in spacetime? Of course, you could talk about the concept redness, like the concept Pi, but even then, these concepts exist in the mind of a human thinking about them, still tied to a particular location in spacetime.
But qualia are inherently subjective. You can correlate brain activity (which exists at a position in spacetime) to subjective experience, but that experience is not related to spacetime.
Said otherwise: imagine you are in the Matrix at a coffee shop and sense redness, but your brain is actually in a vat somewhere being fed fake sensory input. "Where" is the redness? You would clearly say that it arises in your brain in the coffee shop. Imagine then the vat is moved (so its position in spacetime changes), your brain is rolled back to its previous state, and then fed the same sensory input again. Where is the redness now?
You can't differentiate the two sensations of redness based on the actual position of the brain in spacetime. For all intents and purposes, they are the same. Qualia only depend on the internal brain state at a point in time and on the sensory input. Spacetime is nowhere to be found in that equation.
The two brains don't receive the same sensory inputs
But let's say they do. Identical brains, identical inputs = identical qualia. What differentiates both consciousnesses?
It might be deeper than you think.
Qualia exist "outside" spacetime, e.g. redness doesn't have a position in spacetime. If consciousness is purely physical, then how can two identical systems (identical brains with identical sensory input) giving rise by definition to the same qualia not literally be the same consciousness?
It seems models are pre-planning though:
How does Claude write rhyming poetry? Consider this ditty:
He saw a carrot and had to grab it,
His hunger was like a starving rabbit
To write the second line, the model had to satisfy two constraints at the same time: the need to rhyme (with "grab it"), and the need to make sense (why did he grab the carrot?). Our guess was that Claude was writing word-by-word without much forethought until the end of the line, where it would make sure to pick a word that rhymes. We therefore expected to see a circuit with parallel paths, one for ensuring the final word made sense, and one for ensuring it rhymes.
Instead, we found that Claude plans ahead. Before starting the second line, it began "thinking" of potential on-topic words that would rhyme with "grab it". Then, with these plans in mind, it writes a line to end with the planned word.
[https://www.anthropic.com/research/tracing-thoughts-language...]
and are trying to justify it in reverse
In split-brain experiments this is exactly how one half of the brain retroactively justifies the action of the other half. Maybe it is the case in LLMs that an overpowered latent feature sets the overall direction of the "thought" and then inference just has to make the best of it.
Negative comments are so weird, it's like people forgot what GPT 2 was like. I know this isn't completely new, but it's a world simulation inside a goddamn LLM. Not perfect, not coherent over longer time periods, but still insane. I swear if tomorrow magic turned out to be real and wizards start controlling the literal fabric of the universe people will be like "meh" before the week ends :D
I hope you know what you're in for! [0] Good luck and godspeed :D
Glicol seems very cool! Looks a bit like Faust (https://faust.grame.fr), an FP sound programming language I came across recently.
I'm still reading it, but something caught my eye:
I interpret there to typically be hand waving on all sides of this issue; people concerned about AI risks from limited models rarely give specific failure cases, and people saying that models need to be more powerful to be dangerous rarely specify any conservative bound on that requirement.
I think these are two sides of the same coin - on one hand, AI safety researchers can very well give very specific failure cases of alignment that don't have any known solutions so far, and take this issue seriously (and have been for years while trying to raise awareness). On the other, finding and specifying that "conservative bound" precisely and in a foolproof way is exactly the holy grail of safety research.
Ah, I understand now.
That seems like a good idea indeed, however I'm not sure how it'd look in practice. The transition from input space to state space happens in the event handlers, which currently look like this:
onClick :: Bounded a => Enum a => a -> VDOM a
onClick :: Bounded a => Enum a => a -> VDOM b
why not just explore all paths instead?
Author here.
The problem is that concur-static generates static JS code that encodes all possible UI state transitions - so if the state space is big or infinite, so will be the resulting generated JS.
I wanted to explore the viability of generating simple static UIs with some level of dynamism. concur-static is definitely not intended as a replacement for full-blown client side UI libraries/frameworks.
The problem is that being "flatmappable" very strongly implies that it's a container
Can't fully agree with that, although I see your point. "Mappable" doesn't imply a container more than Functor's fmap method implies that all functors are containers. And "flattening" something is basically Monad's join.
But still, even if "FlatMappable" has a strong container connotation, I think it's good enough for establishing a first intuition. I think that once one shows what flatMap looks like in terms of e.g. Promises, the notion that it's about arrays or containers will vanish pretty quickly.
Sure! But note I said "initial intuition". return/pure and monad laws can be explained later, once one understands that there's really nothing magical about monads.
If you can implement flat_map [0] for something, it's (probably) a monad. You might as well call monads FlatMappables.
That's the simplest, most understandable and most accurate explanation for an initial intuition I've come up with so far.
I agree, but what I meant is that if you're forced to use a language other than Haskell on the backend, than there's no advantage in choosing GHCJS over Purescript in terms of code sharing.
I think Bower was just a "good enough" solution when Purescript was initially implemented. Afaik, people are moving away from it in favor of spago [0] or psc-package [1].
JS' semantics are pretty much opaque when staying in Purescript. Of course all bets are off when using the FFI, but then again the same goes for GHCJS.
One major thing in favor of GHCJS is the ability to share code between backend and frontend, but that's not a concern when e.g. the backend is written in another language anyway.
EDIT: Also, Purescript on the backend (targeting node or native code) is slowly becoming a thing as well, as this is what this submission is about :)
Tangential, but some very cool things are happening in Purescript-land, especially when it comes to row types or UI research:
* https://github.com/natefaubion/purescript-variant (open variant types)
* https://github.com/natefaubion/purescript-run (extensible effects implementation based on purescript-variant)
* https://github.com/ajnsit/purescript-concur (time-reifying UI framework, there's also a Haskell and a JS implementation of Concur)
* https://github.com/arthurxavierx/purescript-comonad-ui-todos (comonadic UIs)
* https://github.com/paf31/purescript-purview (incremental lambda calculus UI library, this is mind blowing!)
* https://github.com/paf31/purescript-sdom (declarative diff-less UI library)
There's also [0], a mature UI framework used in production at Slamdata. Lumi [1] are writing their frontend in Purescript.
What I especially like about Purescript is that the community is open to experimentation, while at the same time not being afraid to backtrack when things turn out to be a bad idea, like the row tagged Eff monad. The recent addition of QualifiedDo is a good example of this, which allows you to rebind >>= in the following manner:
test :: forall m a. I.IxMonad m => m a a String
test = I.do
a <- I.pure "test"
b <- I.pure "test"
I.pure (a <> b)
And yet, you are waving off potential answers because you are convinced there are none.
I agree with you, the cited papers probably don't solve the hard problem of consciousness but to assume that qualia is just intrinsically unexplainable won't help solve anything either.
I can imagine that consciousness will either turn out to be something completely groundbreaking (i.e. the universe consists of consciousness) or completely mundane (i.e. it's an illusion all sufficiently complex information processing systems develop), but ignoring research is not the way find out.
For completeness' sake, Haskell has had this for over a decade :) A SO thread that gives a nice overview [0], the paper [1], the library [2]. Here's how a parallel fib looks like:
fib :: Int -> Int
fib n
| n <= 1 = 1
| otherwise = x ‘par‘ (y ‘pseq‘ x + y + 1)
where
x = fib (n-1)
y = fib (n-2)
[1] http://simonmar.github.io/bib/papers/strategies.pdf
[2] http://hackage.haskell.org/package/parallel-3.2.2.0/docs/Con...
The things you listed may form a monad, but your list/iterator transformation doesn't use monadic composition.
list.select { |x| x.foo > 10 }.map { |x| x.bar }
Where's `bind` or `join` in that example?
OO is not about state
OO is very much about state, and that's the fundamental difference between non-FP languages and FP.
a1 = object.f(b);
a2 = object.f(b);
It also doesn't matter if your language implements OO in terms of message passing (Smalltalk, Erlang) or method calling (Java, C#, ...).
You try to parse the received data into a predefined data type, if this fails you are forced by the type system to handle the failure scenario, if it parses correctly you now have a 100% valid data structure you can work with in the rest of your codebase, no defensive checks necessary.
Did you read the whole thing? This is exactly the point the author is trying to make. Look, you both arrive at the same conclusion even:
Or you change the game and just use PureScript. Or ReasonML, or Elm, or even ClojureScript.
If you want to see actual dynamic typing and how it can shine, use ClojureScript. If you want to see actual static typing and how it can kick ass, use PureScript.