Re: extend-type and extend-protocol: different syntax for multi-arity methods

Hi Tassilo, Thanks for the reply. The thing is, although the implementations for extending protocols directly in records and with extend-type might be different, there is no reason why the syntax should be different: from Clojure-programmer perspective it’s all the same. It is a leaked abstractio

Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I wrote the following code to solve this challenge - https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/. Code - https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_interme

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I forgot to link the input files https://raw.githubusercontent.com/fsufitch/dailyprogrammer/0e4bb5ba1e3bc6e749b9e9bb49387513d5a623b7/ideas/pile_of_paper/100rects100x100.in https://raw.githubusercontent.com/fsufitch/dailyprogrammer/0e4bb5ba1e3bc6e749b9e9bb49387513d5a623b7/ideas/pile_of_paper/100re

Managing database schema

Is there a lib that will allow me to have my sql defined in a file which I can reference from Clojure? I cannot use one of the existing migration libraries as I need to do more than just manipulate SQL on a version upgrade. I am aware of yesql which would be great but it didn't work out for DDL

Re: Managing database schema

Have you looked at ragtime? Particularly it's sql.files library. As far as I see, it will suit your needs. https://github.com/weavejester/ragtime On 14 May 2015 at 11:45, Colin Yates wrote: > Is there a lib that will allow me to have my sql defined in a file which I > can reference from Clojure

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

My general rule of thumb is that "idiomatic" Clojure is about 10x slower than Java. So this result doesn't really surprise me. If you want to get maximum performance, you will have to do some more advanced / non-idiomatic things like: - Add type hints for classes and primitive values - Use "deft

Re: Probabilistic programming anyone?

A complete comparison would take quite a long time and probably warrants a journal paper-length effort. In short: Anglican: fast, composable queries, parallel, expressive - slower than Stan for models in which one can use HMC and less modular than Venture Stan: no recursion, continuous valued p

Re: Probabilistic programming anyone?

We'd love to have contributions! It's read only for outsider for now -- we'd like you to "sign-up" if you're going to be making pull requests, etc. The examples are on github only momentarily -- it's a mirror of a bitbucket repo. The public release of the eaxmples was easier for silly technica

Re: Managing database schema

Thanks, I'll take a look Sent from my iPhone > On 14 May 2015, at 10:18, Gadzhi Musaev wrote: > > Have you looked at ragtime? Particularly it's sql.files library. As far as I > see, it will suit your needs. > > https://github.com/weavejester/ragtime > >> On 14 May 2015 at 11:45, Colin Yates

Re: Managing database schema

You can put a .sql file in /resources and read it with clojure.java.io/resource. –S On Thursday, May 14, 2015 at 9:45:31 AM UTC+1, Colin Yates wrote: > > Is there a lib that will allow me to have my sql defined in a file which I > can reference from Clojure? I cannot use one of the existing mig

Re: separation of concerns w/o encapsulation

On May 13, 2015, at 11:07 PM, Brian Craft wrote: > http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism > > In an environment where you

Re: separation of concerns w/o encapsulation

I guess a related concern is abstraction. I notice I often have functions which work at different levels of abstraction in the same ns which makes me uncomfortable. In OO land they would be package level or even instance classes. I haven't yet found a way to solve this in clojure land. To be expli

Re: separation of concerns w/o encapsulation

