Re: Frustrations so far

[Didier]

*1) Slow startup speed.*

Everyone dislikes the slow startup speed. Though it's been argued that it 
should be known as the Clojure slow startup speed. Since even though the 
JVM is slower to start then say python, most of the slowness comes from the 
Clojure overhead.

*I know this problem is being addressed by the Clojure supporters, but its 
a hard one to solve, all I can say is that its improved version after 
version.*

*2) Slow dependency resolution*

It doesn't sound like an issue with Clojure. Can you elaborate? Are you 
complaining about Leiningen being slow, or just that having to download 
dependencies is slow? Either way, this is probably more of a JVM issue, or 
even a tooling issue, you could look into alternate tooling.

*Not a Clojure related problem.*

*3) `empty?` doesn't behave as I intuitively interpret the name of it*

One thing you should embrace in Clojure, is that part of why its so awesome 
is that you are not as restricted by the limitations of the language as 
with other languages. So if you don't like empty? throwing exceptions for 
Long and Keyword, you can re-def your own empty? which catches those and 
returns false or true (whatever behavior you want) instead.

As some people have said before, a lot of the functions have good reason to 
behave as they do, but sometimes its not as intuitive from the name or form 
people's expectations. The doc mentions: "Returns true if coll has no items 
- same as (not (seq coll)). Please use the idiom (seq x) rather than (not 
(empty? x))" I'd be curious if anyone knows what is the idea behind empty? 
and why the doc mentions to use the idiom (seq x) when there is also a 
not-empty fn in core.

As an example, I struggled with `contains?` for a while. Couldn't figure 
out why they decided to make this: `(contains? [:a :b :c] :a)` return 
false. Why they chose to make contains? check for the existence of the 
index on a vector. Then I learned that the use-case behind `contains?` is 
to verify that a call to `get` will succeed. Once I learned that I was 
like... make total sense. So I wrote myself a `contains-val?` for the 
use-case I was having and done. I'm sure there's similar reasoning for 
`empty?`

*So I'd say this is not a Clojure related problem, though maybe there's a 
little issue with the names of functions having similar names then other 
popular languages and not behaving the same way.*

*4) Maps are unordered by default*

Maps are unordered from the theory itself. Don't ever expect Maps to be 
ordered, unless its very explicitly stated. Ordered Maps have different 
time/space characteristics too, which is why Maps are unordered by default. 
This isn't anything to do with Clojure. You should try and get more 
familiar with the formal literature on common data structures, as its what 
most languages build upon.

*Not a Clojure related problem.*

*5) Reloading has some quirks*

Clojure gives you so much reloading-ability with its REPL centric 
development process, that it plays against it when it fails, we get really 
upset. Its almost like the uncanny valley of reloading. You can search for 
reloaded workflows though, some people have apparently figured out ways to 
organize your code so that everything can be reloaded without ever failing 
or having to restart the REPL.

*This problem relates to Clojure, but also to Lisp in general, and I don't 
think its solvable without constraining the language too much.*

*6) Cryptic official doc*

I thought the official doc was very cryptic at first too, but over time, I 
got used to the way its documented, and I can now figure out how to use 
almost all functions just from the official doc. So I'd say this is just a 
matter of time and experience with the nomenclature and the way its 
explained. But I agree, its not meant for people just starting off with 
Clojure. I recommend clojuredocs for a more beginner friendly doc.

*Clojure could try to add a bit of a friendlier doc to its official doc.*

On Wednesday, 20 July 2016 05:54:27 UTC-7, Peter Romfeld wrote:
>
> I really love clojure over all, it makes maintenance/collaboration of code 
> such a breeze. its easy to get new employees start to work on it even 
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch 
> deps on a aws medium instance (you probably can fix it with uberjars)
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
> Not complete clojure, but i hate datomic.api/log since you cant put into 
> your tests with a in-mem db
> I had some issues understanding that maps of certain size are not in order 
> anymore because of the underlying java functions and optimizations 
> Im a bit upset about development reload with defrecords
> most of the things that are not documented by the community are documented 
> very cryptic and hard to understand
> the api docs are almost useless! - to get the arrity and stuff.. wtf i 
> still have no clue how to use 

Re: Frustrations so far

[Stuart Halloway]

Hi Peter,

The latest release of Datomic (0.9.5390) includes the addition of the Log
API for memory-backed databases.
https://groups.google.com/d/topic/datomic/QLdZ_WePR5A/discussion.

Hope this and some of other items on this thread will combine to improve
your experience with Clojure.

Regards,
Stu

On Wed, Jul 20, 2016 at 8:49 AM, Peter Romfeld 
wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
> Not complete clojure, but i hate datomic.api/log since you cant put into
> your tests with a in-mem db
> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
> Im a bit upset about development reload with defrecords
> most of the things that are not documented by the community are documented
> very cryptic and hard to understand
> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>
> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>
> cheers,
> peter
>
> --
> 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

