Discussion:
In your opinion, what's the best, and what's the worst aspects of using Clojure?
(too old to reply)
Kelker Ryan
2013-12-27 21:17:48 UTC
Permalink
In your opinion, what's the best, and what's the worst aspects of using Clojure?

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Daniel
2013-12-27 23:44:01 UTC
Permalink
Best: Language & Community
Worst: Error Reporting

On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>
> In your opinion, what's the best, and what's the worst aspects of using
> Clojure?
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Guru Devanla
2013-12-28 01:48:55 UTC
Permalink
Seconded on Error reporting.

I have been playing around with Clojure for sometime now and also completed
almost 150 of the 4clojure problems. What still scars me in terms of
incorporating Clojure as a language of choice in more complicated projects
I work on in my other life, is the error reporting facility. The errors
sometimes might as well just say 'I just cannot run!'. It would be nice if
there was some facility to approximately point to some s-exp or line
numbers.

May be I am missing some workflow used by other expert users. Can someone
throw more light on this.


Thanks
Guru


On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com> wrote:

> Best: Language & Community
> Worst: Error Reporting
>
>
> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>
>> In your opinion, what's the best, and what's the worst aspects of using
>> Clojure?
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Guru Devanla
2013-12-28 01:49:48 UTC
Permalink
Ok, wanted to be clear that I do support the Best part of language so far
has been the Language itself and community!


On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla <***@gmail.com> wrote:

> Seconded on Error reporting.
>
> I have been playing around with Clojure for sometime now and also
> completed almost 150 of the 4clojure problems. What still scars me in terms
> of incorporating Clojure as a language of choice in more complicated
> projects I work on in my other life, is the error reporting facility. The
> errors sometimes might as well just say 'I just cannot run!'. It would be
> nice if there was some facility to approximately point to some s-exp or
> line numbers.
>
> May be I am missing some workflow used by other expert users. Can someone
> throw more light on this.
>
>
> Thanks
> Guru
>
>
> On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com> wrote:
>
>> Best: Language & Community
>> Worst: Error Reporting
>>
>>
>> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>>
>>> In your opinion, what's the best, and what's the worst aspects of using
>>> Clojure?
>>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Sean Corfield
2013-12-28 03:44:57 UTC
Permalink
Whilst the stacktraces can be pretty painful at times - esp. if you're
dealing with lazy sequences - they do include filenames and line
numbers, at least when you're outside the REPL. There are also a
number of tools to clean up stack traces to show only Clojure-related
entries and/or color-code them etc (e.g.,
clojure.stacktrace/print-stack-trace which is part of the core Clojure
download).

That said, yes, debugging errors is probably the worst aspect of using
Clojure :)

And +1 on the language/community as best!

Sean

On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla <***@gmail.com> wrote:
> Seconded on Error reporting.
>
> I have been playing around with Clojure for sometime now and also completed
> almost 150 of the 4clojure problems. What still scars me in terms of
> incorporating Clojure as a language of choice in more complicated projects I
> work on in my other life, is the error reporting facility. The errors
> sometimes might as well just say 'I just cannot run!'. It would be nice if
> there was some facility to approximately point to some s-exp or line
> numbers.
>
> May be I am missing some workflow used by other expert users. Can someone
> throw more light on this.
>
>
> Thanks
> Guru
>
>
> On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com> wrote:
>>
>> Best: Language & Community
>> Worst: Error Reporting
>>
>>
>> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>>
>>> In your opinion, what's the best, and what's the worst aspects of using
>>> Clojure?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Alex Baranosky
2013-12-28 03:53:04 UTC
Permalink
I always hear people say that the errors are bad, but I just don't see it.
The stacktraces say exactly what went wrong and at what line of the
source. To me that's all I can hope for.

I think there may have been some more obtuse errors that came up in older
versions of Clojure that have since been improved in newer versions, though.


On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield <***@gmail.com>wrote:

> Whilst the stacktraces can be pretty painful at times - esp. if you're
> dealing with lazy sequences - they do include filenames and line
> numbers, at least when you're outside the REPL. There are also a
> number of tools to clean up stack traces to show only Clojure-related
> entries and/or color-code them etc (e.g.,
> clojure.stacktrace/print-stack-trace which is part of the core Clojure
> download).
>
> That said, yes, debugging errors is probably the worst aspect of using
> Clojure :)
>
> And +1 on the language/community as best!
>
> Sean
>
> On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla <***@gmail.com> wrote:
> > Seconded on Error reporting.
> >
> > I have been playing around with Clojure for sometime now and also
> completed
> > almost 150 of the 4clojure problems. What still scars me in terms of
> > incorporating Clojure as a language of choice in more complicated
> projects I
> > work on in my other life, is the error reporting facility. The errors
> > sometimes might as well just say 'I just cannot run!'. It would be nice
> if
> > there was some facility to approximately point to some s-exp or line
> > numbers.
> >
> > May be I am missing some workflow used by other expert users. Can someone
> > throw more light on this.
> >
> >
> > Thanks
> > Guru
> >
> >
> > On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com> wrote:
> >>
> >> Best: Language & Community
> >> Worst: Error Reporting
> >>
> >>
> >> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
> >>>
> >>> In your opinion, what's the best, and what's the worst aspects of using
> >>> Clojure?
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to ***@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+***@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+***@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to ***@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+***@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+***@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Colin Fleming
2013-12-28 07:42:30 UTC
Permalink
I think the error complaints are generally more about the errors when you
have something wrong in your code. Things like parsing of ns forms has
little to no error checking, and you can get some extremely obscure errors.
For example if you (or some tool) places an :import clause ahead of your NS
docstring, you get an error like: "java.lang.Character cannot be cast to
clojure.lang.Named" and it's generally attributed to a different namespace.
This sort of thing is terribly demoralising for newcomers, and occasionally
to seasoned pros too.


On 28 December 2013 16:53, Alex Baranosky <***@gmail.com>wrote:

> I always hear people say that the errors are bad, but I just don't see it.
> The stacktraces say exactly what went wrong and at what line of the
> source. To me that's all I can hope for.
>
> I think there may have been some more obtuse errors that came up in older
> versions of Clojure that have since been improved in newer versions, though.
>
>
> On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield <***@gmail.com>wrote:
>
>> Whilst the stacktraces can be pretty painful at times - esp. if you're
>> dealing with lazy sequences - they do include filenames and line
>> numbers, at least when you're outside the REPL. There are also a
>> number of tools to clean up stack traces to show only Clojure-related
>> entries and/or color-code them etc (e.g.,
>> clojure.stacktrace/print-stack-trace which is part of the core Clojure
>> download).
>>
>> That said, yes, debugging errors is probably the worst aspect of using
>> Clojure :)
>>
>> And +1 on the language/community as best!
>>
>> Sean
>>
>> On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla <***@gmail.com> wrote:
>> > Seconded on Error reporting.
>> >
>> > I have been playing around with Clojure for sometime now and also
>> completed
>> > almost 150 of the 4clojure problems. What still scars me in terms of
>> > incorporating Clojure as a language of choice in more complicated
>> projects I
>> > work on in my other life, is the error reporting facility. The errors
>> > sometimes might as well just say 'I just cannot run!'. It would be
>> nice if
>> > there was some facility to approximately point to some s-exp or line
>> > numbers.
>> >
>> > May be I am missing some workflow used by other expert users. Can
>> someone
>> > throw more light on this.
>> >
>> >
>> > Thanks
>> > Guru
>> >
>> >
>> > On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com>
>> wrote:
>> >>
>> >> Best: Language & Community
>> >> Worst: Error Reporting
>> >>
>> >>
>> >> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>> >>>
>> >>> In your opinion, what's the best, and what's the worst aspects of
>> using
>> >>> Clojure?
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to ***@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+***@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to clojure+***@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to ***@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+***@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+***@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Brian Craft
2013-12-28 19:20:49 UTC
Permalink
Yes, exactly, the error messages are often very obtuse. In part this is
just the nature of dynamic languages: if you don't sanity check data
structures at API boundaries, you get errors reported from obscure corners
of implementation. Also, laziness can lead to very deep, very confusing
stack traces. It's a bit like debugging deeply nested async callbacks,
except that most async platforms have effective debuggers that can quickly
elucidate how it's ended up at the bottom of a deep call stack, in
seemingly unrelated code.

On Friday, December 27, 2013 11:42:30 PM UTC-8, Colin Fleming wrote:
>
> I think the error complaints are generally more about the errors when you
> have something wrong in your code. Things like parsing of ns forms has
> little to no error checking, and you can get some extremely obscure errors.
> For example if you (or some tool) places an :import clause ahead of your NS
> docstring, you get an error like: "java.lang.Character cannot be cast to
> clojure.lang.Named" and it's generally attributed to a different namespace.
> This sort of thing is terribly demoralising for newcomers, and occasionally
> to seasoned pros too.
>
>
> On 28 December 2013 16:53, Alex Baranosky <***@gmail.com<javascript:>
> > wrote:
>
>> I always hear people say that the errors are bad, but I just don't see
>> it. The stacktraces say exactly what went wrong and at what line of the
>> source. To me that's all I can hope for.
>>
>> I think there may have been some more obtuse errors that came up in older
>> versions of Clojure that have since been improved in newer versions, though.
>>
>>
>> On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield <***@gmail.com<javascript:>
>> > wrote:
>>
>>> Whilst the stacktraces can be pretty painful at times - esp. if you're
>>> dealing with lazy sequences - they do include filenames and line
>>> numbers, at least when you're outside the REPL. There are also a
>>> number of tools to clean up stack traces to show only Clojure-related
>>> entries and/or color-code them etc (e.g.,
>>> clojure.stacktrace/print-stack-trace which is part of the core Clojure
>>> download).
>>>
>>> That said, yes, debugging errors is probably the worst aspect of using
>>> Clojure :)
>>>
>>> And +1 on the language/community as best!
>>>
>>> Sean
>>>
>>> On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla <***@gmail.com<javascript:>>
>>> wrote:
>>> > Seconded on Error reporting.
>>> >
>>> > I have been playing around with Clojure for sometime now and also
>>> completed
>>> > almost 150 of the 4clojure problems. What still scars me in terms of
>>> > incorporating Clojure as a language of choice in more complicated
>>> projects I
>>> > work on in my other life, is the error reporting facility. The errors
>>> > sometimes might as well just say 'I just cannot run!'. It would be
>>> nice if
>>> > there was some facility to approximately point to some s-exp or line
>>> > numbers.
>>> >
>>> > May be I am missing some workflow used by other expert users. Can
>>> someone
>>> > throw more light on this.
>>> >
>>> >
>>> > Thanks
>>> > Guru
>>> >
>>> >
>>> > On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com<javascript:>>
>>> wrote:
>>> >>
>>> >> Best: Language & Community
>>> >> Worst: Error Reporting
>>> >>
>>> >>
>>> >> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>> >>>
>>> >>> In your opinion, what's the best, and what's the worst aspects of
>>> using
>>> >>> Clojure?
>>> >>
>>> >> --
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups "Clojure" group.
>>> >> To post to this group, send email to ***@googlegroups.com<javascript:>
>>> >> Note that posts from new members are moderated - please be patient
>>> with
>>> >> your first post.
>>> >> To unsubscribe from this group, send email to
>>> >> clojure+***@googlegroups.com <javascript:>
>>> >> For more options, visit this group at
>>> >> http://groups.google.com/group/clojure?hl=en
>>> >> ---
>>> >> You received this message because you are subscribed to the Google
>>> Groups
>>> >> "Clojure" group.
>>> >> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> >> email to clojure+***@googlegroups.com <javascript:>.
>>> >> For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>> > --
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Clojure" group.
>>> > To post to this group, send email to ***@googlegroups.com<javascript:>
>>> > Note that posts from new members are moderated - please be patient
>>> with your
>>> > first post.
>>> > To unsubscribe from this group, send email to
>>> > clojure+***@googlegroups.com <javascript:>
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/clojure?hl=en
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Clojure" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> > email to clojure+***@googlegroups.com <javascript:>.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>> --
>>> Sean A Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>> World Singles, LLC. -- http://worldsingles.com/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to ***@googlegroups.com<javascript:>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+***@googlegroups.com <javascript:>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+***@googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-28 04:03:20 UTC
Permalink
On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
> I always hear people say that the errors are bad, but I just don't see it. The stacktraces say exactly what went wrong and at what line of the source. To me that's all I can hope for.

