Yes, I have had that problem in the past. But I do not recall the last
time I did.
And I don't remember if any time that I had an unresponsive UI that it
was due to an infinite loop as described here as opposed to some other
CPU intensive and possibly memory increasing bug.
My example here is only for common infinite loop mistakes. Which are
easy to do. Especially in languages in which you loop via your created
and manually incremented index.
True many can do the same in explicit special situations. In your
example of an attached debugger. But does anybody run Python with Pydb
as default? I have never used Pydb. Any infinite loop I created means
killing the interpreter. Or any other language?
Regardless it would be much less common elsewhere. And generally if
available, much more awkward and inconvenient, and explicit. You have to
be ready and prepared.
Pharo/Smalltalk it is a way of being. :)
Did Lisp when Lisp was the language and environment do such? Even if it
did, I would guess that a modern Lisp such Clojure would still require
attaching a debugger.
Thanks.
Jimmie
On 05/02/2016 08:36 AM, Peter Uhnák wrote:
I can execute foreverTrue in a Playground and when nothing returns
in an appropriate amount of time. I can stop the execution
Assuming the UI is responsive enough to receive the stop command…
which (at least in my experience) is more often false than true.
In principle any environment that has a debugger attached to the
execution (so launching from any modern IDE) should be able to do it.
But of course the developer experience is somewhere completely
different. Plus they won't ship it to production with the debugger
attached. We would. :)
Peter
On Mon, May 2, 2016 at 2:36 PM, Jimmie Houchin <jlhouc...@gmail.com
<mailto:jlhouc...@gmail.com>> wrote:
While working on a project I made a mistake in some code. A common
mistake in most languages, a less common one in Smalltalk or
Pharo. Something similar to the below.
foreverTrue
| index end |
[ index < end ] whileTrue: [
"Do something clever.
But forget to increment index."
].
^ returnSomething
I can execute foreverTrue in a Playground and when nothing returns
in an appropriate amount of time. I can stop the execution. Fix
the bug. Try again. I lose nothing. All my data, all my image
state is still there. I do not have to do anything special to
execute foreverTrue again, but now successfully so.
Because Pharo/Smalltalk is so much more than just a programming
language, this is possible.
Most languages I know you would have to kill the vm and start all
over. I would have to do everything I had already done to get to
the correct state in order to execute my method. I guess many
static languages might catch the bug and not allow execution. But
I have no experience there.
I was just curious as to what other languages, environments might
survive my mistake and allow me to gracefully correct and continue.
I think this one of the big wins for Pharo/Smalltalk. We can
sometimes mess up and recover gracefully.
I think small things like this should possibly be collected in a
document as to some reasons for Pharo.
Thanks.
Jimmie
