Re: Frustrations so far

2016-07-23 Thread Timothy Baldridge 
Peter,

I share your frustration, or at least I did at one point. If you dig back
about 6 years in this mailing list you will find an epic rant by me about
OpenGL and Clojure. Looking back on what I thought at that time, I'll
mention as perhaps they can help you not make the mistakes I did.

1) Be as specific as possible. If I say "clojure sucks because I can get a
nil anywhere", isn't that helpful to anyone. But if I say "here's some code
that stumped me, what am I doing wrong, how can I get better", people can
chime in with a direct example, and a direct solution.

2) It's hard, but stick with one problem per email thread.  Too often I see
lists (and yes I've written them myself) that go on a tirade of "everything
that's wrong with X". The problem is that mailing lists are very poor
mediums for having multithreaded conversations. So some questions will get
lost or emphasized, to the determent of other questions. So to use your
email as an example, it would be awesome to see a email thread about
"defrecord reloading", one about "empty? and ints" and another about
datomic's log function. They all have different answers and it's hard to
answer them all at once.

3) Many things in Clojure seem random until you understand the reasoning
behind them. I hate telling people to go read the Clojure source, but I'll
say the more of it you read the more you will understand. Very few things
in Clojure are done without a reason, and some things that seem like bugs
may actually just be a misunderstanding of the basic concepts of the
language.

I once had a co-worker (who used Ruby a lot) say, "why does Python suck so
much?". After a conversation with him we both kindof realized it's not that
Ruby rocks and Python sucks, its simply a different set of tradeoffs and
optimizations that make each language unique. The same is true for Clojure.
Learning what those tradeoffs is, is very important.

4) Don't give up! I played with Clojure for about 2 years before becoming
comfortable with it. Don't be like me and throw it away every few months in
anger. Keep at it, please keep asking questions, and do so before you reach
the point of frustration. I've worked with more languages than I can
remember, but Clojure is the only one I've stuck with this long, simply
because it's that good. Not perfect, but more perfect (imo) than any other
language I've used.

Hope this helps,

Timothy

On Sat, Jul 23, 2016 at 8:17 AM, Colin Yates  wrote:

> Abstractions and dynamic/static typing are orthogonal. Static/dynamic
> is simply _when_ types are considered. Strong/weak typing is arguably
> more relevant and is about how narrowly type information is
> considered.
>
> I can't find an actual declaration but I consider Clojure is dynamic
> but strongly typed. Some dynamically typed languages tend to be more
> forgiving when asking questions and will guess at what you are asking
> regardless of whether they are statically or dynamically typed, so
> Ruby (sort of strongly typed) and JavaScript (weakly typed) have no
> problem with asking if an Integer is empty.
>
> Wow, that reads like I am lecturing down to somebody - apologies, that
> isn't my intent. Half of the problem is that like 'Functional
> Programming' there isn't really an authoritative definition of
> 'strongly typed' or 'weakly typed' :-).
>
> On 23 July 2016 at 14:15, 'Adrian A.' via Clojure
>  wrote:
> >
> >
> >> The point is that an 'Integer'
> >> (abstraction) has no sense of 'emptiness' or 'fullness'.
> >>
> > IMHO that might be true for a statically typed language, but in the case
> of
> > a dynamic language like Clojure it makes perfect sense, and most users
> > expect
> > this behavior.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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

Re: Clojure News is out

2016-07-23 Thread Timothy Washington 
+1


On Tue, Jul 19, 2016 at 10:35 AM, Jacob Strength  wrote:

> This looks great! I was just curious though, what are the advantages of
> this over say the Clojure page on reddit? To me it seems very similar.
>
>
> On Friday, July 15, 2016 at 9:28:12 AM UTC-6, Ertuğrul Çetin wrote:
>>
>> Hi Everyone,
>>
>> I'm very excited to announce that Clojure News(Beta) https://clojure.news is
>> out which is Hacker News Clone built for Clojurists.
>>
>> My goal is gathering Clojurists under one roof and helping Clojure
>> Community to improve.
>>
>> It has cool and community driven features.
>>
>> P.S: It is open source you can check out the source code from GitHub:
>> https://github.com/ertugrulcetin/ClojureNews
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Frustrations so far

2016-07-23 Thread Mimmo Cosenza 
One of the best and instructive post I have read in years. Thanks Timothy