On May 14, 2015, at 10:28 AM, Colin Yates wrote: > I guess a related concern is abstraction. I notice I often have functions > which work at different levels of abstraction in the same ns which makes me > uncomfortable. In OO land they would be package level or even instance > classes. I haven'

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Ditto F# vs. C#. One has to wonder when / where / if functional-pure-immutable approaches will ever under the covers get "fast enough"? -- 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

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I think it false view that immutable/functional constructs are slow by default. Instead, a lot of it comes down to lack of support in the popular VMs for these constructs. For example the following code: (defn add-fn [& args] (reduce -add 0 args)) (loop [x 0] (if (eq x 1) x (recur

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I could be a bit off here, but I'd say the speed differences between Clojure and Java are actually due to immutability AND weak-typing, while in C# vs F# the difference should be less pronounced and governed primarily by the use of immutability (i.e., using mutable data-structures yield results in

a record that implements the iFn protocol can itself be called as a function?

The docs offer this example: https://clojuredocs.org/clojure.core/defrecord user=> (defrecord Someone [nick-name preffered-drink] Fun-Time (drinky-drinky [_] (str nick-name "(having " preffered-drink "): uuumm"))) user.Someone user=> (def dude (->Someone "belun" "daiquiri")) #'user/dude use

Re: separation of concerns w/o encapsulation

On Thu, May 14, 2015 at 12:14 PM, Sean Corfield wrote: > > In an environment where you can’t trust your co-workers(!), you certainly > want to hide *mutable* data so they can’t modify your objects’ state. When > you remove mutability, there’s a lot less damage they can do and they it’s > really m

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

The major problem here is that you are using boxed math for everything instead of primitives. 0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below are dependent on it for best performance. And use Java 1.8. 1) Parse the lines you're reading directly into longs (Clojure focuses on

Re: separation of concerns w/o encapsulation

That assumes the intermediate functions are reusable. I guess with all these things asthetics come into play, and there is of course the option of letfn as well. On 14 May 2015 18:40, "Sean Corfield" wrote: > On May 14, 2015, at 10:28 AM, Colin Yates wrote: > > I guess a related concern is abstr

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Gah. Meant in project.clj: :jvm-opts ^:replace ["-server"] ;; maybe also set max heap with "-Xmx1g" in there On Thursday, May 14, 2015 at 2:46:59 PM UTC-5, Alex Miller wrote: > > Oh also, the default Leiningen settings are optimized for reducing > startup, not for speed. Use: > > ^:jvm-opt

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Oh also, the default Leiningen settings are optimized for reducing startup, not for speed. Use: ^:jvm-opts ^:replace ["-server"] ;; maybe also set max heap with "-Xmx1g" in there Or just don't use lein when perf testing. On Thursday, May 14, 2015 at 2:44:38 PM UTC-5, Alex Miller wrote: >

Re: separation of concerns w/o encapsulation

On May 14, 2015, at 12:37 PM, Erik Price wrote: > The code itself is mutable. The nice thing about a private function is that I > have reserved the right to change how it works someday, without fear that > others have become dependent on the way it currently works. That’s why I suggested foo.ap

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Also using `lein run` without supplying correct JVM settings (like -server) is going to lead to pretty misleading results. On Thu, May 14, 2015 at 3:44 PM, Alex Miller wrote: > The major problem here is that you are using boxed math for everything > instead of primitives. > > 0) Switch to Clojur

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I'd like to get more guidance on how to specify :jvm-opts for maximum performance. I've received some help on this topic from people on this list in the past (thanks!), but I'm pretty sure that I'm still not doing things right. I'm almost always interested in maximum performance for long-running

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Probably not helpful, but I tend to rely on the jvm optimisations and just -server. I figured this is an area where a little knowledge is a dangerous thing. At the very least I would have a realistic benchmark suite to prove to myself that these gains were worth it. In my experience the performanc

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I know that remembering to put "-server" used to be a huge issue, but I thought that on all recent versions of Java on all modern 64-bit machines, -server is now the default. I thought it was a non-issue at this point. Is that incorrect? On Thu, May 14, 2015 at 1:54 PM, Colin Yates wrote: > Pro

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Now I feel even more of an ignoramus :) On 14 May 2015 21:57, "Mark Engelberg" wrote: > I know that remembering to put "-server" used to be a huge issue, but I > thought that on all recent versions of Java on all modern 64-bit machines, > -server is now the default. I thought it was a non-issue

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

FWIW if I run with no :jvm-opts at all then I often crash with an out-of-memory error, so I do know that whatever happens by default doesn't do what I'm doing with respect to memory, at least. I don't know what happens with respect to the other issues (tiered compilation and whatever else) by d

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I always run my REPL inside of Counterclockwise, but as far as I know it uses leiningen to launch the REPL. In any case, when I attach a profiler such as the built-in jvisualvm to the REPL process, it clearly says that the REPL is running in 64-bit server mode. On Thu, May 14, 2015 at 2:29 PM, Le

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

By default, I believe that lein will set: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 for the JVM opts. If you supply :jvm-opts, they will be *added* to these. Using ^:replace will instead *replace* the defaults with what you supply. There are a bunch of rules in the JVM for whether -server

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

In general, running any kind of JVM via Leiningen, using the 'ps' command with lots of '' on the end of the command line options should give full command line options used to start the JVM, so you can see what is happening. Understanding exactly which options are good or bad for performance, I

Re: separation of concerns w/o encapsulation

