Re: Clojure Literature
I started clojure right at the point where contrib changed. I think I had a lot less problems than did many who had already started and were use to the old setup. I didn't mention the contrib change because it was long before the dates the OP was talking about, because none of the books I mentioned (except 1st editonn of Stuart's book) are based on anything pre 1.3 and because while the change to how contrib was structured may cause some little confusion, it is not a change in the language. All the core language constructs and basic concepts are the same. Of course, anyone who is using a book where it states it was written against an earlier version of the language than the current version they are using would be wise to check the release notes and summary of what has changed in the versions between the one the book used and the one they are using. Doesn't do any real harm to force some early problem solving anyway - certainly helps cement your knowledge and understanding. What would be a shame is to dismiss an otherwise good text simply because it was written for an older version. Imagine a C programmer not reading KR simply because it was written for an old version of C@ Tim On Saturday, January 19, 2013 1:46:14 AM UTC+11, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- 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
Re: How to (easily) show the advantages of Clojure
I think it depends a lot on your audience. For example, java spring programmers are likely going to be impressed by the simplicity and speed at which you can get a project started, especially when using lein and being able to avoid the common load of bolerplate java, xml, etc. Programmers familiar with database development etc, may appreciate the STM more, lisp programmers will likely be impressed by how easy it is to take advantage of the huge wealth of existing Java APIs and managers may be impressed by the fact things can be deployed under the existing ecosystem. There is no single answer, but a little research into what type of audience you are addressing will help. Try and find out what some of the current 'pain points' are with their current environment. This could be testing, it could be deployment, it could be the ability to make rapid changes, handle concurrency issues, prototyping, cumbersome code, build test cycles etc. If you know this, you can structure examples that will clearly show the relevance and likely generate some excitement etc. Tim On Thursday, January 17, 2013 2:08:41 AM UTC+11, Thomas wrote: Hi All, Something that came up last night in the blank? thread. What is a good way to show someone the advantages of Clojure. Something that is simple, not too complicated, easily understood, shows a (significant) benefit, etc. Any ideas? (As said in the other thread, I have used the blank? example from Stuart Halloway to show people the difference). Thomas -- 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
Re: Clojure Literature
The books I've found valuable are Clojure Programming. Really liked this book because it just fitted well with my preferred style of book. Really enjoyed it and found that often, just as I was asking myself a question, the answer was in the next paragraph. Joy of Clojure. Excellent book. Possibly not a great first book, but absolutely a must once you have read one of the others and you really want to get a deeper understanding. I have returned to sections on this book a number of times and get something out of it each time. Really helps with the deeper knowledge I think you need for real projects. Programming Clojure. This was the first book I read. A good starting point (have only read 1st edition). Has enough to get you started, but avoids getting you too bogged down, so you feel like your making progress. I also have a copy of the new clojureScript book from O'Reilly, but have not read it yet. I wouldn't worry too much about differences because a book was written for clojure 1.2 or 1.3 even though 1.5 is only just around the corner. The differences are minor and tend to be most directly related to more advanced topics that are unlikely to be of critical importance to begin with. Once you have covered the content in these books, you will pick up the minor differences in later versions easily enough. Probably more important is to use Lein 2.0 right from the start and ensure you spend as much time trying to cut clojure code as reading about cutting clojure code! have fun. Tim On Saturday, January 19, 2013 1:46:14 AM UTC+11, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- 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
Re: Full stack Clojure web/REST framework - is there any mileage in it?
A good thought/discussion provoking post, thanks. I find myself between two camps here. On one side and coming from the position of both learning Clojure and coming back to web development after a long period of mainly working on large backend database apps, the suggestion of a nicely bundled and complete clojure web framework is appealing. On the other hand, having been required to become familiar with some frameworks, such as spring, being forced to search through large quantities of documentation and then finding 80% of what it offered was not relevant to what I needed for my application, I'm far less enthusiastic regarding complete frameworks. I think there may be two different requirements here which need addressing. The first is for those, often new to clojure, who would like to get up and running fast. They have a new idea to start developing and don't want to spend hours evaluating lots of different, but outwardly similar libraries - especially as they may not yet have the knowledge to easily make such decisions. The second requirement is for more experienced or knowledgable devs or those who have a well defined design who just need to know which specific libraries to use. I suspect that as you gain web dev experience with clojure, you will move more twards the second group. If this is the case, complete frameworks are likely to be of only limited benefit while you become familiar and experienced. This may asiist adoption to some degree. However, as individuals become more experenced and accustomed to a more clojure style philosophy of fewer and more specific libraries for a task, they will likely move away from the framework. Unfortunately, this may have a detremental impact on the maintenance of such a framework as it may be difficult to attract or retain interest as experience grows. I think possibly the best way to assist adoption and also provide valuable content for more experienced developers are things like case studies, examples and reviews which cover the various libraries and their use. Example dependency templates etc may also be useful. Blogs such as yours, where you document your experiences and give examples are very valuable. Articles like the hooroku one or Andrew Brehaut's one are extremely useful and valuable. Possibly what would be very valuable would be one consolidated place where all this valuable information could be found. Someone interested in clojure and web development could just go to a single place and find a majority of the good articles, case studies, overviews and evaluation of web dev relevant libraries and techniques/idioms for Clojure. Ideally, this would just be part of another well know Clojure documentation site. Tim On Saturday, January 12, 2013 3:52:05 AM UTC+11, Paul Umbers wrote: I've been experimenting with Clojure web services recently, and posting the work on GitHub https://github.com/3rddog/doitnow and my bloghttp://internistic.blogspot.ca/search/label/clojure . When putting this test app together, it occurred to me that most other languages have a full-stack API available which makes life easier when it comes to making decisions about which libraries/APIs/frameworks to use. It also reduces the possibility of impedance mismatch between the libraries. For Java, you can use Spring (or any one of a dozen or more other popular frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, Ring, several logging, validation and database libraries, and they can be used together but they don't constitute a coordinated full stack - and that creates issues. For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. By the time you add logging, validation, data access, etc the odds of a mismatch between these libraries goes up dramatically. This is a concern, because these mismatches must be worked around in *my*code and are likely to break as the libraries are upgraded in future versions. So, I'm having to spend my time maintaining what are essentially patches for third-party libraries just so that they work together. Now, it may not be the best decision to try to put together a true full-stack framework from scratch, but is it worth choosing a bunch of existing frameworks and coordinating their releases - in much the same way as Eclipse coordinates plugin releases for major releases - so that putting together a full-stack app becomes easier? Projects taking part in the meta-project will work together to harmonize their functionality APIs, and coordinate their development cycles releases so that the meta-framework remains consistent and easily usable. Is this another barrier to adoption the Clojure community can remove? Is this even a barrier? Am I missing something? Thoughts?
Re: [emacs over ssh limitations]
I've just got my first mac and will investigate a bit and let you know what I find out. I know that emacs can work over ssh with all key combos and am fairly certain it will be an issue with the terminal emulator, so I should be able to find the right setup with a bit of time.. Tim On Tuesday, August 28, 2012 11:29:22 PM UTC+10, Stuart Sierra wrote: SSH in iTerm 2 from an OS X machine to a Linux server. $TERM is xterm-256color at both ends. We use this for pair-programming, so X and tramp are not helpful. -S -- 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
Re: [emacs over ssh limitations]
Hi Stuart, can I ask what platform are you sshing from and what terminal you are using? I use emacs over ssh a lot and while I have encountered some of the issues you mention, they are in a far more limited way. For example, I have found different behaviour between delete and sometimes, Alt doesn't work as expected. There can also be some differences in key behaviour between emacs running in GUI compared to emacs running in a terminal. Some of this is due to different kemaps being used in terminals. In nearly all cases, the issue is due to a combination of the terminal emulator, the ssh configuration and the terminfo/termcap settings on the remote host. Having three points of potential problems certainly doesn't make matters easy, but it can be sorted out with a bit of effort. A lot can depend on the terminal emulator you are using. I use Linux almost exclusively and it is possible that some of the issues cannot be easily solved if you are using completely different OSs at each end. However, if sshing from Linux to a remote Linux/Unix host, you should be able to get consistent behaviour. Some of the things I do are 1. Use either the console-setup or console-tools to get appropriate keymaps etc loaded so that differences between console and X behaviour are minimized. The console-setup is the more recent package and 'automates' more of the process. Console-tools, loadkeys etc give hyou more control. This will help ensure that 'special'modifiers, such as shit+tab will work. 2. Experiment with different terminal emulators. Nearly all can be configured to 'do the right thing', but lets face it, none of us really want to spend time working this out if we can avoid it. Some terminals are better/more consistent than others. Try different emulators and see. 3. Check local and remote $TERM environment variables. A common problem is that the local TERM variable is set to a value which the remote system does not understand. The result is that the remote system sets up a dumb or basic terminfo setting, which gives basic functionality, but fails to provide support for things like Meta, Super, etc. 4. Check ssh config. Make sure ssh isn't using an escape character you want sent to the remote system etc. Other alternatives are 1. Use an X compression protocol to enable runniing native X version of emacs remotesly. How well this works depends on your connection speed. However, provided you turn off font-lock, this an work very well even on quite slow DSL lines. 2. I suspect we cold do some clever stuff using tramp. Instead of running emacs remotely over ssh, run it locally, edit the remote file using tramp and set things up so that the local (n)repl can connect to the remote instance. However, I don't think nrepl supports this yet (I've done this with slime and lisp). These days, I found more consistent results running emacs remotely in daemon mode and then using emacsclient -t to connect. Not entirely sure why, but I do seem to get fewer keymapping issues doing it this way rauther than just running emacs remotely. HTH Tim On Tuesday, August 28, 2012 10:44:41 AM UTC+10, Stuart Sierra wrote: It's easy enough to test: fire up a small EC2 instance and use Emacs over an SSH+tmux session. You could also try using your own local Emacs that way by SSH'ing to localhost. In my experience, commands don't work in a terminal if they use modifier keys (Control, Meta, Shift) AND non-letter keys (arrows, ENTER, some punctuation). I assume it has something to do with how those combinations get encoded for the terminal emulator. You can always work around it with M-x, or by rebinding the command to a different key. It's mildly annoying, but not a showstopper. One consistently annoying thing is that PageUp, PageDown, and Delete don't work in clojure-mode buffers with Paredit in Emacs in a terminal. They insert weird characters like ^[ instead. I would very much like to have a fix for that! -S -- 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
Re: Newbie question about rebinding local variables
On Friday, April 20, 2012 8:21:56 AM UTC+10, Craig Ching wrote: Ok, I've read that what I want to do is a no no. But this is the sort of thing I did in Scheme about 20 years ago (and because of that I'm probably misremembering ;-)). Basically I'm learning clojure and thought I'd write a tic tac toe game. But not any tic tac toe, I want to write one where I can have multiple games going simultaneously. Something like: (def g1 (new-game)) (def g2 (new-game)) (g1 :x 0) (g1 :print) (g2 :x 5) (g2 :print) So the schemer in me (and probably the imperative programmer as well) thought I could return a clojure that encapsulates the board value, something like this: (defn new-game [] (let [board (into [] (repeat 9 nil))] (fn [n i] (cond (= n :x)(set! board (assoc board i 'x)) (= n :o)(set! board (assoc board i 'o)) (= n :print) (println board) Of course I get an error saying I can't bind to the non-mutable board. I'm really new to Clojure, so apologies if this is really basic for this list. Can I do what I want or can someone point me in the right direction? I've seen some other tic tac toe implementations on github, but they use recur to track state and I was hoping there was a cleaner idiomatic way than that. Thanks! -- 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
Re: Newbie question about rebinding local variables
On Saturday, April 21, 2012 12:26:30 AM UTC+10, Craig Ching wrote: On Friday, April 20, 2012 9:07:49 AM UTC-5, Walter van der Laan wrote: You could start with pure functions to handle the game logic, e.g.: (defn new-game [] [[\- \- \-] [\- \- \-] [\- \- \-]]) (defn print-game [game] (doseq [row game] (println (apply str row (defn move [game mark pos] (assoc-in game pos mark)) (print-game (new-game)) (print-game (move (new-game) \x [1 1])) (print-game (- (new-game) (move \x [1 1]) (move \o [0 2]))) Right, but then I'm having to keep track of the moves and reapply them on every game update, right? I guess my question is more conceptual (so that I can gain an understanding of Clojure), I don't really care about tic tac toe, what I really care about is how to maintain mutable state. Yes, you will need to track the state, but keep in mind that Clojure is clever about copies and works to make sure they are very fast and use as few resources as possible. I would be careful of thinking of the changes in state as being mutable state rather than new state simply because of old habits where copying of state was an expensive operation. I think the functional approach is the way to go. Highly recommend reading some of Rich's articles on state at the clojure site. Tim -- 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
Re: lein run and standard input (*in*) with read-line
Hi Phil, thanks, lein trampoline run seems to get around the problem. BTW, spotted a minor error in the .lein/bin/swank-clojure script. The CLASSPATH setting at the top of the script appears to have a hard coded path instead of one based on $HOME. For example, after installing the swank plugin, my script has the path CLASSPATH=/home/phil/.m2/repository/swank-clojure/swank-clojure/1.4.0/swank-clojure-1.4.0.jar instead of CLASSPATH=/home/tcross/. Tim On Sunday, March 4, 2012 4:54:00 AM UTC+11, Phil Hagelberg wrote: Tim Cross theophil...@gmail.com writes: My guess is that lein run does something different wrt *in*, but I've no idea what and cannot find anything obvious in the docs. Try using lein trampoline run to get around the subprocess issues with stdin. -Phil -- 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
lein run and standard input (*in*) with read-line
Hi All, I've been working on my first little clojure project for the past couple of days, but have now run into a problem with leiningen and was hoping someone could point me in the right direction to find a solution. I'm using lein 1.7.0, clojure 1.3.0 and openJDK 6 on a ubuntu based system. My code has a simple loop iin the -main funciton which calls read-line to get the input. If I run lein repl, execute (-main), I can enter data If I create an uberjar, and run it, I can enter data However, if I use lein run, I cannot eneter any data. It appears the program enters the while loop, but when I try to enter data, nothing happens - no characters are echoed to the screen (as is the case in the other two invokations) and it appears that the program is waiting for input from some other input source. My guess is that lein run does something different wrt *in*, but I've no idea what and cannot find anything obvious in the docs. My project file is very simple - (defproject clj-espeak 1.0.0-SNAPSHOT :description FIXME: write description :dependencies [[org.clojure/clojure 1.3.0]] :java-source-path java :ant [clj-espeak.core] :main clj-espeak.core) The java-source-path is necessary for some java interface classes for a JNI based interface to a C based text to speech library. This seems to be working fine. My -main funciton is very simple (defn -main [ args] (println Starting interpreter) (tts-initialize) (println Starting command loop.) (flush) (while true (dispatch (parse-input (read-line) As mentioned, this is my first clojure program. I'm also not a java programmer (though I did do some java back in the late 90's using java 1.0). I'm hoping it is just something obvious I've missed and would appreciate any suggestions. Background The reason I want to use lein run is that I want to execute the program via a shell script which is called by emacs. Emacs then communicates with this sub-process via standard input. The data it sends are commands to generate various bits of speech from text. Eventually, the aim is to have emacs start the clojure applicaiton, which will setup swank and also listen for input from emacs. I will then use slime to connect to the running process so that I can futher develop/refine the clojure code based on the input recieved from emacs. This is all part of developing a clojure based speech server for the emacspeak program. TIA Tim -- 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
Re: Lack in the documentation
Hi All, very new to clojure, so thought my experience may be relevant. Initially, the java aspect is a bit daunting. However, I don't believe you need to know java in order to take advantage of all the java interop features of clojure. All that you really need is to understand how to read java API documentation and understand the way clojure can interface with java libraries. This in itself may appear to be a big hurdle at first, but its not that hard provided you just have a go. My main advice would be to use Leiningen to help manage things, ignore maven etc and use the repl to experiment. Just reading the docs is insufficient - you have to sit at the repl and try using a few java libs and it will become clearer as you progress. I also find looking at other clojure code and how others have used java very useful. There are also some good books out there which are quite useful. I'm currently reading The Joy of Clojure and while tastes and mileage may differ, I am finding it a really interesting and informative book. From a documentation standpoint, I've not found it too bad. The cheatsheet has been very useful and using things like find-doc etc help to narrow down the search space. I do suspect that as the complexity of what I'm trying to do increases, I will likely need to understand java better, I suspect that is a way down the road yet and it will come in little pieces as I need them. Perhaps my only criticism with the docs are that there may be too many documents out there covering the 'getting started' aspect. I'm using emacs, slime and lein and it has all worked fine, but there was quite a bit of conflicting and in some cases incorrect information out there. Much of it seems to have made it far more complicated than it ended up being. I would possibly be good if clojure.org, clojuredocs.org and dev.clojure.org had just one definitive/official getting started document. I'd go further and suggest that document should really just be download lein; chmod u+x lein and lein install. Then, one official document for clojure+emacs, clojure+vim, clojure+eclipse etc and pointers to other tweaks/setups. However, in general, I think things are pretty good for such a young/new language and I'm having a lot of fun! Is there a document which covers the changes in 1.3 in more detail than the official release notes - especailly one which may explain how some of the changes can impact on past idioms etc. For example, it took me a while to find (with-redefs ...) as an alternative to using (bindings ...) for doing things like mocking functions for testing - I'm still not 100% sure this is even the right approach, but seems more correct than using ^:dynamic just to enable a test harness to work. Tim -- 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
