Re: Errors

On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote: > > Several of the Clojure/core folks have said at various times over the > years that Clojure is deliberately not optimized for novices, on the > grounds that whilst everyone starts out as a novice, most of your time >

Re: Tight coupling of spec implementation and function preconditions

I went ahead and logged this here so we don't lose it: http://dev.clojure.org/jira/browse/CLJ-2076 On Monday, December 5, 2016 at 12:01:27 PM UTC-6, Alex Miller wrote: > > > > On Monday, December 5, 2016 at 11:53:10 AM UTC-6, Tom Locke wrote: >> >> I haven't watched the keynote so I look

Re: Errors

On Monday, December 5, 2016 at 7:28:21 PM UTC-6, p...@pwjw.com wrote: > > Hi! > Hi Paul, > > Boy I really think you've all done a nice job with Clojure. I've used > quite a few environments over the years and clojure + CIDER + etc is a > great experience. The immutability and threading are

Re: Errors

On Tuesday, 6 December 2016 10:47:42 UTC+8, James Reeves wrote: > > On 6 December 2016 at 01:28, wrote: >> >> And the error messages are not good. >> >> So I was wondering: Is this a philosophical thing? Or is it an effort >> thing? And if it is an effort thing, is there some

Re: Errors

> I cherrypicked a case where the runtime difference would be tiny I wouldn’t be so sure of that. Adding any additional code to the function call logic is going to impact almost every single expression in Clojure and that “tiny” difference is going to add up pretty fast. As others have

Re: Errors

Yeah I understand that tradeoff. I cherrypicked a case where the runtime difference would be tiny but others are harder I’m sure. I guess I will go figure out how spec applies to my project. Thanks as always. This group is so responsive. Appreciated. - Paul > On Dec 5, 2016, at 9:46

Re: Errors

On 6 December 2016 at 01:28, wrote: > > And the error messages are not good. > > So I was wondering: Is this a philosophical thing? Or is it an effort > thing? And if it is an effort thing, is there some sort of plan for what > effort to put in? And if so, can I help by closing

Re: Errors

I think it has been rehashed often and core is very conservative about changes, but the current latest and greatest for improving many kinds of errors is going to be clojure.spec, which runs parallel to the actual execution path, so as not to effect things like performance or old code that depends

Errors

Hi! Boy I really think you've all done a nice job with Clojure. I've used quite a few environments over the years and clojure + CIDER + etc is a great experience. The immutability and threading are smart. I've been able to finish a hobby project in clojure which I've been mulling for a long

Re: Tight coupling of spec implementation and function preconditions

I haven't watched the keynote so I look forward to that. I sure Rich's arguments will convince me, as always! In my case I am spec'ing rather complex and deeply nested structures. The conformed values are changed all the way down. I have a bunch of functions to interrogate these structures in

Re: Tight coupling of spec implementation and function preconditions

On Monday, December 5, 2016 at 11:18:47 AM UTC-6, Tom Locke wrote: > > I'm sure this is a well known issue, but I've not found much written about > it online. > > In the spec guide, we have this example of spec'ing a function > > (s/fdef ranged-rand > :args (s/and (s/cat :start int? :end

Tight coupling of spec implementation and function preconditions

I'm sure this is a well known issue, but I've not found much written about it online. In the spec guide, we have this example of spec'ing a function (s/fdef ranged-rand :args (s/and (s/cat :start int? :end int?) #(< (:start %) (:end %))) ...) This form, an s/cat within an

Re: What does "Map literal must contain an even number of forms" mean?

This: (defn turd [] {:c "Turd" :d "More Turd"}) Would return this map: {:c "Turd" :d "More Turd"} This: (defn config [username password] {:u username :p *password*}) returns a map based on the function arguments. On Monday, December 5, 2016 at 10:41:33 AM UTC-5, larry google groups

Re: What does "Map literal must contain an even number of forms" mean?

This is all you need: {:c "Turd" :d "More Turd"} (defn turd [] {:c "Turd" :d "More Turd"}) On Sunday, December 4, 2016 at 4:03:04 PM UTC-5, bill nom nom wrote: > > ;; This works, > (hash-map :a 1 :b 2 ) > > > ;; Here's another way to create a hash map, this won't work because map > ;;

[ANN] data.xml 0.1.0-beta3

data.xml is a Clojure contrib library that parses and emits XML. Github: https://github.com/clojure/data.xml Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md Information on updating the dependency is here .

Call for Participation: BOB 2017 (February 24, Berlin)

Several Clojure talks at BOB - also, joint registration discounts with :clojureD, which is also in Berlin, on the very next day! BOB 2017 Conference "What happens if we simply use

Re: Clojure as a first programming language?

On 5 December 2016 at 02:56, 'Lee Spector' via Clojure < clojure@googlegroups.com> wrote: Colin Fleming has done some nice work on this in Cursive. > Sadly that work is not in Cursive proper yet, although I'm planning to get it in there soon once I work out what I'm doing with spec. However I

Re: What does "Map literal must contain an even number of forms" mean?

(hash-map :a 1 :b 2) is equivalent of {:a 1 :b 2} so this will work: {:c "Turd" :d "More Turd"} On Sunday, December 4, 2016 at 10:03:04 PM UTC+1, bill nom nom wrote: > > ;; This works, > (hash-map :a 1 :b 2 ) > > > ;; Here's another way to create a hash map, this won't work because map > ;;

ClojureScript talk

Here is the link to a talk I gave in the last Clojure Conj, about developing a web app with ClojureScript: https://www.youtube.com/watch?v=K6ZoF3CHsa0 Good for beginners and intermediates. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to