pasting here what I think could be a separation of concerns code pattern proposal from "Graph: Abstractions for Structured Computation" *... Object-oriented programming encourages the decomposition of large systems into

Re: Probabilistic programming anyone?

Anglican seems very interesting to me (I have no prior experience on the "probabilistic programming"); can I find more newbie like me friendly document on this? On Tuesday, May 12, 2015 at 7:05:50 PM UTC+9, Frank Wood wrote: > > I'm a professor at Oxford and my group has been working on a new emb

Multimethod or protocol or...? Clojure design feedback

I'm working on a tool to orchestrate the migration from mongodb to datomic, and i'm looking for a bit of design feedback as i'm new to clojure. The user needs to provide functions that transform mongodb documents into datomic txes. Do y'all prefer the top or bottom style, or think there's a

Re: Multimethod or protocol or...? Clojure design feedback

I personally prefer multimethods, generally speaking—I think they feel more idiomatic. Although it does depend on the context of what you’re doing. In some cases a protocol may be the correct choice. Here the multimethod seems fine. > On May 14, 2015, at 16:34, Jason Marmon wrote: > > I'm wor

Re: separation of concerns w/o encapsulation

> Once an engineer comes to grok FP, they tend to organize code around how > data 'flows' between these pure functions to produce output data. The > structure of how functions connect to form the structure of a functional > computation has typically been informal. Until now see Flow Based Prog

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I can heartily recommend Java Performance: The Definitive Guide to anyone interested in digging further into all the knobs you can set on the command line: http://www.amazon.com/Java-Performance-The-Definitive-Guide/dp/1449358454 -- You received this message because you are subscribed to the Go

Re: Multimethod or protocol or...? Clojure design feedback

Alex Miller's recent blog post on this is quite relevant http://insideclojure.org/2015/04/27/poly-perf/ On Fri, 15 May 2015 at 12:00 pm Max Countryman wrote: > I personally prefer multimethods, generally speaking—I think they feel > more idiomatic. Although it does depend on the context of what y

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Thanks Colin and also Alex and Andy. I'm trying to determine a reasonable way to do this without reading a book about it. It sounds like I should use ^:replace, -server, and also -XX:-TieredCompilation (is that right, the way I've changed + to -?), and also -XX:+AggressiveOpts. Does it make se

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

On Thursday, May 14, 2015 at 8:45:09 PM UTC-4, Lee wrote: > > Thanks Colin and also Alex and Andy. > > I'm trying to determine a reasonable way to do this without reading a book > about it. > > It sounds like I should use ^:replace, -server, and also > -XX:-TieredCompilation (is that right, the

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

I agree that the problem is immutable/functional constructs per se., but I don't think the problem is the lack of VM support either. It is possible to get *very* fast code on the JVM. In Clojure the issue is more that the dynamic nature of many Clojure constructs and lack of static type inferen

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

> On May 14, 2015, at 9:15 PM, Fluid Dynamics wrote: > > Umm, the :replace metadata needs to be on the vector. Attaching it to the let > form won't do much of anything useful. So: > > :jvm-opts ~(let [mem-to-use >(long (* (.getTotalPhysicalMemorySize >

Managing database schema

I use clj-liquibase, https://github.com/kumarshantanu/clj-liquibase. It's a clojure wrapper for Liquibase. There is a function to load schema changes (changeset) from a file, along with many other functions to create changesets for your schema. -- You received this message because you are su

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

All the advice here is valid; type hinting + eliminating boxed math will probably give you the biggest gains. By adding one type hint in the proper place sometimes I've been able to make my code go 5-10x faster. I've used tools like YourKit to great advantage to be able to pinpoint exactly whic

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

> I.e. your time is better spent optimizing a fn that's called 1k times per > second and it's a little slow (for example, missing a type hint and has to > do reflection or using boxed math) vs. a fn that's very slow but is only > called once a minute. not all apps, and not all developers, end up w

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

Ok, IF there's such a spot : ) . On Thursday, May 14, 2015 at 9:57:53 PM UTC-7, raould wrote: > > > I.e. your time is better spent optimizing a fn that's called 1k times > per > > second and it's a little slow (for example, missing a type hint and has > to > > do reflection or using boxed math

Controlling growth rates of generators with test.check

Hi all, I am doing some generative testing with test.check and need a way to control the growth rate of data structures (the regular linear growth quickly makes the computations too large for meaningful testing usage). I came up with the following solution to do this: (defn gen-resize "Crea