Mimmo

> Il giorno 23 lug 2016, alle ore 22:26, Timothy Baldridge 
>  ha scritto:
> 
> Peter, 
> 
> I share your frustration, or at least I did at one point. If you dig back 
> about 6 years in this mailing list you will find an epic rant by me about 
> OpenGL and Clojure. Looking back on what I thought at that time, I'll mention 
> as perhaps they can help you not make the mistakes I did. 
> 
> 1) Be as specific as possible. If I say "clojure sucks because I can get a 
> nil anywhere", isn't that helpful to anyone. But if I say "here's some code 
> that stumped me, what am I doing wrong, how can I get better", people can 
> chime in with a direct example, and a direct solution.
> 
> 2) It's hard, but stick with one problem per email thread.  Too often I see 
> lists (and yes I've written them myself) that go on a tirade of "everything 
> that's wrong with X". The problem is that mailing lists are very poor mediums 
> for having multithreaded conversations. So some questions will get lost or 
> emphasized, to the determent of other questions. So to use your email as an 
> example, it would be awesome to see a email thread about "defrecord 
> reloading", one about "empty? and ints" and another about datomic's log 
> function. They all have different answers and it's hard to answer them all at 
> once. 
> 
> 3) Many things in Clojure seem random until you understand the reasoning 
> behind them. I hate telling people to go read the Clojure source, but I'll 
> say the more of it you read the more you will understand. Very few things in 
> Clojure are done without a reason, and some things that seem like bugs may 
> actually just be a misunderstanding of the basic concepts of the language. 
> 
> I once had a co-worker (who used Ruby a lot) say, "why does Python suck so 
> much?". After a conversation with him we both kindof realized it's not that 
> Ruby rocks and Python sucks, its simply a different set of tradeoffs and 
> optimizations that make each language unique. The same is true for Clojure. 
> Learning what those tradeoffs is, is very important. 
> 
> 4) Don't give up! I played with Clojure for about 2 years before becoming 
> comfortable with it. Don't be like me and throw it away every few months in 
> anger. Keep at it, please keep asking questions, and do so before you reach 
> the point of frustration. I've worked with more languages than I can 
> remember, but Clojure is the only one I've stuck with this long, simply 
> because it's that good. Not perfect, but more perfect (imo) than any other 
> language I've used. 
> 
> Hope this helps, 
> 
> Timothy
> 
>> On Sat, Jul 23, 2016 at 8:17 AM, Colin Yates  wrote:
>> Abstractions and dynamic/static typing are orthogonal. Static/dynamic
>> is simply _when_ types are considered. Strong/weak typing is arguably
>> more relevant and is about how narrowly type information is
>> considered.
>> 
>> I can't find an actual declaration but I consider Clojure is dynamic
>> but strongly typed. Some dynamically typed languages tend to be more
>> forgiving when asking questions and will guess at what you are asking
>> regardless of whether they are statically or dynamically typed, so
>> Ruby (sort of strongly typed) and JavaScript (weakly typed) have no
>> problem with asking if an Integer is empty.
>> 
>> Wow, that reads like I am lecturing down to somebody - apologies, that
>> isn't my intent. Half of the problem is that like 'Functional
>> Programming' there isn't really an authoritative definition of
>> 'strongly typed' or 'weakly typed' :-).
>> 
>> On 23 July 2016 at 14:15, 'Adrian A.' via Clojure
>>  wrote:
>> >
>> >
>> >> The point is that an 'Integer'
>> >> (abstraction) has no sense of 'emptiness' or 'fullness'.
>> >>
>> > IMHO that might be true for a statically typed language, but in the case of
>> > a dynamic language like Clojure it makes perfect sense, and most users
>> > expect
>> > this behavior.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to

Re: Frustrations so far

2016-07-23 Thread Colin Yates 
Abstractions and dynamic/static typing are orthogonal. Static/dynamic
is simply _when_ types are considered. Strong/weak typing is arguably
more relevant and is about how narrowly type information is
considered.

I can't find an actual declaration but I consider Clojure is dynamic
but strongly typed. Some dynamically typed languages tend to be more
forgiving when asking questions and will guess at what you are asking
regardless of whether they are statically or dynamically typed, so
Ruby (sort of strongly typed) and JavaScript (weakly typed) have no
problem with asking if an Integer is empty.

