[Pharo-users] What other languages can do something similar?

Peter Uhnák i.uhnak at gmail.com
Mon May 2 09:36:51 EDT 2016


>
> 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 <jlhouchin at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160502/da9dbc6d/attachment.html>


More information about the Pharo-users mailing list