One can hope to see the values of locals, which for me would make a big difference. This is apparently possible (through some combination of nrepl-ritz and avoiding locals clearing, I think), but not at all easy. In other parts of the Lisp universe this has been standard for decades and, I think, central to common debugging practices.

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Alex Baranosky
2013-12-28 04:11:31 UTC
Permalink
Lee,

Sure, it'd be nice to have a functioning debugger, I'll give you that.


On Fri, Dec 27, 2013 at 8:03 PM, Lee Spector <***@hampshire.edu> wrote:

>
> On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
> > I always hear people say that the errors are bad, but I just don't see
> it. The stacktraces say exactly what went wrong and at what line of the
> source. To me that's all I can hope for.
>
> One can hope to see the values of locals, which for me would make a big
> difference. This is apparently possible (through some combination of
> nrepl-ritz and avoiding locals clearing, I think), but not at all easy. In
> other parts of the Lisp universe this has been standard for decades and, I
> think, central to common debugging practices.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
guns
2013-12-28 04:18:04 UTC
Permalink
On Fri 27 Dec 2013 at 11:03:20PM -0500, Lee Spector wrote:

> On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
>
> > I always hear people say that the errors are bad, but I just don't
> > see it. The stacktraces say exactly what went wrong and at what line
> > of the source. To me that's all I can hope for.

I'll have to agree with Alex, I've never really had that much of a
problem with Clojure errors. A stacktrace is certainly better than
"Segmentation fault".

> One can hope to see the values of locals, which for me would make a
> big difference. This is apparently possible (through some combination
> of nrepl-ritz and avoiding locals clearing, I think), but not at all
> easy. In other parts of the Lisp universe this has been standard for
> decades and, I think, central to common debugging practices.

I personally use the following macro from my user.clj:

(defmacro dump-locals []
`(clojure.pprint/pprint
~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))))))

It's not the automatic break-on-exception-and-start-local-repl of CL +
Emacs, but it's editor agnostic and usually does the trick.

I find that my desires for a stepping debugger are mostly absent with
Clojure as data is immutable, and the reference types may be monitored
with add-watch.

guns
Lee Spector
2013-12-28 04:23:22 UTC
Permalink
On Dec 27, 2013, at 11:18 PM, guns wrote:
>
> I personally use the following macro from my user.clj:
>
> (defmacro dump-locals []
> `(clojure.pprint/pprint
> ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))))))
>
> It's not the automatic break-on-exception-and-start-local-repl of CL +
> Emacs, but it's editor agnostic and usually does the trick.


When and where do you call this?