Wow, that reads like I am lecturing down to somebody - apologies, that
isn't my intent. Half of the problem is that like 'Functional
Programming' there isn't really an authoritative definition of
'strongly typed' or 'weakly typed' :-).

On 23 July 2016 at 14:15, 'Adrian A.' via Clojure
 wrote:
>
>
>> The point is that an 'Integer'
>> (abstraction) has no sense of 'emptiness' or 'fullness'.
>>
> IMHO that might be true for a statically typed language, but in the case of
> a dynamic language like Clojure it makes perfect sense, and most users
> expect
> this behavior.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Displaying functions generated for the REPL

2016-07-23 Thread Jason Felice 
If they are all in one namespace, you can use `ns-publics` on that
namespace ... e.g. `(ns-publics 'user)`.

On Sat, Jul 23, 2016 at 5:28 AM, Cecil Westerhof 
wrote:

> For a project I define some extra functions if it is started in the REPL.
> I like to know which extra functions there are in the REPL, so at the
> moment I am doing the following:
>(print (str "Defined REPL functions:\n"
>"- do-show-schemas\n"
>"- do-show-table [table]\n"
>"- do-show-tables\n"
>"- get-h2-version\n"
>"- get-random-quotes <[nr]>\n"
>)
>   )
>
> The problem with this is that every time I add or remove a function I need
> to change this print. Is there a way to generate this list? I probably lose
> the parameters, but for a long list of functions this could be handy.
>
> --
> Cecil Westerhof
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Frustrations so far

2016-07-23 Thread Ster Swade 


thanks,
wade

> On Jul 23, 2016, at 6:57 AM, Colin Yates  wrote:
> 
> As James said it is correct, but maybe not intuitive. Intuitively we
> think an integer isn't empty, but actually it is a non-sensical
> question - Integers can no more be empty than they can be full.
> 
> I noticed that Clojure's use of abstractions, and sticking to those
> abstractions is far greater than in other languages (I used at least)
> and getting on board with that really helps. Sure, you could ask _the
> data structure holding the value of an int_ whether it is 'full' in
> some sense, but that isn't the point. The point is that an 'Integer'
> (abstraction) has no sense of 'emptiness' or 'fullness'.
> 
>> On 22 July 2016 at 23:22, James Reeves  wrote:
>> On 22 July 2016 at 16:42, Peter Romfeld  wrote:
 
 
> 
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
 
 
 What should happen? Asking whether an integer or keyword is "empty?"
 doesn't really make sense IMO, and if it doesn't make sense, it should 
 throw
 an exception.
>>> 
>>> 
>>> well its a fn?... "?" ! i would only expect a boolean out of it, of course
>>> if you read doc and look implementation it makes sense what it does, i still
>>> think that a function called "empty?" should not throw up, if its an Number
>>> or Keyword its in my opinion not an empty value! (i understand that a Number
>>> or Keyword is not sequential.. but then call it "not-seq?")
>> 
>> 
>> I think your expectation is perhaps wrong in this case. Predicates should
>> throw an exception on invalid inputs. If you're passing a number or keyword
>> to `empty?` then there's an error in your code. Throwing an exception rather
>> than failing silently is absolutely the right thing to do.
>> 
>> The `empty?` function isn't particularly unusual in throwing exceptions.
>> `(pos? "foo")` will throw an error, as will `(> "foo" 1)`. If you pass an
>> input that doesn't make sense, then an exception should be thrown.
>> 
> security features in most frameworks are just smoke and mirrors,
> functions that dont actually do what they should do...
 
 
 Do you have an example?
>>> 
>>> 
>>> I dont want to make negative advertisement,  but its about csrf, and
>>> giving false sense of being taken care of for people who dont fully
>>> understand it
>> 
>> 
>> I maintain Ring-Anti-Forgery, so if it's anything to do with that, feel free
>> to raise a concern. Maybe the documentation can be improved.
>> 
>> - James
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Frustrations so far

2016-07-23 Thread Colin Yates 
As James said it is correct, but maybe not intuitive. Intuitively we
think an integer isn't empty, but actually it is a non-sensical
question - Integers can no more be empty than they can be full.

