Re: Multimethods dispatch value order

[david swift]

Just lastly, I've seen people use the following structure of data
(def test-html {:language ::html :data "hello"})
and passing it as an argument to the mutlimethod, though not sure if it 
would or could apply to my case but when I use it simply returns nil under 
this condition
(transform test-html)

But I can do the following and produce a correct output, again not sure if 
it's to do my approach or not, or even if varargs doesn't allow it…
(transform {:language :html} "hello")



On Wednesday, 11 January 2017 22:47:02 UTC, Alex Miller wrote:
>
> Yes, multimethod handles varargs.
>
> On Wednesday, January 11, 2017 at 4:37:12 PM UTC-6, david swift wrote:
>>
>> Ah seems the repl state was the cause, restarted and the ordering worked 
>> correctly though it still confuses me greatly! but I'll get there 
>> eventually (I hope). as for the extra ')' that was manually retyping into 
>> forum error :) 
>>
>> Using nightcode editor's insta-repl for testing and seems it doesn't 
>> refresh the changes. Also does mutlimethod handle varargs? purely for 
>> testing purposes, doubt it'll be used but just incase
>>
>> On Wednesday, 11 January 2017 22:29:00 UTC, Alex Miller wrote:
>>>
>>>
>>>
>>> On Wednesday, January 11, 2017 at 4:23:28 PM UTC-6, david swift wrote:

 Been working on a tiny snippet of code related to multimethods 
 (something I've never quite wrapped my head around) and when it comes to 
 the dispatching of the function I'm confused by the order in which I've to 
 pass the arguments in as it seems to go against all common sense.

 To show what I am trying to do (to begin with); ignoring name 
 conflictions. Without implementing algorithm details I supply a simple 
 string for ease.
 (defmulti transform (fn [language data] language))

 (defmethod transform :html
[_ data]
(str data " will be transformed into html")))

>>>
>>> ^ extra ) at the end there fyi
>>>  
>>>


 (defmethod transform :java-fx
[_ data]
(str data " will be transformed into javafx"))

 What I would expect from this outcome would be to do the following on 
 dispatch
 (transform :html "some data") => "some data will be transformed into 
 html"

>>>
>>> This is what I see and that looks right to me. I suspect you somehow 
>>> have old method impls in your repl state. You should try with a fresh repl.
>>>  
>>>

 But instead the output I actually get ends up being
  "some data" 
 which I assume to be the default for mulitmethods to return the data 
 value. Though if I were to instead to change the order of the arguments 
 like so.

 (transform "some data" :html) => "some data will be transformed into 
 html"
 The expect outcome I wanted but not with the "correct" argument order I 
 was expecting, and to also note this (for me) prevents me from having more 
 than one argument and dispatch case.

>>>
>>> I get 
>>>
>>> IllegalArgumentException No method in multimethod 'transform' for 
>>> dispatch value: some data  clojure.lang.MultiFn.getFn (MultiFn.java:156)
>>>
>>>
>>> I know that I can do this approach
 (transform {:language :html} "some data")
 and it would work in the correct order but it's extra data I'm looking 
 to avoid for the sake of correct argument order

 Ideally I would of like the code to look something like below
 (defmulti transform :language)

 (defmethod transform :html
[data]
(str data " will be transformed into html"))

 (defmethod transform :java-fx
[data]
(str data " will be transformed into javafx"))

 I'd be grateful if someone could give me some simple examples to go by 
 that work by keyword dispatch that isn't foobaz, thank you :)

>>>

-- 
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: Multimethods dispatch value order

[Alex Miller]

Yes, multimethod handles varargs.