I can live without the local REPL (although I'll always miss it), but what I want is to see the locals when I hit an exception somewhere that I didn't expect one. I'd like every exception to dump locals, all up the stack if possible. Can this, or something like it, do that?

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
guns
2013-12-28 04:33:45 UTC
Permalink
On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote:
>
> On Dec 27, 2013, at 11:18 PM, guns wrote:
> >
> > I personally use the following macro from my user.clj:
> >
> > (defmacro dump-locals []
> > `(clojure.pprint/pprint
> > ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))))))
> >
> > It's not the automatic break-on-exception-and-start-local-repl of CL +
> > Emacs, but it's editor agnostic and usually does the trick.
>
>
> When and where do you call this?

I call this inside of the closest function that raised the exception.

> I can live without the local REPL (although I'll always miss it), but
> what I want is to see the locals when I hit an exception somewhere
> that I didn't expect one. I'd like every exception to dump locals, all
> up the stack if possible. Can this, or something like it, do that?

Like you mentioned, I've heard nrepl-ritz does this in emacs, and David
Greenberg has something like this set up for vim:

https://github.com/dgrnbrg/vim-redl

I don't use this myself, however. The dump-locals macro is essentially a
fancy way to do printf debugging, which I have found sufficient.

guns
Lee Spector
2013-12-28 08:56:56 UTC
Permalink
On Dec 27, 2013, at 11:33 PM, guns wrote:

> On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote:
>>
>> On Dec 27, 2013, at 11:18 PM, guns wrote:
>>>
>>> (defmacro dump-locals [] ...
>>> `
>> When and where do you call this?
>
> I call this inside of the closest function that raised the exception.

Ah, so you have to see an exception, edit your code to include a call to this, re-run, and get to the same exception.

So it will only help for exception-raising situations that are easy to repeat, which mine often are not.


> Like you mentioned, I've heard nrepl-ritz does this in emacs, and David
> Greenberg has something like this set up for vim:
>
> https://github.com/dgrnbrg/vim-redl

It would be really nice if this sort of thing -- dumping all locals when an exception is raised -- could be done in an IDE-independent way. FWIW my code is often running via "lein run," and when one of those runs raises an exception I'd really like to get more information about what happened.

-Lee

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Cedric Greevey
2013-12-28 16:27:24 UTC
Permalink
On Sat, Dec 28, 2013 at 3:56 AM, Lee Spector <***@hampshire.edu> wrote:

>
> On Dec 27, 2013, at 11:33 PM, guns wrote:
>
> > On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote:
> >>
> >> On Dec 27, 2013, at 11:18 PM, guns wrote:
> >>>
> >>> (defmacro dump-locals [] ...
> >>> `
> >> When and where do you call this?
> >
> > I call this inside of the closest function that raised the exception.
>
> Ah, so you have to see an exception, edit your code to include a call to
> this, re-run, and get to the same exception.
>
> So it will only help for exception-raising situations that are easy to
> repeat, which mine often are not.
>

It helps to go with the "functional, immutable" flow, in which case if you
get an unwanted exception it should *usually* have bubbled up from some
failing test. Add a dump-locals where suggested by the stack trace and
rerun the failing test and voila! That should do it for almost all
non-exogenous exceptions, leaving mainly things like network timeouts and
other wonkiness caused by factors outside of your code (and, often, outside
of your control anyway).

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-28 17:45:03 UTC
Permalink
On Dec 28, 2013, at 11:27 AM, Cedric Greevey wrote:
>
> It helps to go with the "functional, immutable" flow, in which case if you get an unwanted exception it should *usually* have bubbled up from some failing test. Add a dump-locals where suggested by the stack trace and rerun the failing test and voila! That should do it for almost all non-exogenous exceptions, leaving mainly things like network timeouts and other wonkiness caused by factors outside of your code (and, often, outside of your control anyway).

You've given me some interesting things to think about re: the role of testing, but I think that it may be hard to map your approach directly on to the kind of work that I do.

I often work with stochastic simulations which run for days and for which repeatability is hard to engineer, especially in a multicore context. There's a lot of unpredictable dynamism and usually code is generated and run dynamically (and mutated and recombined; this is "genetic programming"). Even if you code functionally and immutably (which I try to do, to a reasonable extent), and stamp out all nondeterminism (which would be a pain), it may take days to re-create a situation.

So it'd be really nice if the system could just spit out more of the state that produced the exception in the first place, when it happens.

-Lee

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Cedric Greevey
2013-12-28 19:56:51 UTC
Permalink
On Sat, Dec 28, 2013 at 12:45 PM, Lee Spector <***@hampshire.edu>wrote:

>
> On Dec 28, 2013, at 11:27 AM, Cedric Greevey wrote:
> >
> > It helps to go with the "functional, immutable" flow, in which case if
> you get an unwanted exception it should *usually* have bubbled up from some
> failing test. Add a dump-locals where suggested by the stack trace and
> rerun the failing test and voila! That should do it for almost all
> non-exogenous exceptions, leaving mainly things like network timeouts and
> other wonkiness caused by factors outside of your code (and, often, outside
> of your control anyway).
>
> You've given me some interesting things to think about re: the role of
> testing, but I think that it may be hard to map your approach directly on
> to the kind of work that I do.
>
> I often work with stochastic simulations which run for days and for which
> repeatability is hard to engineer, especially in a multicore context.
> There's a lot of unpredictable dynamism and usually code is generated and
> run dynamically (and mutated and recombined; this is "genetic
> programming"). Even if you code functionally and immutably (which I try to
> do, to a reasonable extent), and stamp out all nondeterminism (which would
> be a pain), it may take days to re-create a situation.
>

Your requirements are unusual.

That being said, you might want to consider:

1. Using a PRNG with recordable seed, and sane concurrency semantics, to
achieve repeatability -- rerun with same seed to get identical replay of
events.

2. If crashes are happening after days, add snapshotting -- some ability to
save the state of the whole simulation from time to time (including current
PRNG state). Use the last snapshot before a crash to investigate the crash.
Requires item 1, above, for rerunning from the same snapshot to produce
unvarying results.

I'd suggest using a ref world, with a periodically waking thread that does
a (spit (dosync (dump-all-the-refs-to-some-data-structure))) or something.
(If retries become a big problem you'll need to add more coordination,
maybe using core.async to get everything else to take a breather during
each state dump.) You also need order-independence (which suggests a
deterministic breaking up of the world into the domains of different
threads, with defined interaction channels and times, and a separate PRNG
per thread -- I'd suggest a state-dumpable Mersenne Twister instance per
thread, seeded at startup using values from java.util.Random, itself seeded
with a known startup seed).

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Cedric Greevey
2013-12-28 20:11:15 UTC
Permalink
Adding to the above, in the specific context of genetic programming, I'd
suggest dividing the population into N subsets, one per core, and trialling
them in parallel to generate fitness scores; then parallel-mergesort to get
a ranked order; then (apply map vector (partition (/ num-to-keep num-cores)
(take num-to-keep sorted-population))) to cull all but the best num-to-keep
and distribute them across N new subsets with each subset a representative
sample of the range of fitness scores (so any correlation between trial
speed and fitness won't make some populations slow and stop), then apply
any recombination/crossovers to generate, say, M new genomes in each subset
(parallel, uses the static data from the previous round and per-thread
PRNGs to decide which pairs of survivors to use to make offspring added to
that thread's subpopulation), then apply mutation (parallel, each thread
mutates its own subpopulation), then next trial... No
thread-order-of-action dependencies this way. Snapshot once a round by
saving the subpopulations and per-thread PRNG internal states right before
each fitness trial phase. Snapshot should evolve deterministically if
restored with the same values for num-to-keep and num-cores and whatever
other parameters. Last snapshot before crash should crash the same way
every time.

On Sat, Dec 28, 2013 at 2:56 PM, Cedric Greevey <***@gmail.com> wrote:

> On Sat, Dec 28, 2013 at 12:45 PM, Lee Spector <***@hampshire.edu>wrote:
>
>>
>> On Dec 28, 2013, at 11:27 AM, Cedric Greevey wrote:
>> >
>> > It helps to go with the "functional, immutable" flow, in which case if
>> you get an unwanted exception it should *usually* have bubbled up from some
>> failing test. Add a dump-locals where suggested by the stack trace and
>> rerun the failing test and voila! That should do it for almost all
>> non-exogenous exceptions, leaving mainly things like network timeouts and
>> other wonkiness caused by factors outside of your code (and, often, outside
>> of your control anyway).
>>
>> You've given me some interesting things to think about re: the role of
>> testing, but I think that it may be hard to map your approach directly on
>> to the kind of work that I do.
>>
>> I often work with stochastic simulations which run for days and for which
>> repeatability is hard to engineer, especially in a multicore context.
>> There's a lot of unpredictable dynamism and usually code is generated and
>> run dynamically (and mutated and recombined; this is "genetic
>> programming"). Even if you code functionally and immutably (which I try to
>> do, to a reasonable extent), and stamp out all nondeterminism (which would
>> be a pain), it may take days to re-create a situation.
>>
>
> Your requirements are unusual.
>
> That being said, you might want to consider:
>
> 1. Using a PRNG with recordable seed, and sane concurrency semantics, to
> achieve repeatability -- rerun with same seed to get identical replay of
> events.
>
> 2. If crashes are happening after days, add snapshotting -- some ability
> to save the state of the whole simulation from time to time (including
> current PRNG state). Use the last snapshot before a crash to investigate
> the crash. Requires item 1, above, for rerunning from the same snapshot to
> produce unvarying results.
>
> I'd suggest using a ref world, with a periodically waking thread that does
> a (spit (dosync (dump-all-the-refs-to-some-data-structure))) or something.
> (If retries become a big problem you'll need to add more coordination,
> maybe using core.async to get everything else to take a breather during
> each state dump.) You also need order-independence (which suggests a
> deterministic breaking up of the world into the domains of different
> threads, with defined interaction channels and times, and a separate PRNG
> per thread -- I'd suggest a state-dumpable Mersenne Twister instance per
> thread, seeded at startup using values from java.util.Random, itself seeded
> with a known startup seed).
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-28 20:54:51 UTC
Permalink
On Dec 28, 2013, at 3:11 PM, Cedric Greevey wrote:

> Adding to the above, in the specific context of genetic programming, I'd suggest dividing the population into N subsets, one per core, and trialling them in parallel to generate fitness scores; then parallel-mergesort to get a ranked order; then (apply map vector (partition (/ num-to-keep num-cores) (take num-to-keep sorted-population))) to cull all but the best num-to-keep and distribute them across N new subsets with each subset a representative sample of the range of fitness scores (so any correlation between trial speed and fitness won't make some populations slow and stop), then apply any recombination/crossovers to generate, say, M new genomes in each subset (parallel, uses the static data from the previous round and per-thread PRNGs to decide which pairs of survivors to use to make offspring added to that thread's subpopulation), then apply mutation (parallel, each thread mutates its own subpopulation), then next trial... No thread-order-of-action dependencies this way. Snapshot once a round by saving the subpopulations and per-thread PRNG internal states right before each fitness trial phase. Snapshot should evolve deterministically if restored with the same values for num-to-keep and num-cores and whatever other parameters. Last snapshot before crash should crash the same way every time.

Some of what you're suggesting would have implications for evolutionary dynamics. Maybe good, maybe bad, some related to things that I and others have studied (e.g. various schemes for working with subpopulations), and some maybe incompatible with other experimental things that I may be working with. I'm a researcher in this area, so I do care about and have tried related things for various reasons, but I don't want my search/evolution algorithm design to be driven by inadequacies of my programming environment (e.g. difficulties in finding sources of crashes).

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Cedric Greevey
2013-12-28 21:46:54 UTC
Permalink
Eh, the above should just parallelize working with a single big population.
It's not partitioned as far as making-the-cut is concerned, nor crossover
(given that each thread adds its M crossover-generated entities by
reference to the whole pool of survivors from the previous round). The only
constraint the above scheme imposed, in fact, was to force the population
size to be divisible by the number of cores, which could be relaxed with
the only consequence being a mildly underutilized core (whichever got fewer
than the others in its subpopulation). If you have dynamics involving
subpopulations that are subjected to separate fitness cuts, reproductively
isolated, or what-have-you, that just seems to afford more scope for
parallelizing without the order of execution of particular bits of stuff on
particular threads affecting things.


On Sat, Dec 28, 2013 at 3:54 PM, Lee Spector <***@hampshire.edu> wrote:

>
> On Dec 28, 2013, at 3:11 PM, Cedric Greevey wrote:
>
> > Adding to the above, in the specific context of genetic programming, I'd
> suggest dividing the population into N subsets, one per core, and trialling
> them in parallel to generate fitness scores; then parallel-mergesort to get
> a ranked order; then (apply map vector (partition (/ num-to-keep num-cores)
> (take num-to-keep sorted-population))) to cull all but the best num-to-keep
> and distribute them across N new subsets with each subset a representative
> sample of the range of fitness scores (so any correlation between trial
> speed and fitness won't make some populations slow and stop), then apply
> any recombination/crossovers to generate, say, M new genomes in each subset
> (parallel, uses the static data from the previous round and per-thread
> PRNGs to decide which pairs of survivors to use to make offspring added to
> that thread's subpopulation), then apply mutation (parallel, each thread
> mutates its own subpopulation), then next trial... No
> thread-order-of-action dependencies this way. Snapshot once a round by
> saving the subpopulations and per-thread PRNG internal states right before
> each fitness trial phase. Snapshot should evolve deterministically if
> restored with the same values for num-to-keep and num-cores and whatever
> other parameters. Last snapshot before crash should crash the same way
> every time.
>
> Some of what you're suggesting would have implications for evolutionary
> dynamics. Maybe good, maybe bad, some related to things that I and others
> have studied (e.g. various schemes for working with subpopulations), and
> some maybe incompatible with other experimental things that I may be
> working with. I'm a researcher in this area, so I do care about and have
> tried related things for various reasons, but I don't want my
> search/evolution algorithm design to be driven by inadequacies of my
> programming environment (e.g. difficulties in finding sources of crashes).
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-28 23:42:38 UTC
Permalink
On Dec 28, 2013, at 4:46 PM, Cedric Greevey wrote:

> Eh, the above should just parallelize working with a single big population. It's not partitioned as far as making-the-cut is concerned, nor crossover (given that each thread adds its M crossover-generated entities by reference to the whole pool of survivors from the previous round). The only constraint the above scheme imposed, in fact, was to force the population size to be divisible by the number of cores, which could be relaxed with the only consequence being a mildly underutilized core (whichever got fewer than the others in its subpopulation). If you have dynamics involving subpopulations that are subjected to separate fitness cuts, reproductively isolated, or what-have-you, that just seems to afford more scope for parallelizing without the order of execution of particular bits of stuff on particular threads affecting things.

Ah yes, I now see that you weren't operating on the subpopulations in ways that would change the global behavior. Sorry I read that too quickly, and I do appreciate the suggestions. You've specified some other things that aren't quite compatible with the ways we often do things (e.g. about how and when selection works), but those could be tweaked and in fact we already do many of the things that you suggest, with concurrent fitness evaluation using thread-local RNGs (although we sometimes actually see mysterious bad performance from this -- which led to this thread: https://groups.google.com/forum/#!searchin/clojure/abysmal/clojure/48W2eff3caU/p12kY9D8d1cJ).

The question is, would it be worth it to take the time to ensure that all of the RNG handling allows complete repeatability, and add the snapshotting (which presumably has both development and runtime costs), and add whatever would be needed to restart from a snapshot? Maybe, but since I generally don't actually care about repeatability, it seems like the long way around. If I could instead get Clojure to dump the values of locals when an exception is raised -- which is already available in some IDEs but not more generally -- then I wouldn't have any other reason to do this.

Thanks,

-Lee


--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Colin Fleming
2013-12-29 01:51:24 UTC
Permalink
Just out of interest (and I'm not trying to be combative here, I'm
genuinely curious) - it seems from many of your posts here that this is a
serious pain point for you. Why not just use another lisp? High-performance
numeric programming doesn't seem like Clojure's strong point and the error
handling is clearly difficult for you - why not some CL variant? Do other
benefits of Clojure compensate for these problems?


On 29 December 2013 12:42, Lee Spector <***@hampshire.edu> wrote:

>
> On Dec 28, 2013, at 4:46 PM, Cedric Greevey wrote:
>
> > Eh, the above should just parallelize working with a single big
> population. It's not partitioned as far as making-the-cut is concerned, nor
> crossover (given that each thread adds its M crossover-generated entities
> by reference to the whole pool of survivors from the previous round). The
> only constraint the above scheme imposed, in fact, was to force the
> population size to be divisible by the number of cores, which could be
> relaxed with the only consequence being a mildly underutilized core
> (whichever got fewer than the others in its subpopulation). If you have
> dynamics involving subpopulations that are subjected to separate fitness
> cuts, reproductively isolated, or what-have-you, that just seems to afford
> more scope for parallelizing without the order of execution of particular
> bits of stuff on particular threads affecting things.
>
> Ah yes, I now see that you weren't operating on the subpopulations in ways
> that would change the global behavior. Sorry I read that too quickly, and I
> do appreciate the suggestions. You've specified some other things that
> aren't quite compatible with the ways we often do things (e.g. about how
> and when selection works), but those could be tweaked and in fact we
> already do many of the things that you suggest, with concurrent fitness
> evaluation using thread-local RNGs (although we sometimes actually see
> mysterious bad performance from this -- which led to this thread:
> https://groups.google.com/forum/#!searchin/clojure/abysmal/clojure/48W2eff3caU/p12kY9D8d1cJ
> ).
>
> The question is, would it be worth it to take the time to ensure that all
> of the RNG handling allows complete repeatability, and add the snapshotting
> (which presumably has both development and runtime costs), and add whatever
> would be needed to restart from a snapshot? Maybe, but since I generally
> don't actually care about repeatability, it seems like the long way around.
> If I could instead get Clojure to dump the values of locals when an
> exception is raised -- which is already available in some IDEs but not more
> generally -- then I wouldn't have any other reason to do this.
>
> Thanks,
>
> -Lee
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-29 03:37:55 UTC
Permalink
On Dec 28, 2013, at 8:51 PM, Colin Fleming wrote:
> Just out of interest (and I'm not trying to be combative here, I'm genuinely curious) - it seems from many of your posts here that this is a serious pain point for you. Why not just use another lisp? High-performance numeric programming doesn't seem like Clojure's strong point and the error handling is clearly difficult for you - why not some CL variant? Do other benefits of Clojure compensate for these problems?

I lived in and loved Common Lisp for a long time (since the mid 80s), but eventually I became frustrated with what seemed to be an ever-shrinking community and ecosystem and a failure to keep up with emerging tools and trends. After a brief holiday in Scheme I saw Rich Hickey's Intro to Clojure for Lisp programmers and was hooked because I saw that Clojure retains much of what I love about Common Lisp while improving a couple of things in the core of the language (e.g. maps and vectors), making it easy to leverage everything in the Java universe, and supporting concurrency (although I've had less success than I hoped in actually seeing the benefits there). Most importantly, it has an active and growing community, and lots of cool new things happening all of the time.

I'm generally pretty happy with life in the Clojure universe, although it's true that I'm sometimes frustrated when Clojure tools haven't caught up with the Common Lisp tools of my youth. I do try to express this frustration in constructive ways :-)

BTW what I'm doing isn't usually heavy on the numeric computing side -- it's usually heavier on symbol/list processing.

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Colin Fleming
2013-12-29 03:44:33 UTC
Permalink
Sure, in general I think your criticisms are very constructive, and I think
we do need to try to identify the pain points as much as possible. Thanks
for the explanation! I agree that the community is one of the best features
of Clojure.


On 29 December 2013 16:37, Lee Spector <***@hampshire.edu> wrote:

>
> On Dec 28, 2013, at 8:51 PM, Colin Fleming wrote:
> > Just out of interest (and I'm not trying to be combative here, I'm
> genuinely curious) - it seems from many of your posts here that this is a
> serious pain point for you. Why not just use another lisp? High-performance
> numeric programming doesn't seem like Clojure's strong point and the error
> handling is clearly difficult for you - why not some CL variant? Do other
> benefits of Clojure compensate for these problems?
>
> I lived in and loved Common Lisp for a long time (since the mid 80s), but
> eventually I became frustrated with what seemed to be an ever-shrinking
> community and ecosystem and a failure to keep up with emerging tools and
> trends. After a brief holiday in Scheme I saw Rich Hickey's Intro to
> Clojure for Lisp programmers and was hooked because I saw that Clojure
> retains much of what I love about Common Lisp while improving a couple of
> things in the core of the language (e.g. maps and vectors), making it easy
> to leverage everything in the Java universe, and supporting concurrency
> (although I've had less success than I hoped in actually seeing the
> benefits there). Most importantly, it has an active and growing community,
> and lots of cool new things happening all of the time.
>
> I'm generally pretty happy with life in the Clojure universe, although
> it's true that I'm sometimes frustrated when Clojure tools haven't caught
> up with the Common Lisp tools of my youth. I do try to express this
> frustration in constructive ways :-)
>
> BTW what I'm doing isn't usually heavy on the numeric computing side --
> it's usually heavier on symbol/list processing.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lee Spector
2013-12-28 20:44:50 UTC
Permalink
On Dec 28, 2013, at 2:56 PM, Cedric Greevey wrote:
> Your requirements are unusual.
>
> That being said, you might want to consider:
>
> 1. Using a PRNG with recordable seed, and sane concurrency semantics, to achieve repeatability -- rerun with same seed to get identical replay of events.
>
> 2. If crashes are happening after days, add snapshotting -- some ability to save the state of the whole simulation from time to time (including current PRNG state). Use the last snapshot before a crash to investigate the crash. Requires item 1, above, for rerunning from the same snapshot to produce unvarying results.
>
> I'd suggest using a ref world, with a periodically waking thread that does a (spit (dosync (dump-all-the-refs-to-some-data-structure))) or something. (If retries become a big problem you'll need to add more coordination, maybe using core.async to get everything else to take a breather during each state dump.) You also need order-independence (which suggests a deterministic breaking up of the world into the domains of different threads, with defined interaction channels and times, and a separate PRNG per thread -- I'd suggest a state-dumpable Mersenne Twister instance per thread, seeded at startup using values from java.util.Random, itself seeded with a known startup seed).

I can see how and why all of the above would work. But it's a pretty big effort, for which I would have no other use, and which would be unnecessary for me if I could just see the values of locals on crashes, as I can with other Lisps.


--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Luc Prefontaine
2013-12-30 10:36:14 UTC
Permalink
We added this as part of our standard
logging, not only when exceptions
are raised. It does help a lot in prod...

Luc P.


>
> On Dec 27, 2013, at 11:33 PM, guns wrote:
>
> > On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote:
> >>
> >> On Dec 27, 2013, at 11:18 PM, guns wrote:
> >>>
> >>> (defmacro dump-locals [] ...
> >>> `
> >> When and where do you call this?
> >
> > I call this inside of the closest function that raised the exception.
>
> Ah, so you have to see an exception, edit your code to include a call to this, re-run, and get to the same exception.
>
> So it will only help for exception-raising situations that are easy to repeat, which mine often are not.
>
>
> > Like you mentioned, I've heard nrepl-ritz does this in emacs, and David
> > Greenberg has something like this set up for vim:
> >
> > https://github.com/dgrnbrg/vim-redl
>
> It would be really nice if this sort of thing -- dumping all locals when an exception is raised -- could be done in an IDE-independent way. FWIW my code is often running via "lein run," and when one of those runs raises an exception I'd really like to get more information about what happened.
>
> -Lee
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Luc Prefontaine<***@softaddicts.ca> sent by ibisMail!

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
larry google groups
2013-12-29 01:58:27 UTC
Permalink
I like this:

(defmacro dump-locals []
`(clojure.pprint/pprint
~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))))))

Slingshot also allows one to throw+ an object that is full of local
information:

https://github.com/scgilardi/slingshot


And Michael Drogalis's library Dire recently adopted Slingshot for handling
exceptions:

https://github.com/MichaelDrogalis/dire




On Friday, December 27, 2013 11:18:04 PM UTC-5, guns wrote:
>
> On Fri 27 Dec 2013 at 11:03:20PM -0500, Lee Spector wrote:
>
> > On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
> >
> > > I always hear people say that the errors are bad, but I just don't
> > > see it. The stacktraces say exactly what went wrong and at what line
> > > of the source. To me that's all I can hope for.
>
> I'll have to agree with Alex, I've never really had that much of a
> problem with Clojure errors. A stacktrace is certainly better than
> "Segmentation fault".
>
> > One can hope to see the values of locals, which for me would make a
> > big difference. This is apparently possible (through some combination
> > of nrepl-ritz and avoiding locals clearing, I think), but not at all
> > easy. In other parts of the Lisp universe this has been standard for
> > decades and, I think, central to common debugging practices.
>
> I personally use the following macro from my user.clj:
>
> (defmacro dump-locals []
> `(clojure.pprint/pprint
> ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))))))
>
> It's not the automatic break-on-exception-and-start-local-repl of CL +
> Emacs, but it's editor agnostic and usually does the trick.
>
> I find that my desires for a stepping debugger are mostly absent with
> Clojure as data is immutable, and the reference types may be monitored
> with add-watch.
>
> guns
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
larry google groups
2013-12-29 01:52:26 UTC
Permalink
> What still scars me in terms of incorporating Clojure as a language of
choice in more
> complicated projects I work on in my other life, is the error reporting
facility. The
> errors sometimes might as well just say 'I just cannot run!'. It would
be nice if
> there was some facility to approximately point to some s-exp or line
numbers.

