date:20091218

Laurent,
1.  You are correct.  juxt returns a vector.  This is based on some
old articles I wrote, and I must of missed those references.
2.  Guilty :)  The partial is (deliberate) overkill.

Sean

On Dec 18, 4:17 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 Hello,

 2009/12/18 Sean Devlin francoisdev...@gmail.com





  Hello everyone,
  Today I'd like to shed some light on a new funciton in 1.1, juxt.  In
  order to understand juxt(apose), I'd like to first talk about comp
  (ose).  Comp can be defined in terms of reduce like so:

  (defn my-comp [ fns]
   (fn [args]
     (reduce
       (fn[accum f](f accum))
       (conj (reverse (seq fns)) args

  Granted, this isn't 100% equivalent to the Clojure comp function, but
  it is very, very close.  What it demonstrates is that comp applies a
  list of functions in series using reduce.  After writing Clojure for a
  while, one usually finds frequent need to apply a list of functions in
  parallel using map.  juxt can be defined as follows

  (defn juxt [ fns]
   (fn[  arg] (map #(apply % args) fns)))

  Notice that juxt creates a closure.  The most straightforward case is
  to *predictably* access multiple values from a map.

  user=(def test-map {:a 1 :b 2 :c 3 :d 4})

  user=((juxt :a :c) test-map)
  (1 3)

 Which version of juxt are you using ? Mine (from branch 1.1.x) returns a
 vector, not a list/seq







  However, as one works with maps more and more, situations arise where
  it is desired to perform many operations on a map at once.  For
  example

  ;assume parse-int turns a string to an int appropriately
  user=((juxt :a (comp parse-int :c)) test-map)
  (1 3)

  Since juxt returns a closure, it is very useful in any place one would
  use a map operation as well.  For example, this can make turning a
  list of maps into a list of lists very easy. Also, this made it very
  easy to determine if a sub-selection of a hash-map is equal to another
  hash- map

  user=(def test-juxt (juxt :a :c))
  user=(= (test-juxt {:a 1 :b 2 :c 3}) (test-juxt {:a 1 :b 34 :c 3}))
  true

  One thing that is very interesting is that this function allows one to
  simulate the behavior of let in a point-free style.

  ;This is deliberate overkill for a small example
  ;Generate a list of squares
  ;Notice that the juxt fn uses the range twice
  user=((partial map (juxt identity #(* % %))) (range 1 6))
  ((1 1) (2 4) (3 9) (4 16) (5 25))

 We're used to you being in love with point-free style, but the above example
 really does not need to use partial ?
 (map (juxt (identity #(* % %)) (range 1 6))

 ;-)

 Anyway thanks for sharing this since it's not in my zone of comfort so it's
 interesting stuff to think about.





  This also is useful when combined w/ clojure.contrib/group-by.
  Suppose you have a sales database with a table in it.  This table keep
  tracks of each sale (:id), when it happened (:year, :quarter), who
  sold it (:sold-by), and what category (:category) the product was
  in.

  It is obviously useful to group items by who sold it, or what category
  it was sold under.  However, it is also interesting to see which
  employees are selling which items.  This is a grouping by :sold-by
  AND :category.  In order to get at this information we'd do the
  following.

  ;Assume our sales data is a list of maps, in the sales-coll variable
  ;returns a map with two element vectors as keys, a list of maps as the
  vals.
  user=(group-by (juxt :sold-by :category) sales-coll)
  Lots-Of-Data

  Now, what happens when you need to change how you group the data?
  Instead of :sold-by  :category, you need :year  :quarter?  juxt
  makes it easy.

  user=(group-by (juxt :year :category) sales-coll)
  Lots-Of-Different-Data

  And finally, what happens when you need to break it down by all for
  variables simultaneously?

  user=(group-by (juxt :year :category :sold-by :category) sales-coll)
  Our-Last-Data-Sample

  There are tons of other uses for juxt, and I would encourage you to
  experiment and find out some of these uses yourself.  I hope these
  examples help everyone understand how to use the new operator.

  Happy Hacking,
  Sean

  --
  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.comclojure%2bunsubscr...@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 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

Re: mapmap

Konrad,
Yeah, there are discussions of two libs there.  The idea is that most
of the fn in this thread will be used for table-utils.

The last entry is the most relevant to a map-utils library.  Check out
the visitor stuff:

http://groups.google.com/group/clojure-dev/msg/6c1bbce17cafdf52

The idea is to take your generic functor application idea and put it
on steroids.  I'm going to be writing about this a lot more once 1.1
is out the door.  A whole lot.

Sean

On Dec 18, 3:50 am, Konrad Hinsen konrad.hin...@fastmail.net wrote:
 On 17 Dec 2009, at 20:26, Sean Devlin wrote:

  Konrad,
  I am working on a different proposal on the dev list:

 http://groups.google.com/group/clojure-dev/browse_thread/thread/9a518...

  This is a more in depth version of these functions for maps.  I'd love
  to have you contribute to the discussion here.

 I vaguely remember that discussion, but at the time I was too busy  
 with other things to look at it. Now I did, but I don't think I have  
 much to contribute. The way maps are used in the code examples of that  
 thread just doesn't occur in the applications I have for Clojure.

 Just one general remark: I don't think it is a good idea to structure  
 libraries around Clojure datatypes, as it is implied by a library name  
 such as map-utils. Clojure's built-in data types can implement many  
 different data abstractions, and I'd prefer to structure libraries  
 around those abstractions rather than around the concrete  
 representations. BTW, this is also the reason why I like multimethods  
 and protocols, as very often an abstraction can have multiple  
 practically useful implementations.

 Let's take maps as an example. A map can represent a table, or a small  
 database. A map can also represent a function defined on a finite set  
 of arguments. The operations used on maps are likely to be different  
 for those two use-cases, and it is even quite possible that the same  
 operation should have a different name for each application. So I'd  
 rather see a library table-utils and another library discrete-function-
 utils. The latter should also provide implementations of its functions  
 for vectors, which can represent functions defined on a finite range  
 of integers.

 The discussion in the thread you cite turns mostly around using maps  
 to represent tables. As I said, I don't have much use for this, so my  
 only recommendation is to call it table-utils rather than map-utils  
 and to envisage altenative representations, such as on-disk databases.

 Konrad.

-- 
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

Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Patrick Kristiansen

Hi

We're two students that have been working with concurrent programming
languages (Erlang and Clojure), and while both languages are very
interesting, we would like to work on something related to Clojure in
our masters thesis.

I once asked on #clojure for ideas, and Rich Hickey suggested looking
into predicate dispatch and it is one idea that we are considering. We
have also considered working on distributed Clojure, but I don't know
if there is already an effort going on in that regard?

Do you have any other suggestions? We'd be really thankful for any
suggestions.

Thanks in advance.

-Patrick

-- 
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

leiningen with latest clojure

2009-12-18 Thread Andrea Tortorella

I'm new to the group, I've been following clojure development for a
while, and I want to thank rich and you all for the fantastic work.

I'd like to ask how to use leiningen with the latest clojure
development new branch, is this possible?

thanks,
Andrea Tortorella

-- 
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 analysis



On 18 Dec 2009, at 06:42, Mike Meyer mwm-keyword-googlegroups.620...@mired.org 
  wrote:

 On Fri, 18 Dec 2009 00:44:02 -0500
 Luc Préfontaine lprefonta...@softaddicts.ca wrote:

 Mike, I think that the whole issue about Lisp creates a big cloud  
 about
 Clojure.

 Yes, it does. When I mention that, people tend to shudder.

That's the price Clojure pays for S-exprs rather than using M-exprs or  
even Dylan-exprs.

Clojure quacks like a lisp.

Martin



 If you sum up Clojure as being a Lisp because of what it look likes  
 and
 use only this to compare it to other
 languages then you are missing the forest and looking at a single  
 tree.

 I agree with that as well. My point wasn't that Clojure is just
 another LISP, it's that a good grasp on writing LISP well gets you
 over the biggest hurdle in going from C-family languages to Clojure.

 If you code in a Lisp like language using setq or set! or alike  
 then you
 can get very far away from functional
 programming and end up writing procedural code with parenthesis. You
 will eventually face the issues that Clojure avoids.

 Yup, but those were considered bad style in the places I learned
 LISP. If you avoided those - as I was taught to do - the code you
 wrote looks a lot like most of the Clojure code I've seen to date.

 Clojure takes a brutal approach, forget the left-right assignment  
 that
 almost every language eventually
 supports, forget variable mutations visible to everyone, forget
 procedural code...
 Oups these are the real show stoppers independently of the syntax  
 used.
 There's no escapes in Clojure while in other languages you can still
 cheat (setq/set! and similar).

 Why don't you consider ref's and atoms escapes in Clojure? I can use
 those to write C code with Clojure syntax, just like I can use setters
 to write C code with Scheme syntax. The point isn't how easy/hard it
 is to write C code with that syntax; it's that well-written LISP looks
 an awful lot like well-written Clojure.

 What I found non-trivial in Clojure were these restrictions, no the
 syntax. As soon as I understood
 the decisions behind these choices, my mental blockage vanished.

 Again, I agree. The real issue isn't the syntax, it's the
 *mindset*. Well-written LISP is functional, and tends to avoid set,
 and dynamically scoped variables, and macros that capture variables,
 and all such things. Sure, they're available if you find yourself
 stuck, but they shouldn't be your first choice.

 Immutable data structures, transparent iterations over a variety of
 structures,  lazy sequences, a workable STM implementation,
 parallel processing capabilities ridiculously simple to use, huge  
 set of
 Java librairies available, easy to use, ...
 These are the real features that make Clojure distinct from other
 languages. All the choices made are sound and the
 sum of these decisions is coherent. Nothing looks like it's been  
 added
 late to fill a gap like a nose in a face.

 Yes, but it's the sum of those choices that make Clojure
 distinct. Each of them exist in one or more other languages.

 My point was that of all of those features, the hardest to get used to
 if you haven't seen it before is the LISP-like functional programming
 aspect. That's a fundamental change in the way you program. The rest
 of them - well, they may be major improvements in the areas they touch
 upon, but they don't change they way you think about programming much
 outside of that area. Those others are like switching from playing
 cornerback to safety, or defensive end to tackle. Getting used to pure
 functional programming the first time is like switching from defensive
 end to wicket-keeper.

 I adhere to justified critics when a rationale has been exposed
 otherwise I call it (repeat blablabla).

 I wasn't claiming that the original analysis was anywhere near
 correct. I was responding to the claim that two or three months wasn't
 enough time to learn Clojure well. I don't see anything here that
 someone who's already got their head around writing pure functional
 code should have a lot of trouble with in that amount of time. Sure,
 there are other pure functional languages with loopholes - and even
 some with high-level concurrency features - but those are all even
 less popular than LISP when it comes to real-world programming.

 To expose some rationale it implies that you understand the subject  
 you
 are talking about. If you don't then you should
 be cautious about what you state or you state it conditionally.

 You state that as if there were hard scientific facts behind any of
 this. When was the last time you saw a serious scientific study of how
 any of these features - or pretty much any set of features - affect
 programmer productivity? All we've got is hearsay and personal
 experience, possibly gussied up as case studies to make them sound
 respectable.

 So would it make you happy if I point out that my conclusions are
 based on my experiences? I think comparing

Var clojure.core/refer is unbound???

2009-12-18 Thread Gorsal

So im trying to do some extremely simple AOT. However, when i run the
following code i get an error which i swear ive seen before but i dont
quite remember how to fix it!

(ns console.TheConsole
 (:gen-class
  :extends org.eclipse.ui.console.IOConsole
  :constructors  {[] [String
org.eclipse.jface.resource.ImageDescriptor]}
  :init console-init
   ))

(defn -console-init []
  [[The Console nil] []] )

Error:
Caused by: java.lang.RuntimeException:
java.lang.IllegalStateException: Var clojure.core/refer is unbound.
at clojure.lang.RT.clinit(RT.java:295)
... 59 more
Caused by: java.lang.IllegalStateException: Var clojure.core/refer is
unbound.
at clojure.lang.Var.deref(Var.java:140)
at clojure.lang.Var.fn(Var.java:336)
at clojure.lang.Var.invoke(Var.java:359)
at clojure.lang.RT.doInit(RT.java:421)
at clojure.lang.RT.clinit(RT.java:292)

Any ideas???

-- 
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

1.1 changes.txt typo

2009-12-18 Thread David Thomas Hume

From the 1.1 release notes:

Futures represent asynchronous computations. They are away to get
code to run in another thread, and obtain the result.

I know away is just a typo for a way, but be damned if that isn't
the best pun I've seen in a while.

Apologies if this seems like noise, but it brightened my last pre-
holiday work day, and I wanted to vote for not changing it, apart from
possibly adding a warning not to bank on them.

-Dave

-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread ajay gopalakrishnan

Hi,

An idea I was interested in (more from an learning opportunity perspective
than thesis) is provided more Persistent data structures. As of now, we have
the the Array mapped Hash tree based structure that works well for Vectors,
Maps and Graphs too. What I feel is missing is Tree based structures.
Although, you can simulate them using Vectors as children indices, I think
if we directly implement the Persistent Data structure of Binomial/Fibonacci
Heaps and BSTs with all their operations (insert,delete,search,meld), it
would be much faster. I could be wrong though!

Anyways ... my 2 cents.

Thanks,
Ajay G.

-- Forwarded message --
From: Patrick Kristiansen patrick.kristian...@gmail.com
Date: Fri, Dec 18, 2009 at 7:35 AM
Subject: Call for masters thesis ideas (possibly related to Clojure)
To: Clojure clojure@googlegroups.com


Hi

We're two students that have been working with concurrent programming
languages (Erlang and Clojure), and while both languages are very
interesting, we would like to work on something related to Clojure in
our masters thesis.

I once asked on #clojure for ideas, and Rich Hickey suggested looking
into predicate dispatch and it is one idea that we are considering. We
have also considered working on distributed Clojure, but I don't know
if there is already an effort going on in that regard?

Do you have any other suggestions? We'd be really thankful for any
suggestions.

Thanks in advance.

-Patrick

--
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.comclojure%2bunsubscr...@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 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: Call for masters thesis ideas (possibly related to Clojure)

Most of the distributed Clojure work is based on running Clojure on a
distributed JVM package.

Here's a link on Clojure + Terracotta.  I have heard mention of other
solutions as well, I just don't recall them.

http://groups.google.com/group/clojure/browse_thread/thread/9a9690947617906/6bc50fb45ca56e7d

Sean

On Dec 18, 7:35 am, Patrick Kristiansen
patrick.kristian...@gmail.com wrote:
 Hi

 We're two students that have been working with concurrent programming
 languages (Erlang and Clojure), and while both languages are very
 interesting, we would like to work on something related to Clojure in
 our masters thesis.

 I once asked on #clojure for ideas, and Rich Hickey suggested looking
 into predicate dispatch and it is one idea that we are considering. We
 have also considered working on distributed Clojure, but I don't know
 if there is already an effort going on in that regard?

 Do you have any other suggestions? We'd be really thankful for any
 suggestions.

 Thanks in advance.

 -Patrick

-- 
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: Any interest in a Nova Clug?

2009-12-18 Thread Mike Hogye

Reston is a great location for me and my coworkers, too.

On Dec 17, 9:50 am, Mike Hogye stacktra...@gmail.com wrote:
 I'm interested, but may have a hard time making it consistently. I do
 have a coworker or two who might have both interest and availability.

 On Dec 16, 1:14 pm, Matt macourt...@gmail.com wrote:



  I'm looking into setting up a Northern Virginia Clojure User Group and
  would like to know who is interested. I know there is a DC clojure
  study group, but it seems to not be as active recently. DC is also
  hard for me to get to during the week.

  We have a couple of other user groups which meet once a month right
  here in my office in Reston, VA. If there are enough people
  interested, I can coordinate with the other user group organizers to
  start a Clojure user group using the same meeting space.

  Questions? Comments? Hassletations? Aggravations? Contemplations?

-- 
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 The whole language is there, all of the time.

2009-12-18 Thread Jeff Dik

On Wed, Dec 09, 2009 at 02:35:24PM -0800, Joost wrote:
 On 9 dec, 17:03, Jeff Dik s45...@gmail.com wrote:
  The part Running code at read-time lets users reprogram Lisp's
  syntax caught my attention.  Is this talking about reader macros?  I
  believe I read that clojure doesn't have reader macros, so would it be
  more accurate to say The whole language is there, _most_ of the
  time?
 
 Clojure doesn't have user-implementable reader macros, but neither
 does emacs lisp. Reader macros are nice when you need to embed a
 significantly different looking kind of language - that's why clojure
 implements regular expressions as a reader macro instead of a function
 on a string; you'd have to doubly escape every backslash otherwise.
 But they're mostly only a way to provide syntactic sugar.
 
 I think what Paul is +mainly+ talking about in terms of syntax is
 just plain ordinary macros that can implement short-circuiting and
 different evalution strategies for readable data, so that you can
 implement things like (unless ...) yourself, with no (significant)
 overhead compared to the built in (if), but you'll have to keep to the
 basic reader constructs (but not evalution rules). This has the
 advantage of keeping the language simpler to parse and readble for
 humans too.
 
 The other part of the always there is that you can use whatever is
 already compiled/parsed to construct new macros, so you can build
 macros on top of each other, and on top of a mix of macros and (user-
 defined) functions instead of being restricted to the traditional
 sparseness of C preprocessor macros.

Thanks to everyone who replied to my question!  I had not realized that
clojure had built-in reader macros (which I should have realized from
section 2.2 Reader Macros of Programming Clojure).  The day I
wrote the original email was the first day I think I actually realized
what reader macros do, which, in retrospect, should have been obvious
from their name.  Just another example of Lisp blowing my mind.

I wasn't advocating user-creatable reader macros or bemoaning the lack
of them in Clojure.  I trust Rich Hickey's judgment :-) He's
much smarter than me and is an excellent language designer[1] (IMHO).

Still, I may have to play with user-creatable reader macros in Scheme
or Common Lisp.  I can see how they could make code harder to read if
a lot of people used them, but wonder if people standardized on some
of them, if they might make it more easier to write code for certain
fields (e.g. matrix math).  I think Graham Fawcett's idea of having an
experimental branch of Clojure that allowed user-creatable reader
macros is a good idea and wish I was smart enough to do it :-)

Thanks,
Jeff

[1]: Side note.  I think one of the best illustration's of Rich's
genius[2] is that he was able to combine Lisp, Java, functional
programming, and concurrency into such a beautiful language, as
opposed to Bjarne Stroustrup (also extremely smart) taking C and
adding OOP, etc, and making a lot of very reasonable decisions, and
still coming up with a monstrosity.

[2]: Side note on the side note.  Another example of Rich's genius are
the changes to Clojure for version 1.1.

 
 -- 
 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 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: Any interest in a Nova Clug?

2009-12-18 Thread Matt

I've started a meetup for a National Capital Area Clojure Users Group:

http://www.meetup.com/Cap-Clug/

The meetings will be held in Reston, but another user group organizer
in the area suggested I go with National Capital Area instead of
northern Virginia so it be more inclusive.

Our first meeting is scheduled for January 14th. I'm looking for pizza
sponsors and speakers.

-- 
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: Help recreating OS X Leiningen 1.0 +Swank bug

2009-12-18 Thread mac

I think I have solved the arguments issue but I had a strange bug with
clojure.test which worries me a little bit. If you can try this out
and see if it works for you that would be great:
http://github.com/bagucode/leiningen/tree/setfork

/mac

On Dec 17, 7:02 pm, Steve Purcell st...@sanityinc.com wrote:
 I came across this problem too, and David's patch helps, to a certain extent.

 Additionally, without David's patch, the src and test directories of the 
 current project don't get added to the classpath one sees from inside swank. 
 (All the jars upon which leiningen depends *are* in the classpath, which is 
 probably also less than ideal.)

 However, by forking the JVM, the console output is reformatted unpleasantly 
 by Ant, and any JAVA_OPTs etc. passed to lein's master JVM are not passed 
 through.  The former is a nuisance, but the latter stops you from running 
 Swank with an increased max memory allowance, for example.

 Given my immediate goal of processing a moderate pile of data within a swank 
 REPL session and charting it with Incanter, I have had to revert to 
 swank-clojure-project, when it would have been considerably cleaner to use 
 lein swank.

 I'm trying to get my head around what can be done here, and will report back 
 if I have any insights. It's been so nice to let leiningen take care of the 
 classpath for me, having abandoned Java years ago for less encumbered 
 languages. (Ah, my old nemesis CLASSPATH, finally we meet again!)

 -Steve

 On 9 Dec 2009, at 19:13, David Nolen wrote:



  I found a solution to this problem and patched my own fork of Leiningen:

 http://github.com/swannodette/leiningen/commit/9d79d631a9faa870a93479...

  The important thing to do if you want this to work is to closely follow the 
  instructions for hacking on Leiningen that's currently available on GitHub. 
  Then you need a custom-build of lein-swank. This is easy enough to do, move 
  into lein-swank in your Leiningen checkout and run:

  lein uberjar

  You might see some errors but none are deal breakers. Copy the new 
  lein-swank-standalone.jar and replace the one in that is in your lib folder 
  in your leiningen checkout.

  David

  On Tue, Dec 8, 2009 at 11:35 AM, David Nolen dnolen.li...@gmail.com wrote:
  Just want to make sure other people are seeing this on OS X. When starting 
  up lein swank from the project directory and attempting to connect from 
  Emacs with slime-connect with this simple clojure 
  projecthttp://github.com/swannodette/lein-macosx-bug(just creates a JPanel 
  and draws a small line) I get an exception:

  Cannot load apple.laf.AquaLookAndFeel

  I'm using lein 1.0, usual Emacs/Clojure/SLIME config on OS X 10.6, JDK 1.6 
  64bit.

  I note that if I use leiningen from git checkout I don't have this problem 
  which seems odd since there aren't many changes between 1.0 and 
  leiningen/master.

  Thanks,
  David

  --
  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 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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Tassilo Horn

ajay gopalakrishnan ajgop...@gmail.com writes:

Hi Ajay,

 An idea I was interested in (more from an learning opportunity
 perspective than thesis) is provided more Persistent data structures.
 As of now, we have the the Array mapped Hash tree based structure that
 works well for Vectors, Maps and Graphs too.

In the last few month I didn't find any time to play around with clojure
or follow discussions on this list, so could you give me a pointer to
persistent graph structures?  That would be an area where I would be
utmost interested.

Bye,
Tassilo

-- 
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 fund open source Clojure development

2009-12-18 Thread Joost

On 16 dec, 21:48, Joe globalwarmingisah...@gmail.com wrote:
 a. Offer new clojure features in binary form to developers who pay
 $100 a year 3 months before everyone else.

Would stifle development and piss off everybody who's working with
clojure and doesn't want to pay.

 b. Run a clojure programmer temp and/or high level consulting agency.

Running an agency costs money. Who is going to do all the work?
Basically you're asking for a company or other intested parties to
donate money. That's what Rich is doing already.

 c. Charge for cert testing and training.

See b. Also: I bloody hate tests.

 d. Sell for access to online library api calls.

If you want to kill off clojure that would be a good idea.

 e. Find a business for whom Clojure is a critical piece of technology.

Yes. See b)

 f. Get employed by a standards body or consortium trying to develop
 parallel programming.

Who? What? See b)

 g. Keep Clojure open source but make native tool chain compilers for
 various platforms available only online-ie android.

See d)

 h. Sell support contracts or create a business that does that and than
 employs you, similar to RedHat.

See b)

 i. Sell Clojure training classes to teachers and schools, advocating
 that Clojure is ideal for the classroom since it combines the
 widespread industry tool Java and the comp sci friendly and desireable
 Lisp.

See b)

-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Niels Mayer

(0)  Create a toolkit to run multiple parallel, tightly communicating
clojure apps on google-app engine, simulating a single, long-running,
multithreaded JVM instance that does not appear, to the user, to be limited
by the constraints of GAE's java implementation (e.g. single threading,
shared refs work despite being distributed); at the same time, the toolkit
would minimize resources consumed in GAE, persisting threads/continuations
waiting for data, and heuristically determining lowest cost for long-term
storage versus memory and runtime consumption.

Note: http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html

THE BIG CAVEAT


  Two unusual aspects of the Google AppEngine environment create pretty major

 constraints on your ability to write idiomatic Clojure.


  First, an AppEngine application runs in a security context that doesn't

 permit spawning threads, so you won't be able to use Agents, the

 clojure.parallel library, or Futures.


  Second, one of the most exciting features of AppEngine is that your

 application will be deployed on Google's huge infrastructure, dynamically

 changing its footprint depending on demand. That means you'll potentially be

 running on many JVMs at once. Unfortunately this is a strange fit for

 Clojure's concurrency features, which are most useful when you have precise

 control over what lives on what JVM (and simplest when everything runs on

 one JVM). Since shared references (Vars, Refs, and Atoms) are shared only

 within a single JVM, they are not suitable for many of their typical uses

 when running on AppEngine. You should still use Clojure's atomic references

 (and their associated means of modification) for any state that it makes

 sense to keep global per-JVM, since there may be multiple threads serving

 requests in one JVM. But remember JVMs will come and go during the lifetime

 of your application, so anything truly global should go in the Datastore or

 Memcache.


(1)  a clojure implementation of Yahoo's PNUTs, using STM's and all the cool
facilities clojure provides: http://research.yahoo.com/files/pnuts.pdf
(interesting
to have a writeup of a real-world impl alongside comparisons to Google
Bigtable and Amazon Dynamo)

We describe PNUTS, a massively parallel and geographically distributed
 database system for Yahoo!'s web applications.


 The foremost requirements of web applications are scalability, consistently
 good response time for geographically dispersed users, and high
 availability. At the same time, web applications can frequently tolerate
 relaxed consistency guarantees.


 For example, if a user changes an avatar ... little harm is done if the new
 avatar is not initially visible to one friend  It is often acceptable to
 read (slightly) stale data, but occasionally stronger guarantees are
 required by applications.


 PNUTS provides a consistency model that is between the two extremes of
 general serializability and eventual consistency ... We provide per-record
 timeline consistency: all replicas of a given record apply all updates to
 the record in the same order  The application [can] indicate cases where
 it can do with some relaxed consistency for higher performance  [such as
 reading] a possibly stale version of the record.


Some interesting commentary from
http://glinden.blogspot.com/2009/02/details-on-yahoos-distributed-database.html

http://glinden.blogspot.com/2009/02/details-on-yahoos-distributed-database.html
..
*
*
*When reading the paper, a couple things about PNUTS struck me as
surprising:

First, the system is layered on top of the guarantees of a reliable pub-sub
message broker which acts both as our replacement for a redo log and our
replication mechanism. I have to wonder if the choice to not build these
pieces of the database themselves could lead to missed opportunities for
improving performance and efficiency.

Second, as figures 3 and 4 show, the average latency of requests to their
database seems quite high, roughly 100 ms. This is high enough that web
applications probably would incur too much total latency if they made a few
requests serially (e.g. ask for some data, then, depending on what the data
looks like, ask for some other data). That seems like a problem.

Please see also my August 2006 post, Google Bigtable
paperhttp://glinden.blogspot.com/2006/08/google-bigtable-paper.html,
which discusses the distributed database behind many products at Google.

Please see also my earlier post, Highly available distributed hash store at
Amazonhttp://glinden.blogspot.com/2007/10/highly-available-distributed-hash.html,
on the distributed database behind some features at Amazon.com.

Please see also my earlier posts, Cassandra data store at
Facebookhttp://glinden.blogspot.com/2008/08/cassandra-data-store-at-facebook.html
and HBase: A Google Bigtable
clonehttp://glinden.blogspot.com/2007/07/hbase-google-bigtable-clone.html
.

Update: One of the developers of PNUTS

Re: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Joost

On 18 dec, 13:35, Patrick Kristiansen patrick.kristian...@gmail.com
wrote:
 Hi

 We're two students that have been working with concurrent programming
 languages (Erlang and Clojure), and while both languages are very
 interesting, we would like to work on something related to Clojure in
 our masters thesis.

 I once asked on #clojure for ideas, and Rich Hickey suggested looking
 into predicate dispatch and it is one idea that we are considering. We
 have also considered working on distributed Clojure, but I don't know
 if there is already an effort going on in that regard?

 Do you have any other suggestions? We'd be really thankful for any
 suggestions.

Erm, what's your master? I'll assume CS.

Personally, I'm interested in whether complete thread abstraction that
makes threads as light-weight as possible, but also the only way to
do concurrency (like Erlang provides with its processes) is really
the best way to model concurrent programs. I'm over 95% sure that
native threads really are not the best way to model in-process
concurrency for most programs, simply because of all the overhead that
you incur especially when dealing with massively concurrent long-
running thead-like-things - since you both know erlang, you will know
what I'm talking about - that sort of approach really doesn't work in
clojure, that's why clojure uses thread pools for agents etc.

But maybe a new and lightweight in-kernel thread model is an
interesing subject? Just asking :)

Good luck with your thesis,
Joost Diepenmaat.

-- 
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

Advice for someone coming from an OO world?

2009-12-18 Thread IslandRick

Up until a month ago, my total Lisp experience consisted of hacking
my .emacs file to bend it to my will -- a lot.  Discovering Clojure
was amazing.  I immediately liked several aspects of it, especially
how compact it feels and easy it is to do complex functional tasks.

I decided the best way to get to know Clojure is to write something in
it.  So I've been doing a stock-market backtesting simulator with
Clojure in my nights  weekends.  There's just one problem: I think
I'm tainted by too much exposure to OO.

I often find my self going upstream, against the language.  I want to
have an object and send it a message or invoke it, rather than
invoking a function in some package and happening to pass it the right
type of thing.  An object-oriented model feels more natural to me,
and when I try to express that design in Clojure, I wind up doing a
lot of awkward-feeling things involving watchers and agents.

As an experiment, I switched over to Ruby, and within 2 hours I had a
basic scaffolding up and running.  Now I know being new to Clojure
means I shouldn't expect miracles, and I don't -- but it did feel like
I'm missing something.  Either too many years of OO have poisoned my
brain, or I'm just using the wrong tool for the job.

Can anyone here offer some advice to those who are too ingrained in
using an object-oriented hammer on every nail they see?  I know Rich
and Stuart have some good design examples around (I've read many), but
if there are any tutorials that show how to re-envision OO problems in
an FP world, I'd love to see them.

Thanks for the great  lively community,
Rick in Bainbridge Island, WA

-- 
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

Bert Clojure Implementation

2009-12-18 Thread Trotter Cashion

Hi,

I've mostly finished an implementation of Tom Preston-Werner's Bert
library in clojure. Bert is a binary serialization protocol that you
can read about at http://bert-rpc.org. My library is available on
github at http://github.com/trotter/bert-clj. I'd love for people to
give it a go and let me know if you find any bugs. Also, any tips on
coding style would be much appreciated. This is my first real open
source attempt in clojure.

- Trotter

-- 
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

bug or feature in (require ...)?

2009-12-18 Thread Alex Ott

Hello all

I found interesting behaviour of clojure when debugging why tests aren't
working when build incanter with maven...

In incanter there is following code:

(def test-names [:core-tests
 :stats-tests
 :io-tests
 :charts-tests
 :internal-tests
 :chrono-test
 :transformations-tests
 :probability-tests
 :information-theory-tests
 :bayes-tests])

(def test-namespaces (map #(symbol (str incanter. (name %))) test-names))

(defn run Runs all defined tests []
  (println Loading tests...)
  (apply require :reload-all test-namespaces)
  (apply run-tests test-namespaces))

that dynamically loads and executes set of tests. The problem is
if :reload-all option is used, then tests, defined in incanter.charts-tests
aren't working.  But when i change it to :reload, then all works fine.

It seems, that tests, that are loaded after charts-tests, completely reload
libraries, discarding previously loaded incanter.chart library, that is
used only in charts-tests...

Question - this is feature of require? or this is a bug?

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/http://xtalk.msk.su/~ott/
http://alexott-ru.blogspot.com/

-- 
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

Parenthesis Inference

I had this thought at work, when I should have been working, so please bear 
with me if it's nonsense.

One of the things that always puts people off of Lisp, as we all know, are the 
parentheses. Now, many ways have been suggested of doing this in other Lisps, 
but have never taken off, mainly due to inertia and a fear of sacrificing 
homoiconicity.

However, I love Clojure, and want to see it really take off. And so I want to 
see all barriers to that removed. Also, I think the language is young enough 
that seemingly-but-not-really radical proposals can still be sneaked in.

Let's take this example, since I note that Rich Hickey weighed in in the 
comments:

http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html

(apply merge-with +
(pmap count-lines
(partition-all *batch-size*
(line-seq (reader filename)

This little snippet has ten parentheses. And is potentially very unnerving to a 
non-lisper. Ten parentheses in four lines seems a lot to most programmers.

Rich, in the comments, suggests a pipelined style to make the code more 
readable:

(- (line-seq (reader filename))
  (partition-all *batch-size*)
  (pmap count-lines)
  (apply merge-with +))


I accept that this is more readable because it has less nesting. But it now has 
*12* parentheses, more than the original, potentially just as alarming to the 
Lispophobes.

My question is this: why can't we introduce a simple and importantly, optional 
'off-side rule' (much simpler than Haskell's) that allows the reader to infer 
many of the parentheses?

A very simple offside rule could turn the original into:

apply merge-with +
pmap count-lines
partition-all *batch-size*
line-seq (reader filename)


With a startling two parentheses and Rich's corrected version into:

-
  line-seq (reader filename)
  partition-all *batch-size*
  pmap count-lines
  apply merge-with +


Also with two. That last example in particular looks splendidly readable. 
Almost... monadic. 

The parenthesis inference here is very simple, and could be stated in two 
sentences:

For each line that is not within a vector, and does not have an opening 
parenthesis, infer an opening parenthesis at the start of the line. Remember 
the level of indentation, and infer a closing parenthesis at the end of the 
line *before* the next line whose indentation is the same as or less than the 
remembered one.

My question is: why would such a scheme work/not work, and why would/would not 
it be desirable?

Martin

-- 
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 analysis

2009-12-18 Thread Santhosh G R

 Lookup (and contrast) words analysis and opinion in your favorite
 dictionary.

Being a blog I thought that analysis would be from my perspective and
hence an opinion. Dictionaries become muddied in the blog world, and
mea culpa. If nothing else, at least I will make sure that I am
careful :-)

-- 
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: 1.0 Compatible Terracotta Integration Module

2009-12-18 Thread Sergey Didenko

Sounds interesting! Thanks.

Hope to look at it when I have more time in my hands.

On Thu, Dec 10, 2009 at 1:37 PM, Paul Stadig p...@stadig.name wrote:



 There is a new repo at http://github.com/pjstadig/tim-clojure-1.0.0/
 that has a 1.0 compatible version of the TIM. It should be simpler to
 setup and test (though it still depends on Maven...sorry). This time
 around I also tested it on Windows, because I know a couple people
 have asked about that.



-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Patrick Kristiansen

On Dec 18, 11:06 pm, Joost jo...@zeekat.nl wrote:
 Erm, what's your master? I'll assume CS.

Well it's software engineering, but close enough :). I should have
mentioned that.

 Personally, I'm interested in whether complete thread abstraction that
 makes threads as light-weight as possible, but also the only way to
 do concurrency (like Erlang provides with its processes) is really
 the best way to model concurrent programs. I'm over 95% sure that
 native threads really are not the best way to model in-process
 concurrency for most programs, simply because of all the overhead that
 you incur especially when dealing with massively concurrent long-
 running thead-like-things - since you both know erlang, you will know
 what I'm talking about - that sort of approach really doesn't work in
 clojure, that's why clojure uses thread pools for agents etc.

 But maybe a new and lightweight in-kernel thread model is an
 interesing subject? Just asking :)

Thanks for your suggestion. It's an interesting idea, and we've been
considering something along those lines. I don't know if Erlang's
processes are even more lightweight than green threads. According to
Wikipedia [1], Linux actually performs really well in terms of context
switching OS threads compared to green threads. But I can't find the
paper Wikipedia cites, and it seems not to be downloadable from ACM
[2].

In any case, we will take this suggestion into consideration.

[1] http://en.wikipedia.org/wiki/Green_threads#Performance
[2] http://portal.acm.org/citation.cfm?id=603551

-- 
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: Parenthesis Inference

2009-12-18 Thread Mark Engelberg

The main downside of such an approach is that if you copy and paste
your code to a new context in which it has a different level of
indenting, it's very easy to screw things up.  You then have no way to
re-indent the code without fully analyzing and understanding the
*semantics* of the code, because the only syntactic cues (the
whitespace) is now invalid and can't be trusted.

Lispers tend to like the fact that the parentheses can be used by the
computer to auto-format and auto-indent your code, and parens help
ensure that everything is grouped correctly (e.g., when you put your
cursor over a paren, it shows you the other paren that goes with it)
-- then once it is formatted, they use the indenting levels to
understand their code and ignore the parentheses.  But it's comforting
to know the parentheses are there should the code ever get moved
around or edited.

On Fri, Dec 18, 2009 at 11:07 AM, Martin Coxall pseudo.m...@me.com wrote:
 My question is: why would such a scheme work/not work, and why would/would 
 not it be desirable?


-- 
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: Parenthesis Inference

What you're looking for is called Python.

The parens are your friend.  Learn to love them.  They are there to
remind you that you're building a data structure, not just writing
code.

Sean

On Dec 18, 2:07 pm, Martin Coxall pseudo.m...@me.com wrote:
 I had this thought at work, when I should have been working, so please bear 
 with me if it's nonsense.

 One of the things that always puts people off of Lisp, as we all know, are 
 the parentheses. Now, many ways have been suggested of doing this in other 
 Lisps, but have never taken off, mainly due to inertia and a fear of 
 sacrificing homoiconicity.

 However, I love Clojure, and want to see it really take off. And so I want to 
 see all barriers to that removed. Also, I think the language is young enough 
 that seemingly-but-not-really radical proposals can still be sneaked in.

 Let's take this example, since I note that Rich Hickey weighed in in the 
 comments:

 http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html

 (apply merge-with +
         (pmap count-lines
                 (partition-all *batch-size*
                         (line-seq (reader filename)

 This little snippet has ten parentheses. And is potentially very unnerving to 
 a non-lisper. Ten parentheses in four lines seems a lot to most programmers.

 Rich, in the comments, suggests a pipelined style to make the code more 
 readable:

 (- (line-seq (reader filename))
   (partition-all *batch-size*)
   (pmap count-lines)
   (apply merge-with +))

 I accept that this is more readable because it has less nesting. But it now 
 has *12* parentheses, more than the original, potentially just as alarming to 
 the Lispophobes.

 My question is this: why can't we introduce a simple and importantly, 
 optional 'off-side rule' (much simpler than Haskell's) that allows the reader 
 to infer many of the parentheses?

 A very simple offside rule could turn the original into:

 apply merge-with +
         pmap count-lines
                 partition-all *batch-size*
                         line-seq (reader filename)

 With a startling two parentheses and Rich's corrected version into:

 -
   line-seq (reader filename)
   partition-all *batch-size*
   pmap count-lines
   apply merge-with +

 Also with two. That last example in particular looks splendidly readable. 
 Almost... monadic.

 The parenthesis inference here is very simple, and could be stated in two 
 sentences:

 For each line that is not within a vector, and does not have an opening 
 parenthesis, infer an opening parenthesis at the start of the line. Remember 
 the level of indentation, and infer a closing parenthesis at the end of the 
 line *before* the next line whose indentation is the same as or less than the 
 remembered one.

 My question is: why would such a scheme work/not work, and why would/would 
 not it be desirable?

 Martin

-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Joost

On 19 dec, 01:20, Patrick Kristiansen patrick.kristian...@gmail.com
wrote:
 Thanks for your suggestion. It's an interesting idea, and we've been
 considering something along those lines. I don't know if Erlang's
 processes are even more lightweight than green threads. According to
 Wikipedia [1], Linux actually performs really well in terms of context
 switching OS threads compared to green threads. But I can't find the
 paper Wikipedia cites, and it seems not to be downloadable from ACM
 [2].

The problem seems to be two part:

1. Starting new native thread takes a relatively long time

2. Native threads means a fairly significant memory and scheduler
consumption. In Java-based threads, that means for example that a
20,000 connection server is pretty much the maximum that's possible in
that model. In Erland, 20,000 concurrent connections is what you
should expect from an unoptimized system. This is at least partly due
to kernel design, but also due to language design. A purely side-
effect free language is much more capable of sharing data. In *that*
regard, it's probably easier to optimize Erlang than Clojure.

But in any case, massive networking is the key  - In clojure, there is
plenty of room to improve in that regard. In Erlang probably too, but
erlang has no really interesing memory sharing mechanisms.

-- 
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: Bert Clojure Implementation

2009-12-18 Thread Vagif Verdi

FYI
There a binary protocol library http://hessian.caucho.com/
It is pure java, supports all the primitives BERT has, has bindings to
many languages including Python, Ruby, Erlang, even Flash. And of
course because it is java, it is readily available from clojure.

It also supports streaming of course.

-- 
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: Parenthesis Inference

2009-12-18 Thread CuppoJava

In my personal experience, the fastest way to get accustomed to the
parenthesis is to learn how to read the indentation. That was the
biggest hurdle for me coming from reading C/Java code. Lisp
indentation is quite expressive and a little more subtle (unlike the
indent-two-spaces-for-a-loop scheme in C/Java). I think this point is
maybe not stressed enough. No one can actually read lisp code by
counting parentheses in their head.
  -Patrick

-- 
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: Parenthesis Inference

2009-12-18 Thread Vagif Verdi

Welcome to the big club of people who in last 50 years came up with a
brilliant idea to fix lisp.

As for Ten parentheses, i do not see a single one. Noone notices
starting parens because they are markers saying this is a function.
And of course noone notices ending parens because they are for your
IDE, not for the human.

-- 
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: Parenthesis Inference


On 19 Dec 2009, at 00:29, Mark Engelberg wrote:

 The main downside of such an approach is that if you copy and paste
 your code to a new context in which it has a different level of
 indenting, it's very easy to screw things up.  You then have no way to
 re-indent the code without fully analyzing and understanding the
 *semantics* of the code, because the only syntactic cues (the
 whitespace) is now invalid and can't be trusted.

My general feeling is that it's bad form to make sensitive whitespace the 
*only* option (I'm looking at you, Python).

What I'm wondering is whether there's any harm in making it available as an 
option, and whether it makes sense as a default. Haskell answered yes to both 
these questions, and what it gains Haskell in readability is well worth the 
tradeoff.

However, I agree that fully-parenthesized syntax should always be available to 
those that want it. But I assume that it's Rich's plan that Clojure should be 
more accessible than to just Lisp-heads, and a less parenthesized syntax might 
go a long way to easing their jitters.

Martin

-- 
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: Parenthesis Inference

2009-12-18 Thread Mike Meyer

On Fri, 18 Dec 2009 19:07:43 +
Martin Coxall pseudo.m...@me.com wrote:

 For each line that is not within a vector, and does not have an opening 
 parenthesis, infer an opening parenthesis at the start of the line. Remember 
 the level of indentation, and infer a closing parenthesis at the end of the 
 line *before* the next line whose indentation is the same as or less than the 
 remembered one.
 
 My question is: why would such a scheme work/not work, and why would/would 
 not it be desirable?

Congratulations, you've just (re-invented) ABC  Python.

It can work. It's very comfortable to write, as it cuts down on a lot
of the syntactic noise in a program.

Downsides:

- Breaking the formatting of code beaks the meaning.
- Cutting and pasting inside a program becomes more interesting. It
  can be done - emacs can rigidly indent a region that's been pasted
  to the right place - but you can't really fix it by hand later.
- The size of tabs suddenly *matters*.

And the biggie:

- A lot of people find this significant whitespace as off-putting as
  the parenthesis in LISP. Not as many, but still a significant
  number.

mike
-- 
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread ajay gopalakrishnan

Put

*Comparative performance evaluation of Java threads for embedded
applications**: Linux thread vs. Green thread

Google, and click the second link that says [PDF]. It is for free.
*
On Fri, Dec 18, 2009 at 7:20 PM, Patrick Kristiansen 
patrick.kristian...@gmail.com wrote:

 On Dec 18, 11:06 pm, Joost jo...@zeekat.nl wrote:
  Erm, what's your master? I'll assume CS.

 Well it's software engineering, but close enough :). I should have
 mentioned that.

  Personally, I'm interested in whether complete thread abstraction that
  makes threads as light-weight as possible, but also the only way to
  do concurrency (like Erlang provides with its processes) is really
  the best way to model concurrent programs. I'm over 95% sure that
  native threads really are not the best way to model in-process
  concurrency for most programs, simply because of all the overhead that
  you incur especially when dealing with massively concurrent long-
  running thead-like-things - since you both know erlang, you will know
  what I'm talking about - that sort of approach really doesn't work in
  clojure, that's why clojure uses thread pools for agents etc.
 
  But maybe a new and lightweight in-kernel thread model is an
  interesing subject? Just asking :)

 Thanks for your suggestion. It's an interesting idea, and we've been
 considering something along those lines. I don't know if Erlang's
 processes are even more lightweight than green threads. According to
 Wikipedia [1], Linux actually performs really well in terms of context
 switching OS threads compared to green threads. But I can't find the
 paper Wikipedia cites, and it seems not to be downloadable from ACM
 [2].

 In any case, we will take this suggestion into consideration.

 [1] http://en.wikipedia.org/wiki/Green_threads#Performance
 [2] http://portal.acm.org/citation.cfm?id=603551

 --
 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.comclojure%2bunsubscr...@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 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: Parenthesis Inference


On 19 Dec 2009, at 00:53, Sean Devlin wrote:

 What you're looking for is called Python.
 
 The parens are your friend.  Learn to love them.  They are there to
 remind you that you're building a data structure, not just writing
 code.
 
 Sean
 

As it happens, I agree with you: I learned to stop noticing the parens a long 
time ago, and think that Clojure's rather pragmatic approach to 
parens-reduction (lambda/vector literals) and other syntactic conveniences 
(object invocation syntax, comma whitespace) strikes a good balance.

But I'm trying to think of it from the point of view of Joe Q. Coder, who will 
take one look at our beloved elegant, expressive Clojure, see all the parens 
and run screaming.

Many people find would Clojure's comparative lack of syntax very human-hostile. 
Who is the intended audience of Clojure? Is it other Lispers? Or other Java 
programmers?

Martin

-- 
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: leiningen with latest clojure

2009-12-18 Thread defn

Hello Andrea,

The default project.clj for a `lein new myproject` should provide you
with the latest snapshot.  Then, in the myproject directory run `lein
deps`.  This will pull down 1.1.0-master-SNAPSHOT per the settings in
project.clj which is as new as Dec. 18th, 16:00 at the time of writing
this.  I hope that helps.

Devin


On Dec 18, 7:00 am, Andrea Tortorella elian...@gmail.com wrote:
 I'm new to the group, I've been following clojure development for a
 while, and I want to thank rich and you all for the fantastic work.

 I'd like to ask how to use leiningen with the latest clojure
 development new branch, is this possible?

 thanks,
 Andrea Tortorella

-- 
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: Advice for someone coming from an OO world?

This came up on the group recently.  There was a lot of discussion
here:

http://groups.google.com/group/clojure/browse_thread/thread/c30e313ca2b0ee29#

On Dec 18, 11:55 am, IslandRick rick.braumoel...@gmail.com wrote:
 Up until a month ago, my total Lisp experience consisted of hacking
 my .emacs file to bend it to my will -- a lot.  Discovering Clojure
 was amazing.  I immediately liked several aspects of it, especially
 how compact it feels and easy it is to do complex functional tasks.

 I decided the best way to get to know Clojure is to write something in
 it.  So I've been doing a stock-market backtesting simulator with
 Clojure in my nights  weekends.  There's just one problem: I think
 I'm tainted by too much exposure to OO.

 I often find my self going upstream, against the language.  I want to
 have an object and send it a message or invoke it, rather than
 invoking a function in some package and happening to pass it the right
 type of thing.  An object-oriented model feels more natural to me,
 and when I try to express that design in Clojure, I wind up doing a
 lot of awkward-feeling things involving watchers and agents.

 As an experiment, I switched over to Ruby, and within 2 hours I had a
 basic scaffolding up and running.  Now I know being new to Clojure
 means I shouldn't expect miracles, and I don't -- but it did feel like
 I'm missing something.  Either too many years of OO have poisoned my
 brain, or I'm just using the wrong tool for the job.

 Can anyone here offer some advice to those who are too ingrained in
 using an object-oriented hammer on every nail they see?  I know Rich
 and Stuart have some good design examples around (I've read many), but
 if there are any tutorials that show how to re-envision OO problems in
 an FP world, I'd love to see them.

 Thanks for the great  lively community,
 Rick in Bainbridge Island, WA

-- 
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: Parenthesis Inference

2009-12-18 Thread Vagif Verdi

On Dec 18, 4:59 pm, Martin Coxall pseudo.m...@me.com wrote:
 But I'm trying to think of it from the point of view of Joe Q. Coder, who 
 will take one look at our beloved elegant, expressive Clojure, see all the 
 parens and run screaming.

Let James Gosling worry about Joe Q. Coder. He does a very good job at
that. Do you think HP worries that soccer moms will not use their
Engineering Calculators ?

 Who is the intended audience of Clojure? Is it other Lispers? Or other Java 
 programmers?

The intended audience are Software Engineers. Not the people who hide
behind this-is-not-intuitive their lack of willing to learn the most
effective way to spend their professional life.

-- 
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: Parenthesis Inference

Look, Clojure does a lot to make life easier.  But if Joe Q. Coder
isn't willing to *try* to work with parens, he won't have a chance
picking up Clojure.

It is proudly a Lisp for people that want to get things done.  Any
Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) that
want to get better are welcome.  However, there is a way things are
done in the language, driven by the underlying problems reality
imposes on developers.  A prospective Clojure developer must accept
that the language does this to help you, not hurt you, and they need
to be open to the ideas.

That is the intended audience.

Sean

On Dec 18, 7:59 pm, Martin Coxall pseudo.m...@me.com wrote:
 On 19 Dec 2009, at 00:53, Sean Devlin wrote:

  What you're looking for is called Python.

  The parens are your friend.  Learn to love them.  They are there to
  remind you that you're building a data structure, not just writing
  code.

  Sean

 As it happens, I agree with you: I learned to stop noticing the parens a long 
 time ago, and think that Clojure's rather pragmatic approach to 
 parens-reduction (lambda/vector literals) and other syntactic conveniences 
 (object invocation syntax, comma whitespace) strikes a good balance.

 But I'm trying to think of it from the point of view of Joe Q. Coder, who 
 will take one look at our beloved elegant, expressive Clojure, see all the 
 parens and run screaming.

 Many people find would Clojure's comparative lack of syntax very 
 human-hostile. Who is the intended audience of Clojure? Is it other Lispers? 
 Or other Java programmers?

 Martin

-- 
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: Parenthesis Inference

2009-12-18 Thread Anniepoo

  I read this and think of Roedy Green's essay on source code in
database, http://mindprod.com/project/scid.html and on Knuth's
'literate programming'  - the idea that source code is inherently not
it's representation (it's the reader output that's homoiconic, not the
file representation on disk) and that there might be several
representations.
  Reading Roedy Green's essay I think of how obsolete it sounds after
refactoring IDE's came around. Let me suggest that this is a great
idea, but one that should be part of some clojure-centric IDE, not a
part of the language.

It seems barking up the wrong tree to think that clojure will find
more acceptance if we find some method of reducing the number of
parens involved.
What's hostile to most programmers is that Clojure demands a lot more
thinking per line of code. I remember when OO came in, and then when
design patterns came in - each decreased the amount of thinking about
code and increased the amount of typing.
After all, the same java programmers who are frightened by Clojure are
happily reading nested structures in XML all the time.

-- 
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: Call for masters thesis ideas (possibly related to Clojure)

2009-12-18 Thread Niels Mayer

*Re:
Update: One of the developers of PNUTS
commentedhttp://glinden.blogspot.com/2009/02/details-on-yahoos-distributed-database.html?showComment=123388434#c1254841206330803677
on
this post, pointing out that PNUTS performance is much better in practice
(1-10ms/request) when caching layers are in place and making a few
comparisons to Bigtable.*

Note this very interesting conversation (below) which IMHO has potential
for STM implementation in clojure http://clojure.org/refs (excerpt: PNUTs
supports row-level transactions too-- they are done through a get followed
by test-and-set. This is nothing new: it is called optimistic concurrency
control and has been around in database literature for ages, and is also
used by BigTable.).

...

Can and would clojure help and simplify the construction of a framework for
high-volume, high-availability, distributed web apps? Has something like
PNUTs been implemented for Clojure and Java Clouds?

http://www.blogger.com/profile/07702915403582319413
Brian Cooper http://www.blogger.com/profile/07702915403582319413 said...

Hi folks,

I'm another member of the PNUTS group at Yahoo! This has been a very
interesting discussion; I'm glad you folks are as interested in this stuff
as we are.

Just to reiterate a few points that Utkarsh brought up:

- There's no free lunch for performance, and if you want consistency some
writes will have to go cross-datacenter, increasing the average latency.
Cross-datacenter communication is required because of our mastership
protocol. Consider a user who's record is mastered in California. If she
flies to Europe, or a network problem causes her request to be redirected to
a datacenter on the East coast, then her write will originate in a
non-master datacenter and be forwarded back to the master for that record.
In practice this happens 10-20% of the time, just because of the way web
requests happen.

Even if you had Paxos, and managed to put the local participants in the
same datacenter, occasionally a write would originate in the non-local
datacenter and pay the cross-datacenter latency to find enough members of
the quorum. So this cost is really unavoidable.

- You could weaken the consistency, to something like eventual consistency
(write anywhere and resolve conflicts later) or even best effort (write
anywhere and don't worry about conflicts) and avoid ever paying the
cross-datacenter cost. And in fact it is possible to turn off mastership in
PNUTS. But then you need a resolution protocol, and until conflicts are
resolved inconsistent copies of the data are visible to readers. So again
there is no free lunch.

- Anonymous is write that this system is not as optimized for scans a la
MapReduce. In fact, you make different architectural decisions if you are
optimizing for low-latency updates to a geographic database than if you are
optimizing for scanning for MapReduce within a single datacenter. We have
been able to run Hadoop jobs over PNUTS and get performance that is pretty
good, just not as good as a native store (HDFS) optimized for MapReduce. So
if you want to transactionally update data with very low latency and
occasionally run MapReduce, you can use PNUTS; if you want to always run
MapReduce but don't need a lot of high performance updates, use HDFS.

- As Utkarsh has said, the hardware used for the paper is not as good as
production hardware (e.g. no battery-backed write cache, and other
limitations). We hope to publish some numbers from live workloads on the
production system soon.
..

--
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: Parenthesis Inference

Martin Coxall pseudo.m...@me.com writes:

 My question is this: why can't we introduce a simple and importantly,
 optional 'off-side rule' (much simpler than Haskell's) that allows the
 reader to infer many of the parentheses? 

If you haven't seen them before, check out sweet expressions.  This guy
has put a lot of thought and experimentation into it.

http://www.dwheeler.com/readable/sweet-expressions.html

Coming from a background in Python and Ruby, I found S-expressions
initially very hard to read and would probably have loved something like
this.  However I pretty soon got used to the Lisp syntax and now I
actually prefer it.  If I did use something like sweet-expressions as
training wheels, I'd probably have stuck with them and then never have
learned to read other people's code and never discovered the joy of
paredit and SLIME.

It's possible to use paredit with other languages, but it
doesn't seem to work as well due to the lack of consistency.
Similarly, I have tried a couple of SLIME-like things for Ruby and
Python but they never worked quite as well as you have to resort to
manually selecting everything you want to eval, instead of just being
able to say eval last expression.  I guess in theory it should be
possible to make this work with an infix/whitespace-sensitive syntax but
the amount of extra effort involved must discourage implementation
efforts.

I agree with Anniepoo, if you really want to do something like this it's
probably better done in the editor rather than the language itsel.  By
putting it in the editor, you're retaining the simplicity in the actual
source-code, plus any file you open will be in your preferred syntax and
when you give your code to other people it will be in their preferred
syntax.

In fact it looks like there's already an Emacs mode for doing it on a
read-only basis:

http://www.emacswiki.org/emacs-zh/UnParenMode

I have at some point seen a mode that makes them invisible for editing
as well and uses whitespace and highlighting to indicate nesting, but I
can't find it now.

-- 
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: leiningen with latest clojure

defn dev...@gmail.com writes:
 On Dec 18, 7:00 am, Andrea Tortorella elian...@gmail.com wrote:
 I'd like to ask how to use leiningen with the latest clojure
 development new branch, is this possible?

 This will pull down 1.1.0-master-SNAPSHOT per the settings in
 project.clj which is as new as Dec. 18th, 16:00 at the time of writing
 this.

I think Andrea meant the new branch rather than the master branch.
Just use 1.1.0-new-SNAPSHOT as the version number for both clojure and
clojure-contrib and you should be okay.  Just be aware that if you pull
in other Clojure libraries they may be compiled against master and
won't work against new.  This compatibility will hopefully be sorted
out in future as slim jars (not AOT-compiled) are probably going to
become the default in most tools.

-- 
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: Parenthesis Inference

2009-12-18 Thread Seth

Many/most of the best programmers I know have allergic reactions to
parens. I think this is a normal reaction based on the amount of
successful time they have spent with ; terminated languages. FWIW, I
certainly flinch when I see Objective-C code with [ ] in strange
places, although these other programmers do not.

I'd like to think that forgetting about operator precedence and
enabling things like ( 1 2 3 4) are the first step to appreciating
list oriented mental parsing.

I don't hope Clojure ever becomes a lowest common denominator
language. There will always be a stream of competitors for that title,
like VB and Java. But I do hope that Clojure becomes widely known
enough to build a reputation for terse, fast, concurrency-friendly
code with a fair amount of punctuation. Remember, the punctuation
threshold for hello, world in Java is {([]){();}}

On Dec 18, 7:59 pm, Martin Coxall pseudo.m...@me.com wrote:
 On 19 Dec 2009, at 00:53, Sean Devlin wrote:

  What you're looking for is called Python.

  The parens are your friend.  Learn to love them.  They are there to
  remind you that you're building a data structure, not just writing
  code.

  Sean

 As it happens, I agree with you: I learned to stop noticing the parens a long 
 time ago, and think that Clojure's rather pragmatic approach to 
 parens-reduction (lambda/vector literals) and other syntactic conveniences 
 (object invocation syntax, comma whitespace) strikes a good balance.

 But I'm trying to think of it from the point of view of Joe Q. Coder, who 
 will take one look at our beloved elegant, expressive Clojure, see all the 
 parens and run screaming.

 Many people find would Clojure's comparative lack of syntax very 
 human-hostile. Who is the intended audience of Clojure? Is it other Lispers? 
 Or other Java programmers?

 Martin

-- 
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: Parenthesis Inference

Anniepoo annie6...@yahoo.com writes:

 What's hostile to most programmers is that Clojure demands a lot more
 thinking per line of code. I remember when OO came in, and then when
 design patterns came in - each decreased the amount of thinking about
 code and increased the amount of typing.

*shudder*  Yes, this is a seriously disturbing trend in some languages.
While each line is doing less there's an awful lot more of them.  I
guess this is another good example of apparent simplicity with real
complexity.

-- 
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: new fn: juxt - Theory application