Re: Compiling Clojure security knowledge
> > clojars uses > https://github.com/ato/clojars-web/blob/master/src/clojars/web/safe_hiccup.clj > > which automatically escapes. But that double escapes attribute values if you don't put them in raw-calls. On Monday, September 2, 2013 6:32:59 AM UTC+2, Ivan Kozik wrote: > > On Sun, Sep 1, 2013 at 7:06 PM, Vincent Ambo > > wrote: > > * How and where do we prevent XSS attacks? Do we have templating engines > > that escape things unless told otherwise, or - if not - do these > features > > exist in the form of a helper function? If yes, where? (And so on...) > > clojars uses > https://github.com/ato/clojars-web/blob/master/src/clojars/web/safe_hiccup.clj > > which automatically escapes. > > Ivan > -- -- 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: [ANN] Component: dependency injection and state management
Hi, great work indeed. One question though: Why do you prefer declaring dependencies between components of a system explicitly instead of using prismatics Graph? On Thursday, November 21, 2013 3:01:19 AM UTC+1, Stuart Sierra wrote: > > This is a small library/framework I've been working on for a few months. > > https://github.com/stuartsierra/component > > I use this to manage runtime state in combination with my "reloaded" > workflow using tools.namespace.[1] > > I've started using this on some personal and professional projects and it > seems to be working fairly well. > > > [1]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded > > -- -- 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: [GSoC 2013] CinC
Is this work related? http://clojurewest.org/sessions#martin https://github.com/kanaka/clojurescript On Monday, March 4, 2013 4:15:07 PM UTC+1, Ambrose Bonnaire-Sergeant wrote: > > Any prospective students interested? > > On Mon, Mar 4, 2013 at 11:04 PM, Aaron Cohen > > wrote: > >> I think there probably is pretty easily a few months work there. >> >> If more work were needed, it would be interesting to try to get the >> clojurescript and clojure compilers using the same front-end. I'm fairly >> confident that's at least a summer's work. :) >> >> --Aaron >> >> >> On Sat, Mar 2, 2013 at 11:05 AM, Ambrose Bonnaire-Sergeant < >> abonnair...@gmail.com > wrote: >> >>> Is there enough to do here for a few months work? I've added a new >>> project here: >>> >>> http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-ClojureinClojure >>> >>> Feel free to change it Aaron. >>> >>> Thanks, >>> Ambrose >>> >>> On Sat, Mar 2, 2013 at 2:11 PM, Aaron Cohen >>> >>> > wrote: >>> I'd really like to see this happen actually. If there's interest I'd be happy to help or mentor. The current status is that I have a commit that needs finishing to implement letfn and I believe that was the last major special form that needed implementing in the compiler. Next up would be figuring out how to bootstrap a little better. It would also be nice to pull in the work that's been done recently on the reader in clojure and datastructures in clojure. On Sat, Mar 2, 2013 at 12:50 AM, Ambrose Bonnaire-Sergeant < abonnair...@gmail.com > wrote: > Hi, > > I think completing Aaron Cohen's CinC implementation would be a > fantastic GSoC 2013 project. > > https://github.com/remleduff/CinC > > Is Aaron willing to mentor this project? If the core.typed proposal > isn't chosen, I would be interested in > this project also as a student. > > Thoughts? > > Thanks, > Ambrose > -- -- 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/groups/opt_out. >>> >>> -- >>> -- >>> 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/groups/opt_out. >>> >>> >>> >> >> -- >> -- >> 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/groups/opt_out. >> >> >> > > -- -- 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
Re: Not using dependency injection - how do I share services around?
Well, you could also watch Stuart Sierras talks on structuring functional programs: Clojure in the Large http://vimeo.com/46163090 Thinking in Data & Functional Design Patterns http://www.infoq.com/author/Stuart-Sierra On Saturday, May 11, 2013 10:48:02 AM UTC+2, Colin Yates wrote: > > Yes it does, thanks. It is amazing how much you can do in the typical > spring/hibernate stack with a decent IDE without engaging your brain :). > > Clojure involves far less ceremony and really does expose you to the raw > elements of your problem domain and make you think. > > This is of course a good thing, but boy is it quite humbling :). No more > procrastinating by setting up JPA and thinking long and hard about "Java, > Annotations or good old XML?". > > I am definitely at the stage where I think Clojure's simplicity is very > hard (according to Rich's "simple made easy" talk). Not implying Clojure's > simplicity is only the lack of ceremonial frameworks! > > Loving it, and yes, looking back I can see how easy it is to lose your > solution amongst the staggering amount of incidental complexity. > > I guess my (rambling) point is to reiterate that it is very easy to > plaster over symptoms/effects using the very powerful framework beasts. > The lack of them forces you to think, and hopefully remove the cause. > > Finally, I have worked with some fantastic developers who happen to use > Java to build incredibly elegant and transparent solutions. I have just > worked with far more code monkeys, myself being one of them :). > On 11 May 2013 08:21, "Sean Corfield" > > wrote: > >> Korny mentioned java.jdbc and I figured that was a good in to talk >> about how we use it at World Singles. Even with the old API we used a >> function in a specific namespace that returned the data source (in >> fact it returned a pooled data source, using c3p0). Behind the scenes, >> we actually use an atom to provide a cached, singleton instance. >> with-redefs allows us to mock that for testing, if needed :) >> >> I haven't missed DI at all since moving to Clojure - after decades of >> OO - and I still use it in the non-Clojure, OO code that could be >> considered our "legacy" system that wraps our Clojure code. >> >> Clojure makes me think about my dependencies and organize them in a >> very clean top-to-bottom tree, with very clear divisions between >> subsystems. In the OO world, DI makes you sloppy... You can have >> circular dependencies. You can easily add whatever dependencies you >> need. You don't have to think about it, you can work around problems >> that crop up. >> >> Does that help Colin? >> >> Sean >> >> On Fri, May 10, 2013 at 4:04 AM, Colin Yates >> > >> wrote: >> > (newbie, getting better each day!) >> > >> > I assume we all know DI. Through the use of a central registry I can >> > register a service (a bean in a Spring bean factory for example). I >> also >> > define consumers of that service in the same registry passing in the >> > configured *instance* of that service. >> > >> > In Clojure I have a service (i.e. a datasource) defined in its own >> > namespace. What is idiomatic Clojure?: >> > >> > 1) to use (defonce *data-source*...) so that every body who requires >> that >> > ns gets the same instance? >> > 2) to provide a 'get-ds' accessor which returns a new instance and >> rely on >> > passing that service along to every function that needs it? >> > 3) some other way I don't know about >> > >> > Option 1 seems to be less-typing, but now functions aren't pure - they >> > depend upon state defined elsewhere. I can change the binding through >> > 'with-XYZ' type functions, but that isn't solving the non-explicit >> > dependency between the function and the state. >> > >> > Option 2 means functions are still pure, but how do you prevent huge >> lists >> > of services - i.e. if func-a calls func-b which calls func-c and func-c >> > needs service-a then func-a and func-b need to access service-a. Yuck. >> It >> > also means the main entry point to my application needs to assemble all >> of >> > these services up in one go. >> > >> > To be more explicit - DI containers provide a graphs of logic coupled >> with >> > state - the state being the instances of the collaborators (i.e. "I will >> > have ConsumerA with an instance of SimpleServiceA please"). Clojure has >> > very strong opinions about how to manage state. >> > >> > How does the Clojure community handle this use case of separating out >> the >> > definition of a service, the configuration of that service and providing >> > that service as a collaborator to a consumer? >> > >> > Thanks a bunch. >> > >> > Col >> > >> > -- >> > -- >> > 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 g
Re: clooj, a lightweight IDE for clojure
Why is it necessary to press TAB at all? Couldn't auto-indent be the default for a line and only manually reindented lines opt-out until one opts in again using TAB or something? On 18 Jul., 22:20, Shantanu Kumar wrote: > > All indentation uses spaces. I guess my fear is that users will find > > it annoying if the TAB key is devoted to smart indentation and space > > and delete are the only tools for adjusting the indentation manually. > > But maybe manual indentation is a rare enough that it is better to use > > TAB for smart indentation. > > Just wanted to highlight that both Emacs Clojure-mode and Eclipse/ > CounterClockWise use TAB to auto-indent the current line correctly. > So, I guess the expectation would be likewise for the respective > proportion of Clojure users. Though of course the key bindings should > be re-mappable too IMHO. > > Regards, > Shantanu -- 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: better community docs: getting started
> * *Meet Clojure* That's also an upcoming book on Clojure: http://meetclj.raynes.me/ -- 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: protocols and records -- use when?
Have a look at this: http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/ Now, as far as i understood, you define a protocol and the extend it on types defined via defrecord. That's more like Character is a protocol that defines functions for movement, attacks and other things and then you extend this protocol to Player, Monster etc. records and provide protocol-implementations for each of these types. It's less like packing all things into one class, more like behavioural composition. Your could also extend an AI protocol on your Monster-record. Then you have a Monster, moving like a Character, controlled by an AI. On 28 Jul., 10:12, Oskar wrote: > Hi! > > I have not heard much about records and protocols. What is a typical > use case in idiomatic Clojure code for them? Is it a good idea, for > example, to make a "Character" protocol and "Player" and "Monster" > records or something in a game. It feels a bit too much like OOP for > me to be comfortable with it, but I can't immediately see why that > would be bad. I just don't know how they are supposed to be used. -- 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: is my understanding correct for function "identity"?
I wanted to add the map/cycle sample, then thougt of clojuredocs and here you go: http://clojuredocs.org/clojure_core/clojure.core/identity On 14 Aug., 00:25, Alan Malloy wrote: > On Aug 13, 12:45 pm, jaime wrote: > > > I found an interesting function "identity" which will do nothing but > > only returns the parameter passed to it. The next minute I came up a > > question: "then what's the purpose of this function?" -- I've tried to > > figure out reasons of existence of "identity". > > > The only reason that I can imagine is this: because we often use > > higher-order functions, these higher-order functions will accept > > functions as its parameters, in such a situation, when we want to use > > a higher-order function but don't want to pass any "real" functions to > > it, then we can use function like "identity" and "identity" here is > > just to fill the role of parameter of higher-order function. > > > Guys, is my guess correct or not? Are there other reasons for > > identity's existence?? Are there other functions for the same purpose? > > One of my favorite uses of identity is for use with partition-by: > > user> (partition-by identity '(a a b a a a a c c d)) > ;; ((a a) (b) (a a a a) (c c) (d)) > > I sometimes speculate that, while identity is plenty useful, if your > program contains the characters "(identity", you probably don't know > how to program. -- 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: Question about sets
I use literals for collection-construction from arbitrary values too. Just haven't run into that issue. So, please: Put hash maps and hash sets back to the way they were -- they worked >> perfectly fine. Use the duplicate key check in ArrayMap to make ArrayMaps >> behave like all the other maps, i.e., last instance of a key wins. > > > -- 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: Routing HTTP/ JSON in clojure
For a decent intro to ring and compojure you probably want to watch http://skillsmatter.com/podcast/home/functional-web It's an introduction to the libraries by their author/maintainer, James Reeves. On Wednesday, September 5, 2012 9:56:51 AM UTC+2, David Dawson wrote: > > Thanks guys! > > I'll go with ring + compojure bundled with cheshire json and > clojuremongodb as a starting point and see where I get to. > I'm all in favour of pleasant suprises! > > David. > > On Wednesday, 5 September 2012 03:05:33 UTC+1, Gaz wrote: >> >> We do all of the things you mention (minus the replay, but that would >> be trivial) in Clojure where I work, and it is remarkably easy. We >> use: >> >> * ring + compojure and an embedded jetty server to create lightweight >> webservers >> * the Cheshire JSON encoding/decoding library for all JSON purposes >> (https://github.com/dakrone/cheshire) >> * we wrote our own small wrapper around rabbitmq - but there are >> several available now (such as >> https://github.com/michaelklishin/langohr) >> * for mongo we use: http://clojuremongodb.info/ >> >> We also found that when processing JSON messages, multimethods can be >> extremely useful as a dispatch mechanism if the shape of the JSON data >> dictates what should happen to it. I would certainly recommend Clojure >> for what you describe, I think you will be pleasantly suprised how >> straightforward it is :) >> >> On Tue, Sep 4, 2012 at 7:05 PM, Russell Whitaker >> wrote: >> > On Tue, Sep 4, 2012 at 4:45 PM, David Dawson >> > wrote: >> >> Hiya! >> >> >> >> I saw the names, but then was swamped by moustache, noir and others >> that at >> >> first glance appear to be in similar spaces. I found it a bit >> difficult to >> >> pick out the various specialisms or layers each library is aiming at >> tbh. >> >> So, I thought it best to look for some guidance if possible from >> people who >> >> know what they're doing ... :-) >> >> >> > >> > Some of us are only "ahead of you" by relative measures: I myself had >> > to _remove_ noir >> > & noir-async from a project today because of some reloading issues >> > introduced by the latter; see >> > today's (4 Sep 2012) clojure IRC log: >> > >> > http://clojure-log.n01se.net/ >> > >> > Russell >> > >> >> david >> >> >> >> >> >> On Wednesday, 5 September 2012 00:24:46 UTC+1, Russell Whitaker wrote: >> >>> >> >>> On Tue, Sep 4, 2012 at 1:52 PM, David Dawson >> >>> wrote: >> >>> > Hiya, >> >>> > >> >>> > So, I'm a clojure newbie... and I've been asked to evaluate a few >> >>> > different >> >>> > technology options for a project I've been handed. >> >>> > >> >>> > The end result will need to be a 'router' that accepts JSON >> messages >> >>> > over >> >>> > HTTP, store them into some datastore (ideally one of the ones >> available >> >>> > on >> >>> > cloudfoundry, postgres mongo etc), then forward the message onto >> one or >> >>> > more >> >>> > end points. Forwarding will probably be either dropping into >> rabbitmq >> >>> > or >> >>> > posting on with HTTP. >> >>> > (or both). >> >>> > >> >>> > There also needs to be a replay capability, so you can tell the >> router >> >>> > to >> >>> > scoop up the historical messages from the datastore and forward >> them all >> >>> > on >> >>> > (in order) to a particular end point. >> >>> > >> >>> > I'm totally open to any tech, prebuilt (and commercial) or >> development >> >>> > required but given that the system needs some algorithmic routing >> rules, >> >>> > clojure seemed a really nice conceptual fit over the languages I >> >>> > normally >> >>> > work with (imperative jvm ones, essentially) >> >>> > >> >>> > So, I'm really interested in any suggestions on how this might best >> be >> >>> > approached in the clojure world! >> >>> > >> >>> >> >>> Hi David, have you looked at Ring + Compojure? >> >>> >> >>> -- >> >>> Russell Whitaker >> >>> http://twitter.com/OrthoNormalRuss / >> http://orthonormalruss.blogspot.com/ >> >>> http://www.linkedin.com/pub/russell-whitaker/0/b86/329 >> >> >> >> -- >> >> 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 >> > >> > >> > >> > -- >> > Russell Whitaker >> > http://twitter.com/OrthoNormalRuss / >> http://orthonormalruss.blogspot.com/ >> > http://www.linkedin.com/pub/russell-whitaker/0/b86/329 >> > >> > -- >> > 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 f
Re: Question about sets
I too approve of Mark's reasoning and solution. Probably that should be moved into http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements On Wednesday, September 5, 2012 6:40:50 AM UTC+2, Peter Taoussanis wrote: > > +1 on Mark's most recent reply, that is: > > * Revert to 1.2 behaviour. > * Consistency is good, but must be in favour of not throwing RTEs. > * No knobs. > > It's clear that there's lots of directions that could be taken here, but > getting caught up on trying to find a solution that pleases everyone 100% > is, IMO, both a non-starter and inconsistent with Clojure's generally > opinionated approach. > > The pre-1.2 behaviour was sensible, consistent (both in terms of API and > Clojure design idioms IMO) and didn't raise any complaints (as Mark has > pointed out, the motivation behind the original change was actually for > something unrelated). Mark's arguments on the relative value of RTE/no-RTE > behaviour are also sound IMO. > > My 2c: let's try not to over-analyse this thing. Revert the behaviour, and > let's move on to more interesting ways of moving the language forward :) > -- 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: Question: Looking at Noir code - hey, are those singletons?
>From what I've heard, you are absolutely right on those globals. It isn't
considered idiomatic and should be avoided, like in all other languages.
The singleton analogy fits pretty good.
Some advice on how to encapsulate state in a sane way can be found for
example here: http://vimeo.com/46163090
I think the global vars in those libs were mostly for convenience while
programming and *could* be removed by thinking through the alternatives.
On Wednesday, September 12, 2012 4:30:54 PM UTC+2, the80srobot wrote:
>
> Hello,
>
> So I've been working on a project at work, that required me to code a
> simple web interface. I considered going with Noir, and while reading the
> code, I noticed a pattern that seems to repeat throughout most of the code
> that Chris Granger has published in Clojure. This is what I'm referring to:
>
> ; these are at the top level in (ns noir.core)
> (defonce noir-routes (atom {}))
> (defonce route-funcs (atom {}))
> (defonce pre-routes (atom (sorted-map)))
> (defonce post-routes (atom []))
> (defonce compojure-routes (atom []))
>
> Now, I am new to Clojure, but I am not new to (functional) programming and
> I'd like to think that I know a singleton when I see one. Is that really
> what these are? If I'm right then defining your 'globals' (for lack of a
> better word) like this would mean, among other things, that you really
> can't have two independent Noir apps defined/running in the same project -
> is that a correct assessment?
>
> Can someone more experienced shed some light on why it's done this way? My
> experience in functional programming has taught me to always limit my scope
> - I would think that either using thread-local bindings (and then rebinding
> them to child threads) or relying on lexical scope would be preferable to
> polluting the global state. Is this a Clojure best practice?
>
> Thanks. I'm looking to use Clojure a lot at work, and I'm trying to really
> understand the language before I throw it our production problems.
>
> ~Adam
>
--
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: code design in clojure
You probably want to watch this: vimeo.com/46163090 Also, try to think of your programs in terms of pipelines as much as possible. You get input, you produce output. That probably applies to every program ever written, but when you get how that works in Clojure, it's like an enlightment, at least it was for me. You can then structure all the processes in your program like that, and wire those up until you're done. On Thursday, October 18, 2012 5:51:23 AM UTC+2, Brian Craft wrote: > > I'm finding the books on clojure to be very focused on low-level language > features. Are there any good references for how to design code in clojure > (or perhaps in functional languages more generally)? For example, knowing > when to use a data type or a protocol, knowing when and how to separate > purely functional code from code with side effects, making use of monads, > queues, and the other forms that one hears about in the forums, etc. -- 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: code design in clojure
Now I remember the more important video: www.infoq.com/presentations/Thinking-in-Data Also (haven't watched): www.infoq.com/presentations/Programming-with-Values-in-Clojure -- 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: reduce, reduce-kv, map, mapv, reducers/map and nil
>
> I find this behaviour quite unfortunate because I now have to explicitly
> test
> for nil? and ensure consistent behaviour.
Yes, especially unfortunate considering that Rich said the reducers lib
could be used as a drop in replacement for core to speed up programs, or
something along the lines.
On Monday, October 29, 2012 2:00:35 PM UTC+1, Wolodja Wentland wrote:
>
> Hi all,
>
> I am currently testing performance of different reduce and map
> implementations
> in my programs and have problems because their treatment of nil is
> different.
> The "normal" clojure.core implementations of reduce and map work well when
> called on nil, but reduce-kv and functions in clojure.reducers throw
> exceptions.
>
> --- snip ---
> user=> (defn fold-into-vec
> "Provided a reducer, concatenate into a vector.
>
> Note: same as (into [] coll), but parallel."
> ([coll]
>(r/fold (r/monoid into vector) conj coll))
> ([n coll]
>(r/fold n (r/monoid into vector) conj coll)))
>
> user=> (map (fn [el] (* 2 el)) nil)
> ()
> user=> (mapv (fn [el] (* 2 el)) nil)
> []
> user=> (fold-into-vec (r/map (fn [el] (* 2 el)) nil))
> # implementation of method: :coll-fold of protocol:
> #'clojure.core.reducers/CollFold found for class: nil>
> user=> (reduce (fn [ret el] (+ el el)) {} nil)
> {}
> user=> (reduce (fn [ret [k v]] (+ k v)) {} nil)
> {}
> user=> (reduce-kv (fn [ret k v] (+ k v)) {} nil)
> # implementation of method: :kv-reduce of protocol:
> #'clojure.core.protocols/IKVReduce found for class: nil>
> --- snip ---
>
> I find this behaviour quite unfortunate because I now have to explicitly
> test
> for nil? and ensure consistent behaviour. This inconsistency violates the
> principle of least-surprise and I am not sure if the current behaviour is
> intentional or merely an unfortunate implementation detail.
>
> Wouldn't it make sense if reduce-kv and r/map mirror the behaviour of
> reduce,
> map and mapv in core?
>
> P.S. Would it be possible to have something like fold-into-vec in
> clojure.reducers?
> --
> Wolodja >
>
> 4096R/CAF14EFC
> 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
>
--
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: Converting large OOP codebase to clojure
Use abstractions, forget inheritance. Try modeling what the program does in terms of data conversion. Then you will only need functions and data. On Saturday, November 17, 2012 2:40:05 PM UTC+1, Jonathon McKitrick wrote: > > One project I've considered porting is highly OO, with a large number of > classes and several levels of inheritance. In Common Lisp, I'd just use > CLOS. What methodology would be good to translate such a project to > clojure, while maintaining heavy reuse of inherited behavior and > abstraction? -- 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: What are the advantages of clojurescript over straight-forward javascript?
Seems like Knockout [1] could be used [2] also. I haven't tried that, but it would be great. Any ideas how the used MVVM-pattern could fit with FP? [1] http://knockoutjs.com/ [2] https://github.com/SteveSanderson/knockout/blob/master/build/build-windows.bat#L21 On 31 Aug., 02:39, Mark Rathwell wrote: > On Tue, Aug 30, 2011 at 6:06 PM, Mike S wrote: > > > Two question: > > 1. Can I use clojurescript with dojo? > > You should be able to use the advanced compile option with Dojo, it is > the only library other than Google Closure to meet the Closure > compiler requirements for the advanced compilation option. It will > take some tinkering, though, to get it all working, I'm sure. > > > 2. what are the advantages of clojurescript compared to just writing > > the code in javascript? I can see why clojure would be useful for java/ > > jvm (dynamic/interactive development rather than compilation cycle, it > > does away with much java boilerplate code, simplified > > concurrency... ). Javascript already has dynamic/interactive that's > > only complicated by an additional compilation from clojurescript, It's > > code, when using a modern library, is almost boilerplate-free, it has > > quircks but those are well documented and easily avoided. What does > > clojurescript bring to the table? > > The reasons are much the same as the reasons for CoffeeScript, > Cappuccino, etc. One big reason being you get to write Clojure, end > to end. -- 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
Twitter's Storm (complex event processing system) is now open source
See https://github.com/nathanmarz/storm also http://news.ycombinator.com/item?id=3014039 especially http://news.ycombinator.com/item?id=3014556 -- 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