On Wednesday, January 11, 2017 at 4:37:12 PM UTC-6, david swift wrote:
>
> Ah seems the repl state was the cause, restarted and the ordering worked 
> correctly though it still confuses me greatly! but I'll get there 
> eventually (I hope). as for the extra ')' that was manually retyping into 
> forum error :) 
>
> Using nightcode editor's insta-repl for testing and seems it doesn't 
> refresh the changes. Also does mutlimethod handle varargs? purely for 
> testing purposes, doubt it'll be used but just incase
>
> On Wednesday, 11 January 2017 22:29:00 UTC, Alex Miller wrote:
>>
>>
>>
>> On Wednesday, January 11, 2017 at 4:23:28 PM UTC-6, david swift wrote:
>>>
>>> Been working on a tiny snippet of code related to multimethods 
>>> (something I've never quite wrapped my head around) and when it comes to 
>>> the dispatching of the function I'm confused by the order in which I've to 
>>> pass the arguments in as it seems to go against all common sense.
>>>
>>> To show what I am trying to do (to begin with); ignoring name 
>>> conflictions. Without implementing algorithm details I supply a simple 
>>> string for ease.
>>> (defmulti transform (fn [language data] language))
>>>
>>> (defmethod transform :html
>>>[_ data]
>>>(str data " will be transformed into html")))
>>>
>>
>> ^ extra ) at the end there fyi
>>  
>>
>>>
>>>
>>> (defmethod transform :java-fx
>>>[_ data]
>>>(str data " will be transformed into javafx"))
>>>
>>> What I would expect from this outcome would be to do the following on 
>>> dispatch
>>> (transform :html "some data") => "some data will be transformed into 
>>> html"
>>>
>>
>> This is what I see and that looks right to me. I suspect you somehow have 
>> old method impls in your repl state. You should try with a fresh repl.
>>  
>>
>>>
>>> But instead the output I actually get ends up being
>>>  "some data" 
>>> which I assume to be the default for mulitmethods to return the data 
>>> value. Though if I were to instead to change the order of the arguments 
>>> like so.
>>>
>>> (transform "some data" :html) => "some data will be transformed into 
>>> html"
>>> The expect outcome I wanted but not with the "correct" argument order I 
>>> was expecting, and to also note this (for me) prevents me from having more 
>>> than one argument and dispatch case.
>>>
>>
>> I get 
>>
>> IllegalArgumentException No method in multimethod 'transform' for 
>> dispatch value: some data  clojure.lang.MultiFn.getFn (MultiFn.java:156)
>>
>>
>> I know that I can do this approach
>>> (transform {:language :html} "some data")
>>> and it would work in the correct order but it's extra data I'm looking 
>>> to avoid for the sake of correct argument order
>>>
>>> Ideally I would of like the code to look something like below
>>> (defmulti transform :language)
>>>
>>> (defmethod transform :html
>>>[data]
>>>(str data " will be transformed into html"))
>>>
>>> (defmethod transform :java-fx
>>>[data]
>>>(str data " will be transformed into javafx"))
>>>
>>> I'd be grateful if someone could give me some simple examples to go by 
>>> that work by keyword dispatch that isn't foobaz, thank you :)
>>>
>>

-- 
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: Multimethods dispatch value order

[david swift]

Ah seems the repl state was the cause, restarted and the ordering worked 
correctly though it still confuses me greatly! but I'll get there 
eventually (I hope). as for the extra ')' that was manually retyping into 
forum error :) 

Using nightcode editor's insta-repl for testing and seems it doesn't 
refresh the changes. Also does mutlimethod handle varargs? purely for 
testing purposes, doubt it'll be used but just incase

On Wednesday, 11 January 2017 22:29:00 UTC, Alex Miller wrote:
>
>
>
> On Wednesday, January 11, 2017 at 4:23:28 PM UTC-6, david swift wrote:
>>
>> Been working on a tiny snippet of code related to multimethods (something 
>> I've never quite wrapped my head around) and when it comes to the 
>> dispatching of the function I'm confused by the order in which I've to pass 
>> the arguments in as it seems to go against all common sense.
>>
>> To show what I am trying to do (to begin with); ignoring name 
>> conflictions. Without implementing algorithm details I supply a simple 
>> string for ease.
>> (defmulti transform (fn [language data] language))
>>
>> (defmethod transform :html
>>[_ data]
>>(str data " will be transformed into html")))
>>
>
> ^ extra ) at the end there fyi
>  
>
>>
>>
>> (defmethod transform :java-fx
>>[_ data]
>>(str data " will be transformed into javafx"))
>>
>> What I would expect from this outcome would be to do the following on 
>> dispatch
>> (transform :html "some data") => "some data will be transformed into 
>> html"
>>
>
> This is what I see and that looks right to me. I suspect you somehow have 
> old method impls in your repl state. You should try with a fresh repl.
>  
>
>>
>> But instead the output I actually get ends up being
>>  "some data" 
>> which I assume to be the default for mulitmethods to return the data 
>> value. Though if I were to instead to change the order of the arguments 
>> like so.
>>
>> (transform "some data" :html) => "some data will be transformed into 
>> html"
>> The expect outcome I wanted but not with the "correct" argument order I 
>> was expecting, and to also note this (for me) prevents me from having more 
>> than one argument and dispatch case.
>>
>
> I get 
>
> IllegalArgumentException No method in multimethod 'transform' for dispatch 
> value: some data  clojure.lang.MultiFn.getFn (MultiFn.java:156)
>
>
> I know that I can do this approach
>> (transform {:language :html} "some data")
>> and it would work in the correct order but it's extra data I'm looking to 
>> avoid for the sake of correct argument order
>>
>> Ideally I would of like the code to look something like below
>> (defmulti transform :language)
>>
>> (defmethod transform :html
>>[data]
>>(str data " will be transformed into html"))
>>
>> (defmethod transform :java-fx
>>[data]
>>(str data " will be transformed into javafx"))
>>
>> I'd be grateful if someone could give me some simple examples to go by 
>> that work by keyword dispatch that isn't foobaz, thank you :)
>>
>