[Paul deGrandis]

Similar to James'  ring-anti-forgery message,
as the maintainer of Pedestal, I'd also like to know if you had issues with 
Pedestal (specifically, on the Pedestal mailing list 
).  In general, I 
think most maintainers want to know about shortcomings, missteps, or 
security risks.

--Paul

-- 
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

[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

[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: Frustrations so far

[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: Frustrations so far

[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

['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.

Re: Frustrations so far

[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

[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.

Re: Frustrations so far

[James Reeves]

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.

Re: Frustrations so far

[Peter Romfeld]

On Saturday, July 23, 2016 at 12:01:40 AM UTC+8, raould wrote:
>
> Unfortunately, dynamically typed most often means what you are 
> experiencing, as far as I know. Python, JavaScript, Scheme, Lua, etc. all 
> have something like NPE that can happen at any random time, it feels like, 
> no?
>

im sorry i have little experience with other langs.. just learned the 
basics in python for scripting when i was still sysadmin.. then i did 
elixir for a short while.. and almost all of my developer time is in 
clojure.. 

-- 
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

[Peter Romfeld]

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.

RE: Frustrations so far

[Raoul Duke]

Unfortunately, dynamically typed most often means what you are experiencing, as 
far as I know. Python, JavaScript, Scheme, Lua, etc. all have something like 
NPE that can happen at any random time, it feels like, no?

-- 
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

[Peter Romfeld]

I dont wanna go into the problems we have with this "dynamic typesystem" 
where you would think it takes care of different types in different 
functions, but in the end you just get NullPointerExceptions and waste half 
a day figuring out from where it comes from

-- 
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

[Peter Romfeld]

>
>  
>
>> 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 had some issues understanding that maps of certain size are not in 
>> order anymore because of the underlying java functions and optimizations 
>>
>
> Maps are officially unordered. The fact that small maps are ordered is an 
> implementation detail (though one that I know trips up a lot of newcomers).
>

Yeah kinda hard to figure out, special if you have 0 Java background
 

>  
>
>> the api docs are almost useless! - to get the arrity and stuff.. wtf i 
>> still have no clue how to use this new function i never used before...
>>
>
> Do you have an example of a poorly documented function? Also, do you know 
> about https://clojuredocs.org/?
>

I dont remember right now and too lazy (it was something without community 
examples), and then you just see maybe a cryptic docstring and what 
arguments it accepts 

 
>
>> 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

cheers,
peter

>

-- 
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

[Alan Thompson]

Hi Peter - I started the Tupelo library 
and related Tupelo-Datomic library
 in order to collect helper &
convenience functions that I felt were missing (IMHO) from core Clojure.
If you have any ideas to add or improve them, please let me know!
Bye,
Alan


On Wed, Jul 20, 2016 at 5:49 AM, Peter Romfeld 
wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
> Not complete clojure, but i hate datomic.api/log since you cant put into
> your tests with a in-mem db
> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
> Im a bit upset about development reload with defrecords
> most of the things that are not documented by the community are documented
> very cryptic and hard to understand
> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>
> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>
> cheers,
> peter
>
> --
> 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

[James Reeves]

On 20 July 2016 at 13:49, Peter Romfeld  wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
>

To my mind, uberjars are the better way of deploying as they guarantee a
fixed binary, and you only have to build them once.


> 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.


> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
>

Maps are officially unordered. The fact that small maps are ordered is an
implementation detail (though one that I know trips up a lot of newcomers).


> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
>

Do you have an example of a poorly documented function? Also, do you know
about https://clojuredocs.org/?


> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>

Do you have an example?


> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>

Thanks for taking the trouble to post :)

- 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.

Frustrations so far

[Peter Romfeld]

I really love clojure over all, it makes maintenance/collaboration of code 
such a breeze. its easy to get new employees start to work on it even 
without any previous clojure knowledge!

I do hate the JVM startup shit, i hate how you it takes forever to fetch 
deps on a aws medium instance (you probably can fix it with uberjars)
Im frustrated with `empty?` throwing exceptions for Long and Keyword
Not complete clojure, but i hate datomic.api/log since you cant put into 
your tests with a in-mem db
I had some issues understanding that maps of certain size are not in order 
anymore because of the underlying java functions and optimizations 
Im a bit upset about development reload with defrecords
most of the things that are not documented by the community are documented 
very cryptic and hard to understand
the api docs are almost useless! - to get the arrity and stuff.. wtf i 
still have no clue how to use this new function i never used before...
security features in most frameworks are just smoke and mirrors, functions 
that dont actually do what they should do...

anyways, if i remember more i can add...
just wanted to give you guys some input, and looking forward to make 
development experience even better!

cheers,
peter

-- 
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.