I agree that some of the stacktraces make it difficult to track down where
an error is. I've lately dealt with that by writing a lot of :pre and :post
assertions. That tends to narrow everything down very quickly. For
instance:

(defn get-count [request]
{:pre [
(= (type request) clojure.lang.PersistentHashMap)
(= (type (get-in request [:params :item-type])) java.lang.String)
]
:post [
(= (type %) java.lang.Long)
(or (pos? %) (zero? %))
]}
(monger/get-count (get-in request [:params :item-type])))


At the top level of my app, I wrap everything in a try/catch and print out
(clojure.stacktrace//print-stack-trace e). It's a bit of work, but once I
wrote enough :pre and :post conditions they became sufficient to give me
exact information about where any error occurred.





On Friday, December 27, 2013 8:48:55 PM UTC-5, Guru Devanla wrote:
>
> Seconded on Error reporting.
>
> I have been playing around with Clojure for sometime now and also
> completed almost 150 of the 4clojure problems. What still scars me in terms
> of incorporating Clojure as a language of choice in more complicated
> projects I work on in my other life, is the error reporting facility. The
> errors sometimes might as well just say 'I just cannot run!'. It would be
> nice if there was some facility to approximately point to some s-exp or
> line numbers.
>
> May be I am missing some workflow used by other expert users. Can someone
> throw more light on this.
>
>
> Thanks
> Guru
>
>
> On Fri, Dec 27, 2013 at 3:44 PM, Daniel <***@gmail.com <javascript:>
> > wrote:
>
>> Best: Language & Community
>> Worst: Error Reporting
>>
>>
>> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>>
>>> In your opinion, what's the best, and what's the worst aspects of using
>>> Clojure?
>>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Timothy Washington
2013-12-30 14:03:55 UTC
Permalink
:pre and :post <http://blog.fogus.me/2009/12/21/clojures-pre-and-post/> are
great tools, but must be used at the very top of your function. You can
also use assert <http://clojuredocs.org/clojure_core/clojure.core/assert>,
at any location in your function. I've also had success with Prismatic's
Schema <https://github.com/Prismatic/schema>.


Hth

Tim Washington
Interruptsoftware.com <http://interruptsoftware.com>



On Sat, Dec 28, 2013 at 8:52 PM, larry google groups <
***@gmail.com> wrote:

>
> > What still scars me in terms of incorporating Clojure as a language of
> choice in more
> > complicated projects I work on in my other life, is the error reporting
> facility. The
> > errors sometimes might as well just say 'I just cannot run!'. It would
> be nice if
> > there was some facility to approximately point to some s-exp or line
> numbers.
>
> I agree that some of the stacktraces make it difficult to track down where
> an error is. I've lately dealt with that by writing a lot of :pre and :post
> assertions. That tends to narrow everything down very quickly. For
> instance:
>
> (defn get-count [request]
> {:pre [
> (= (type request) clojure.lang.PersistentHashMap)
> (= (type (get-in request [:params :item-type])) java.lang.String)
> ]
> :post [
> (= (type %) java.lang.Long)
> (or (pos? %) (zero? %))
> ]}
> (monger/get-count (get-in request [:params :item-type])))
>
>
> At the top level of my app, I wrap everything in a try/catch and print out
> (clojure.stacktrace//print-stack-trace e). It's a bit of work, but once I
> wrote enough :pre and :post conditions they became sufficient to give me
> exact information about where any error occurred.
>
>
>
> On Friday, December 27, 2013 8:48:55 PM UTC-5, Guru Devanla wrote:
>
>> Seconded on Error reporting.
>>
>> I have been playing around with Clojure for sometime now and also
>> completed almost 150 of the 4clojure problems. What still scars me in terms
>> of incorporating Clojure as a language of choice in more complicated
>> projects I work on in my other life, is the error reporting facility. The
>> errors sometimes might as well just say 'I just cannot run!'. It would be
>> nice if there was some facility to approximately point to some s-exp or
>> line numbers.
>>
>> May be I am missing some workflow used by other expert users. Can someone
>> throw more light on this.
>>
>>
>> Thanks
>> Guru
>>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
James Reeves
2013-12-28 12:26:18 UTC
Permalink
The worst aspect of Clojure is probably its dependency on the JVM - which
also happens to be one of its best attributes as well.

A lot of the rough edges Clojure has can be traced back to trade-offs with
running on a VM built for another language. The stacktraces of lazy
sequences, the limitations of the protocol/type system, the lack of
continuations or TCO, the slow startup time - pretty much everything I
dislike about the language is due to some practical compromise with the JVM.

This is one of the reasons I'm rather interested in the progress of
analyzer and emitter projects in contrib. It's a step toward a bootstrapped
language.

- James


On 27 December 2013 21:17, Kelker Ryan <***@yandex.com> wrote:

> In your opinion, what's the best, and what's the worst aspects of using
> Clojure?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to ***@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+***@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+***@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Brian Craft
2013-12-28 19:29:04 UTC
Permalink
heh. Yes, well put.

On Saturday, December 28, 2013 4:26:18 AM UTC-8, James Reeves wrote:
>
> The worst aspect of Clojure is probably its dependency on the JVM - which
> also happens to be one of its best attributes as well.
>
> A lot of the rough edges Clojure has can be traced back to trade-offs with
> running on a VM built for another language. The stacktraces of lazy
> sequences, the limitations of the protocol/type system, the lack of
> continuations or TCO, the slow startup time - pretty much everything I
> dislike about the language is due to some practical compromise with the JVM.
>
> This is one of the reasons I'm rather interested in the progress of
> analyzer and emitter projects in contrib. It's a step toward a bootstrapped
> language.
>
> - James
>
>
> On 27 December 2013 21:17, Kelker Ryan <***@yandex.com <javascript:>>wrote:
>
>> In your opinion, what's the best, and what's the worst aspects of using
>> Clojure?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to ***@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+***@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+***@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Mikera
2013-12-28 14:29:00 UTC
Permalink
On Friday, 27 December 2013 21:17:48 UTC, Kelker Ryan wrote:
>
> In your opinion, what's the best, and what's the worst aspects of using
> Clojure?
>

The best part is the community + ecosystem: the innovative and useful
libraries created by the community that build on Clojure's design strengths
(immutability, data, concurrency, abstraction etc.), plus the great
integration with the vast ecosystem of Java/JVM libraries and tools. I love
the fact that the libraries are easily composable rather than "one size
fits all" frameworks. This gives you great platform reach and productivity.

The worst part is the design of the namespace system / dynamic vars. It's
an uncomfortable mess of mutability and side effects in the midst of an
otherwise very nicely designed functional language, and it is a major cause
of various downstream problems (lack of circular compilation references,
harder to build solid tooling, performance overhead of var lookup,
preventing better compiler optimisations, putting obstacles in the way of
smarter type inference, etc.). IMHO namespaces would be much better
designed as environments that are immutable and declarative (The dynamism
that we all love could still be provided by allowing redefinition and
dynamic recompilation in a way that produces a new namespace, i.e.
namespaces would behave much more like Clojure's other immutable data
structures).

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+***@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Loading...