-- 
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: Multimethods dispatch value order

[Alex Miller]

On Wednesday, January 11, 2017 at 4:23:28 PM UTC-6, david swift wrote:
>
> Been working on a tiny snippet of code related to multimethods (something 
> I've never quite wrapped my head around) and when it comes to the 
> dispatching of the function I'm confused by the order in which I've to pass 
> the arguments in as it seems to go against all common sense.
>
> To show what I am trying to do (to begin with); ignoring name 
> conflictions. Without implementing algorithm details I supply a simple 
> string for ease.
> (defmulti transform (fn [language data] language))
>
> (defmethod transform :html
>[_ data]
>(str data " will be transformed into html")))
>

^ extra ) at the end there fyi
 

>
>
> (defmethod transform :java-fx
>[_ data]
>(str data " will be transformed into javafx"))
>
> What I would expect from this outcome would be to do the following on 
> dispatch
> (transform :html "some data") => "some data will be transformed into html"
>

This is what I see and that looks right to me. I suspect you somehow have 
old method impls in your repl state. You should try with a fresh repl.
 

>
> But instead the output I actually get ends up being
>  "some data" 
> which I assume to be the default for mulitmethods to return the data 
> value. Though if I were to instead to change the order of the arguments 
> like so.
>
> (transform "some data" :html) => "some data will be transformed into html"
> The expect outcome I wanted but not with the "correct" argument order I 
> was expecting, and to also note this (for me) prevents me from having more 
> than one argument and dispatch case.
>

I get 

IllegalArgumentException No method in multimethod 'transform' for dispatch 
value: some data  clojure.lang.MultiFn.getFn (MultiFn.java:156)


I know that I can do this approach
> (transform {:language :html} "some data")
> and it would work in the correct order but it's extra data I'm looking to 
> avoid for the sake of correct argument order
>
> Ideally I would of like the code to look something like below
> (defmulti transform :language)
>
> (defmethod transform :html
>[data]
>(str data " will be transformed into html"))
>
> (defmethod transform :java-fx
>[data]
>(str data " will be transformed into javafx"))
>
> I'd be grateful if someone could give me some simple examples to go by 
> that work by keyword dispatch that isn't foobaz, thank you :)
>

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

Multimethods dispatch value order

[david swift]

Been working on a tiny snippet of code related to multimethods (something 
I've never quite wrapped my head around) and when it comes to the 
dispatching of the function I'm confused by the order in which I've to pass 
the arguments in as it seems to go against all common sense.

To show what I am trying to do (to begin with); ignoring name conflictions. 
Without implementing algorithm details I supply a simple string for ease.
(defmulti transform (fn [language data] language))

(defmethod transform :html
   [_ data]
   (str data " will be transformed into html")))

(defmethod transform :java-fx
   [_ data]
   (str data " will be transformed into javafx"))

What I would expect from this outcome would be to do the following on 
dispatch
(transform :html "some data") => "some data will be transformed into html"

But instead the output I actually get ends up being
 "some data" 
which I assume to be the default for mulitmethods to return the data value. 
Though if I were to instead to change the order of the arguments like so.

(transform "some data" :html) => "some data will be transformed into html"
The expect outcome I wanted but not with the "correct" argument order I was 
expecting, and to also note this (for me) prevents me from having more than 
one argument and dispatch case.

