Fork me on GitHub
#clojure-dev
<
2020-02-25
>
ghadi00:02:21

imagine the API didn't exist

ghadi00:02:28

what would you do?

hiredman00:02:41

what I do today

hiredman00:02:51

I don't know that I use it ever

hiredman00:02:31

but that doesn't mean it is good ergonomics to be like "type code into your repl and it just runs forever even if you made a mistake"

ghadi00:02:43

that's not what I said

ghadi00:02:55

let it run in the background, and return input control

hiredman00:02:04

no one wants that

ghadi00:02:28

it's worse to give the people the illusion that they can stop bad loops 100% of the time without hitting the things that the Thread.stop() warns about

hiredman00:02:29

the next question in #beginners is going to be "why is clojure eating my cpu, ram, and filesystem?"

dpsutton00:02:48

Isn’t it better to let them try and if it doesn’t work they can kill the process just as if they didn’t have the tool?

hiredman00:02:43

I am not saying Thread.stop is good, I am saying basically everything you would reason about by analogy (setting aside if the analogy is good, os processes, ec2 instances, etc) has some kind of kill switch and that is a very useful usability affordance of those systems, and it is unfortunate that we, as part of the jvm community, are unable to offer a useful feature

andy.fingerhut00:02:10

It seems that interactive Clojure dev systems have a reasonably common use of Thread.stop today, from recent discussion here. I can see why -- it is expedient, and despite the warnings, often does "what you want", in a sharp-knife-that-sometimes-cuts-you kind of way. If Thread.stop is removed from a future JVM completely, it does seem that having a different approach in common use would be useful. I doubt many people want a Clojure compiler that forces interrupt status checks into all loops, though.

cfleming08:02:33

The alternative for a lot of cases to Thread.stop() is basically kill your REPL process and start again.

cfleming08:02:40

If that’s not good, then I think at least offering Thread.stop() as an option is ok - it’s (AFAICT) always worked for me, and saved me many REPL restarts. If my app does get funky after using it, I’m still going to be restarting my process anyway.

orestis12:02:49

For anyone following along, who like me was clueless about Thread.stop(), I found this: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html (linked from the Thread.stop() API docs)

borkdude21:02:33

in sci I have something called :realize-max which sets a hard limit on the length of sequences being realized. of course this comes with significant overhead, but for sandboxing things like 4clojure puzzles I guess it's fine.

user=> (sci/eval-string "(range)" {:realize-max 10})
Error printing return value (ExceptionInfo) at sci.impl.max-or-throw/bottom$fn (max_or_throw.cljc:8).
Maximum number of elements realized: 10
(0 1 2 3 4 5 6 7 8 user=>