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 <aho...@gmail.com> 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, 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. <flame suit>Boot looks like the more flexible >> but if you don't need that flexibility then leiningen will get you >> started quicker </flame suit> >> >> [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 used to reading source code >> - go and read the core docs, almost everything you need is there. >> Zippers are also more useful than you might think. >> - go and read the core docs again >> - pure forms changing data rather than a blob of code offering >> functionality. Although old, >> >> http://thinkrelevance.com/blog/2009/08/12/rifle-oriented-programming-with-clojure-2 >> is still a great read here >> >> here endeth the ramble. >> >> On 8 January 2017 at 07:47, ahawk <aho...@gmail.com> 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 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 clo...@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+u...@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+u...@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.
