New to Clojure - productivity and debugging with Emacs

[Chad Stovern]

Not much to add here, but if you're digging into Emacs and the modes you've 
listed, I've started to document my emacs config here: 
https://github.com/chadhs/dotfiles/blob/master/editors/emacs-config.org

If you're curious about common feature uses; head to the keybindings section 
and look at the cider and paredit areas.  (I'm still learning too so this is 
often evolving.)

Also for source control, I highly recommend taking a peek at "magit"; but not 
at the expense of slowing down your learning.  ^_^

- Chad

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

[Bill Piel]

The key to using sayid to capture curl requests is having emacs/cider 
connected to the same jvm instance that is running the web server. I did 
this by starting a repl with `lein repl`, then calling the -main function, 
which started the web server. From there, I used sayid to trace namespaces 
and finally, I made a request to the web server with curl. I may not be 
including the right details here. Let me know if you still have questions.



On Wednesday, January 11, 2017 at 3:32:31 PM UTC-5, ahawk wrote:
>
> 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

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

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 
> 

Re: New to Clojure - productivity and debugging with Emacs

[J.-F. Rompre]

Hi ahawk,

If you have the time, by all means reach for all the references and books 
mentioned in this thread, and there is a wealth of free resources out 
there. However doing both that and learning a powerful tool such as 
Emacs/CIDER at the same time can be frustrating. If time is of the essence 
and to both "learn by doing " the best practices and get tooling working 
for you ASAP, I would recommend Eric Normand's FunctionalTV courses 
  and Arne Brasseur's Lambda Island 
, in addition to pursuing your own learning 
projects and experimentations - they are not free services however. 

Personally, it took me months to learn enough of Emacs/CIDER to feel the 
rewards, but it was more than worth it, and I can't think of doing any work 
without it now. (I switched from vim thanks to evil-mode, and started off 
following the example in Brave Clojure 
.  



On Sunday, January 8, 2017 at 2:52:13 AM UTC-5, ahawk wrote:
>
> Hi everyone
>
> I am a rather unexperienced Clojure user, so please bear with me.
>
> I am developing a web app using popular libraries such as ring, compojure, 
> liberator and friend to handle routing, content negotiation and 
> authentication. There is quite a lot of map manipulation going on with the 
> request and response maps. To 
>
 

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

[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

[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

[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
spacemacs ;-).

Both tools will let you debug although to be honest, I haven't needed
to use a debugger in the 5+ years I have been contorting Clojure. In a
large part, because of the succinctness and small footprint of the
language, 'pure' forms and common idioms (sequences, sequences and
more sequences) you end up with a very small toolset which is
amazingly powerful.

Other essential tools are either leiningen or boot. Leiningen is the
'old guard' whereas boot is the newer one. Both are actively
maintained and developed but have different mindsets. Leiningen is
similar to maven; 'declare your project' and plugins use that
declaration as a source of truth. Boot is more like gradle, it is just
another Clojure program. Boot looks like the more flexible
but if you don't need that flexibility then leiningen will get you
started quicker 

[Summary]
If you are still reading this then congrats :-).

If you are new to LISP then SICP is a must. To get used to Clojure:
 - go and watch almost all of Rich Hickey's videos
 - get used to REPL development
 - get 

New to Clojure - productivity and debugging with Emacs

[ahawk]

Hi everyone

I am a rather unexperienced Clojure user, so please bear with me.

I am developing a web app using popular libraries such as ring, compojure, 
liberator and friend to handle routing, content negotiation and 
authentication. There is quite a lot of map manipulation going on with the 
request and response maps. To me, as an unexperienced Clojure user, the 
content of these maps is not very transparent as I code. What I am trying 
to say is that 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.

I am using various Emacs packages for productivity (see below), and while 
they are very helpful, the code is still not as transparent to me as a 
strongly typed language, where the IDE shows you exactly what type of data 
a function returns. Part of the problem is probably that I am only using a 
fraction of the functionality that these plugins provide or don't use the 
functionality properly:

   - clojure-mode
   - cider
   - paredit
   - rainbow-delimiters
   - rainbow-mode
   - eldoc
   - web-mode
   - clj-refactor

Questions: 
Based on the above, could you perhaps suggest any functionality in these or 
other packages, which could make the interaction (in lack of a better word) 
with other libraries more transparent to me?

Also, can you tell me if it is possible to debug a running Clojure web app 
with Ciders debugging feature, or something similar (with break points 
etc.)? So far I have only been able to use Ciders debugging feature on code 
running in my local REPL. Therefore, since I am developing a web app, I 
need to call my functions with mock requests.

Best regards
ahawk   

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