I know that I can do this approach
(transform {:language :html} "some data")
and it would work in the correct order but it's extra data I'm looking to 
avoid for the sake of correct argument order

Ideally I would of like the code to look something like below
(defmulti transform :language)

(defmethod transform :html
   [data]
   (str data " will be transformed into html"))

(defmethod transform :java-fx
   [data]
   (str data " will be transformed into javafx"))

I'd be grateful if someone could give me some simple examples to go by that 
work by keyword dispatch that isn't foobaz, thank you :)

-- 
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: New to Clojure - productivity and debugging with Emacs

[Colin Yates]

The big barrier for me with emacs was discovering and then remembering
all of the various finger-bending chords to do things. Spacemacs uses
hydra so all the key mappings are grouped in a very logical way. Have
a read of http://spacemacs.org, particularly the horizontal image
slide show.

But yeah, spacemacs was a breath of fresh air - and if you like vim it
gets even better :-).

On 11 January 2017 at 20:09, ahawk  wrote:
> Thanks a lot for the very elaborate reply.
>
> I should probably buy SICP.
>
> With regards to discovery, I will have a closer look at clojure.spec. It
> looks interesting. I've previously (perhaps wrongfully) discarded Prismatic
> Schema, thinking something like "don't you really just want static types?"
> (which is apparently not the case according to this background info:
> http://plumatic.github.io/schema-for-clojurescript-data-shape-declaration-and-validation/).
> Anyway, some of these libraries seem like they try to mix Clojure with ideas
> derived from other languages. I would like to learn to develop Clojure
> productively in an idiomatic way.
>
> With regards to developer tools, spacemacs seems interesting. What do you
> mean by keymap discoverability?
>
> Den søndag den 8. januar 2017 kl. 10.52.55 UTC+1 skrev Colin Yates:
>>
>> Hi ahawk and welcome to Clojure!
>>
>> Your question seems to cover multiple domains:
>>  - navigating/discovery in non-statically typed languages, specifically
>> Clojure
>>  - developing in Clojure
>>  - developer tools (e.g. IDE for Clojure)
>>
>> (I can feel a stream of consciousness/ramble coming so so this might
>> take a while; settle in ;-)).
>>
>> [discovery]
>> Clojure apps tend to prefer data over functions, so the data itself
>> becomes part of the API. The notion of 'it's just a map' is very
>> prevalent. How is that addressed? Well, it typically comes down to:
>>  - ad-hoc documentation of the shapes
>>  - pre/post conditions (not very scalable but works OOTB)
>>  - Plumatic (previously known as Prismatic) Schema became the de-facto
>> standard for describing and asserting conformity to a given shape at
>> runtime
>>  - core.typed was an attempt to apply static typing that could be
>> validated as a compilation step. I am not sure it was as wildly
>> successful in terms of implementation as it was as an intriguing
>> possibility?
>>  - core.spec - a new, blessed and very exciting part of Clojure v1.9
>> which promises to bring the power of Clojure to creating 'specs' that
>> your data but follow. It also has the very neat trick of producing
>> generators (for property based testing) from those specs. I haven't
>> used this in anger, but like all the best things Clojure it promises
>> to bring simplicity to a previously complex and convoluted space. Very
>> interested to see how this plays out.
>>
>> None of that addressed your question of "how do I know what to expect"
>> _unless_ the tool author has documented it. I would expect more and
>> more libraries to ship with Clojure specs over time (although there is
>> some controversy over this).
>>
>> The other common thing to expect is lots of data-driven unit tests
>> which can also document your code. Clojure's preference of pure forms
>> makes this much more feasible.
>>
>> You mention looking at the source, yeah, that is another assumed tool
>> developers will employ. The nice thing is that Clojure, being such a
>> 'small' language has quite a low barrier to entry so reading other's
>> source code becomes quite efficient quite quickly.
>>
>> Unfortunately, the lack of a blessed code style and the rush of OO
>> developers moving to Clojure _without_ reading SICP (yeah, I'm talking
>> about me) means some of the code might make your eyes bleed.
>>
>> [developing in Clojure]
>> Briefly:
>>  - data over forms
>>  - no global state/pure forms
>>  - REPL, REPL and more REPL
>>
>> Rich Hickey did a great talk about 'systems' development rather than
>> 'function' (that isn't right but I can't remember the exact phrasing)
>> development where in LISP you build a living system made up of lots of
>> living components. In other languages you build chunks of code.
>>
>> This mindset, coupled with the desire for 'pure' forms makes the REPL
>> an indispensable and incredibly powerful tool.
>>
>> In other languages (e.g. Java) you don't have a living system, you
>> have a bunch of small chunks of code and you frequently start/stop
>> that system. In Clojure you start the REPL once and then build the
>> system over time. That won't make sense until it does :-).
>>
>> Yeah, there is much more I could write about this but it is long enough
>>
>> [developer tools]
>> If you are an emacs developer then CIDER and clj-refactor is an
>> incredibly powerful toolset. If you haven't already looked then
>> checkout spacemacs as well, just for the keymap discoverability if
>> nothing else.
>>
>> Cursive an IntelliJ plugin is also fantastic and brings a lot of the
>> power of IntelliJ to Clojure. Code navigation, re

