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