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.
| index end |
[ index < end ] whileTrue: [
"Do something clever.
But forget to increment index."
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
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.
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. :)
On Mon, May 2, 2016 at 2:36 PM, Jimmie Houchin <[hidden email]> 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.
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.
On 05/02/2016 08:36 AM, Peter Uhnák wrote:
|Free forum by Nabble||Edit this page|