Re: New to Clojure - productivity and debugging with Emacs

[ahawk]

Thanks a lot for your reply.

I saw the video of your presentation and it seems like your tool is exactly 
what I am looking for. I've actually installed the package in Emacs and 
configured the Emacs/CIDER integration, but I haven't gotten to try it 
thoroughly just yet.

In your video, you demonstrate using sayid to debug curl requests, but it 
is unclear to me how you make this happen. If you have the time, please 
elaborate. It would be very helpful to me to be able to log http requests 
originating from curl or a browser.

Den mandag den 9. januar 2017 kl. 13.24.26 UTC+1 skrev Bill Piel:
>
> ahawk,
>
> I've been using clojure for years, but can still relate to the issues you 
> are facing, which is why I wrote a debugging/development tool to help. It's 
> called sayid. It can be used directly from the repl, but has an emacs/cider 
> integration that makes it much more powerful. 
>
> http://bpiel.github.io/sayid/
>
> In a nutshell, sayid will let you capture all the args and return values 
> from functions as they are executed -- then allow you to inspect, query and 
> visualize them. The project is still in alpha and not thoroughly 
> documented, so if you do decide to try it out and run into any issues, 
> PLEASE get in touch by filing an issue or even emailing me. My address is 
> on my github profile.
>
> https://github.com/bpiel
>
> Also, I presented it at the last Conj conference in Austin.  
> https://www.youtube.com/watch?v=ipDhvd1NsmE
>
>
>
>
>
>
>
>
> On Sunday, January 8, 2017 at 11:06:34 AM UTC-5, Matching Socks wrote:
>>
>> That is an ambitious project.  Divide and conquer.  One super duper 
>> benefit of Clojure is that if you make a web app with, say, just Ring and 
>> Compojure, you can later transplant that work into a more elaborate app 
>> scaffolding, because it's all just plain maps.
>>
>> "quite a lot of map manipulation going on with the request and response 
>> maps"
>>
>> On the bright side, map manipulation is *all* that is going on.  There 
>> are no side effects.  Therefore, it can be very helpful to log the request 
>> and response maps.  For example, make a Ring handler that does nothing but 
>> log the request, delegate to the next handler, log its response, and return 
>> its response; then stick that handler wherever in the handler stack makes 
>> you curious.  Using the Emacs CIDER REPL you may change the handler stack 
>> and fiddle with logging while the program runs, so logging is a convenient 
>> debugging technique.
>>
>> "unless, of course, I read and understand their source"
>>
>> On the bright side again, there is not much source code there, at least 
>> compared with what you'd expect in Java.  Also, the jar that Maven (etc) 
>> can fetch for you *is* the source code, and Emacs can open such jars and 
>> browse the files inside.  
>>
>> Some of the libraries have overview documentation that puts the API docs 
>> in context.  Keep the Ring SPEC open, and the Liberator graph too if you 
>> can figure out how to view more than a tiny bit of it.
>>
>> By all means point out gaps in the docs on the libraries' respective 
>> issue trackers.
>>
>

-- 
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: New to Clojure - productivity and debugging with Emacs

[Gregg Reynolds]

On Jan 8, 2017 1:52 AM, "ahawk"  wrote:



..  I find it difficult to know exactly what to expect from these libraries
and many other, unless, of course, I read and understand their source. That
is a challenge in its own right for a less advanced programmer such as
myself.


