I still have to do my personal large scale project in Clojure, but I
would like to share my thoughts so far. (10 years ago I implemented a
60k Common Lisp project; I never worked on more than 5k Clojure code
so far; the C++ and Java projects I was involved in reached 800k to 1M
lines of code).
I
This is an unfinished thought: I think that the Single-Level-of-
Abstraction (SLA) principle promoted in OO needs to have a prominent
place in functional programming, too!
Each function should talk about the problem in its level of
abstraction, e.g. in its language. Functions related to the same
Thanks for your feed-back. I already have RDF/OWL in my tool-kit. I am
only not sure if an ERP like system should be modeled along those
lines. But I did not put enough thought in that direction yet. Would
you base an ERP like system on top of RDF/OWL?
--
You received this message because you
No worries. I have the book on my shelf. The first version. But thanks
for making me aware of the second version.
--
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
Hi all,
I am coming from common lisp and was wondering if clojure supports
intersection and union not only on sets, but also on normal sequences/
lists? I just did a google search but without a result. For the moment
I'm writing those functions myself.
Thanks for any hints,
Christian
--
You
You're right. Your version does what I want. Actually I've just seen
that common lisps behaviour in the case of duplicates is undefined:
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node152.html
I was certain that it behaved the way your intersect behaves.
--
You received this message because
Hello all,
I've implemented the levenshtein measure in clojure and am quite happy
with it except that I run into stack overflows if I hand over long
strings. My current solution looks like this:
-- snip start --
(declare levenshtein-rec)
(declare change-cost)
(defn levenshtein
Compute
Actually Mark is right. My point is not about the Levenshtein
distance. I've even found a quite nice and concise implementation here
on the list a few weeks ago:
generic (works for any seq) levenshtein distance
https://groups.google.com/group/clojure/browse_frm/thread/c5da3ac1b6704eda
My point is
that
there is no version of the open system call with only one parameter.
I've modified the tangle program and now its working.
I've attached the patch.
I cannot imagine that I am the only one with that problem. Am I?
Thanks,
Christian
daly wrote:
On Wed, 2011-03-23 at 00:31 -0700, Christian Schuhegger
Hi all,
I am continuing on my path to explore clojure in more detail and am
trying to implement the following haskell algorithm in clojure:
http://www.csse.monash.edu.au/~lloyd/tildeFP/Haskell/1998/Edit01/
Even after trying several different approaches and investing several
hours I do not seem
I understand now the problem. Clojure is really not lazy enough :) I
was forgetting that clojure evaluates its function arguments eagerly
like lisp and not lazily like haskell.
I have to wrap the function arguments that should be evaluated lazily
into closures (fn [] value).
Once I have a
Finally! I have a solution. You can have a look at it here:
https://gist.github.com/889354/
I would like to hear comments about how to do it better or in a more
idiomatic clojure way.
Especially I am uncertain about my use of binding and the top level
declares. I needed the ability to reference
I am replying to this thread from January this year:
https://groups.google.com/group/clojure/browse_frm/thread/47c388127e0da3ef
I am not certain if my solution fulfills the aesthetic requirements of
clojure hackers, but I use one of my old C/C++ marcros for aligning
equal signs to align at commas
I am taking up a discussion from 2010:
https://groups.google.com/group/clojure/browse_frm/thread/60dff89149c3d2e6/
I would prefer if it would be possible to define closed maps, e.g.
maps that allow only a certain set of keywords, both for get and
set (like in assoc, assoc-in, update-in, ...). It
Thanks for all of your answers, but I think for my use cases the
approach proposed by Justin looks most promising. I'll implement my
own closed map.
Another idea that come to my mind was that a closed map is actually a
Java Bean without behaviour. Perhaps the closed map could be
implemented by
Thanks for that recommendation, I definitely like that proposal!
I guess the drawback is then that destructuring will not be safe.
I have to think some more time about it.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send
I am using maven directly to work with clojure and I had the problem
with the tools.jar, too. I resolved it by adding the following block
to my pom.xml:
profiles
profile
iddefault-tools.jar/id
activation
property
namejava.vendor/name
valueSun
My comment is unrelated to Clojure but related to the general topic of
avoiding redundancy. Please have a look at InfoQ's Dan Haywood's
Domain-Driven Design Using Naked Objects:
http://www.infoq.com/articles/haywood-ddd-no
The book is definitely worth a read!
Naked Object's (now called Apache
Sorry, the link to their mailing list is here:
http://mail-archives.apache.org/mod_mbox/incubator-isis-dev/201104.mbox/BANLkTim+9061Se1mPLK3=wymmj0qkdu...@mail.gmail.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
Hello list,
I have a question that perhaps may be relevant for more people. I
strongly believe that reading code of other people is an undervalued
discipline of all developers. Typically it just happens as a side
effect of working in a project with other people. Like that a style of
development
Many thanks for all of your contributions so far! I definitely will
(and already have to some extent) go through the recommended links.
One additional project I came across that looks interesting is midje:
https://github.com/marick/Midje/wiki
I see the point of having a forum to discuss best
Thanks, that sound good! I'll have a look at the clojars project and
yours once it is in the right state for that.
On 10 Mai, 18:04, Paul deGrandis paul.degran...@gmail.com wrote:
I'm also working on a project to augment clojars called clopi (Clojure
Package Index), that will let you filter
Ah, sorry, perhaps I misunderstand you, but if you use multimethods
(defmulti) in Clojure you do not need to attach methods to anything.
The defmulti will allow you dispatch-on-type based on the key which
is present in the map (e.g. if :delete is present or if :insert is
present).
The nice thing
Thanks a lot for the link to the paper about FRP! My personal thinking
is going 90% in the same direction that the paper describes. I am
happy to see that somebody else did the hard work of writing it
down :)
Is anybody aware of an implementation of such an approach for Clojure?
--
You received
Hi all,
I just had a lengthy debugging session behind me to find out why maven
hangs when trying to execute the clojure:compile target of the
clojure-maven-plugin.
I found out that the problem does not lie in maven but in clojure (or
in my code if you want to see it that way). My code executes
Hello,
after my first attempts with clojure I needed to evaluate the clojure
results against pure Java results.
First to make my report complete here are my OS and JVM details. I run
my tests on an Ubuntu 64bit 10.04 on Intel i7 3GHz hardware with a
custom compiled kernel using the BFS
I understand the differenece between Object vs doubles and in fact I
do not want to point out that C is faster than Java (which it is not)
but I want to see the 10:1 speed improvement between my Batcher sort
implementation and the standard sort.
The ellipticgroup Benchmark class is very
Hi all,
just out of interest I've done the tests with double arrays in Java.
The results for the Arrays.sort are 1.060us. Now it's becoming
interesting. The results for the Batcher sort are: 803.784ns. Already
an improvement! Finally I've tried once again to do the Batcher double
sort in the same
28 matches
Mail list logo