I noticed that Clojure's use of abstractions, and sticking to those
abstractions is far greater than in other languages (I used at least)
and getting on board with that really helps. Sure, you could ask _the
data structure holding the value of an int_ whether it is 'full' in
some sense, but that isn't the point. The point is that an 'Integer'
(abstraction) has no sense of 'emptiness' or 'fullness'.

On 22 July 2016 at 23:22, James Reeves  wrote:
> On 22 July 2016 at 16:42, Peter Romfeld  wrote:
>>>
>>>

 Im frustrated with `empty?` throwing exceptions for Long and Keyword
>>>
>>>
>>> What should happen? Asking whether an integer or keyword is "empty?"
>>> doesn't really make sense IMO, and if it doesn't make sense, it should throw
>>> an exception.
>>
>>
>> well its a fn?... "?" ! i would only expect a boolean out of it, of course
>> if you read doc and look implementation it makes sense what it does, i still
>> think that a function called "empty?" should not throw up, if its an Number
>> or Keyword its in my opinion not an empty value! (i understand that a Number
>> or Keyword is not sequential.. but then call it "not-seq?")
>
>
> I think your expectation is perhaps wrong in this case. Predicates should
> throw an exception on invalid inputs. If you're passing a number or keyword
> to `empty?` then there's an error in your code. Throwing an exception rather
> than failing silently is absolutely the right thing to do.
>
> The `empty?` function isn't particularly unusual in throwing exceptions.
> `(pos? "foo")` will throw an error, as will `(> "foo" 1)`. If you pass an
> input that doesn't make sense, then an exception should be thrown.
>
 security features in most frameworks are just smoke and mirrors,
 functions that dont actually do what they should do...
>>>
>>>
>>> Do you have an example?
>>
>>
>> I dont want to make negative advertisement,  but its about csrf, and
>> giving false sense of being taken care of for people who dont fully
>> understand it
>
>
> I maintain Ring-Anti-Forgery, so if it's anything to do with that, feel free
> to raise a concern. Maybe the documentation can be improved.
>
> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Frustrations so far

2016-07-23 Thread 'Adrian A.' via Clojure 


The point is that an 'Integer' 
> (abstraction) has no sense of 'emptiness' or 'fullness'. 
>
> IMHO that might be true for a statically typed language, but in the case 
of a dynamic language like Clojure it makes perfect sense, and most users 
expect
this behavior. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Displaying functions generated for the REPL

2016-07-23 Thread Cecil Westerhof 
For a project I define some extra functions if it is started in the REPL. I
like to know which extra functions there are in the REPL, so at the moment
I am doing the following:
   (print (str "Defined REPL functions:\n"
   "- do-show-schemas\n"
   "- do-show-table [table]\n"
   "- do-show-tables\n"
   "- get-h2-version\n"
   "- get-random-quotes <[nr]>\n"
   )
  )

The problem with this is that every time I add or remove a function I need
to change this print. Is there a way to generate this list? I probably lose
the parameters, but for a long list of functions this could be handy.

-- 
Cecil Westerhof

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Frustrations so far

2016-07-23 Thread mond 
You are not alone - it's the number one frustration in the community

https://www.reddit.com/r/Clojure/comments/433y02/state_of_clojure_2015_survey_results/

But also see the responses - maybe we will have some major improvements 
with 1.9. Spec looks like good infra to support those efforts for improving 
macro errors.

On a practical note - and it's not a 'solution'  - iterative development 
can helps since you can go usually go back to a known good position and 
work backwards. 

Like I say, not a great solution but might help to reduce the frustration.

Ray


On Friday, 22 July 2016 18:10:21 UTC+2, Peter Romfeld wrote:
>
> NPE is just so painful! most exceptions are not that easy to debug, would 
> be cool if it could say from where the problem was initiated.. (well 
> because most of the time i forget to print the stacktrace with 
> `print-stack-trace `)
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Prohibition of *1, *2, etc. with Clojure's assoc-in function

2016-07-23 Thread Michael Rice 
Why the prohibition?

Michael

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Prohibition of *1, *2, etc. with Clojure's assoc-in function

2016-07-23 Thread James Reeves 
What prohibition?

user=> {}
{}
user=> [:a]
[:a]
user=> 1
1
user=> (assoc-in *3 *2 *1)
{:a 1}

- James

On 23 July 2016 at 18:45, Michael Rice  wrote:

> Why the prohibition?
>
> Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.