The good news is that if you stick with it you will rapidly begin to get
the knack f reading Closure source.  That's one of the hidden benefits of
Clojure: there are only so many patterns in practice, and you will begin to
quickly recognize them.

Before clojure:

"Where's the doc?"  "No doc, read the source."  " I'd rather chew my leg
off. "

After Clojure:

"Where's the source?"  "You don need it, we have wonderful docs, only a
little outdated." "I'd rather chew my leg off."

gregg

-- 
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: New to Clojure - productivity and debugging with Emacs

[ahawk]

I guess you're right.. however, I'm generally inclined to try to do it the 
right way (or, what I perceive as the right way) the first time. Now I know 
liberator exists, I feel an urge to use it :-)

With regards to logging, I actually considered that option, but it just 
didn't seem very productive to me compared to the debugging features I've 
been used to from doing OOP years ago.

Den søndag den 8. januar 2017 kl. 17.06.34 UTC+1 skrev Matching Socks:
>
> That is an ambitious project.  Divide and conquer.  One super duper 
> benefit of Clojure is that if you make a web app with, say, just Ring and 
> Compojure, you can later transplant that work into a more elaborate app 
> scaffolding, because it's all just plain maps.
>
> "quite a lot of map manipulation going on with the request and response 
> maps"
>
> On the bright side, map manipulation is *all* that is going on.  There are 
> no side effects.  Therefore, it can be very helpful to log the request and 
> response maps.  For example, make a Ring handler that does nothing but log 
> the request, delegate to the next handler, log its response, and return its 
> response; then stick that handler wherever in the handler stack makes you 
> curious.  Using the Emacs CIDER REPL you may change the handler stack and 
> fiddle with logging while the program runs, so logging is a convenient 
> debugging technique.
>
> "unless, of course, I read and understand their source"
>
> On the bright side again, there is not much source code there, at least 
> compared with what you'd expect in Java.  Also, the jar that Maven (etc) 
> can fetch for you *is* the source code, and Emacs can open such jars and 
> browse the files inside.  
>
> Some of the libraries have overview documentation that puts the API docs 
> in context.  Keep the Ring SPEC open, and the Liberator graph too if you 
> can figure out how to view more than a tiny bit of it.
>
> By all means point out gaps in the docs on the libraries' respective issue 
> trackers.
>

-- 
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: New to Clojure - productivity and debugging with Emacs

[ahawk]

Thanks a lot for the very elaborate reply. 

I should probably buy SICP.

