Re: preference and implications of using as- vs let
What is the major benefit of as- = (- 4 (#(* % %)) (+ 12) ) 28 = (- 4 (as- y (* y y)) (+ 12)) 28 On Monday, August 19, 2013 9:13:36 AM UTC-7, Ben Mabey wrote: On 8/19/13 8:58 AM, Jay Fields wrote: In the past, I've written code like the following (defn foo [x y] (let [x-squared (* x x)] (if (pos? y) (+ x-squared y) (- x-squared y However, the introduction of as- has led me to write the following, at times (defn foo [x y] (as- (* x x) x-squared (if (pos? y) (+ x-squared y) (- x-squared y In essence, I've started replacing single binding lets with as-. John Hume has pointed out that as- seems to have been introduced to work in conjunction with -. Which brings me to my question - do you think it's better to use a single binding let from a readability perspective? Are there any (performance or otherwise) impacts that I should be aware of? Cheers, Jay I prefer the standard `let` in these cases for readability since `as-`, to me, implies some threading is going on. I only use `as-` when I'm already using `-` as it saves me an extra binding that breaks up the flow of the code. WRT performance, the only difference with the `as-` version is an extra rebinding of `x-squared` as this expansion shows: (clojure.core/let [x-squared (* x x) x-squared (if (pos? y) (+ x-squared y) (- x-squared y))] x-squared) -Ben -- -- 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/groups/opt_out.
Re: preference and implications of using as- vs let
Hi Jay Thanks for the reply. I did not know how as- works, till I saw your example. I myself need to many a times chain things where in some cases the variable will go at the first location and in another cases it will go to the last location and it was a big pain to do something like what you did in B. To tell you the truth I found Example A much more readable than Example B. Thanks Anand On Monday, August 19, 2013 9:03:53 PM UTC-7, Jay Fields wrote: On Mon, Aug 19, 2013 at 6:41 PM, Anand Prakash anand@gmail.comjavascript: wrote: What is the major benefit of as- = (- 4 (#(* % %)) (+ 12) ) 28 = (- 4 (as- y (* y y)) (+ 12)) 28 Solving the contrived example doesn't really help answer the original question of preference and tradeoffs. As to the benefits of as-, I'd defer to the benefits of threading macros in general. The actual production code I'd originally written had this shape, though I suspect it won't make much sense without context. (defn foo [xrel yrel] (as- (filter #(= a val (:a-key %)) xrel) x (map :b-key x) (set x) (filter (comp x :b-key) yrel) (set x))) The above solution can be written in many ways, including - a single let to build the filter predicate (defn foo [xrel yrel] (let [pred (- xrel (filter (comp (partial = a val) :a-key)) (map :b-key) set)] (set (filter (comp pred :b-key) yrel and many other options as well - using the - macro, wrapping the map with a (-) and extracting the comp to (it's own) line above - using clojure.set/project, select-keys, clojure.set/select - using group-by to create a map that you use as the filter pred etc, etc. The two that I found the most readable were A. the above as solution, my first example B. single let that builds the predicate set, my second example I find that A, in my opinion, eliminates a let, but sacrifices a bit of readability at a high level - i.e. it's hard to look at the parts of the function and determine the sum of what you're trying to do. Conversely, I find that B includes a let that's strictly introduced for readability, and sacrifices low level readability - i.e. the parts are not easy to digest, but once you've figured them out the sum of what you're trying to do is very obvious. I haven't decided which I prefer, though I tend to lean towards A, considering it to be (as David described) an elimination of a superfluous let. Cheers, Jay -- -- 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/groups/opt_out.
Re: is intellij idea a good ide for clojure development?
Would agree with Laurent. For newbies, I would not recommend anything apart from Eclipse. It's really stable and I have been using it for multiple projects over the past year. It just work. I really love the integrated REPL and ability to debug with breakpoints. I spent 5-6 years with Eclipse and then tried Intellij Idea for 2 years and loved it. However with CCW I do not have any of the issues that people have with eclipse, because clojure vm is very lightweight. I start eclipse, start the repl and then keep using it without any restart for weeks. Any code that I change is live loaded into REPL. Thanks Anand On Thursday, July 25, 2013 3:42:18 PM UTC-7, Laurent PETIT wrote: 2013/7/26 Colin Fleming colin.ma...@gmail.com javascript:: Hi Laurent, Thanks for those links, I'll try the standalone version. I recently tried to set up CCW, I got it running but several of the Paredit keybindings didn't work for me and they didn't appear in the shortcut preferences either. I'm definitely in the have always hated Eclipse camp but I'll give the standalone version a try and let you know how I get on. If I have problems I'll post them to the CCW list. Thanks for all the hard work, CCW has really come a long way! Hi Colin, thanks for the kind words! If you're feeling a little bit more adventurous, you can also try the brand new feature I've been introducing this week: AutoShift! (tl;dr: fix indentation as you type) More on this (explanations, links, etc.) in this thread: https://groups.google.com/d/msg/clojuredev-users/F-gm5I5ZYUs/HZek6XA8u7MJ Also, please note that I'll be on holidays during August, so dont expect too quick a response ;-) Cheers, Colin On 26 July 2013 09:12, Laurent PETIT lauren...@gmail.com javascript: wrote: tl;dr: why not at least *try* Counterclockwise before skipping it 'because of Eclipse'? You may find its editor with paredit shortcuts appealing. A full standalone Eclipse+Counterclockwise is available for your platform here: http://updatesite.ccw-ide.org/branch/master/master-travis000102-git75512b6843a242e2ab3c9f4057c42c884653b2ea/products/ I'm a bit sad when I read people don't want to try Counterclockwise just because they had a prior bad experience with Eclipse. Not even giving it a try, c'mon guys, please ;-) I have been working on the automation of build and delivery recently, and for instance giving it a try is as easy as: 1. download the standalone version for your OS from here: http://updatesite.ccw-ide.org/branch/master/master-travis000102-git75512b6843a242e2ab3c9f4057c42c884653b2ea/products/ (pretty stable version, stick to this link please) It's a big download, but you have everything included (Eclipse base + Counterclockwise + Leiningen + Eclipse Git ...) 2. Unzip into a directory named e.g. counterclockwise 3. Locate counterclockwise / counterclockwise.app / counterclockwise.exe depending on your platform, and start it ! Even if you still don't like the beast, some feedback on what you liked / disliked will always be appreciated since new viewpoints are generally challenging and interesting! Cheers, -- Laurent 2013/7/25 Ryan Stradling ryanst...@gmail.com javascript:: I have used Vi, emacs, and IntelliJ for Clojure. I have used eclipse on non Clojure projects but it is not my default choice. I typically choose IntelliJ over eclipse when that type of environment is needed. I had a very capable set-up in IntelliJ. There are still some issues with the Clojure plugin especially if you are used to paredit. I naturally gravitate towards Vi when choosing between emacs or Vi. Vim-fireplace is really good if Vim is something you would like. Emacs though IMHO is still the best one out there of what I have tried. With all the others, I feel that I miss the interactive REPL experience I get with emacs. That, ergo-mode, and Caps Lock mapped to the ctrl key are what brought me back to it. Daily I use emacs. When needed, I use IntelliJ. (For instance I was writing a plug-in in Clojure for a Java application. I did not know the Java application well at all and had a hard to find issue. I fired up IntelliJ, and I was able to debug in Java and Clojure and found the issue rather quickly.) On Thursday, July 25, 2013 3:55:22 PM UTC-4, Lee wrote: On Jul 25, 2013, at 3:37 PM, Sean Corfield wrote: In October 2011, I decided to give Emacs another chance - specifically for Clojure development - and that's what I use day-in, day-out. I have a slightly customized setup but it really doesn't have much beyond the starter kit, rainbow delimiters and autocompletion added. It has a huge learning curve (nay,
Re: Socket.IO and Clojure?
This is an awesome discussion. Hope this leads to some good frameworks in the community. I was looking at Socket.IO webpage and they seem to support the following: Websocket, Adobe Flash Socket, AJAX long polling, AJAX multipart streaming, Forever Iframe, JSONP polling. I understand some people are not comfortable with Websockets, because if the early stage of this technology. So there are two time of use-cases: a. pseudo real time - e.g. chat apps - they should all be fine with polling and long poll is an optimization. b. real-time - e.g. multi player games, stock ticker etc - they would need some kind of socket. To answer Sean's question - I understand there are benefits with the socket.io client library. However you said that you do not want to go for Websockets. So if that is the case, isn't AJAX long polling sufficient for you. If that is the case then no client side library is required. You just need to keep polling from the client. It's server's choice with it wants return right away or implement long-poll. I am new to this space - so just try to make sure if I am missing something obvious. Thanks Anand On Friday, July 19, 2013 2:08:38 PM UTC-7, Christopher Martin wrote: Shameless plug: I recently shared a Clojure library for WebSockets and HTTP Kit: http://cljwamp.us It provides some features similar to Socket.IO in regards to pubsub/multiplexing events, and uses the WAMP spec which has several multi-platform options: http://wamp.ws/implementations While clj-wamp does not support long polling, a separate solution could potentially run along side it (since HTTP Kit itself supports long polling) though I haven't tried this yet. This library probably isn't a good option for Sean (the OP), but might be of interest for those looking into WebSockets with HTTP Kit. Cheers, ~Christopher Martin On Friday, July 19, 2013 1:33:51 PM UTC-4, c...@bitemyapp.com wrote: If you want something robust I'd recommend something like http-kit or Netty on the backend + using websockets (and a shim) directly on the frontend, or possibly browserchannel if you need to worry about firewalls and ancient browsers. Socket.IO is a moving target intended for a single audience (not multiplatform). It's not going to win you more than you'll pay in bugs and performance issues in the long run. -- -- 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/groups/opt_out.
Re: Socket.IO and Clojure?
BTW one more thing. If I am building anything serious. Anything which might be user facing and could potentially be used by even thousands of users, I would never consider Socket.IO. I just feel that it's a super hack which tries to do too many things with no guarantees on anything. On Saturday, July 20, 2013 3:50:31 PM UTC-7, Anand Prakash wrote: This is an awesome discussion. Hope this leads to some good frameworks in the community. I was looking at Socket.IO webpage and they seem to support the following: Websocket, Adobe Flash Socket, AJAX long polling, AJAX multipart streaming, Forever Iframe, JSONP polling. I understand some people are not comfortable with Websockets, because if the early stage of this technology. So there are two time of use-cases: a. pseudo real time - e.g. chat apps - they should all be fine with polling and long poll is an optimization. b. real-time - e.g. multi player games, stock ticker etc - they would need some kind of socket. To answer Sean's question - I understand there are benefits with the socket.io client library. However you said that you do not want to go for Websockets. So if that is the case, isn't AJAX long polling sufficient for you. If that is the case then no client side library is required. You just need to keep polling from the client. It's server's choice with it wants return right away or implement long-poll. I am new to this space - so just try to make sure if I am missing something obvious. Thanks Anand On Friday, July 19, 2013 2:08:38 PM UTC-7, Christopher Martin wrote: Shameless plug: I recently shared a Clojure library for WebSockets and HTTP Kit: http://cljwamp.us It provides some features similar to Socket.IO in regards to pubsub/multiplexing events, and uses the WAMP spec which has several multi-platform options: http://wamp.ws/implementations While clj-wamp does not support long polling, a separate solution could potentially run along side it (since HTTP Kit itself supports long polling) though I haven't tried this yet. This library probably isn't a good option for Sean (the OP), but might be of interest for those looking into WebSockets with HTTP Kit. Cheers, ~Christopher Martin On Friday, July 19, 2013 1:33:51 PM UTC-4, c...@bitemyapp.com wrote: If you want something robust I'd recommend something like http-kit or Netty on the backend + using websockets (and a shim) directly on the frontend, or possibly browserchannel if you need to worry about firewalls and ancient browsers. Socket.IO is a moving target intended for a single audience (not multiplatform). It's not going to win you more than you'll pay in bugs and performance issues in the long run. -- -- 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/groups/opt_out.
Re: Socket.IO and Clojure?
Hi Sean, We are in process for going with a similar solution on clojure. Lets keep sharing notes. We were on heroku till last week. Websockets wont work on heroku. Lack of sticky session caused other issues. So we moved to elabstic beanstalk. However elastic beanstalk doesn't support jetty and I do not like tomcat. Plus on elastic beanstalk whenever you push code they have a down time upto 5 minutes. So over the past 2 days, we moved things to chef on ec2 which I am really happy with. Now we have a system as easy to use as heroku, with much more control. I am mentioning these because you or others might go through the same steps. Coming to your main point about Socket.IO. We spent around a week exploring Socket.IO. It was super easy to hack up a demo, however we ended up leaving it for couple of reasons: 1. Though the community looks very active in terms of forks etc, the development on Socket.IO is completely stopped. The dev team is focussed on engine.IO and they are very opaque. When you post on socket.io google group, posts do not have get approved. If you propose to help, you do not get any response. 2. The library has lot of features - like rooms etc. However they are not built to scale. I looked at the code and was very disappointed. User-Room mapping, Room-User mapping were stored in memory which will make it not scale beyond a point. Bad coding (e.g. using lists traversal where hash maps should be used) is very common in nodejs community and I am very wary of developing on that platform. 3. There was a memory leak in Socket.IO which would cause memory to increase linearly with usage. Given that most projects using nodejs dont move beyond prototypes these kind of issues do not get highlighted. I used to manage the mobile server at LinkedIn and we had to deal with a lot of memory leaks with node.js. 4. Javascript So finally, if you really have to use Socket.IO, I would recommend using https://github.com/einaros/ws for just websocket and built everything else yourselves. I am not a big fan of keeping two different setups at the stage of our product. We are fine with long-poll for now. So we will start there and eventually get to web sockets. We are considering http://http-kit.org/ for that. For communication between message generators and open client sockets we are exploring some pub sub solution. Hope this helps. Thanks Anand On Tuesday, July 16, 2013 10:07:34 PM UTC-7, Sean Corfield wrote: At work we're starting down the path of building a new piece of functionality based on WebSockets and the external team we're working with is a Node.js shop so their go to solution is Socket.IO and they've produced a very nice front end in CoffeeScript and a prototype back end on Node.js. I'd really like to have our back end on the JVM, of course, and so I'd like to find a JVM-based Socket.IO solution that I use from/with Clojure... This seems like a reasonable option: https://github.com/mrniko/netty-socketio A little bit of experimentation with lein-try (Thank you Ryan!) shows that it's pretty easy to get a basic server up and running in the REPL - and I was able to get several of their demos running unchanged against Clojure, instead of their Java applications, so that was promising. Are there other folks out there doing Socket.IO stuff with Clojure? What approaches have you taken? Obviously, we could run Node.js and have it hit a Clojure-based REST API to do the integration, and that might be less pain long term but... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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/groups/opt_out.