With regards to discovery, I will have a closer look at clojure.spec. It 
looks interesting. I've previously (perhaps wrongfully) discarded Prismatic 
Schema, thinking something like "don't you really just want static types?" 
(which is apparently not the case according to this background info: 
http://plumatic.github.io/schema-for-clojurescript-data-shape-declaration-and-validation/).
 
Anyway, some of these libraries seem like they try to mix Clojure with 
ideas derived from other languages. I would like to learn to develop 
Clojure productively in an idiomatic way.

With regards to developer tools, spacemacs seems interesting. What do you 
mean by keymap discoverability?

Den søndag den 8. januar 2017 kl. 10.52.55 UTC+1 skrev Colin Yates:
>
> Hi ahawk and welcome to Clojure! 
>
> Your question seems to cover multiple domains: 
>  - navigating/discovery in non-statically typed languages, specifically 
> Clojure 
>  - developing in Clojure 
>  - developer tools (e.g. IDE for Clojure) 
>
> (I can feel a stream of consciousness/ramble coming so so this might 
> take a while; settle in ;-)). 
>
> [discovery] 
> Clojure apps tend to prefer data over functions, so the data itself 
> becomes part of the API. The notion of 'it's just a map' is very 
> prevalent. How is that addressed? Well, it typically comes down to: 
>  - ad-hoc documentation of the shapes 
>  - pre/post conditions (not very scalable but works OOTB) 
>  - Plumatic (previously known as Prismatic) Schema became the de-facto 
> standard for describing and asserting conformity to a given shape at 
> runtime 
>  - core.typed was an attempt to apply static typing that could be 
> validated as a compilation step. I am not sure it was as wildly 
> successful in terms of implementation as it was as an intriguing 
> possibility? 
>  - core.spec - a new, blessed and very exciting part of Clojure v1.9 
> which promises to bring the power of Clojure to creating 'specs' that 
> your data but follow. It also has the very neat trick of producing 
> generators (for property based testing) from those specs. I haven't 
> used this in anger, but like all the best things Clojure it promises 
> to bring simplicity to a previously complex and convoluted space. Very 
> interested to see how this plays out. 
>
> None of that addressed your question of "how do I know what to expect" 
> _unless_ the tool author has documented it. I would expect more and 
> more libraries to ship with Clojure specs over time (although there is 
> some controversy over this). 
>
> The other common thing to expect is lots of data-driven unit tests 
> which can also document your code. Clojure's preference of pure forms 
> makes this much more feasible. 
>
> You mention looking at the source, yeah, that is another assumed tool 
> developers will employ. The nice thing is that Clojure, being such a 
> 'small' language has quite a low barrier to entry so reading other's 
> source code becomes quite efficient quite quickly. 
>
> Unfortunately, the lack of a blessed code style and the rush of OO 
> developers moving to Clojure _without_ reading SICP (yeah, I'm talking 
> about me) means some of the code might make your eyes bleed. 
>
> [developing in Clojure] 
> Briefly: 
>  - data over forms 
>  - no global state/pure forms 
>  - REPL, REPL and more REPL 
>
> Rich Hickey did a great talk about 'systems' development rather than 
> 'function' (that isn't right but I can't remember the exact phrasing) 
> development where in LISP you build a living system made up of lots of 
> living components. In other languages you build chunks of code. 
>
> This mindset, coupled with the desire for 'pure' forms makes the REPL 
> an indispensable and incredibly powerful tool. 
>
> In other languages (e.g. Java) you don't have a living system, you 
> have a bunch of small chunks of code and you frequently start/stop 
> that system. In Clojure you start the REPL once and then build the 
> system over time. That won't make sense until it does :-). 
>
> Yeah, there is much more I could write about this but it is long enough 
>
> [developer tools] 
> If you are an emacs developer then CIDER and clj-refactor is an 
> incredibly powerful toolset. If you haven't already looked then 
> checkout spacemacs as well, just for the keymap discoverability if 
> nothing else. 
>
> Cursive an IntelliJ plugin is also fantastic and brings a lot of the 
> power of IntelliJ to Clojure. Code navigation, refactoring etc. Colin 
> (Flemming) has done a _great_ job. 
>
> I, like a bunch of people I expect do both. I use space macs 90% of 
> the time and then occasionally throw the project into Cursive to find 
> unused code and other polishings. 
>
> You could live in exclusively emacs or Cursive perfectly happily, but 
> both brings to spoils I think. There are a bunch of other IDEish 
> tools; NightCode, CounterClockwise etc. I lost track since finding 
> space

Re: Private multimethods possible?

[Didier]

Maybe you're right in not recommending this, but I find it at first glance to 
be quite nice. Now, I wouldn't keep switching namespace back and forth, but 
having two sections in the file, one the public API at the top, and everything 
else at the bottom in a private namespace, that's quite nice I'd say. 

I hate juggling through files, like C++ header and body files annoy me a lot.

-- 
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: [ANN] Ultra v0.5.1 - a Leiningen plugin for a superior development environment

[Mars0i]

David, thanks very much for the quick reply. (!)  OK, got it now.  

update-options! will be useful because sometimes I have a lot of state set 
up within the repl and then realize that I want to change the size of the 
terminal window to see more data at once (or to see more windows at once).

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

[ANN] re-learn: data-driven tutorials for educating users of your reagent/re-frame app

[Oliver Hine]

Hi everyone,

I have released re-learn , a library for 
writing and displaying tutorials to your users on your reagent/re-frame 
application with the following aims:

   - Display "lessons" on the UI right next to the elements they describe
   - Define the lessons as data right next to the code that creates the 
   elements
   - Support incremental introduction of new features to existing users
   - Work with UIs built with React and require no dom manipulation or 
   special markup

I have explained the rationale in more detail in a JUXT blog post at 
https://juxt.pro/blog/posts/re-learn.html

You can check out the library on github at https://github.com/oliyh/re-learn

There is a live demo at https://oliyh.github.io/re-learn/ which you can 
try, or the following animation (hope this works!) shows some of the 
features:




I hope someone will find this useful. There are more features to come, see 
the issues on Github for an idea or feel free to submit any of your own 
wishes.

Thanks
Oliy


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